13 ms·
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 re
by pauldix 11y ago
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.
- cbsmith 11y agoMassive 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?
- CyrusL 11y agoNew storage engine. Introduction from last October: https://influxdata.com/blog/new-storage-engine-time-structured-merge-tree/ https://influxdata.com/blog/new-storage-engine-time-structur...
- cbsmith 11y agoOh 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.
- dbettin 11y agoWhat is the query performance like today? And, what are your goals for query performance after the next release?
- officialchicken 11y ago"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?
- jtblin 11y agoI'd guess go version doesn't matter, you should install the binary which is statically linked, no?