Hacker News new | ask | show | jobs
by throwaway375 1875 days ago
I think idea and promise of Timescale is great, but current(well actually I tried it 1 year ago) state of things makes it very hard to choose Timescale over Clickhouse. I've tried to setup simple Twitter parser for trends analysis, so I needed few thousand counters every few seconds. While I did not encounter any perfomance issues, size on disk was a huge deal. I don't remember precise numbers, but Clickhouse used few magnitudes lower disk space. And while Timescale has nice things like materialized views, Clickhouse has them too. And apart from them Clickhouse has excellent data compression algorithms for repeated key value type counters. So it becomes really hard to understand why Timescale. It aims to help you with tables bigger than traditional pg can handle, but at the same time uses same amount of space.
2 comments

I think ClickHouse is underestimated as a database for time series. Many companies using it for analytics purposes (like Cloudflare [0]), for logs processing (like Uber [1]). I'm just waiting when someone builds something outstanding for monitoring. Articles like [2] shows ClickHouse potential in this area.

Btw, ClickHouse is under Apache 2 license, which makes it much easier to use in big companies.

[0] https://blog.cloudflare.com/http-analytics-for-6m-requests-p...

[1] https://eng.uber.com/logging/

[2] https://altinity.com/blog/clickhouse-for-time-series

Did you turn on compression in TSDB?
I checked documentation and I don't think I did. Looks like it has same compressing algorithms as Clickhouse, so it should be pretty close in space requirements for old chunks.
Is there any reason why it is not turned on by default?
You can't delete arbitrary records from compressed tables, only chunks.