Live data from Hacker News

The Rise of Open Source Time Series Databases

victoriametrics.com

51–60 of 71 posts

Re: The Rise of Open Source Time Series Databases

#51

Earlier quoted context omitted.

The naive relational time series table looks like: propertyid, timestamp, value Then add a covering index so your reads only ever hit the index. This works completely fine for low billions of rows. After that suggest using clickhouse. It is less general but at large enough scale you need to make some tradeoffs. Completely fine to start with a relational DB in many cases though.

Thanks for this. Can we keep going? The article mentioned stock prices, so let's use your schema: LLY.NYSE, 1726377148, 924.38 SHOP.NYSE, 1726377216, 72.45 SHOP.NYSE, 1726377245, 72.41 LLY.NYSE, 1726377284, 924.39 LLY.NYSE, 1726377310, 924.36 Okay, so you're appending values that capture a moment in time for a given index, with the understanding that you're almost never going to revise a tuple. So far as we're concer…

Non-TSDB databases can do an adequate job — up to a certain point. However, getting good performance comes down to query access paths.

For enormous amounts of data, you want your data to be sequential (a few batch reads are generally faster than lots of random ones) and sorted. Databases like Postgres don't store rows in index order, and their indexes are geared towards small fetches as opposed to big ranges of sequential data. (Postgres does have BRIN indexes, but they're not that great for this.) Other databases do support clustered tables, but they're still page-based underneath and still not suboptimal for other reasons. It's a good learning exercise to compare traditional databases with something like ClickHouse, which was s designed from the ground up to store data in this optimized way. (It's a general-purpose OLAP database, so columns can be any kind of data, not just numbers, and data doesn't need to be time-based; so it's useful for much more than "pure" TSDBs.)

As for numbers: For metric data you're storing numeric measurements. The whole point is applying aggregations to the data, like calculating an average or a percentile over a certain time period. Storing numbers also has the advantage of allowing downsampling. For many purposes you don't need 1s granularity for all your data. So as you "roll" data over into old time periods, you can downsample by storing the data points aggregated as mean/min/max/etc. New data can be exact down to the second, while old data can be exact down to the hour, for example.

Re: The Rise of Open Source Time Series Databases

#52
post #44

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.

Also K (1993) and A+ (1988) although the former only became public in 1998 or so, and the latter in 2003 - they were only available inside Morgan Stanley in the beginning IIRC.

I was working in K2 in 1999, and it was public then. This is back when it had the built in GUI and dependency graph. I remember the first time somebody showed it to me, and I didn't think it was very impressive. It took about 2-3 months of messing with it before I realized how very wrong I was.

Re: The Rise of Open Source Time Series Databases

#53
post #48

Earlier quoted context omitted.

Yeah. Would be interested to see how VictoriaMetrics compares to Mimir, not just Prometheus. To be fair many projects in Prometheus "long term store" space come and gone - Thanos, Cortex, M3

Can you elaborate a bit more on the come and gone part?

They're out of tech posters' zeitgeist but AFAIK they are each still maintained and fulfilling people's needs. Just not as much commentary or front-of-mind-share.

Re: The Rise of Open Source Time Series Databases

#54

Earlier quoted context omitted.

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/

Yeah. Would be interested to see how VictoriaMetrics compares to Mimir, not just Prometheus. To be fair many projects in Prometheus "long term store" space come and gone - Thanos, Cortex, M3

Thanos is well alive and kicking, actually used in some of the biggest infrastructure setups in the world such as Shopify and Cloudflare.

Re: The Rise of Open Source Time Series Databases

#55

Earlier quoted context omitted.

The naive relational time series table looks like: propertyid, timestamp, value Then add a covering index so your reads only ever hit the index. This works completely fine for low billions of rows. After that suggest using clickhouse. It is less general but at large enough scale you need to make some tradeoffs. Completely fine to start with a relational DB in many cases though.

Thanks for this. Can we keep going? The article mentioned stock prices, so let's use your schema: LLY.NYSE, 1726377148, 924.38 SHOP.NYSE, 1726377216, 72.45 SHOP.NYSE, 1726377245, 72.41 LLY.NYSE, 1726377284, 924.39 LLY.NYSE, 1726377310, 924.36 Okay, so you're appending values that capture a moment in time for a given index, with the understanding that you're almost never going to revise a tuple. So far as we're concer…

> That said, I'm still significantly confused why the hell you can only store numeric values. It just seems like a very arbitrary constraint.

"In mathematics, a time series is a series of data points indexed (or listed or graphed) in time order."

A a numeric datapoint is by far the largest use case, timeseries databases optimize for that. Most allow you to have several labels ofcourse, i.e. you could store country border crossings as

{from: US,to:Canada} 1726377148, 2123 {from: US,to:Mexico} 1726377148, 34567

Re: The Rise of Open Source Time Series Databases

#56
My biggest beef with VictoriaMetrics is I can't delete and re-ingest a range of data. i.e. if I discover yesterdays data was messed up due to some issue in downstream data processing, I can't delete yesterdays data and re-ingest the cleaned up data. (Or even just delete yesterdays bad data)

The only workaround I've found so far is to dump out the whole timeseries which could go back months/years, delete the timeseries, fix/delete data in the dump and re-ingest the whole thing. This really, really sucks.

Re: The Rise of Open Source Time Series Databases

#57

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.

I think While OpenTSDB was reasonably general purpose, Graphite and RRDTools were done for very specific monitoring use cases.

RRDTool was the generalised version of the TSDB that was born for the specific use case, MRTG. It could be used for anything. Hopefully I've remembered that correctly!

Re: The Rise of Open Source Time Series Databases

#59

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.

InfluxDB always seemed like it was run by children who are good at raising VC money.

Being familiar with both KDB and somewhat so with InfluxDB .. it strikes me as a challenging space. I suspect there just isn't much money in it.

Oddly InfluxDB has raised amounts of VC money approaching KDB parent companies current market cap. I know VC raised and market cap are not directly comparable, but what is the hoped-for enterprise value at exit of NewCo if the IncumbentCo is worth Z?

My take is that orgs with real revenue-generating time series data challenges, budget and dev staff to cook up solutions have long ago bought KDB licenses or rolled their own in-house column store.

Orgs using time series DBs for telemetry/observability/etc type of "back office" problems (where you are willing to downsample/conflate/offload history) either don't want to pay a dime, or want a fully formed SaaS solution with pretty GUI, alerting, etc like a DataDog they will like $10M/year to.

Not a lot of middle ground oddly.

Re: The Rise of Open Source Time Series Databases

#60
post #4

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/

I have done mimir deployments. I am generally very happy with mimir. It's very cost efficient. It does require someone to know enough to admin it though.

I didn't pick thanos because I really like the horizonal scaled blob store architecture the Grafana crew put together.

Post reply on HN