influxdb

Granted, they don't have a link to the GitHub page on the blog post itself, but it's open source software. https://github.com/influxdata/influxdb/releases

The implication of an MIT license is that anyone can use or sell your work with attribution. If the contributor was not happy with that, or unhappy with getting a free db worked on by other people, they simply wouldn't contribute. Since they did contribute on those terms, we have no reason to think they want to be paid. https://github.com/influxdata/influxdb/blob/master/LICENSE

Yep, we're very focused on solving the cardinality problem now. See these for some details about how we're thinking about it: https://github.com/influxdata/influxdb/pull/7175 https://github.com/influxdata/influxdb/pull/7174 https://github.com/influxdata/influxdb/pull/7186 https://github.com/influxdata/influxdb/pull/7264

InfluxDB CTO here, thanks for the note! We've definitely had significant improvements even over the last two months. And the breaking API changes will be a thing of the past very soon: https://github.com/influxdata/influxdb/blob/master/CHANGELOG... 0.13 drops Thursday and 1.0 is the next release :)

Can you explain further why golang is bad for data stores, do you mean cache in particular? Seems contrary to many of the new datastores that I see being developed: etcd[1] , cockroachdb[2], influxdb[3] just to name a couple that are written in go. [1]https://github.com/coreos/etcd [2]https://github.com/cockroachdb/cockroach [3]https://github.com/influxdata/influxdb

Yes 0.10. There are many manifestations of it, but https://github.com/influxdata/influxdb/issues/4121#issuecomm... is the most recent report. Telling people tsm1 is still broken is not FUD. I have no skin in the game other than wanting people to not have to waste time and end in frustration. In hindsight I would steer toward any other open source or paid product to have my time back investigating InfluxDB when I bought into the marketing thinking it could be made to work.

Yeah, I was a bit disappointed with the upgrade methods for InfluxDB, but I've noticed the leak of the _internal DB https://github.com/influxdata/influxdb/issues/5290. I'll probably upgrade soon. The motivation to put this into an image was that other teams wanted to deploy this and they'll probably end up on the same host so I was looking for isolation of the databases (mainly to protect our team's working dashboard from other fiddlers).

I disappeared because I can't spend all evening responding to every person on the internet that may be having trouble with our software. An offer to SSH into a system that isn't running Influx and trying to troubleshoot some ambiguous problem isn't direct. We have people that have given us useful troubleshooting information that we've helped (and have helped us improve InfluxDB). Constructive criticism with an offer to help us improve is the best. While I'd love to trace down every problem for everyone on the internet, my time on this planet is limited. As for your concerns about if it scales, we'll try to put out more benchmarks and test code over the coming weeks. For reference, we built a tool for stress testing that you can see here: https://github.com/influxdata/influxdb/tree/master/cmd/influ... You'll have to make your own decisions

How about issues like these? 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.

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. Looking at less than a month of issues: * https://github.com/influxdata/influxdb/issues/5440 * https://github.com/influxdata/influxdb/issues/5482 * https://github.com/influxdata/influxdb/issues/5534 * 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.

We 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). To give you an idea of the data: * Our default retention policy is currently 30 days * 24 measurements, 11975 serie