3. 时序数据库选型：InfluxDB、TimescaleDB、ClickHouse、TDengine对比
说实话，选型这事儿，我见过太多团队踩坑了。
有的团队一上来就追新，选了最火的数据库，结果业务场景根本不匹配。有的团队死守老一套，明明数据量已经翻了几十倍，还在用关系型数据库硬扛。嗯，这两种我都经历过。
今天咱们就聊聊，在风控系统里，到底该怎么选时序数据库。我会结合我自己的实战经验，把四个主流选手——InfluxDB、TimescaleDB、ClickHouse、TDengine——掰开揉碎了讲清楚。
核心观点：没有最好的数据库，只有最适合你场景的数据库。风控系统的时序数据选型，关键看三点——写入吞吐、查询模式、运维成本。
3.1 四个选手的定位差异
先给个总览。这四个数据库，其实代表了四种不同的设计哲学。
| 特性 | InfluxDB | TimescaleDB | ClickHouse | TDengine |
|---|---|---|---|---|
| 定位 | 纯时序数据库 | 时序+关系型混合 | 列式分析数据库 | 物联网时序数据库 |
| 存储引擎 | TSM Tree | 基于 PostgreSQL | MergeTree 系列 | 自研时序引擎 |
| 写入性能 | 高（单机百万点/秒） | 中（依赖 PostgreSQL） | 极高（列式批量写入） | 极高（单机千万点/秒） |
| 查询性能 | 中等（聚合查询快） | 中等（复杂SQL强） | 极高（OLAP场景） | 高（时序专用优化） |
| SQL支持 | 类SQL（Flux/InfluxQL） | 完整SQL | 完整SQL | 类SQL（有限支持） |
| 集群能力 | 企业版才支持 | 基于 PostgreSQL 扩展 | 原生分布式 | 原生分布式 |
| 运维复杂度 | 低 | 中 | 高 | 低 |
这张表你看完可能会觉得：「嗯，各有千秋嘛。」但实际选型时，你得结合自己的场景来权衡。
3.2 逐个拆解：我的实战感受
InfluxDB：小团队的首选
我个人习惯把 InfluxDB 叫做「时序数据库里的瑞士军刀」。它上手极快，安装完就能用，不需要调什么参数。
我在一个初创风控项目里用过 InfluxDB，那时候团队就三个人，数据量一天也就几千万条。我们用 InfluxDB 存用户行为事件，写了个简单的实时规则引擎，跑得挺欢。
优点：
- 安装配置简单，5分钟搞定
- 自带数据保留策略（Retention Policy），自动清理过期数据
- 连续查询（Continuous Query）做预聚合很方便
缺点：
- 集群版要收费，单机版扛不住大规模
- SQL 支持不完整，复杂分析得用 Flux 写，学习成本不低
- 数据一致性较弱，极端情况下可能丢数据
小提示：如果你团队小于10人，数据量在每天几亿条以内，InfluxDB 是个不错的选择。但别想着用它做复杂关联查询，那不是它的强项。
TimescaleDB：PostgreSQL 用户的福音
TimescaleDB 本质上就是个 PostgreSQL 插件。你想想看，如果你团队里全是 SQL 高手，那 TimescaleDB 简直就是天选之子。
我记得有一次，客户要求我们做「过去7天每个用户的登录次数，按小时聚合，还要关联用户画像表」。用 InfluxDB 我得写一堆 Flux 代码，用 TimescaleDB 一个 JOIN 就搞定了。
优点：
- 完整 SQL 支持，兼容 PostgreSQL 生态
- 自动分区（Hypertable），对开发者透明
- 支持复杂 JOIN、窗口函数、子查询
缺点：
- 写入性能不如专用时序库，高并发写入时容易成为瓶颈
- 存储压缩率一般，磁盘占用较大
- 集群方案依赖 PostgreSQL 的流复制，运维稍复杂
注意：我曾经在一个高并发写入场景（每秒10万+事件）里试过 TimescaleDB，结果写入延迟飙到了秒级。后来我们加了批量写入和缓冲层才解决。所以，如果你的写入量极大，TimescaleDB 可能不是最佳选择。
ClickHouse：分析场景的王者
ClickHouse 是这四个里面我最敬畏的一个。它的查询速度，真的快得离谱。
我在一个风控离线分析系统里用过 ClickHouse，数据量大概几百亿条。我们跑一个「过去30天每个用户的交易次数、金额、设备数」的聚合查询，ClickHouse 只需要几秒钟。同样的查询在 MySQL 里要跑几分钟。
优点：
- 列式存储，压缩率极高（通常能压到原始数据的1/10）
- 聚合查询速度极快，适合 OLAP 场景
- 原生分布式，扩展性好
缺点：
- 不适合点查（查单条记录很慢）
- 不支持事务，数据一致性较弱
- 运维复杂，参数调优需要经验
- 更新和删除操作成本高
我的建议：ClickHouse 最适合做「写多读少、聚合查询多、点查少」的场景。比如风控的离线特征计算、报表分析、异常检测。但别用它做实时风控决策，延迟太高。
TDengine：国产新秀，物联网场景的利器
TDengine 是近年来崛起最快的时序数据库之一。它的设计理念很纯粹——为物联网而生。
我在一个车联网风控项目里用过 TDengine，数据量每天几十亿条。它的写入性能确实惊人，单机就能扛住千万级写入。而且它的超级表（Super Table）设计，对多设备场景特别友好。
优点：
- 写入性能极高，单机千万点/秒
- 存储压缩率优秀，磁盘占用小
- 原生分布式，集群部署简单
- 超级表设计，方便管理多设备数据
缺点：
- SQL 支持有限，复杂查询能力弱
- 生态不如 InfluxDB 和 ClickHouse 丰富
- 社区版功能受限，企业版才支持一些高级特性
小提示：如果你的场景是「大量设备、高频写入、简单查询」，TDengine 是性价比很高的选择。但如果你需要做复杂分析，还是得搭配 ClickHouse 或 Spark 使用。
3.3 选型考量因素
说了这么多，到底该怎么选？我总结了一个「选型四步法」，你可以参考一下。
- 先看写入量：每天几亿条以内，InfluxDB 或 TimescaleDB 都行。每天几十亿条以上，考虑 ClickHouse 或 TDengine。
- 再看查询模式：如果主要是聚合查询、报表分析，ClickHouse 是首选。如果有点查需求（比如查某个用户的最新记录），InfluxDB 或 TDengine 更合适。
- 然后看团队能力：团队 SQL 能力强，选 TimescaleDB 或 ClickHouse。团队运维能力弱，选 InfluxDB 或 TDengine。
- 最后看预算：开源免费版里，ClickHouse 和 TDengine 功能最全。InfluxDB 的集群版要收费，TimescaleDB 的云服务也不便宜。
避坑指南：我曾经见过一个团队，选了 ClickHouse 做实时风控决策。结果因为 ClickHouse 的写入延迟不稳定，导致规则触发不及时，造成了不小的损失。所以，选型时一定要搞清楚你的业务对延迟的容忍度。
3.4 知识体系图
下面这张图，是我自己梳理的时序数据库选型决策流程。你可以把它当作一个快速参考。
3.5 总结
选型这事儿，说白了就是「匹配」二字。匹配你的数据量、匹配你的查询模式、匹配你的团队能力。
我个人建议，如果你还在犹豫，可以先从 InfluxDB 或 TimescaleDB 入手。它们上手快、社区活跃，踩坑了也容易找到解决方案。等业务规模上来了，再考虑迁移到 ClickHouse 或 TDengine。
记住，没有银弹。选型只是开始，后续的调优、运维、架构演进，才是真正的考验。
最后说一句：如果你正在做选型，不妨先拿一个月的真实数据，在几个候选数据库上跑个 POC（概念验证）。数据不会骗人，跑完你就知道该选谁了。