第4章时序数据库选型

4. 时序数据库选型：InfluxDB、TimescaleDB、ClickHouse、DolphinDB对比；选型决策矩阵

好，咱们进入正题。选型这件事，说白了就是「没有银弹」。我见过太多团队，一上来就拍脑袋选 InfluxDB，结果写到后面发现查询性能扛不住。也见过有人迷信 ClickHouse，结果发现单条写入延迟高得离谱。

今天我就把这四个主流时序数据库掰开揉碎讲清楚。每个我都亲手用过，踩过坑，也填过坑。

先给个总览，让你心里有个谱：

嗯，这里要注意。这四个东西虽然都叫时序数据库，但设计哲学完全不同。你选错了，后面改起来会非常痛苦。

我个人习惯把 InfluxDB 叫做「时序界的 MongoDB」。它的数据模型是 tag + field + timestamp，写起来非常自然。我记得第一次用的时候，半小时就搭好了原型。

但坑也在这里。InfluxDB 的集群版（InfluxDB Enterprise）是收费的，而且性能远不如开源版吹得那么神。我在项目中遇到过，单机写入 10 万点/秒没问题，但一旦要跨节点查询，延迟直接翻倍。

适用场景：中小规模监控、IoT 设备数据、快速原型验证。

避坑：不要用它做高频 Tick 存储，写入超过 50 万点/秒时，TSM 引擎的 compaction 会成为瓶颈。

TimescaleDB 本质上就是个 PostgreSQL 插件。你想想看，这意味着什么？意味着你可以直接用 SQL，用 JOIN，用窗口函数。对于团队里熟悉关系型数据库的人来说，简直不要太友好。

我曾经在一个量化回测系统里用过它。当时需要把 Tick 数据和订单数据做关联查询，InfluxDB 搞不定，ClickHouse 的 JOIN 又太弱，最后选了 TimescaleDB。效果还不错，但写入性能确实一般。

我的建议：如果你已经有 PostgreSQL 生态，或者需要复杂关联查询，TimescaleDB 是首选。但别指望它扛住百万级写入。

ClickHouse 是个狠角色。列式存储 + 向量化执行，查询速度是真的快。我做过测试，10 亿行数据做聚合查询，ClickHouse 比 InfluxDB 快 10 倍以上。

但它的短板也很明显。单条写入延迟高，不适合做实时写入。说白了，它更适合「先攒一批，再批量写入」的场景。另外，它的更新和删除操作非常笨重，别指望用它做事务。

注意：ClickHouse 的 MergeTree 引擎在数据合并时会有 IO 毛刺。如果你做高频交易，这个毛刺可能导致 Tick 数据丢失。我吃过这个亏。

DolphinDB 是金融圈的老炮儿。它把时序存储和分布式计算揉在了一起，支持内存表、流计算、甚至机器学习。说实话，它的性能是真的猛，单机就能跑到百万级写入。

但学习曲线也真的陡。它的脚本语言是自创的，跟 SQL 不太一样。我刚开始用的时候，光是理解分区策略就花了一周。不过一旦上手，做 Tick 级别的回测和实时计算，简直如鱼得水。

适用场景：高频量化交易、实时风控、复杂事件处理。

避坑：社区版有节点数限制，商业版价格不菲。小团队慎入。

好了，光说不练假把式。我整理了一个决策矩阵，你直接对着自己的需求打分就行。

评估维度	InfluxDB	TimescaleDB	ClickHouse	DolphinDB
写入吞吐（单机）	⭐⭐⭐	⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐⭐
查询延迟（聚合）	⭐⭐⭐	⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐
SQL 兼容性	⭐（类 SQL）	⭐⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐（自创语言）
分布式能力	⭐⭐（企业版）	⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐⭐
运维复杂度	⭐⭐⭐⭐⭐（简单）	⭐⭐⭐⭐	⭐⭐⭐	⭐⭐
学习成本	⭐⭐⭐⭐⭐（低）	⭐⭐⭐⭐	⭐⭐⭐	⭐（高）
金融 Tick 场景	⭐	⭐⭐	⭐⭐⭐	⭐⭐⭐⭐⭐

怎么用这个表？很简单。把你最看重的三个维度圈出来，然后看哪个数据库的总分最高。比如你做高频 Tick，那写入吞吐和查询延迟就是命门，DolphinDB 基本是唯一选择。

最后分享一个我自己的决策流程。不复杂，就三步：

一个小技巧：如果你实在拿不准，可以先用 InfluxDB 做原型，跑通流程。等数据量上来后，再考虑迁移到 ClickHouse 或 DolphinDB。别一开始就上重武器。

嗯，选型这事没有标准答案。但只要你把写入、查询、团队这三个维度想清楚，就不会跑偏。下一节咱们聊聊具体的存储引擎设计，到时候我会拿 Tick 数据举例，手把手教你做 schema 设计。