InfluxDB v0.10 GA with hundreds of thousands writes/sec, 98% better compression

We are using 0.10 GA in production. We have seen lot of disk space reduction from 22GB to 700MB and performance improvement order of magnitude. Influxdb is the modern timeseries database.<p>Keep Rocking !!

Be _very_ skeptic of this, I wasted weeks trying to get git master versions of this not fall over including tsm1 storage engine. They are very good at marketing and made nice query and API entry, but data storage has been a total shit show.<p>Looking at less than a month of issues:<p>* <a href="https:&#x2F;&#x2F;github.com&#x2F;influxdata&#x2F;influxdb&#x2F;issues&#x2F;5440" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;influxdata&#x2F;influxdb&#x2F;issues&#x2F;5440</a><p>* <a href="https:&#x2F;&#x2F;github.com&#x2F;influxdata&#x2F;influxdb&#x2F;issues&#x2F;5482" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;influxdata&#x2F;influxdb&#x2F;issues&#x2F;5482</a><p>* <a href="https:&#x2F;&#x2F;github.com&#x2F;influxdata&#x2F;influxdb&#x2F;issues&#x2F;5534" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;influxdata&#x2F;influxdb&#x2F;issues&#x2F;5534</a><p>* <a href="https:&#x2F;&#x2F;github.com&#x2F;influxdata&#x2F;influxdb&#x2F;issues&#x2F;5540" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;influxdata&#x2F;influxdb&#x2F;issues&#x2F;5540</a><p>If you need something that won&#x27;t fall over, it&#x27;s not glamorous and a bear to setup, but OpenTSDB will sail with massive load once you&#x27;ve gotten it running.

I have been forwarding Riemann metrics to it and visualizing with Grafana, pretty fun so far. Love that it&#x27;s written in Go and fairly lightweight on resources compared to JVM-based technologies.

I just love the ability to GROUP BY queries, they work so fast and saves me from writing a stupid map-reduce style job for that basic thing. I am building a time series nice analysis product with it and this change would work very fine.

<i>It depends greatly on the shape of your data, but with regularly spaced timestamps at second level precision and float64s, we’ve seen compression reduce each point down to around 2.2 bytes per point.</i><p>AFAIK you&#x27;re using float64 compression scheme from &quot;Gorilla&quot; paper. 2.2 bytes per data point is possible with it but only on data that doesn&#x27;t utilize full double precision (example: small integers converted to float64). You should compare compression algorithm used by TSM storage engine with zlib or any other general purpose compression algorithm, otherwise this number will be meaningless.

I had another go at this new release after failing to get any of the 0.9.x releases to suit my use case of massively high volume writes. Now that I managed to get some of my data in it, aggregation queries seem to be lagging in speed, I would like to know more about what is actually being done currently to improve the query speed rather than waiting out for the v0.11 release as I am deciding whether InfluxDB is the way forward for my use case.

Been using 0.9 for a few months now and been pretty happy with it. Though I&#x27;m not really looking forward to figuring out how to move from telegraf 0.2 to 0.10, since that had some breaking changes.<p>I do love the simplicity of influx+telegraf, kapacitor also looks cool. Chronograf seems like a bad version of grafana still... maybe in the future if its FOSS and somehow manages to be better than grafana I&#x27;d use it.

I don&#x27;t get all the hate. Reading the comments here yesterday and then today again, made me really question what&#x27;s going on in this community.<p>They (InfluxDB) made huge progress, they work hard on an open source DB (and ecosystem) and people insult them and question Paul Dix&#x27;s &gt;30 minute response time to your support questions in a HN thread.

I would love to see some good (and up to date) documentation on replacing graphite with influxdb (retention, rollups, etc).<p>Last time I tried it out I vaguely recall that configuring rollups was kind of painful -- lots of nearly duplicate CS queries, even for a relatively small number of series.

Is the text ingest engine usable with TCP yet? UDP is a bit weird for this when I may care greatly about whether my server is successfully feeding a stream of lines too influxdb.

They did the mongodb approach. Build a shitty db and then build a normal one and claim 100X faster.<p>And then add synchronized disk commits (like postgresql has always done) and performance goes puff (meaning lower than pg) (example: elasticsearch, mongodb).

can you efficiently store logs in InfluxDB? would love to read if somebody have tried that before... (just wondering)

A lot of comments have mentioned Time Series use. How does it compare to Cassandra?

But does it work? It wins the most buggy database servers I&#x27;ve ever used in 20 years award.<p>Is writing less than 20MB&#x2F;sec of data something to brag about?

I don&#x27;t like the fact that old data will continue to use the old engine after the upgrade.

I have nothing to do with influx and I probably won&#x27;t in the future.<p>There are way too many haters in HN. You venomous minority who shit on every bit of good news that isn&#x27;t yours -- keep your negativity to yourself.<p>You fucking monkeys infected with rage.