3 ms·

Key quote from the article: > Overall, although some TimescaleDB queries became faster by enabling compression but many others became bit slower probably due t

by csdvrx 5y ago

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 set of constrains (ex: must be able to delete individual records, ...) and sacrificing performance for them is an acceptable tradeoff. 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! But I suggest interested readers check the history of previous "creative engineering" around tests that has been done to make TimescaleDB come out ahead: https://news.ycombinator.com/item?id=28945903 https://news.ycombinator.com/item?id=28945903 In 99% of the case, ClickHouse is the right choice, especially if you care about the license not adding too many restrictions.

gfody 5y ago
if you're going to compare these two you really ought to get into their materialized views where the real-world performance comes from, and ideally dive into their respective limitations
akulkarni 5y ago
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't believe me, that's fine! Each workload is different and you should test it yourself. p.s. Let's keep HackerNews a more positive place. Negative comments are unnecessary, not productive, and honestly just make the author look immature.
- dexwiz 5y ago
  Honestly, you sound like the bully here hiding behind the overly positive language of the day in order to insult the character of your opponent.
  - staticassertion 5y ago
    OP made accusations, response was leveled and asked for positivity.
    - csdvrx 5y ago
      Sometimes, after trying to engage positively and giving the benefit of doubt, I start to notice some disturbing things. When that happens, I speak my mind, and escalate progressively depending on how trustworthy I believe the person I'm talking to is. Here, I provided a link to the previous discussion, because personally, I do not appreciate being mislead. I encourage you to check the technical details there if you don't believe me. But maybe not being 100% positive and supportive is no longer acceptable in 2021? Or maybe it's the complexity of the issues discussed? So let's give a simpler message: as rkwasni said it best just yesterday: "It's really quite easy, if you don't need DELETE ClickHouse wins every benchmark" https://news.ycombinator.com/threads?id=rkwasny https://news.ycombinator.com/threads?id=rkwasny It's simple as that: if you need deletion, consider TimescaleDB. For every other conceivable scenario, ClickHouse is likely to come ahead, unless you are doing something very very wrong with it: a virtualization example would be splitting cores across VM with no respect of their shared cache. When people talk about doing a millions of tiny inserts, it's a bit like that: a misconfiguration. And that's not how it work in the real world: even with plain Postgres, you often use a middle layer to avoid resource issues (increasing max_connections has a cost, that's why pgpool exist!), either directly in your app, or by putting some kind of buffer in front of the real table. ClickHouse has such features, to automatically handle the flushing to the real table: https://clickhouse.com/docs/en/engines/table-engines/special/buffer/ https://clickhouse.com/docs/en/engines/table-engines/special... I have spend some serious time with both, think of me what you may, but the CEO of TimescaleDB saying TimescaleDB performance can withstand the comparison with ClickHouse is like Intel marketing department saying Intel CPUs can withstand the comparison with AMD: unless you cook the tests with some highly specific workloads (say with lots of simd/AVX512 stuff, monocore...) to be non representative of the most common scenarios, you're not being honest. I believe such thinly veiled dishonesty is a much larger problem than a perceived positivity.
- ishikawa 5y ago
  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.
ensignavenger 5y ago
>>especially if you care about the license not adding too many restrictions. Compression is one of the many closed-source/proprietary features in Timescale. Timescale is a great idea, as its just a postgres extension, so no need to add another database, but with such an important feature being proprietary, I end up looking at the fully Open Source ClickHouse and I see the operational overhead of another DB as reasonable trade-off for keeping my stack Open Source and avoiding vendor lock-in.
- Croftengea 5y ago
  Closed source? https://github.com/timescale/timescaledb/tree/master/tsl/src/compression https://github.com/timescale/timescaledb/tree/master/tsl/src...
  - ensignavenger 5y ago
    Right- did you look at any of the source files in that dir? They all have a header that says they are under the "TimeScale License" and if you look it up, you see that the TimeScale license is a proprietary, not Open Source, but rather Source Available license. Here you can see a chart outlining all the features that are proprietary and which are Open Source in the Open-Core TimeScale DB- https://docs.timescale.com/timescaledb/latest/timescaledb-edition-comparison/#feature-comparison https://docs.timescale.com/timescaledb/latest/timescaledb-ed...
    - TinyCuteGorilla 5y ago
      What you can also read on that linked page is that the only thing you cannot do when using the Timescale license is basically pull an AWS move and sell TimescaleDB as a service. So when you say "closed source" and "proprietary" that's just really not a good description of TImescaleDB imo. (on the other hand you can grab the Apache version and sell it as a DBaaS etc)
      - ensignavenger 5y ago
        >>"closed source" and "proprietary" that's just really not a good description of TimescaleDB I suppose we can agree to disagree on this. Perhaps "Open Core, Source Available" is a term you can agree to? I think my original comment was clear that part of Timescale is Open Source, or in other words Open Core. >> the only thing you cannot do when using the Timescale license is basically pull an AWS move and sell TimescaleDB as a service Actually, by virtue of this, it prevents me from paying some one else to host a Timescale fork for me... this in turn is a major stumbling block to creating a viable fork if my business interests diverge from Timescales's business interests for any reason. Thus leading to Vendor Lock-in, as per my original comment.

