4 ms·

(TimescaleDB engineer here). This is a really unfair critique. The project you cite is super-optimized for the Prometheus use-case and data model. TimescaleDB

by cevian 6y ago

(TimescaleDB engineer here). This is a really unfair critique. The project you cite is super-optimized for the Prometheus use-case and data model. TimescaleDB beats InfluxDB on performance even without these optimization. It's also not possible to optimize in this way in most other time-series databases. These scripts also work hard to give users a UIUX experience that mimicks PromQL in a lot of ways. This isn't necessary for most projects and is a very specialized use-case. That takes up a lot of the 2000 lines you are talking about.

R0b0t1 6y ago
>The project you cite is super-optimized for the Prometheus use-case and data model. That may be true, but: Instead of figuring out how to meet the user's needs you're going to say the user is wrong?
- NicoJuicy 6y ago
  That's not what he said and is kinda rude to be honest. What I consider to be said is that they optimize for extendability ( not just one use-case) and that those 2000 lines do a lot of things. Including replicating optimizations that are are not easy to achieve out of the box in their and other solutions. But they mostly found a way ;)
  - R0b0t1 6y ago
    It's about as rude as telling someone their criticism is misplaced in that way. You've added more words to why you believe that, but that doesn't change the original sentiment. You can say you don't want to support that usecase but someone inquired about whether you would. You said no, they're wrong to compare the two. Sounds a lot like "you're holding it wrong."
aeyes 6y ago
> TimescaleDB beats InfluxDB on performance even without these optimization Would you mind sharing the schema used for this comparison? Maybe I missed it in your documentation of use-cases. When implementing dynamic tags in my own model, my tests showed that your approach is very necessary.
- cevian 6y ago
  You can look at what we use in our benchmarking tool https://github.com/timescale/tsbs https://github.com/timescale/tsbs (results described here https://blog.timescale.com/blog/timescaledb-vs-influxdb-for-time-series-data-timescale-influx-sql-nosql-36489299877/ https://blog.timescale.com/blog/timescaledb-vs-influxdb-for-...). Pretty much it's a table with time, value, tags_id. Where the tags table is id, jsonb

by cevian 6y ago

R0b0t1 6y ago

>The project you cite is super-optimized for the Prometheus use-case and data model. That may be true, but: Instead of figuring out how to meet the user's needs you're going to say the user is wrong?

NicoJuicy 6y ago
That's not what he said and is kinda rude to be honest. What I consider to be said is that they optimize for extendability ( not just one use-case) and that those 2000 lines do a lot of things. Including replicating optimizations that are are not easy to achieve out of the box in their and other solutions. But they mostly found a way ;)
- R0b0t1 6y ago
  It's about as rude as telling someone their criticism is misplaced in that way. You've added more words to why you believe that, but that doesn't change the original sentiment. You can say you don't want to support that usecase but someone inquired about whether you would. You said no, they're wrong to compare the two. Sounds a lot like "you're holding it wrong."

aeyes 6y ago

> TimescaleDB beats InfluxDB on performance even without these optimization Would you mind sharing the schema used for this comparison? Maybe I missed it in your documentation of use-cases. When implementing dynamic tags in my own model, my tests showed that your approach is very necessary.

cevian 6y ago
You can look at what we use in our benchmarking tool https://github.com/timescale/tsbs https://github.com/timescale/tsbs (results described here https://blog.timescale.com/blog/timescaledb-vs-influxdb-for-time-series-data-timescale-influx-sql-nosql-36489299877/ https://blog.timescale.com/blog/timescaledb-vs-influxdb-for-...). Pretty much it's a table with time, value, tags_id. Where the tags table is id, jsonb