Re:Why Postgres RDS didn't work for us
by osigurdson on Saturday February 03, 2024 @08:14PM
(#39246522)
What we ended up doing is maintain meta-data in Postgres but time series data is stored in ClickHouse. Thanks for making / working on ClickHouse. I appreciate it very much.
That PoC benchmark didn't turn on Timescale's columnar compression, which every real deployment uses. So misleading at best.
(Timescaler)
Re:Why Postgres RDS didn't work for us
by tbragin on Saturday February 03, 2024 @06:53PM
(#39245969)
Compression helped, but not enough in our experiments https://benchmark.clickhouse.com/#eyJzeXN0ZW0iOnsiQWxsb3lEQi...
All depends on the benchmark :)
https://www.timescale.com/blog/what-is-clickhouse-how-does-i...
Do you have a version using the same instance type? Seems weird to mix them.
Re:Why Postgres RDS didn't work for us
by tbragin on Saturday February 03, 2024 @10:24PM
(#39247248)
Indeed, ClickHouse results were run on an older instance type of the same family and size (c5.4xlarge for ClickHouse and c6a.4xlarge for Timescale), so if anything ClickHouse results are at a slight disadvantage.
This is an open source benchmark - we'd love contributions from Timescale enthusiasts if we missed something: https://github.com/ClickHouse/ClickBench/
Eh, c6a is also an AMD Rome which has worse memory bandwidth at the tails and weaker per thread performance than Cascadelake (c5). I don't understand anything about this particular benchmark, but I wouldn't compare them simply as "older vs newer".
See results from Gitlab benchmarking ClickHouse vs TimescaleDB: https://gitlab.com/gitlab-org/incubation-engineering/apm/apm...
Key findings:
* ClickHouse has a much smaller data volume footprint in all cases by almost a factor of 10.
* There are very few ClickHouse queries that have >1s latency at q95. TimescaleDB has multiple >1s latencies, including a few in the range of 15-25s.
Disclaimer: I work at ClickHouse