4 ms·

Super excited about this. Congratulations on the release! I've seen Prometheus bash a little on InfluxDB regarding storage requirements [1]. Is this something

Super excited about this. Congratulations on the release! I've seen Prometheus bash a little on InfluxDB regarding storage requirements [1]. Is this something that has been addressed? Is it even something worth worrying about? 1. http://prometheus.io/docs/introduction/comparison/#data-model-storage http://prometheus.io/docs/introduction/comparison/#data-mode...

pauldix 11y ago
We will be starting work on a new storage engine or an optimized version of what we have now that will add compression. Tentatively, that will start in the 0.9.3 release cycle. First rule of software: make it work, then make it efficient
- misframer 11y ago
  I hope you guys collaborate with the RocksDB team. Column families [0] seem like a great fit for time series. [0] https://github.com/facebook/rocksdb/wiki/Column-Families https://github.com/facebook/rocksdb/wiki/Column-Families
jrv 11y ago
Last I checked that still held true. Here's a more up-to-date version of those benchmarks: https://groups.google.com/forum/#!searchin/influxdb/prometheus/influxdb/qxgtzbmCNcY/HqZJllJAWB4J https://groups.google.com/forum/#!searchin/influxdb/promethe... For Prometheus's long-term storage I'd basically like to have something like InfluxDB (Go, simple to operate, distributed storage), but better suited towards purely numeric time series rather than arbitrary log records. Unfortunately as it stands, InfluxDB takes roughly 14x more disk space for exactly the same data (without replication) for a typical Prometheus use case. I hope that improves in the future, but InfluxDB's use case is also different: they enable you to store arbitrary key=value metadata with every single record, rather than defining a time series once and then only appending numeric samples. So the comparison is not really fair, it's just maybe not the right tool for Prometheus-style monitoring.

pauldix 11y ago

We will be starting work on a new storage engine or an optimized version of what we have now that will add compression. Tentatively, that will start in the 0.9.3 release cycle. First rule of software: make it work, then make it efficient

misframer 11y ago
I hope you guys collaborate with the RocksDB team. Column families [0] seem like a great fit for time series. [0] https://github.com/facebook/rocksdb/wiki/Column-Families https://github.com/facebook/rocksdb/wiki/Column-Families

jrv 11y ago

Last I checked that still held true. Here's a more up-to-date version of those benchmarks: https://groups.google.com/forum/#!searchin/influxdb/prometheus/influxdb/qxgtzbmCNcY/HqZJllJAWB4J https://groups.google.com/forum/#!searchin/influxdb/promethe... For Prometheus's long-term storage I'd basically like to have something like InfluxDB (Go, simple to operate, distributed storage), but better suited towards purely numeric time series rather than arbitrary log records. Unfortunately as it stands, InfluxDB takes roughly 14x more disk space for exactly the same data (without replication) for a typical Prometheus use case. I hope that improves in the future, but InfluxDB's use case is also different: they enable you to store arbitrary key=value metadata with every single record, rather than defining a time series once and then only appending numeric samples. So the comparison is not really fair, it's just maybe not the right tool for Prometheus-style monitoring.