by csdvrx 5y ago

gfody 5y ago

if you're going to compare these two you really ought to get into their materialized views where the real-world performance comes from, and ideally dive into their respective limitations

akulkarni 5y ago

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't believe me, that's fine! Each workload is different and you should test it yourself. p.s. Let's keep HackerNews a more positive place. Negative comments are unnecessary, not productive, and honestly just make the author look immature.

dexwiz 5y ago
Honestly, you sound like the bully here hiding behind the overly positive language of the day in order to insult the character of your opponent.
- staticassertion 5y ago
  OP made accusations, response was leveled and asked for positivity.
  - csdvrx 5y ago
    Sometimes, after trying to engage positively and giving the benefit of doubt, I start to notice some disturbing things. When that happens, I speak my mind, and escalate progressively depending on how trustworthy I believe the person I'm talking to is. Here, I provided a link to the previous discussion, because personally, I do not appreciate being mislead. I encourage you to check the technical details there if you don't believe me. But maybe not being 100% positive and supportive is no longer acceptable in 2021? Or maybe it's the complexity of the issues discussed? So let's give a simpler message: as rkwasni said it best just yesterday: "It's really quite easy, if you don't need DELETE ClickHouse wins every benchmark" https://news.ycombinator.com/threads?id=rkwasny https://news.ycombinator.com/threads?id=rkwasny It's simple as that: if you need deletion, consider TimescaleDB. For every other conceivable scenario, ClickHouse is likely to come ahead, unless you are doing something very very wrong with it: a virtualization example would be splitting cores across VM with no respect of their shared cache. When people talk about doing a millions of tiny inserts, it's a bit like that: a misconfiguration. And that's not how it work in the real world: even with plain Postgres, you often use a middle layer to avoid resource issues (increasing max_connections has a cost, that's why pgpool exist!), either directly in your app, or by putting some kind of buffer in front of the real table. ClickHouse has such features, to automatically handle the flushing to the real table: https://clickhouse.com/docs/en/engines/table-engines/special/buffer/ https://clickhouse.com/docs/en/engines/table-engines/special... I have spend some serious time with both, think of me what you may, but the CEO of TimescaleDB saying TimescaleDB performance can withstand the comparison with ClickHouse is like Intel marketing department saying Intel CPUs can withstand the comparison with AMD: unless you cook the tests with some highly specific workloads (say with lots of simd/AVX512 stuff, monocore...) to be non representative of the most common scenarios, you're not being honest. I believe such thinly veiled dishonesty is a much larger problem than a perceived positivity.
ishikawa 5y ago
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.

ensignavenger 5y ago

>>especially if you care about the license not adding too many restrictions. Compression is one of the many closed-source/proprietary features in Timescale. Timescale is a great idea, as its just a postgres extension, so no need to add another database, but with such an important feature being proprietary, I end up looking at the fully Open Source ClickHouse and I see the operational overhead of another DB as reasonable trade-off for keeping my stack Open Source and avoiding vendor lock-in.

Croftengea 5y ago
Closed source? https://github.com/timescale/timescaledb/tree/master/tsl/src/compression https://github.com/timescale/timescaledb/tree/master/tsl/src...
- ensignavenger 5y ago
  Right- did you look at any of the source files in that dir? They all have a header that says they are under the "TimeScale License" and if you look it up, you see that the TimeScale license is a proprietary, not Open Source, but rather Source Available license. Here you can see a chart outlining all the features that are proprietary and which are Open Source in the Open-Core TimeScale DB- https://docs.timescale.com/timescaledb/latest/timescaledb-edition-comparison/#feature-comparison https://docs.timescale.com/timescaledb/latest/timescaledb-ed...
  - TinyCuteGorilla 5y ago
    What you can also read on that linked page is that the only thing you cannot do when using the Timescale license is basically pull an AWS move and sell TimescaleDB as a service. So when you say "closed source" and "proprietary" that's just really not a good description of TImescaleDB imo. (on the other hand you can grab the Apache version and sell it as a DBaaS etc)
    - ensignavenger 5y ago
      >>"closed source" and "proprietary" that's just really not a good description of TimescaleDB I suppose we can agree to disagree on this. Perhaps "Open Core, Source Available" is a term you can agree to? I think my original comment was clear that part of Timescale is Open Source, or in other words Open Core. >> the only thing you cannot do when using the Timescale license is basically pull an AWS move and sell TimescaleDB as a service Actually, by virtue of this, it prevents me from paying some one else to host a Timescale fork for me... this in turn is a major stumbling block to creating a viable fork if my business interests diverge from Timescales's business interests for any reason. Thus leading to Vendor Lock-in, as per my original comment.