ig50 数据落盘 ClickHouse vs TimescaleDB vs DuckDB 实测对比股票数据落盘选什么存储这是量化系统里最常见的问题之一。我用 ig50 的本地数据做了 3 种主流方案的实测对比ClickHouse、TimescaleDB、DuckDB。这篇把测试结果完整分享出来帮你少走弯路。为什么做这个对比我之前用 MySQL 存股票数据单表 5000 万条就开始慢。后来换了 ClickHouse发现性能上来了但运维麻烦。再后来试了 TimescaleDB 和 DuckDB发现不同场景下各有优劣。这次实测我把 ig50 全市场 2023-2024 的真实数据约 320GB导入到 3 个数据库跑 12 组真实查询对比每个方案的写入速度、查询速度、磁盘占用、运维成本。测试环境硬件CPUAMD EPYC 7763 64 核内存256GB DDR4磁盘2TB NVMe SSD三星 990 PRO系统Ubuntu 22.04 LTS软件版本ClickHouse 23.8单节点TimescaleDB 2.14基于 PostgreSQL 15DuckDB 0.10.2嵌入式数据规模全市场 5000 只股票逐笔数据约 8 亿条分钟线数据约 1.2 亿条财务数据约 50 万条总磁盘占用320GBCSV Parquet 压缩测试数据集设计我把数据按 4 类组织成 4 张表tick_data逐笔成交dm股票代码 STRINGcjsj成交时间 DATETIMEcjjg成交价格 DOUBLEcjl成交量 INT64jyzd买卖方向 INT8minute_kline分钟 K 线dm, cjsj, open, high, low, close, volumedaily_kline日 K 线dm, trade_date, open, high, low, close, volume, amountfinancial_data财务数据dm, report_date, metric_name, metric_value写入性能对比我用 ig50 的 Parquet 文件批量导入每方案跑 3 次取中位数表ClickHouseTimescaleDBDuckDBtick_data8 亿条47 分钟2 小时 13 分18 分钟minute_kline1.2 亿条9 分钟28 分钟5 分钟daily_kline600 万条14 秒1 分 22 秒8 秒financial_data50 万条3 秒8 秒1 秒查询性能对比我设计了 12 组查询覆盖量化研究的高频场景查询 1单只股票最近 1 年的日 K 线SELECT*FROMdaily_klineWHEREdm000001ANDtrade_date2024-01-01;方案耗时ClickHouse23 msTimescaleDB156 msDuckDB18 ms查询 2全市场某日所有股票的日 K 线SELECT*FROMdaily_klineWHEREtrade_date2024-08-01;方案耗时ClickHouse87 msTimescaleDB412 msDuckDB64 ms查询 3单只股票最近 30 天逐笔数据范围扫描SELECT*FROMtick_dataWHEREdm000001ANDcjsj2024-07-01;方案耗时ClickHouse1.2 sTimescaleDB8.7 sDuckDB0.9 s查询 4全市场某 5 分钟内所有股票的逐笔成交高基数聚合SELECTdm,COUNT(*),SUM(cjl)FROMtick_dataWHEREcjsjBETWEEN2024-08-01 09:30:00AND2024-08-01 09:35:00GROUPBYdm;方案耗时ClickHouse3.8 sTimescaleDB28.4 sDuckDB2.1 s查询 5单只股票最近 5 年的财务时间序列SELECT*FROMfinancial_dataWHEREdm000001ORDERBYreport_date;方案耗时ClickHouse12 msTimescaleDB89 msDuckDB8 ms查询 6滚动 60 日均线窗口函数SELECTdm,trade_date,AVG(close)OVER(PARTITIONBYdmORDERBYtrade_dateROWSBETWEEN59PRECEDINGANDCURRENTROW)FROMdaily_kline;方案耗时ClickHouse4.7 sTimescaleDB32.1 sDuckDB3.2 s查询 7自相关计算lag 函数SELECTdm,trade_date,close-LAG(close)OVER(PARTITIONBYdmORDERBYtrade_date)FROMdaily_kline;方案耗时ClickHouse5.3 sTimescaleDB38.6 sDuckDB3.8 s查询 8跨表 JOIN财务 日线SELECTa.dm,a.trade_date,b.metric_valueFROMdaily_kline aJOINfinancial_data bONa.dmb.dmWHEREb.metric_nameROEANDa.trade_date2024-06-30;方案耗时ClickHouse187 msTimescaleDB1.4 sDuckDB142 ms磁盘占用对比同样 320GB 的原始 Parquet 数据导入后磁盘占用方案占用ClickHouse默认 MergeTree89 GBClickHouse压缩 MergeTree41 GBTimescaleDB默认压缩124 GBTimescaleDB开启 native 压缩78 GBDuckDB嵌入式38 GB运维成本对比ClickHouse优点性能极强列式存储 向量化执行缺点集群运维复杂Zookeeper 多节点协调单节点配置项多新人学习曲线陡峭TimescaleDB优点基于 PostgreSQLSQL 兼容性好运维生态丰富pgBackRest、pg_stat_statements 等缺点写入性能相对弱超大规模数据下需要仔细调优 chunk 配置DuckDB优点嵌入式不需要单独服务进程单机性能极强Python 集成无缝缺点不支持多客户端并发写入不适合高并发 OLTP 场景最终结论如果你的场景是单机分析 Python 工作流选 DuckDB。DuckDB 在我所有查询测试里都是最快的而且磁盘占用最低。Python 直接 import duckdbpandas 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}逐笔数据导出 Parquettime/f10/fi/{code}财务指标股票数据落盘这件事没有银弹。选哪个数据库取决于你的查询模式、数据规模、团队技术栈。我个人日常研究用 DuckDB重型回测用 ClickHouse时序监控用 InfluxDB另一个时序数据库没在这次对比里。gitee开源地址github开源地址