3 ms·
That’s a really thorough comparison. Much more detailed than I expected. From what I see, the trade off in disk space usage would point me toward Timescale for
by brightball 5y ago
That’s a really thorough comparison. Much more detailed than I expected.
From what I see, the trade off in disk space usage would point me toward Timescale for most of my workloads. The insert performance tradeoff just wouldn’t justify the difference for me.
- ryanbooz 5y ago(Post author) Thanks for the compliment! It's becoming a habit with us and benchmarks. We just really want to dig in and understand what's going on and why things work the way they do. ;-) There really are so many nuances and as we tried to say a number of times, ClickHouse is really great at what it does well. But it's still OLAP at heart (which precludes OLTP features many apps take for granted) and after enabling TimescaleDB compression, the query story isn't as cut and dry. We don't claim that TimescaleDB is the fastest in all circumstances, or that it absolutely has to be for every workload. Features and versatility play a major part in the decision.
- ericb 5y agoA licensing comparison would be a good addition.
- PeterZaitsev 5y agoGood question. Was it Open Source version of TimeScaleDB compared or Source Available ?
- ryanbooz 5y agoSure. As we shared in the blog post it was tested (like other benchmarks) on dedicated EC2 instances using the freely available Community version.
- PeterZaitsev 5y agoThis does not answer the question - is it Open Source License or Source Available (TSL) https://www.timescale.com/legal/licenses https://www.timescale.com/legal/licenses
- CodesInChaos 5y agothe original article and the parent poster say that the community edition was used: > Versions: TimescaleDB version 2.4.0, community edition, with PostgreSQL 13 and the link you posted explains that it's the non OSI license version: > TimescaleDB Community is made available under the Timescale License ("TSL")
- PeterZaitsev 5y agoTnx. I think this is another thing which worth to point out. We're having Open Source solution compared with non Open Source one.
- darthShadow 5y agoDoes the disk usage go down later once the numerous parts are merged or not? I would assume it does but reading the article implies that it does not.
- zepearl 5y agoConcerning Clickhouse, yes it does - exactly the same thing e.g. as when you have 2 compressed files containing each 100 sorted rows, when you merge those 200 rows into a single file, sort them and compress them, the result will be smaller than the sum of the 2 separate files. How much you save is again exactly the same as when dealing directly with files: it depends on the data and on the compression algo.
- ryanbooz 5y agoGreat question. Yes, eventually it does, but (at least for now) it wasn't something we could reliably force as part of the query cycle and know everything was in it's "best" state with ClickHouse. To be honest, we didn't provide the final compressed size of either database because of the need to wait. The code that's currently used by TSBS was submitted by Altinity, a heavy supporter of ClickHouse in the U.S., but TSBS is open source and anyone is welcome to contribute and make the process/test better!
- darthShadow 5y agoThanks for the answer. May be worth pointing that out in the article since the increased disk usage has been mentioned multiple times in the article without any indication that it's only temporary until ClickHouse merges the parts.