Hacker News Reader

Comment by pauldix | Hacker News Reader

Have a look at this release. The write performance is massively better than it was. We did tests writing up to 100B points against a single server.

The next release will focus on improving query performance, but this one still works for many cases.

View on HN

"Massively better" doesn't mean deployable to production either. Especially not if you've only tested with a single point of failure with a single sized payload. But I'm willing to give it a third (and final) trial:

1) Does "DELETE * FROM foo" still cause the system to lockup, freeze, and require a restart to free memory? Or are there other conditions/queries that cause the system to become unstable?

2) There's no README/CHANGELOG/dependencies info on the download page. Which is the preferred version of Go to install on my servers for Influxdb - 1.4 or 1.5?

I'd guess go version doesn't matter, you should install the binary which is statically linked, no?

Massive performance improvements like that tend to come down to overall changes in the data structure and/or algorithm. This is like, "oh yeah, maybe we should do LSM?" or "maybe compressed bitmaps?" kind of stuff. What what the magic?

New storage engine.

Introduction from last October: https://influxdata.com/blog/new-storage-engine-time-structur...

Oh right, I remember when that blog post came out. It was amusing because I'd built an in-house metric store much like InfluxDB (using a LevelDB engine), and reached much the same inflection point and decision. I so should have open sourced that so you poor saps didn't have to experience my pain.

What is the query performance like today? And, what are your goals for query performance after the next release?

Reply on news.ycombinator.com