ig50数据落盘ClickHousevsTimescaleDBvsDuckDB实测对比

ig50 数据落盘 ClickHouse vs TimescaleDB vs DuckDB 实测对比

股票数据落盘选什么存储？这是量化系统里最常见的问题之一。我用 ig50 的本地数据做了 3 种主流方案的实测对比：ClickHouse、TimescaleDB、DuckDB。这篇把测试结果完整分享出来，帮你少走弯路。

为什么做这个对比

我之前用 MySQL 存股票数据，单表 5000 万条就开始慢。后来换了 ClickHouse，发现性能上来了但运维麻烦。再后来试了 TimescaleDB 和 DuckDB，发现不同场景下各有优劣。

这次实测我把 ig50 全市场 2023-2024 的真实数据（约 320GB）导入到 3 个数据库，跑 12 组真实查询，对比每个方案的写入速度、查询速度、磁盘占用、运维成本。

测试环境

硬件：

• CPU：AMD EPYC 7763 64 核
• 内存：256GB DDR4
• 磁盘：2TB NVMe SSD（三星 990 PRO）
• 系统：Ubuntu 22.04 LTS

软件版本：

• ClickHouse 23.8（单节点）
• TimescaleDB 2.14（基于 PostgreSQL 15）
• DuckDB 0.10.2（嵌入式）

数据规模：

• 全市场 5000 只股票
• 逐笔数据：约 8 亿条
• 分钟线数据：约 1.2 亿条
• 财务数据：约 50 万条
• 总磁盘占用：320GB（CSV Parquet 压缩）

测试数据集设计

我把数据按 4 类组织成 4 张表：

写入性能对比

我用 ig50 的 Parquet 文件批量导入，每方案跑 3 次取中位数：

查询性能对比

我设计了 12 组查询，覆盖量化研究的高频场景：

查询 1：单只股票最近 1 年的日 K 线

SELECT * FROM daily_kline WHERE dm = '000001' AND trade_date >= '2024-01-01';

查询 2：全市场某日所有股票的日 K 线

SELECT * FROM daily_kline WHERE trade_date = '2024-08-01';

查询 3：单只股票最近 30 天逐笔数据（范围扫描）

SELECT * FROM tick_data WHERE dm = '000001' AND cjsj >= '2024-07-01';

查询 4：全市场某 5 分钟内所有股票的逐笔成交（高基数聚合）

SELECT dm, COUNT(*), SUM(cjl) FROM tick_data
WHERE cjsj BETWEEN '2024-08-01 09:30:00' AND '2024-08-01 09:35:00'
GROUP BY dm;

查询 5：单只股票最近 5 年的财务时间序列

SELECT * FROM financial_data WHERE dm = '000001' ORDER BY report_date;

查询 6：滚动 60 日均线（窗口函数）

SELECT dm, trade_date, AVG(close) OVER (
PARTITION BY dm ORDER BY trade_date
ROWS BETWEEN 59 PRECEDING AND CURRENT ROW
) FROM daily_kline;

查询 7：自相关计算（lag 函数）

SELECT dm, trade_date, close – LAG(close) OVER (
PARTITION BY dm ORDER BY trade_date
) FROM daily_kline;

查询 8：跨表 JOIN（财务 + 日线）

SELECT a.dm, a.trade_date, b.metric_value
FROM daily_kline a JOIN financial_data b
ON a.dm = b.dm
WHERE b.metric_name = 'ROE'
AND a.trade_date = '2024-06-30';

磁盘占用对比

同样 320GB 的原始 Parquet 数据，导入后磁盘占用：

运维成本对比

ClickHouse：

• 优点：性能极强，列式存储 + 向量化执行
• 缺点：集群运维复杂（Zookeeper + 多节点协调），单节点配置项多，新人学习曲线陡峭

TimescaleDB：

• 优点：基于 PostgreSQL，SQL 兼容性好，运维生态丰富（pgBackRest、pg_stat_statements 等）
• 缺点：写入性能相对弱，超大规模数据下需要仔细调优 chunk 配置

DuckDB：

• 优点：嵌入式（不需要单独服务进程），单机性能极强，Python 集成无缝
• 缺点：不支持多客户端并发写入，不适合高并发 OLTP 场景

最终结论

如果你的场景是单机分析 + Python 工作流：选 DuckDB。

DuckDB 在我所有查询测试里都是最快的，而且磁盘占用最低。Python 直接 import duckdb，pandas DataFrame 无缝互转。320GB 数据单机秒级响应。我现在的研究环境 90% 的查询都用 DuckDB 跑。

如果你的场景是高并发 + 多用户 + 大集群：选 ClickHouse。

ClickHouse 的集群能力是 DuckDB 和 TimescaleDB 都没法比的。100 个并发查询、PB 级数据、分片集群，ClickHouse 是首选。运维成本高是事实，但用得起 PB 数据的公司不会在意这点运维成本。

如果你的场景是已有 PostgreSQL 团队 + 时序数据为主：选 TimescaleDB。

TimescaleDB 在中等规模（10TB 以下）下表现稳定，SQL 兼容性好，运维有 PostgreSQL 经验就能上手。适合不希望引入新数据库技术栈的团队。

实测踩过的 3 个坑

第一个坑是 ClickHouse 的索引选择。默认 MergeTree 不带任何索引，全表扫描很快但需要足够内存。我后来改用 ReplacingMergeTree + ORDER BY (dm, cjsj)，查询速度提升 3 倍。

第二个坑是 TimescaleDB 的 chunk 数量。默认 1 个 chunk 放 1 亿条数据，对 8 亿条的逐笔表来说 chunk 数太少导致压缩率低。我改成按时间分 chunk（每 7 天一个），压缩率从 2.5x 提升到 4.1x。

第三个坑是 DuckDB 的内存占用。DuckDB 默认会使用机器全部内存做加速，我的 256GB 机器跑了 3 个并发查询就被 OOM 杀掉。我后来设置 SET memory_limit = '64GB';，稳定多了。

接口汇总

这次对比测试用到的 ig50 数据接口：

• time/history/trade/{code}/day：日 K 线（建表用）
• time/history/trade/{code}/min：分钟 K 线
• time/real/trace/onebyone/{code}：逐笔数据（导出 Parquet）
• time/f10/fi/{code}：财务指标

股票数据落盘这件事，没有"银弹"。选哪个数据库，取决于你的查询模式、数据规模、团队技术栈。 我个人日常研究用 DuckDB，重型回测用 ClickHouse，时序监控用 InfluxDB（另一个时序数据库，没在这次对比里）。

资料参考：ig50