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.
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…
InfluxDB 1.0 GA Released: A Retrospective and What’s Next
61–70 of 83 posts
Re: InfluxDB 1.0 GA Released: A Retrospective and What’s Next
#62Earlier quoted context omitted.
It's worth noting that Prometheus isn't distributed either. So OSS InfluxDB or that are the same in terms of distributed capabilities.
Prometheus can be scaled with sharding and there are different solutions coming out to address this, like a proxy layer for queries. See the PromCon 2016 videos for latest news on this.
Re: InfluxDB 1.0 GA Released: A Retrospective and What’s Next
#63Re: InfluxDB 1.0 GA Released: A Retrospective and What’s Next
#64Earlier quoted context omitted.
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/
It's worth noting that Prometheus isn't distributed either. So OSS InfluxDB or that are the same in terms of distributed capabilities.
Most importantly, Prometheus will never decide to exclude a feature for commercial reasons. As it's a 100% open-source and independent project not controlled by any single company, we don't have those kinds of incentives. We just want to build the best monitoring system. Note that we still say "no" to a lot of features, but that's only for technical reasons, to avoid bloat, or to keep the project maintainable.
Re: InfluxDB 1.0 GA Released: A Retrospective and What’s Next
#65Earlier 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…
Relational databases are treated like they can store any kind of data, and for small data sets, it really doesn't matter if your data-model does not fit the relational type.
Once you have a larger data set, you're no longer a general purpose user.
Re: InfluxDB 1.0 GA Released: A Retrospective and What’s Next
#66Wins:
* The new storage engine is very, very cool. Would love to work on this thing. It's fast and space efficient.
* Built in support for time bucketing GROUP's
* Grafana integration is pretty good
* Writes come back after the data is stored; makes it easy to create durable, idempotent processing pipelines.
Woahs
* Unable to combine measurements in the same query; needs ETL with continuous queries or external tools
* No support for subqueries; more ETL
* Stream processing is a little lacking -> can't group on values and high cardinality tags make the DB explode; high cardinality is being worked on but IDK how high it will go, plus I mean the storage engine serves up streams of time-sorted data so samza that stuff up.
* Random crashes but the DB gets along fine when it comes back up
* Compactions use LOTS of RAM. Supposedly this can be tweaked and has been improved for 1.0
* Backfill queries with lots of points seem to use a crazy amount of RAM when bucketing on narrow time windows
Overall it's chugging along quite well. Most of the query limitations we are able to solve with a combination of continuous queries and AWS lambda functions kicked off by CloudWatch Events.
Re: InfluxDB 1.0 GA Released: A Retrospective and What’s Next
#67Wins:
* The new storage engine is very, very cool. Would love to work on this thing. It's fast and space efficient.
* Built in support for time bucketing GROUP's
* Grafana integration is pretty good
* Writes come back after the data is stored; makes it easy to create durable, idempotent processing pipelines.
Woahs
* Unable to combine measurements in the same query; needs ETL with continuous queries or external tools
* No support for subqueries; more ETL
* Stream processing is a little lacking -> can't group on values and high cardinality tags make the DB explode; high cardinality is being worked on but IDK how high it will go, plus I mean the storage engine serves up streams of time-sorted data so samza that stuff up.
* Random crashes but the DB gets along fine when it comes back up
* Compactions use LOTS of RAM. Supposedly this can be tweaked and has been improved for 1.0
* Backfill queries with lots of points seem to use a crazy amount of RAM when bucketing on narrow time windows
Overall it's chugging along quite well. Most of the query limitations we are able to solve with a combination of continuous queries and AWS lambda functions kicked off by CloudWatch Events.
Re: InfluxDB 1.0 GA Released: A Retrospective and What’s Next
#68While 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.
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…
Re: InfluxDB 1.0 GA Released: A Retrospective and What’s Next
#69Earlier 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…
All the other OSS TSDBs seem to have very good stories for storing server statistics and web clicks, or IoT data; but there are few stories, case studies, best practices for using these in financial applications?
Re: InfluxDB 1.0 GA Released: A Retrospective and What’s Next
#70Earlier 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…
[0]: https://blog.dataloop.io/top10-open-source-time-series-datab...