8 ms·
InfluxDB v0.10 GA with hundreds of thousands writes/sec, 98% better compression
- bfrog 11y agoBeen using 0.9 for a few months now and been pretty happy with it. Though I'm not really looking forward to figuring out how to move from telegraf 0.2 to 0.10, since that had some breaking changes. 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'd use it.
- kev009 11y agoBe _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. Looking at less than a month of issues: * https://github.com/influxdata/influxdb/issues/5440 https://github.com/influxdata/influxdb/issues/5440 * https://github.com/influxdata/influxdb/issues/5482 https://github.com/influxdata/influxdb/issues/5482 * https://github.com/influxdata/influxdb/issues/5534 https://github.com/influxdata/influxdb/issues/5534 * https://github.com/influxdata/influxdb/issues/5540 https://github.com/influxdata/influxdb/issues/5540 If you need something that won't fall over, it's not glamorous and a bear to setup, but OpenTSDB will sail with massive load once you've gotten it running.
- pauldix 11y agoNot sure what issues you're seeing, but we have people running this in production at significant scale. One of the issues you linked to was for 0.9.6. Others were there because they had super high tag cardinality and not enough memory to actually run. When people post comments like "I have 50 million series and it crashes on my box with 2GB of memory!!!", they're not relevant. You shouldn't expect miracles...
- cantbackup 11y agoHow about issues like these? https://github.com/influxdata/influxdb/issues?utf8=&q=is%3Aopen+label%3Apanic+backup https://github.com/influxdata/influxdb/issues?utf8=&q=is%3Ao... In my case I had a 0.9.4 influxdb setup fed by statsd for about a week. The server hard crashed the first time I tried to back it up.
- pauldix 11y agoWe just have to close those out. Those are all fixed in the release we have today.
- kev009 11y agoNo, and you're countering rhetoric with rhetoric so here are the specs: bare metal 96G RAM, 16 cores, 36 disks (also tried 36 SSDs). Nothing exotic, and something similar you should be using to test before releasing another ill-fated storage engine based on "It works on my Macbook Pro with an artificial load test, ship it!". On the same box carbon is usable, and TSDB can scale linearly across a cluster of these machines. Influx burns down as soon as more than a few GB of metrics are persisted even after backing off collection.
- pauldix 11y agoI'm not quite sure what you're doing. If you have that level of hardware I don't know why you're running out of memory. Our tests with 100B points split across 1M series ran on much more modest hardware than that and didn't have a problem. There's something different with what you're doing than with what we're testing. If you can give more detail about what your actual data looks like, I may be able to help. Are you doing this on v0.10 (beta1 or greater) and you're seeing this problem?
- kev009 11y agoI don't have a lot of time to spare on this and we've found a viable option so I won't be using influx any time soon. I can help you with access to my production system if you are interested and as you are watching arrange for between 1k and 10k hosts (for 2 - 20 values per second)
- CSDude 11y agoI 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.
- thecourier 11y agocan you efficiently store logs in InfluxDB? would love to read if somebody have tried that before... (just wondering)
- lobster_johnson 11y agoInfluxDB is optimized for storing samples. I don't know for sure about 0.9+, but I can't imagine the architecture has improved to the point where it would be happy about storing large amounts of text data.
- pstuart 11y agoPerhaps if the logs used logfmt with a parser as an intermediary.
- piran 11y agoWe store some logs at a small scale (5k/s) and queries are fine 0.9.5. You just have to be smart how you do tags still. Hopefully 0.10 is the same.
- illumen 11y agoBut does it work? It wins the most buggy database servers I've ever used in 20 years award. Is writing less than 20MB/sec of data something to brag about?
- sytse 11y agoWe're using it with GitLab.com and we like it. 0.9 didn't work at all due to the volume but with 0.10 everything is functioning OK
- fweespeech 11y agoA full cluster or a single node?
- YorickPeterse 11y agoWe currently run InfluxDB 0.10.0-nightly-614a37c (I have yet to upgrade it to the stable release) on a single DigitalOcean instance with 8GB of RAM with 30-something GB of storage. The previous stable release (0.9 something) didn't fare very well, even after we significantly reduced the amount of data we were sending (we were sending a lot of data we didn't really need). Switching to 0.10.0-nightly-614a37c in combination with switching to the TSM engine resulted in a very stable InfluxDB instance. So far my only gripe has been that some queries can get pretty slow (e.g. counting a value in a large measurement can take ages) but work is being done on improving the query engine (https://github.com/influxdb/influxdb/pull/5196 https://github.com/influxdb/influxdb/pull/5196). To give you an idea of the data: * Our default retention policy is currently 30 days * 24 measurements, 11975 series. Our largest measurement (which tracks the number of Rails/Rack requests) has a total of 28 539 279 points * Roughly 2.3 out of the 8 GB of RAM is being used * Roughly 4 GB of data is stored on disk This whole setup is used to monitor GitLab.com as well as aid in making things faster (see https://gitlab.com/gitlab-com/operations/issues/42 https://gitlab.com/gitlab-com/operations/issues/42 for more info on the ongoing work).
- fweespeech 11y ago
- SkyRocknRoll 11y agoWe 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. Keep Rocking !!
- Shish2k 11y agoI wonder what sort of data you're storing with that reduction? I'm using it as a drop-in replacement for Graphite (with Grafana as a front-end, loving both BTW) and just had disk space reduced from 140GB to 250MB :D
- ddorian43 11y agoThey did the mongodb approach. Build a shitty db and then build a normal one and claim 100X faster. And then add synchronized disk commits (like postgresql has always done) and performance goes puff (meaning lower than pg) (example: elasticsearch, mongodb).
- pauldix 11y agofsyncs happen on every write. They're durable. This release may be 100x faster than our previous release, but it's also a competitor with other solutions. We haven't run any comparisons vs. other solutions, but we will do that soon and I expect that we'll be competitive and better in some cases.
- CyrusL 11y agoVery tasteful way to handle the parent comment :) Does Todd Persen talk about durability testing in the video or is more about performance benchmarking? I haven't watched yet. https://vimeo.com/153802549 https://vimeo.com/153802549
- pauldix 11y agoThanks :). He talks about doing kill nines on the process while doing a bunch of writes, trying to corrupt the DB, and perf testing. In addition to a little bit of talk about what came before and some lessons learned.
- SEJeff 11y agoHave you had a chance to throw Influx through the paces of Kyle Kingsbury's Jepsen distributed data store tester?
- pauldix 11y agoNot yet, but it's on our TODO list. However, we have to finish the clustering implementation before we bother going through that testing. At this point we're telling people it's experimental and not meant for production use.
- zenlikethat 11y agoI have been forwarding Riemann metrics to it and visualizing with Grafana, pretty fun so far. Love that it's written in Go and fairly lightweight on resources compared to JVM-based technologies.
- effenponderousa 11y agoI have nothing to do with influx and I probably won't in the future. There are way too many haters in HN. You venomous minority who shit on every bit of good news that isn't yours -- keep your negativity to yourself. You fucking monkeys infected with rage.
- donatj 11y agoOn the one hand I agree with your sentiments, on the other hand I disagree with your approach.
- la6470 11y agoLooks like all the hordes of oldies from slashdot is now coming to HN
- dang 11y agoIt's true that there's too much negativity on HN, but it's also true that people contribute to it without meaning to. Your comment kind of demonstrates that. On the other hand, your use of the word 'minority' there was both astute and thoughtful.
- la6470 11y agoI don't like the fact that old data will continue to use the old engine after the upgrade.
- jmcgough 11y agoThere's a migration script that can be used for moving old data to the tsm engine.
- XorNot 11y agoIs 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.
- pauldix 11y agoWe don't have the TCP listener wired up yet, but it's on the roadmap. Thanks for bringing it up, I'll try to get it prioritized for sometime in the next few months.
- kyloon 11y agoI 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.
- pauldix 11y agoThe new query engine work should get merged into master early next week. You'll be able to test against a nightly build then to see what kind of performance improvement will be part of 0.11. What kinds of queries are you seeing poor performance with? That would help us troubleshoot and improve, thanks.
- kyloon 11y agoThanks for the update. Most of the queries I am testing now are 'mean' and 'group by' aggregation for downsampling and visualization in Grafana. Looks like the problem is CPU bound as I see all 8 cores got maxed out when processing the queries. Currently there are about 50 series and 5B data points in total.
- stock_toaster 11y agoI would love to see some good (and up to date) documentation on replacing graphite with influxdb (retention, rollups, etc). 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.
- eklavya 11y agoA lot of comments have mentioned Time Series use. How does it compare to Cassandra?
- chaotic-good 11y agoIt 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. AFAIK you're using float64 compression scheme from "Gorilla" paper. 2.2 bytes per data point is possible with it but only on data that doesn'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.
- Dylan16807 11y agoHonestly if you have a series of increasing unix timestamps you should be able to do much better than 2.2 bytes each.
- chaotic-good 11y agoEven simple delta+RLE can squeeze increasing unix timestamps up to few bytes. I'm talking about floating point data compression. Even the specialized state of the art algorithms can't guarantee you 2.2 bytes per float in general.
- AYBABTME 11y agoI don't get all the hate. Reading the comments here yesterday and then today again, made me really question what's going on in this community. They (InfluxDB) made huge progress, they work hard on an open source DB (and ecosystem) and people insult them and question Paul Dix's >30 minute response time to your support questions in a HN thread.