While talking about InfluxDB people should not forget about their beta release of clustering to attract more users and then making it just enterprise. And no, it's not an argument that this is the only way to get paid in open source. Users should be careful while adopting InfluxDB as Influxdata does not clearly elaborate their plans on the product.
Yeah, that's kinda a dick move. I was waiting for 1.0 before giving it another real go (after their decision to rewrite everything for 0.9). Looks like I'll be checking out something else now, maybe Prometheus[1] or DalmatinerDB[2] will fit the bill. 1. https://prometheus.io/ 2. https://dalmatiner.io/
InfluxDB 1.0 GA Released: A Retrospective and What’s Next
71–80 of 83 posts
Re: InfluxDB 1.0 GA Released: A Retrospective and What’s Next
#72While talking about InfluxDB people should not forget about their beta release of clustering to attract more users and then making it just enterprise. And no, it's not an argument that this is the only way to get paid in open source. Users should be careful while adopting InfluxDB as Influxdata does not clearly elaborate their plans on the product.
Re: InfluxDB 1.0 GA Released: A Retrospective and What’s Next
#73Earlier quoted context omitted.
This is becoming problematic across the open source DB world. Witness the graph capabilities of Datastax Enterprise on top of Cassandra, and Riak TS also took quite a while to open source the "TS" version, hoping I guess to monetize without having to open source. This makes me worried about adopting in case I later get gotcha'd. I am really looking forward to a truly open source time series database. It's not that I…
What is KX KDB?
Extensively used in capital markets.
Re: InfluxDB 1.0 GA Released: A Retrospective and What’s Next
#74Earlier quoted context omitted.
We dropped InfluxDB after they introduced their enterprise version. Currently, we are running several nodes of Riemann/Cyanite/Cassandra. It works very well, integration is pretty straight forward.
That stack would perform even better if you swapped ScyllaDB for Cassandra.
I wanted to use this for a while. Can we consider it 100% compatible and can be used as a drop-in replacement?
Re: InfluxDB 1.0 GA Released: A Retrospective and What’s Next
#75Earlier quoted context omitted.
Agreed, them providing .debs is far from "packaging being a mess". I'm quite happy that they provided .debs, worked with them to make some changes to the debs via pull-requests, and after that have been super happy with the packaging. I grab and import their packages into my own private repo for historic reasons, but it does mean I have to chase upstream changes. Personally, I think this is a straw-man argument. With…
> Agreed, them providing .debs is far from "packaging being a mess". I'm quite happy that they provided .debs, worked with them to make some changes to the debs via pull-requests, and after that have been super happy with the packaging. Clearly you haven't checked how they build their DEBs and RPMs. Some opaque, overcomplicated script that eventually calls fpm instead of proper debianization or spec file for RPM. Thi…
Re: InfluxDB 1.0 GA Released: A Retrospective and What’s Next
#76Earlier quoted context omitted.
That stack would perform even better if you swapped ScyllaDB for Cassandra.
Do you have production experience with ScyllaDB? I wanted to use this for a while. Can we consider it 100% compatible and can be used as a drop-in replacement?
For the most part it's compatible with Cassandra out-of-the-box, i.e. many well-known frameworks that run on top of Cassandra "just work". The main thing it's missing is support for Lightweight Transactions (scheduled for the 2.0 release).
The dev team behind ScyllaDB is rock solid, very competent.
Re: InfluxDB 1.0 GA Released: A Retrospective and What’s Next
#77Earlier quoted context omitted.
> Agreed, them providing .debs is far from "packaging being a mess". I'm quite happy that they provided .debs, worked with them to make some changes to the debs via pull-requests, and after that have been super happy with the packaging. Clearly you haven't checked how they build their DEBs and RPMs. Some opaque, overcomplicated script that eventually calls fpm instead of proper debianization or spec file for RPM. Thi…
You can't rebuild a server from backups? No snark, just wondering what I'm missing.
Second, restoring from backup limits how you can rebuild a server to just one rigid way. You can't bring another already running server to what you have elsewhere.
Re: InfluxDB 1.0 GA Released: A Retrospective and What’s Next
#78Earlier quoted context omitted.
> Seems everyone has opinions on packaging and you know what it's like when everyone has opinions, right? :) Don't try to push this into opinion realm, because it's not, it's a standards realm. Your package doesn't stand lintian test, and it's not a doesn't-really-matter type of errors that there's no README or license file. You don't even put an initscript in packages in a proper way. It wouldn't matter that much, b…
dozzie, do you have a PR or issue open where you could help guide us to a good resolution?
Re: InfluxDB 1.0 GA Released: A Retrospective and What’s Next
#79Influx is absolutely amazing. We're using it along with grafana to store and display our desktop and web apps' analytics (it completely replaced GA), store and display HTTP health analytics (piping custom uwsgi request logger into UDP input), and do continuous analysis of Hearthstone games. It's incredibly fast and the grafana/influx/telegraf stack is really cool to play with. Highly recommended.
Re: InfluxDB 1.0 GA Released: A Retrospective and What’s Next
#80Earlier quoted context omitted.
This is becoming problematic across the open source DB world. Witness the graph capabilities of Datastax Enterprise on top of Cassandra, and Riak TS also took quite a while to open source the "TS" version, hoping I guess to monetize without having to open source. This makes me worried about adopting in case I later get gotcha'd. I am really looking forward to a truly open source time series database. It's not that I…
Why does the open sources world struggle with timeseries / tick databases so much? I'm a very big KDB fan, but I thought there would be some competition from the open source people at some point, but it seems like every attempt fails. KDB does so well because of its simplicity. Can the OS people not do simple (this is a possible argument), or is it that, as you point out, whenever something is about to be released in…