Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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


You can run tsbs by yourself. Just check the options here: https://github.com/timescale/tsbs/blob/master/docs/clickhous...

The blog post benchmarks used `--use-case=cpu-only` case for data ingestion. You can see the table definition here: https://github.com/timescale/tsbs/blob/1eb7705ff921fd31784c0... coming from here: https://github.com/timescale/tsbs/blob/master/pkg/targets/cl...


(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


Few comments:

- The CH table schema generated by TSBS isn't optimized for the queries. First of all, it doesn't uses CODEC (https://altinity.com/blog/2019/7/new-encodings-to-improve-cl...) and many other optimizations CH have.

> We tried multiple batch sizes and found that in most cases there was little difference in overall insert efficiency

This is wrong in CH world where batch size matters a lot. I would recommend keep this even more higher around (10x of current value).

Humble Suggestion: There are many things not quite properly interpreted about CH and reading through the blog it seems like you're focusing more on areas which CH is lacking/missing. Please don't do these things.


Two quick responses:

- The code that TSBS uses was contributed by Altinity[1]. If there is a better setup, please feel free to submit a PR. As stated elsewhere, we did have a former CH engineer review and even updated ClickHouse to the newest version __yesterday__ based on his suggestion to ensure we had the best numbers. (and some queries did improve after upgrading, which are the numbers we presented)

- It seems like you read the article (great job - it was long!!), so I'm sure you understand that we were trying to answer performance and feature questions at a deeper level than almost any benchmark we've seen to date. Many just show a few graphs and walk away. We fully acknowledged that smaller batches are not recommended by CH, but something many (normally OLTP) users would probably have. It matters and nobody (that we know of) has shown those numbers before. And in our test, larger batch sizes do work well, but not to some great magnitude in this one server setup. Did 10k or 20k rows maybe go a little faster for CH? Sometimes yes, sometimes negligible. The illustration was that we literally spent months and hundreds of benchmark cycles trying to understand the nuances.

I think we're pretty clear in the post that CH is a great database for the intended cases, but it has shortcomings just like TimescaleDB does and we tried to faithfully explore each side.

[1]: https://github.com/timescale/tsbs/pull/26


This is what tend to make all vendor benchmarks "benchmarketing" - while many of us fully intend to give a fair shot to other technologies we tend to know best practices for our own software better than "competition"


It also puzzled me when I started benchmarking and helping/reviewing PRs on the tsbs project.

I even wrote an idea about promoting the "time series racing contest" a few months ago: https://gist.github.com/jonatas/a84b734645d288051fb861d9522f...

Orchestrate the race will require a lot of collaboration from all players involved :)

Another small step would be encourage DB companies to bring the most optimized defaults to tsbs or extra scripts and templates to tune the DB server.


(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




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: