Live data from Hacker News

Comparing ClickHouse to PostgreSQL and TimescaleDB for time-series data

blog.timescale.com

41–50 of 184 posts

Re: Comparing ClickHouse to PostgreSQL and TimescaleDB for time-series data

#41
post #18

Can someone give me a real-world example of a scenario where they actually need a time series database, like an example query with the business use case / justification? Just super curious.

We're using TimescaleDB to store log events - so each row has a timestamp, some properties, and a log message. And a lot of that is actually in a JSONB column.

Not the archetypal time series use case, but TimescaleDB is still really useful.

TSDB's compression means we can store a huge volume of data in a fraction of the space of a standard Postgres table. You can achieve even better compression ratios and performance if you spend time designing your schema carefully, but honestly we didn't see the need, as just throwing data in gets us something like 10:1 compression and great performance.

TSDB's chunked storage engine means that queries along chunking dimensions (e.g. timestamp) are super-fast, as it knows exactly which files to read.

Chunking also means that data retention policies execute nearly instantaneously, as it's literally just deleting files from disk, rather than deleting rows one-by-one - millions of rows are gone in an instant!

And best of all, this all works in Postgres, and we can query TSDB data just the same as regular data.

All that combined easily justified the decision to use TSDB - and if you're familiar with Postgres, it's actually really simple to get started with. Really, we'd of needed a business justification not to use it!

Much love for the TimescaleDB team!

Re: Comparing ClickHouse to PostgreSQL and TimescaleDB for time-series data

#42
post #18

Can someone give me a real-world example of a scenario where they actually need a time series database, like an example query with the business use case / justification? Just super curious.

We just migrated to Clickhouse. We collect monitoring data. So response times from 20+ different location. We are not super duper big but at least 100M+ individual metrics per month. We want to give our users a snappy, interactive dashboard that lets them explore aggregates of that data over time: averages, p99 etc..

That is where a time series DB is very handy

Re: Comparing ClickHouse to PostgreSQL and TimescaleDB for time-series data

#44

Any plans to do this kind of detailed comparison with Druid too?

There's a long list of DBs users would like to see. Druid is on the list but probably not happening in the near-term without some community help.

Remember, TSBS is open-source and we've had some great contributions from many teams/databases. :-)

Re: Comparing ClickHouse to PostgreSQL and TimescaleDB for time-series data

#46

Related to TimescaleDB, there was a blog post which explained their internals and also compared with another similar time series DB. I can't seem to find the link, anyone remembers?

Timescaler here. I think you're referring to this comparison of InfluxDB vs TimescaleDB [0]?

There's also comparisons of TimescaleDB vs MongoDB[1] and AWS Timestream [2].

[0]: https://blog.timescale.com/blog/timescaledb-vs-influxdb-for-...

[1]: https://blog.timescale.com/blog/how-to-store-time-series-dat...

[2]:https://blog.timescale.com/blog/timescaledb-vs-amazon-timest...

Re: Comparing ClickHouse to PostgreSQL and TimescaleDB for time-series data

#47

How can i replicate the results of the benchmarks ? I am interested to look at the CH table schema you used.

(Timescale team member here)

We used the Time Series Benchmark Suite for all these tests https://github.com/timescale/tsbs. Also, Ryan (post author) will be giving all the config details in a Twitch stream happening next Wednesday. We'll be uploading the video to Youtube immediately afterwards too >>

twitch.tv/timescaledb youtube.com/timescaledb

Re: Comparing ClickHouse to PostgreSQL and TimescaleDB for time-series data

#48

How can i replicate the results of the benchmarks ? I am interested to look at the CH table schema you used.

(Post author)

Howdy! All of the details about our TSBS settings in the performance section of the docs. Also, we'll be streaming a sample benchmark of the two databases next Wednesday at 10AM ET/4PM CET.

https://blog.timescale.com/blog/what-is-clickhouse-how-does-...

twitch.tv/timescaledb

Re: Comparing ClickHouse to PostgreSQL and TimescaleDB for time-series data

#49
post #18

Can someone give me a real-world example of a scenario where they actually need a time series database, like an example query with the business use case / justification? Just super curious.

I introduced Timescale at an IIOT company, we had thousands of sensors regularly sending data up and wanted to efficiently display such metrics to users on a per-sensor basis, and one "tick" of data had a lot of metrics. Timescale let us go from Postgres for metadata and OpenTSDB (awful, stay far away) for time series to just one Timescale instance for everything. Huge win for us. We had enough data that doing the same with vanilla Postgres would have performed much worse (billions of rows).

We wrote more about this for an earlier Timescale blog post: https://blog.timescale.com/blog/how-everactive-powers-a-dens...

Re: Comparing ClickHouse to PostgreSQL and TimescaleDB for time-series data

#50

Earlier quoted context omitted.

Was this for your primary source-of-truth, or more of a downstream data warehouse, or something else? I'm struggling to imagine a case where these are the two things being considered; Timescale is the obvious choice for a primary database, Clickhouse the obvious choice for a warehouse. I wouldn't let my user-facing app write to Clickhouse, and while I could potentially get away with a read-only Timescale replica for…

> I wouldn't let my user-facing app write to Clickhouse I’ve been thinking of doing exactly that. What are your concerns?

I suppose it depends what you're going to let your user do, but OLAPs in general and Clickhouse in particular don't do well under row-oriented workloads, as described in the post here. I'm imagining users primarily operating on small numbers of rows and sometimes making updates to or deleting them, a worst-case scenario for Clickhouse but best-case for an OLTP like Postgres.
Post reply on HN