CEO and developer of InfluxDB. The next version of InfluxDB (0.9.5) will have a new storage engine. Thanks to this engine, we will be able to efficiently store either the data of one event or regularly recurring series. those. irregular and regular time series.
InfluxDB supports int64, float64, bool and string data types, using different compression schemes for each of them. Prometheus only supports float64.
For compression, version 0.9.5 will have compression compatible with Prometheus. In some cases, we will see better results, because we change the compression at timestamps based on what we see. The best random scenario is a regular series counted at exact intervals. In cases where by default we can compress timestamps of 1k points as an 8-byte start time, delta (zigzag encoded) and counter (also zigzag encoded).
Depending on the form of data that we saw, 2.5 bytes per point on average after lumps.
YMMV based on timestamps, data type and data form. For example, random floats with nanosecond timestamps with large variable deltas will be the worst.
Variable accuracy in timestamps is another feature InfluxDB has. It can be a second, millisecond, microsecond or nanosecond scale. Prometheus is fixed in milliseconds.
Another difference is that the entries in InfluxDB are strong after the client sends a success response. Prometheus buffers are written to memory and, by default, erased every 5 minutes, which opens a window of potential data loss.
Our hope is that after the release of 0.9.5 InfluxDB, it will be a good choice for Prometheus users to use as a long-term metrics repository (with Prometheus). I'm pretty sure that support is already in Prometheus, but until release 0.9.5 drops, it can be a little rocky. Obviously, we will have to work together and do a bunch of testing, but this is what I hope for.
If single servers were swallowed, I would expect Prometheus to have better performance (although we did not test here and did not have a number) because of their more limited data model and because they do not add disk writes before they are written from the index .
The query language between them is very different. I'm not sure that they support what we have not yet or vice versa, so you will need to delve into the documents on both to see if there is something you can do that you need. In the long run, our goal is for InfluxDB query functionality to be a superset of Graphite, RRD, Prometheus, and other time series solutions. I say supernets because we want to cover them later in addition to more analytic functions. Obviously, it will take us a while to get there.
Finally, the longer-term goal of InfluxDB is to maintain high availability and horizontal scalability through clustering. The current clustering implementation is not yet complete and is only in alpha. However, we are working on this, and this is the main goal of the project for the project. Our clustering structure is that the data is ultimately consistent.
As far as I know, Prometheus' approach is to use double-entry for HA (so there is no guarantee of consistency) and use federation for horizontal scalability. I'm not sure how the request to federated servers will work.
Inside an InfluxDB cluster, you can request server boundaries without copying all the data over the network. This is because each request is split into a MapReduce job, which runs on the fly.
Probably more, but this is what I can think of at the moment.