企业官网建设流程全解析

ClickBench 使用指南：1 亿行真实数据 + 43 条查询，给分析型数据库一次可复现的体检

【免费下载链接】ClickBenchClickBench: a Benchmark For Analytical Databases项目地址: https://gitcode.com/gh_mirrors/cl/ClickBench

给分析型数据库选型时，常见的坑是：测试数据自己编、测试查询随手写，跑出来的数字不敢往报告里放。ClickBench 把 1 亿行真实（已匿名化）的 Web 访问日志和 43 条标准 SQL 打包好了，做数据库选型、参数调优或硬件对比的人，一条脚本就能跑出一轮可复现的基准测试。

一句话定位

ClickBench 解决的是"拿什么数据、用什么查询来比较数据库"的问题：它提供一份来自真实 Web 分析平台流量的 hits 数据集（99,997,497 行，约 1 亿条）和 43 条覆盖全表扫描、过滤扫描、索引查找、关系运算的 SQL，让你省掉自造测试数据和设计查询集的时间，直接在一台机器上量出"加载耗时 + 43 条查询的冷/热运行时间"。

适合谁用

• 数据库选型者：日志分析、流量分析场景下要在几个 OLAP 系统之间做取舍，需要一套所有候选者都认的同一把尺子。
• 数据库开发者：改完执行器、索引或压缩算法，用同一组查询验证提升幅度，默认配置和调优配置分开提交。
• 硬件对比与采购评估：同一数据库在不同规格实例上各跑一遍，看差距到底落在存储吞吐、CPU 核数还是内存带宽上。
• 想核实公开数字的人：仓库里存着 60 多个系统的历史结果，每一轮都能用脚本在半自动方式下重放，多数系统约 20 分钟跑完一轮（个别系统需要数小时）。

快速上手：四步跑通第一轮测试

1）准备一台 Linux 机器

Ubuntu 24.04 及以上、有 root 权限（流程里要清空操作系统页缓存）、留出几十 GB 磁盘。数据集官方提供 CSV、TSV、JSONlines、Parquet 四种格式，可以按目标数据库挑最顺手的格式加载。

2）拿到仓库

git clone https://gitcode.com/gh_mirrors/cl/ClickBench cd ClickBench

3）进目标系统目录，跑 benchmark.sh

以 ClickHouse 为例：

cd clickhouse ./benchmark.sh

这个脚本一次完成：安装系统、下载数据集、加载数据、跑 43 条查询（每条 3 次：第 1 次前会停库、清缓存、重启，算冷启动；第 2、3 次算热运行），最后追加一轮 10 并发、10 分钟的持续吞吐探测。仓库里每个系统目录（如 duckdb、starrocks）都有各自的 benchmark.sh，按需替换即可；需要手动在控制台配置的商业化托管服务则看对应目录里的 README.md。

4）产出落盘

标准输出会给出Load time: <秒>、Data size: <字节>和 43 行[t1, t2, t3]。把结果整理成 JSON 放到results/<YYYYMMDD>/<机器名>.json（目录名是 UTC 日期，同一系统换新机器或新日期就多一个文件或子目录），然后在仓库根目录执行：

./generate-results.sh

它会汇总各目录下日期最新的一份结果，重新生成对比页面用的data.generated.js。

结果文件在哪看、字段怎么读 ⏱️

结果按系统、日期、机器三级存放，例如 ClickHouse 最新一轮：

clickhouse/results/20260822/c6a.4xlarge.json

关键字段（取自上面这份真实文件）：

result里每个三元组很好读：比如第 6 条是[2.792, 0.358, 0.349]——首次冷启动 2.8 秒，热状态稳定在 0.35 秒上下。冷/热分开记，是因为很多系统第一次查询要付读盘和建缓存的成本，拿平均值会掩盖这个差异。部分系统跑不满全部查询（OOM、不支持的语法等）时，缺失的位置填null也可以提交。

三个真实用法

选型：在目标硬件上实测候选者，别信纸面参数

给日志或流量分析项目选 OLAP 数据库时，把候选系统都拉到和你生产环境同规格的机器上各跑一遍，重点对比load_time和 43 条查询的冷/热两组数字。数据来自真实流量分布，压缩率、索引命中这类随机数据集造不出来的差异会被测出来。

调参：前后对比用同一把尺子

改了主键、编码或引擎参数之后，不要只跑一两条"顺眼"的查询。仓库里就有先例：clickhouse/下提供create-tuned.sql、queries-tuned.sql等变体，README 也建议默认配置和调优结果分成两个目录分别提交（如MyDatabase和MyDatabase-tuned），避免数字混在一起。

换机器：同一数据库在不同硬件上定位瓶颈

43 条查询对不同硬件敏感点不同：有的吃存储吞吐，有的吃 CPU 核数，有的吃单核主频，有的吃内存带宽。同一个系统跑c6a.large和c8g.metal-48xl各一轮，对照逐条查询的时间变化，就能看出扩容收益卡在哪个部件上。hardware/目录甚至把整套流程反过来用来给服务器本身打分。

周边项目

• ClickHouse（clickhouse/目录）：数据集和查询集源自 ClickHouse 团队 2013 年起用于生产选型的真实负载，它同时是基准里历史结果最完整的被测对象，常作为其他系统的参照基线。
• DuckDB（duckdb/目录）：内嵌式单文件数据库的代表，和常驻服务型系统在相同 43 条查询下并列对比，架构差异直接体现在数字里。
• 硬件基准（hardware/目录）：复用同一套驱动脚本测 CPU、内存、存储，回答的是"这台机器值多少钱"而不是"这个数据库快不快"。

小结

ClickBench 的价值不在某次测试跑得多快，而在数据集、查询集、流程和结果格式都被固定下来，任何系统、任何日期的数字都能互相重放核对。下一步建议：先挑一个你最熟悉的系统目录完整跑一遍，把输出日志和results里的 JSON 逐字段对上，熟悉流程后再照着 README 的 "How To Add a New Result" 一节，把你要测的目标系统按同样的目录结构加进去。

【免费下载链接】ClickBenchClickBench: a Benchmark For Analytical Databases项目地址: https://gitcode.com/gh_mirrors/cl/ClickBench