4 ms·
(TimescaleDB co-founder) Thanks for the mention, and I completely agree :-) Personally, there is a lot in this article that is misguided. For example, it ess
by akulkarni 5y ago
(TimescaleDB co-founder)
Thanks for the mention, and I completely agree :-)
Personally, there is a lot in this article that is misguided.
For example, it essentially defines "time-series database" as "metric store." As TimescaleDB users know, TimescaleDB handles a lot more than just metrics. In fact, we handle any of the data types that Postgres can handle, which I suspect is more than what Honeycomb's custom store supports.
TSDBs are good at what they do, but high cardinality is not built into the design. The wrong tag (or simply having too many tags) leads to a combinatorial explosion of storage requirements.
This is a broad generalization. Some time-series databases are better at high cardinality than others. Also, what is "high-cardinality" - 100K? 1M? 10M? (We in fact are designed for _higher cardinalities_ than most other time-series databases [0])
In contrast, our distributed column store optimizes for storing raw, high-cardinality data from which you can derive contextual traces. This design is flexible and performant enough that we can support metrics and tracing using the same backend. The same cannot be said of time series databases, though, which are hyper-specialized for a specific type of data.
We just launched tracing and metrics support in the same backend - in Promscale, built on TimescaleDB [1]
I do commend the folks at Honeycomb for having a good product loved by some of my colleagues (at other companies). I also commend them for attempting to write an article aimed to educate. But I wish they had done more research - because without it, this article (IMO) ends up confusing more than educating.
For anyone curious on our definition of "time-series data" and "time-series databases": https://blog.timescale.com/blog/what-the-heck-is-time-series-data-and-why-do-i-need-a-time-series-database-dcf3b1b18563/ https://blog.timescale.com/blog/what-the-heck-is-time-series...
[0] https://blog.timescale.com/blog/what-is-high-cardinality-how-do-time-series-databases-influxdb-timescaledb-compare/ https://blog.timescale.com/blog/what-is-high-cardinality-how...
[1] https://blog.timescale.com/blog/what-are-traces-and-how-sql-yes-sql-and-opentelemetry-can-help-us-get-more-value-out-of-traces-to-build-better-software/ https://blog.timescale.com/blog/what-are-traces-and-how-sql-...
- eska 5y agoI had a serious case of deja vu reminding me of your article on compression in timescaledb :-D
- akulkarni 5y agoThanks for reading that article :-)
- ignoramous 5y agoHow does timescale (a single-purpose database) hold up against single-store (a multi-purpose database)? Of course, timescale is cheaper, but other than that, have you folks compared / contrast against single-store as a TSDB? PS https://www.timescale.com/papers/timescaledb.pdf https://www.timescale.com/papers/timescaledb.pdf is 404
- akulkarni 5y agoTimescaleDB performs quite well. One of our unique insights is that it is quite possible to build a best-in-class time-series database on top of Postgres (although it’s not easy ;-) Here is one benchmark: 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-... There are some challenges with building on Postgres - but what we’ve been able to do is build innovative capabilities that overcome these challenges (Eg columnar compression in a row-oriented store, multi-node scale out). We also have some exciting things that we are announcing this week. Stay tuned :-) PS - Where did you find that PDF? Thought we took it down (it was hard to keep it up to date :-) )
- ignoramous 5y agoThanks. Re: paper: I stumbled upon it when going through other timescaledb threads on news.yc, specifically here, https://news.ycombinator.com/item?id=13943939 https://news.ycombinator.com/item?id=13943939 (5 yrs ago)