21–30 of 71 posts
Had me until claiming that InfluxDB was the first mainstream TSDB in 2013 . OpenTSDB (2010)? Graphite (2008)? RRDtool (1999)? Maybe Influx took off in a way these prior projects didn't, but people have been storing time series data for decades.
The author calls out InfluxDB as the first time series database. Why would that not have been rrdtool or something earlier?
I'm using VictoriaMetrics (VM) to store basic weather data, like temperature and humidity. My initial setup was based on Prometheus however it seemed very hard to set a high data retention value, default was something like 15 days if I recall correctly. Since I would actually like to store all recorded values permanently, I could partially achieve this with VM which let me set a higher threshold, like 100 years. Stil…
Mimir [1] is what we use where I work. We are very happy with it, and we have very long retention. Previously, our Prometheus setup was extremely slow if you went past today, but Mimir partitions the data to make it extremely fast to query even long time periods. We also used Thanos for a while, but Mimir apparently worked better. [1] https://grafana.com/oss/mimir/
To be fair many projects in Prometheus "long term store" space come and gone - Thanos, Cortex, M3
InfluxDB is open source ( https://github.com/influxdata ) and seems to be leader by far as per DBEngines ranking : https://db-engines.com/en/ranking/time+series+dbms
I’ve personally found TimescaleDB to be a much easier to work with platform, even if there is more overhead in defining a schema and enabling compression, etc.
Why would you use this instead of CH if your usecase is metrics?
How do these stack up to https://www.timescale.com/ ?
Broadly speaking I can say I'd trust TSDB over Influx for a lot of cases since it's using Postgres under the hood, and while I don't know precisely what issues we had adopting Influx, I know we had some as we 'scaled up' tho and that was when stuff like tag limits were brought up a lot (Interestingly, our app was 'barely passing' because we metric'd a lot but we also kept stuff just short enough for everyone to be OK with it, mostly because the metrics we got were very useful for things)
This is unsurprisingly a VictoriaMetrics post that frames the history in a narrow way to talk favorably about VictoriaMetrics.
I remember when a bunch of WSO2 contribs broke off, made their own (AGPL) ESB, and created a 'ESB Performance' website that cherry picked specific scenarios to make WSO2 look worse than their product.
This was made funnier because the 'consultant' (really a buddy of management that used us as an experiment for all sorts of things, at least the code was readable, learned lots of languages fixing things lol) wound up having us go with the AGPL product, and it wasn't until I said to the team 'hey, lets try using the WSO2 docs as a cross reference' before we got productive.
I do miss the 'dramatic readings' of UltraESB docs, learned a colleague understood Pashto [0].
[0] - After a specific 'verse', the colleague pointed out one of the odd phrases in the docs that prompted this practice, was a colloquialism in that language.