时序数据库选型：InfluxDB、TimescaleDB、ClickHouse、DolphinDB对比

做高频做市系统，数据存储是个绕不开的坎。我见过不少团队，策略写得漂亮，结果一到回测阶段，数据查询慢得像蜗牛爬。说白了，选错数据库，后面全白干。

今天咱们就聊聊四个主流时序数据库：InfluxDB、TimescaleDB、ClickHouse、DolphinDB。我会从写入性能、压缩比、查询语法、生态成熟度四个维度，结合我踩过的坑，给你掰开揉碎了讲。

一、写入性能：谁扛得住千万级tick数据？

高频做市的数据写入，说白了就是一场「洪水」。每秒几万笔tick数据，峰值时甚至上百万。数据库能不能接住，直接决定了系统会不会崩。

数据库	单机写入吞吐	批量写入支持	我的实际体验
InfluxDB	~50万点/秒	HTTP批量写入	小规模场景够用，但并发一高就卡
TimescaleDB	~30万行/秒	PostgreSQL COPY	写入稳定，但受限于单机磁盘IO
ClickHouse	~200万行/秒	批量插入+异步写入	写入性能极强，我用来存全市场tick数据
DolphinDB	~500万点/秒	分区批量写入	写入速度最快，但配置复杂

我个人习惯，如果只是存几个合约的tick数据，InfluxDB够用。但如果你要存全市场5000+只股票的逐笔成交，那必须上ClickHouse或DolphinDB。

二、压缩比：存储成本能省多少？

高频数据有多占空间？我算过一笔账：一个交易所的Level2行情，一天大概产生50GB原始数据。一个月就是1.5TB。如果不压缩，光存储成本就能吃掉你一半的预算。

数据库	压缩算法	典型压缩比	备注
InfluxDB	自定义浮点压缩	3:1 ~ 5:1	对整数类型压缩效果一般
TimescaleDB	列式存储+pg压缩	4:1 ~ 8:1	依赖PostgreSQL原生压缩
ClickHouse	LZ4 / ZSTD	6:1 ~ 12:1	ZSTD压缩比高，但解压慢
DolphinDB	列式+字典压缩	8:1 ~ 15:1	对重复值多的字段压缩效果极好

你想想看，同样的1TB原始数据，用InfluxDB存大概要200GB，用DolphinDB可能只要70GB。一年下来，存储成本差距可不是一星半点。

嗯，这里要注意：压缩比不是越高越好。压缩比高的算法，写入和查询时CPU开销也大。我建议你根据硬件配置来选——如果CPU够强，用ZSTD；如果CPU紧张，用LZ4。

三、查询语法：写起来顺不顺手？

做高频回测，查询语句写得顺不顺，直接影响开发效率。我见过有人为了查一个5分钟K线，写了50行SQL——这显然不合理。

InfluxDB：类SQL的Flux查询

from(bucket: "tick_data")
  |> range(start: -1h)
  |> filter(fn: (r) => r.symbol == "BTCUSDT")
  |> aggregateWindow(every: 1m, fn: mean)

Flux语法很灵活，但学习曲线陡。我刚开始用的时候，光是理解管道操作符就花了两天。而且Flux的调试工具不太友好，报错信息经常让人摸不着头脑。

TimescaleDB：标准SQL

SELECT time_bucket('1 minute', ts) AS bucket,
       symbol,
       AVG(price) AS avg_price
FROM ticks
WHERE symbol = 'BTCUSDT'
  AND ts > NOW() - INTERVAL '1 hour'
GROUP BY bucket, symbol;

TimescaleDB用的是标准SQL，对PostgreSQL用户来说零成本上手。我个人很喜欢这一点——毕竟SQL是通用语言，团队里随便拉个人都能写。

ClickHouse：类SQL但有限制

SELECT toStartOfMinute(ts) AS bucket,
       symbol,
       avg(price) AS avg_price
FROM ticks
WHERE symbol = 'BTCUSDT'
  AND ts > now() - INTERVAL 1 HOUR
GROUP BY bucket, symbol;

ClickHouse的SQL语法和标准SQL很像，但有一些限制——比如不支持UPDATE和DELETE（虽然最新版本有了轻量级删除）。如果你需要频繁修改数据，ClickHouse会让你很头疼。

DolphinDB：脚本语言+SQL混合

t = select avg(price) as avg_price from loadTable("dfs://tick", "ticks")
      where symbol=`BTCUSDT, ts > now() - 3600
      group by minute(ts) as bucket

DolphinDB的语法介于SQL和脚本之间。说实话，刚开始用的时候我挺不习惯的——它的函数命名和参数顺序跟主流数据库差别很大。但用熟了之后，你会发现它在处理复杂计算时特别顺手，比如计算VWAP、波动率这些指标。

四、生态成熟度：社区、工具、运维

选数据库不能只看性能，还得看生态。我见过太多项目，选了个冷门数据库，结果出了问题连个问的人都没有。

维度	InfluxDB	TimescaleDB	ClickHouse	DolphinDB
社区活跃度	高	中	高	低
监控工具	Grafana原生支持	Grafana+pgAdmin	Grafana+自研工具	自带Web界面
运维复杂度	低	中	高	高
文档质量	好	好	一般	差
第三方集成	丰富	丰富	中等	少

我个人建议：如果你团队小、运维能力弱，优先考虑InfluxDB或TimescaleDB。它们开箱即用，出了问题社区里一搜就有答案。ClickHouse虽然性能强，但运维门槛高——你得懂分布式架构、懂ZooKeeper、懂数据分片策略。

至于DolphinDB，嗯，它更像一个「封闭生态」。性能确实强，但文档写得像天书，社区里也没几个人。我建议除非你有专门的DolphinDB工程师，否则别轻易碰。

五、我的选型建议

说了这么多，到底怎么选？我根据实际项目经验，给你几个参考方案：

• 小团队、单机部署、数据量<1TB/天：选InfluxDB。简单、够用、社区支持好。
• 需要SQL兼容、团队有PostgreSQL经验：选TimescaleDB。性能稳定，生态成熟。
• 大数据量、需要做复杂分析、有运维能力：选ClickHouse。写入快、压缩高、查询强。
• 极致性能、有专门团队、愿意接受封闭生态：选DolphinDB。性能天花板最高，但代价也最大。

六、知识体系图

下面这张图展示了时序数据库选型的核心逻辑，你可以对照着看自己的场景适合哪个库：

这张图的核心逻辑很简单：先看数据量，再看团队能力。别一上来就追求最强性能，适合的才是最好的。

---

好了，时序数据库选型就聊到这儿。记住，没有完美的数据库，只有最适合你场景的数据库。选型之前，先搞清楚你的数据量、查询模式、团队能力，然后再做决定。