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 ClickBench3进目标系统目录跑 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关键字段取自上面这份真实文件字段示例值含义system/machineClickHouse/c6a.4xlarge被测系统和硬件规格load_time304数据加载耗时 304 秒data_size15269865399落盘后占用约 15.3 GB含索引result43 组[冷, 热, 热]每条查询 3 次的运行秒数concurrent_qps0.90810 并发 10 分钟窗口的持续 QPSresult里每个三元组很好读比如第 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/目录甚至把整套流程反过来用来给服务器本身打分。周边项目ClickHouseclickhouse/目录数据集和查询集源自 ClickHouse 团队 2013 年起用于生产选型的真实负载它同时是基准里历史结果最完整的被测对象常作为其他系统的参照基线。DuckDBduckdb/目录内嵌式单文件数据库的代表和常驻服务型系统在相同 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
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 ClickBench3进目标系统目录跑 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关键字段取自上面这份真实文件字段示例值含义system/machineClickHouse/c6a.4xlarge被测系统和硬件规格load_time304数据加载耗时 304 秒data_size15269865399落盘后占用约 15.3 GB含索引result43 组[冷, 热, 热]每条查询 3 次的运行秒数concurrent_qps0.90810 并发 10 分钟窗口的持续 QPSresult里每个三元组很好读比如第 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/目录甚至把整套流程反过来用来给服务器本身打分。周边项目ClickHouseclickhouse/目录数据集和查询集源自 ClickHouse 团队 2013 年起用于生产选型的真实负载它同时是基准里历史结果最完整的被测对象常作为其他系统的参照基线。DuckDBduckdb/目录内嵌式单文件数据库的代表和常驻服务型系统在相同 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
