Traceway团队最近做了一次压测:同一台Hetzner CCX13云服务器,月租16.49美元,跑同一版开源可观测性工具Traceway,只换了底层存储引擎——从SQLite换成DuckDB。
结果是,写入吞吐提升3到15倍,仪表盘能扛住的数据规模上限普遍往后挪了100倍。这是Traceway团队自己发布的压测结果,不是第三方复现,数字给得比较细,但这100倍到底意味着什么、边界在哪里,得拆开看。
写入快3到15倍,15倍这一档背后有一次内存崩溃
三类信号写入速度都有提升,但幅度差得不小。
| 信号类型 | SQLite 写入速度 | DuckDB 写入速度 | 提升倍数 |
|---|---|---|---|
| 指标 | 61,712 点/秒 | 254,242 点/秒 | 约4倍 |
| Span | 30,508 条/秒 | 95,737 条/秒 | 约3倍 |
| 日志 | 4,877 条/秒 | 75,225 条/秒 | 约15倍 |
日志这15倍不是白来的。Traceway团队最初测DuckDB时,机器在压测中途直接死机。查下来是写入路径没做并发限流,一波密集大批次请求能把内存吃光。
团队后来加了一道摄取限流:并发请求数封顶,超载就返回503和Retry-After,而不是硬扛到崩溃。现在公布的数字都是修完这个漏洞之后重跑的。修复前,DuckDB的Span和日志成绩分别被低估23%和将近一半,原因是崩溃截断了压测的后半段。
这里要小心一个结论:列式存储不是在任何写入场景下都比行式快。SQLite这次没暴露崩溃问题,是因为它写入路径更慢,压力上来早早就报错,不会撑到内存耗尽。DuckDB的优势更像是这套特定写入路径加上限流修复之后的结果,原文也没公开表结构、批次大小和具体版本号,不能直接推广成"列式天生更快"的普遍规律。
读取上限后移100倍,但10亿行这档已经查不动
写入是热身,真正决定要不要换库的是读取。Traceway把"读取上限"定义得很具体:仪表盘能不能在5秒内加载出真实页面,再往上一个数量级,查询就不是变慢,而是直接超时不返回。
| 信号类型 | SQLite 读取上限 | DuckDB 读取上限 | 倍数 |
|---|---|---|---|
| 指标 | 100万行 | 1亿行 | 100倍 |
| Span | 10万行 | 1000万行 | 100倍 |
| 日志 | 10万行 | 1000万行 | 100倍 |
这100倍说的是阈值后移,不是所有查询都快100倍。原文没给出具体的延迟分位数,不该把它读成"查询普遍快100倍"。
测试还往上加了一档:把指标表塞到10亿行。DuckDB不到一小时写完,占用磁盘10.8GB,压缩后每个点大约10.8字节,机器全程没崩,健康检查一直能答。但到了这个规模,原本几秒能跑完的查询直接超过60秒——写入撑住了,查询没撑住。10亿行这一档只证明DuckDB能把数据存下来,不代表能在这个规模上继续查得动。
这组读取数字还有两个前提没写进对比里。测试时没有并发写入,读的时候机器很闲。数据保留策略也全程关闭。生产环境里边写边查、定期跑保留清理是常态,这次压测都没覆盖。
对谁有用:小团队可以缓一缓ClickHouse,选型还得补作业
这项测试对两类人有实际用处,但用处不一样。
自托管OpenTelemetry或轻量可观测性平台的小团队,如果数据量在千万行以内、预算有限,这组结果给了一个具体理由:先把SQLite换成DuckDB,把"要不要上ClickHouse"这个决定往后推一推。不用额外起一个容器,也不用多背一套客户端-服务器架构的运维成本。
正在SQLite、DuckDB、ClickHouse之间做后端选型的工程负责人,不能把这次结果当成生产选型的终点。
| 数据库 | 架构 | 这次测试的结论 |
|---|---|---|
| SQLite | 单文件,行式事务 | 写入和读取上限都最低 |
| DuckDB | 单文件,列式分析 | 单机写入快3到15倍,读取上限后移100倍 |
| ClickHouse | 客户端-服务器,分布式OLAP | 本次未直接测试,并发场景优势没有验证 |
ClickHouse的客户端-服务器架构是为了应对高并发查询和多机扩展,这次测试完全没有触及。报告本身也留了空白:没有公开服务器CPU核数和内存、DuckDB与SQLite的具体版本、索引设计、数据生成方式,也没给出查询语句和重复测试次数,目前也没有第三方复现。选型之前,并发读写测试、和ClickHouse的直接对比,这两项作业还得自己补上。