What does HackerNews think of ClickBench?

ClickBench: a Benchmark For Analytical Databases

Language: HTML

#2 in Database
#34 in SQL
I've recently implemented a project to test and compare analytical databases, including cloud services: https://github.com/ClickHouse/ClickBench/

It compares Redshift and Athena as well.

Full disclosure: I work at StarTree, which is powered by Apache Pinot.

ClickHouse's ClickBench is a good general tool. However, it's not the end-all, be-all of performance benchmarking and testing. Its results may or may not be applicable for guidance on the performance of your specific use case when you get to production.

It is definitely a stab at getting an objective suite of tools for the real-time analytics space. But just like you had YCSB as a good general performance test, eventually a subset of users wanted something specific for Cassandra and Cassandra-like databases (DSE, ScyllaDB, etc.), so you eventually saw cassandra-stress. We have to consider cases where certain databases may need to have testing suites that really capture their capabilities.

ClickHouse themselves publishes a list of Limitations that everyone should keep in mind as they run ClickBench:

https://github.com/ClickHouse/ClickBench/#limitations

CelerData (based on StarRocks) also wrote up this:

https://celerdata.com/blog/what-you-should-know-before-using...

Plus, I want to direct people to the discussion generated when ClickBench was first posted to HN:

https://news.ycombinator.com/item?id=32084571

As user AdamProut commented back at the time:

> It looks like the queries are all single table queries with group-bys and aggregates over a reasonably small data set (10s of GB)?

>I'm sure some real workloads look like this, but I don't think it's a very good test case to show the strengths/weaknesses of an analytical databases query processor or query optimizer (no joins, unions, window functions, complex query shapes ?).

> For example, if there were any queries with some complex joins Clickhouse would likely not do very well right now given its immature query optimizer (Clickhouse blogs always recommend denormalizing data into tables with many columns to avoid joins).

So, again, ClickBench is a good (great) beginning. As an industry we should not let it be seen as the end. I'd be interested in the community's opinions on what and how we should be doing better.

I am the author of ClickBench: https://github.com/ClickHouse/ClickBench/

You can check the methodology described in the README and check the pull requests submitted by many database vendors.

One way to add some trust is to make benchmarks open-source and reproducible: https://github.com/ClickHouse/ClickBench/

(I work at ClickHouse)

I recommend checking ClickBench: https://github.com/ClickHouse/ClickBench

Disclaimer: I'm the author of ClickBench. It contains the comparison of Datafusion, DuckDB as well, and 30+ more DB engines in an open benchmark. The results of Datafusion were contributed by their team, and the results of DuckDB were contributed by their respective team.

I've added a benchmark of ClickHouse and Athena to ClickBench:

https://pastila.nl/?0198061e/f2e0e7b2d61d0fe322607b58fc7200b...

Where ClickHouse operates in a "data lake" mode - simply by processing a bunch of parquet files on S3. Obviously it is faster than Athena. But I also want to add Presto, Trino, Spark, Databricks, Redshift Spectrum, and Boilingdata, that are currently missing from the benchmark.

Please help me adding them: https://github.com/ClickHouse/ClickBench

Also, it includes another mode of ClickHouse, named "web" - MergeTree tables hosted on a HTTP server (which is more efficient than parquet). See https://github.com/ClickHouse/web-tables-demo

About R2 - it is currently slow, and also incompatible with S3 (e.g., no multipart uploads).

When I tested BigQuery for ClickBench, the minimum query latency was 0.5 seconds. However, there is some feature for better query latency (need to check).

Note: BigQuery has a "De-Witt" clause[2] that prevents publishing the benchmark results. That's why there are all the testing instructions, but no published results: https://cube.dev/blog/dewitt-clause-or-can-you-benchmark-a-d...

Nevertheless, BigQuery is good for long-running queries, as the number of query workers is selected dynamically on a per-query basis.

[1] ClickBench: https://github.com/ClickHouse/ClickBench/ [2] https://cube.dev/blog/dewitt-clause-or-can-you-benchmark-a-d...

Yes, ClickBench results are presented as Relative Time, where lower is better. You can read more on the specifics of ClickBench methodology in the GitHub repository here: https://github.com/ClickHouse/ClickBench/

There are other responses from ClickHouse in the comments on the pricing, so I'll defer to their expertise on that topic there. Thank you for your feedback and ideas, as normalizing a price-based benchmark is an interesting concept (and where ClickHouse would expect to lead also given the architecture and efficiency)

Benchmarks can be quite difficult to interpret when the test parameters vary between tests. However, I think the point in providing the open-source ClickBench benchmark [https://github.com/ClickHouse/ClickBench] is exactly to allow users to do their own research in providing a standardized client and workload across any SQL-based DBMS. Standardized benchmarking is an important technique, for comparing across different applications, or also for comparing the same application across different environments (compute, storage, cloud vs. self-managed, etc.). SPEC [https://www.spec.org] used to do a great job in developing and releasing standardized benchmarks, although their activity has waned of late