Go Share your TimeSeries|NameSpace KeyVal (with leveldb powers) over HTTP|ZeroMQ

Go Share

is a time-machine written for state of any key-factor across a time-frame

just supports key:val data-point reference (also name-space, and w/o timestamp as well)

the main cog of this machine is "leveldb" and is written in "GoLang"

this is the engine to power bigger vehicles like MomentDB

__ ____ _____ _____/ /_ ____ _________ / __ `/ __ \ / ___/ __ \/ __ `/ ___/ _ \ / /_/ / /_/ / (__ ) / / / /_/ / / / __/ \__, /\____/ /____/_/ /_/\__,_/_/ \___/ /____/

What's the idea?

A TimeSeries DataStore i.e. a data store built especially for the need of key-value transactions within a time-frame. Particular use-case of tracking change of state for a particular factor over a period of time.

Why build one?

The requirement for FOSS datastore was to be

built for timeseries (not a common store with forced schema for it)

standalone (simple to install/manage)

fast (for data transaction)

So it's easy to set-up and quick to dump data over. Most of the alternatives out there are either based off other components to be managed (also increasing up the hops, resource requirements, and more), some are commercial and some both.

Other popular datastores built specifically for time-series data are:

InfluxDB, looks good ...gotta checkout

Cube, uses MongoDB as backend ...uhhoh

GoCircuit Vena, think it requires ZooKeeper ...will have to see

OpenTSDB, defers to Hadoop's HBASE ...handle that

KairosDB, like OpenTSDB with Cassandra as base ...again

Tempo-DB looks good, but Commercial

IBM Informix & Microsoft StreamInsight been mentioned at places mainly for CEP, Commerical ...whatever MS|IBM

Go Share any data among the nodes. Over HTTP or ZeroMQ.

GOShare eases up communication over HTTP GET param based interaction.

ZeroMQ REQ/REP based quick synchronous communication model.

it's "go get"-able