I mentioned last week that I was planning to look closer at InfluxDB this past weekend, and some folks asked me to do a writeup on my findings.
InfluxDB is a time-series metrics and events database based on the LevelDB key-value store. LevelDB was written and open sourced by Google, and is an optional backend for Riak. InfluxDB (or "Influx", for short) inherits many of LevelDB's default characteristics, which means it's optimized for writes and uses compression by default, but it can be slow for reads and deletes.
Influx was only recently released as an open source project under the MIT license by the team over at Errplane. Its authors are transparent about their goals and roadmap, publishing them on the project website.
Getting started with Influx is easy enough. They provide a free online sandbox where you can create a user account and database, then immediately begin writing metrics via their administration UI. You can also start sending metrics remotely, which is simple enough with curl and a bit of JSON.
$ for i in `seq 100`; do \
> curl -X POST "http://sandbox.influxdb.org:9061/db/foobar/series?u=foo&p=bar" \
> -d "[{\"name\":\"data\",\"columns\":[\"foo\",\"bar\"], \
> \"points\":[[$((RANDOM%200+100)),$((RANDOM%300+50))]]}]"; \
> sleep 1; \
> done
From there you can run queries and visualize your metrics within the same interface.
I don't care for their choice of accepting credentials via URL parameters, but it looks like they agree and intend to support HTTP Basic Auth soon. Otherwise, their HTTP API is largely param-driven, making it straightforward and easy to use, and is capable of sending chunked or non-chunked responses.
Influx accepts queries via an SQL-like query language, so if you're comfortable with traditional relational databases, you should feel right at home. It already supports filtering using where clauses, in addition to aggregates using group by, merge and join. There are a handful of mathematical functions (min, max, mean, mode, median, and percentile), making it suitable for routine analytics tasks.
They plan to add a feature called continuous queries, which will allow users to "precompute expensive queries into another time series in real-time". At face value this sounds very much like Graphite's carbon-aggregator. However, because you would have the entire query language at your disposal, it has the potential to be much more powerful.
There remain some questions around its potential to scale, as well as general benchmarks. Paul Dix, the founder of Errplane and apparent Influx project lead, says that both clustering and benchmarks are expected to be released in December. A work-in-progress GitHub pull-request is open for tracking the ongoing clustering work. Paul has given some anecdotal numbers of "20k-70k points per second" in the project mailing list.
Language bindings already exist for Javascript (front-end), Ruby, Python and Node.js. Personally, I found that interacting directly with the HTTP API was already simple enough, and managed to add backend support for InfluxDB to Tasseo within a couple hours. It would be nice to see a more efficient binary wire protocol for submitting metrics, and it seems the authors agree, but only time will tell if that happens.
As someone who loves metrics, there's a lot to like about InfluxDB. It's easy to get started with, there are no external service/component dependencies, and submitting and querying metrics are a breeze. Because Errplane already uses Influx in production (or something based on it), I think it's safe to assume that innovation will continue at a healthy pace.
However, there remain some very important gaps in functionality, particularly in the areas of scaling and high availability, complex and/or user-defined functions, and a more robust graphing / discovery UI. And yet, I think many of us want Influx to succeed, if only because scaling tools such as Graphite can be such a challenge. The next couple of months should reveal whether InfluxDB is the scalable time-series project that many of us believe it can be, or whether it falls by the wayside as an orphaned fork of the Errplane engine.