Recent submissions

Comment · 25 days ago
the tradeoff with regards to slower queries and io only comes into play if the TSDB is performing a narrow lookup on a handful of series. In that case it’ll be faster. But when you scale up to 100s of millions, columnar dbs like Parseable win because-

a) there's no per-series inverted index and labels are parquet columns so memory is not bounded by cardinality

b) data lives on much cheaper object storage (parseable gives an option to cache data locally to remove io bound latency)

c) columnar store helps with faster data scanning by aggressively pruning and filtering data out

Comment · 25 days ago
Sizing for this kind of deployment was a lot of fun! We went ahead with- 5x Ingestors, each with 64 vcpu 128 GB

5x Queriers, each with 64 vcpu 192 GB

The current utilization sits comfortably at 10-15 vcpu and 20-30 GB memory for the ingestors 20-40 vcpu and 40-60 GB memory for the queriers

Ample of headroom for transient spikes and planned near-future growth

Comment · 25 days ago
We haven't yet tried pushing it to the scale of billions yet. The max that we've gone to is 150-180 million.
Comment · 1 year ago
Based on the feedback, we could have done a much better job with these results (lessons for our next experiment). But yes, the models were tested against the same dataset which was aggregated over different granularities (1 minute, 1 hour, 1 day)
Comment · 1 year ago
We'll definitely include it in our next experiment (shaping up to be quite big!)
Comment · 1 year ago
At the moment our focus is on observability, hence the narrow scope of our dataset. A pretty good benchmark for observability seems to be Datadog's BOOM- https://huggingface.co/datasets/Datadog/BOOM

But for general purpose time-series forecasting, benchmarks mentioned in other comments like GIFT or M4 might come in handy. We might include them in the follow-up experiment.

Comment · 1 year ago
we're grateful for the honest feedback (and the awesome resource!), makes it easier to identify areas for improvement. Also, your point about using multiple metrics (based on use-cases, audience, etc) makes a lot of sense. Will incorporate this in our next experiment.
Comment · 1 year ago
That's actually one of the use-cases that we set out to explore with these models. We'll release a head-to-head comparison soon!
Comment · 1 year ago
This looks like a great benchmark! We've been thinking of doing a better and more detailed follow-up and this seems like the perfect dataset to do that with. Thanks!
Comment · 1 year ago
Author here, we're trying these out for the first time for our use-cases so these are great points for us to improve upon!

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton