Live data from Hacker News

TimescaleDB vs ClickHouse

pradeepchhetri.xyz

21–30 of 76 posts

Re: TimescaleDB vs ClickHouse

#21
post #2

Key quote from the article: > Overall, although some TimescaleDB queries became faster by enabling compression but many others became bit slower probably due to decompression overhead. This may be the reason why TimescaleDB disable compression by default This matches my experience: ClickHouse is generally faster, and a better solution for time series (more robust, more mature, ...) unless you have a highly specific s…

I have no doubt that, as usual, akulkarni will make a good PR job / community outreach to explain why, numbers and experience be damned, TimescaleDB is better! I don't like responding to bullies and people who enter dialogues without good intentions. But since this is a public forum, I'll answer your comment: In general: ClickHouse is better than TimescaleDB for OLAP. TimescaleDB is better for time-series. If you don…

I'm totally in favor for more positivity. It is very easy to criticize something when you don't know what is happening on the other side. HN is a place for Hackers to discuss facts and not to imply what they think others think. If two comparisons differ, there might be several reasons as lack of trials on both sides or lack of a common ground for comparison but a lot here are doing their best to make lives of developers easier.

Re: TimescaleDB vs ClickHouse

#22

Earlier quoted context omitted.

I think both Clickhouse and TimeScaleDB are great systems with different design goals and approaches. Specifically I think Clickhouse is much better suited to "Event Logs" than "Metrics" storage (Clickhouse Inspired VM does well in this regard) I would just encourage all vendors to be more humble positioning their benchmarks. In my practice production behaviors for better or worse rarely resemble benchmark results

What is "Clickhouse Inspired VM"?

Hm. Not sure why My previous response is marked as dead, I guess VM is swear word It refers to V-I-CTO-R-I-A Metrics

Re: TimescaleDB vs ClickHouse

#23
It sounds like ClickHouse is the default OLAP choice and TimeScaleDB is the time-series workload choice.

Does anyone have a TimeScaleDB implementation that they love for time-series workloads that they are so happy with that they don't miss the non-timescale benefits of ClickHouse?

Re: TimescaleDB vs ClickHouse

#25

(Timescale co-founder) I'll answer this here with a similar response that I gave Pradeep (the author) via Twitter. I think ClickHouse is a great technology. It totally beats TimescaleDB for OLAP queries. I'll be the first to admit that. What our (100+ hour, 3 month analysis) benchmark showed is that for _time-series workloads_, TimescaleDB fared better. [0] Pradeep's analysis - while earnest - is essentially comparin…

I think TimescaleDB is amazing piece of technology but I think you're making arguments much broader than they can be made based on the facts.

The results which TimescaleDB showed to me seems to show what it is better than ClickHouse in TSBS benchmark (or particular configuration) not for Time Series workloads in general.

In my experience "Time Series" workloads can be defined very broadly (by casual user) and querying log of events can be often seen as such

Re: TimescaleDB vs ClickHouse

#26
I haven't used ClickHouse nor TimescaleDB, but I thought TimescaleDB was competing with the likes of InfluxDB, QuestDB & Prometheus. I guess I'm not surprised that it looses to an OLAP database on OLAP queries.

Are people using ClickHouse as their timeseries backend? IIRC, Clickhouse doesn't perform all that well with millions of tiny inserts.

Re: TimescaleDB vs ClickHouse

#27

I haven't used ClickHouse nor TimescaleDB, but I thought TimescaleDB was competing with the likes of InfluxDB, QuestDB & Prometheus. I guess I'm not surprised that it looses to an OLAP database on OLAP queries. Are people using ClickHouse as their timeseries backend? IIRC, Clickhouse doesn't perform all that well with millions of tiny inserts.

I've had a really positive experience using ClickHouse as an InfluxDB replacement. Initially I used the BUFFERED table type to overcome the "tiny inserts" problem, but ultimately just batch up writes in my custom line-protocol TCP server which translates line-protocol to JDBC inserts (RowBinary).

Last time I checked I have a few hundred billion rows in the table with a significant compression ratio (not sure off hand). Most importantly, the table is ordered efficiently enough to allow me to query years of metrics (Grafana plugin) at millisecond speed.

Side note, I recall ClickHouse developers mentioning they are currently working on an implementation change which will allow many tiny inserts to be much more performant and realistic to use in the real-world.

Hope this helps!

Re: TimescaleDB vs ClickHouse

#28

I haven't used ClickHouse nor TimescaleDB, but I thought TimescaleDB was competing with the likes of InfluxDB, QuestDB & Prometheus. I guess I'm not surprised that it looses to an OLAP database on OLAP queries. Are people using ClickHouse as their timeseries backend? IIRC, Clickhouse doesn't perform all that well with millions of tiny inserts.

The answer is yes. I used ClickHouse to calculate and forecast sales of products at a dozen or so stores. The compression was huge because it's essentially the same data every day except for changes to the inventory. At the time I checked vanilla PostgreSQL, TimeScaleDB and ClickHouse. It wasn't even close when it came to storage or performance. ClickHouse allowed me to work off of an old workstation where I installed Ubuntu.

In my case the data arrived in CSVs with around 20k skus. Had they arrived a couple at a time, I could have created a CSV and written to ClickHouse later or used any of the other storage methods available in ClickHouse.

Re: TimescaleDB vs ClickHouse

#30
I remember reading that Clickhouse is quite bad at joins, which can be important if you have to build a snowflake schema. Is that still true? Is this something TimescaleDB would be better at?
Post reply on HN