时序数据库选型指南：我们是怎么评估和选型的
时序数据库选型指南：我们是怎么评估和选型的
最近团队在重构物联网大数据平台，最头疼的就是时序数据库选型。市面上号称“专为时序数据设计”的数据库少说也有二三十种，每家都说自己“性能最强”“压缩比最高”“查询最快”。花了小半年时间调研、测试、对比，踩了不少坑，也积累了一些经验。
今天不吹不黑，把选型过程中的思考框架和真实体验分享出来，希望对正在做技术选型的同学有所帮助。
为什么需要独立的时序数据库？
先说个题外话。最开始有人质疑：直接用关系型数据库或者NoSQL不就行了，干嘛非要单独弄个时序库？
其实这是个经典误区。我们早期用过MySQL存设备数据，一张表几十亿行数据，查询一个设备一天的数据要等好几分钟，写入压力大的时候还经常死锁。后来试过HBase，写性能确实上来了，但查询复杂度和存储膨胀的问题又让人头疼。
时序数据有自己独特的特点：写多读少、数据量大、有时间维度、查询模式相对固定（按时间范围、聚合、降采样）。通用数据库没有针对这些场景做优化，要么写入成为瓶颈，要么查询慢得无法接受，要么存储成本爆炸。这就催生了专门为时序数据设计的数据库。
选型框架：我们重点关注什么
在开始评估具体产品之前，我们先把评估维度定下来。这个框架花了两周时间反复讨论，最终确定了五个核心维度：
1. 写入性能
物联网场景下，成千上万的设备并发上报数据，写入吞吐必须足够高，延迟要低。我们内部定的及格线是：单节点至少支撑50万点/秒写入，平均延迟<10ms。
测试方法：用同一批模拟设备数据，在相同硬件配置下跑压力测试，对比各产品的极限写入能力和延迟稳定性。
2. 存储成本
时序数据量级动不动就PB级别，压缩能力直接决定硬件成本和运维负担。我们的目标是：原始数据压缩比至少达到5倍以上。
测试方法：同样规模的数据（比如10亿个数据点），对比不同产品最终占用的磁盘空间。这个差距往往非常大，有的产品压缩后只有原始数据的1/10，有的只压缩了一半。
3. 查询能力
不只是简单的点查，还要支持时间范围查询、聚合分析、降采样、甚至一些简单的时序计算。我们主要测试了三种典型查询场景：
- 点查：查询某个设备某个测点的最新值
- 范围查：查询某设备一天内的所有数据
- 聚合查：按小时/天聚合统计（平均值、最大值、最小值等）
4. 生态与集成
能不能和现有的大数据组件（Spark、Hadoop、Grafana等）无缝对接。我们现有的技术栈里有Kafka、Spark、Grafana，所以入选产品至少要能跟这些组件顺畅集成。
5. 运维复杂度
部署、扩容、备份、恢复这些日常操作的便捷程度，直接决定团队幸福感。我们的原则是：学习成本低、文档完善、社区活跃。
主流时序数据库横向对比
按照上述框架，我们筛选了4个候选产品进行深度测试。下面简单说下各自的优缺点。
方案A：InfluxDB（国外主流）
InfluxDB是时序数据库领域的“老大哥”，生态成熟、文档完善、社区庞大。它的TICK技术栈（Telegraf、InfluxDB、Chronograf、Kapacitor）非常完整，开箱即用。
优点：
- 生态完整，从采集到展示一条龙
- 社区活跃，遇到问题容易搜到解决方案
- 查询语言InfluxQL和Flux都比较强大
缺点：
- 开源版集群功能受限，真正做集群需要商业版
- 存储成本偏高，压缩比不如一些新方案
- 对国内用户来说，官方支持有时差
方案B：TimescaleDB（基于PostgreSQL）
TimescaleDB走的是另一条路——在PostgreSQL之上扩展成时序数据库。它的优势是“能复用PostgreSQL生态”。
优点：
- 继承了PostgreSQL的稳定性和生态
- 完整支持SQL，学习成本最低
- 社区活跃，文档详细
缺点：
- 写入性能相对一般，不如专门设计的时序库
- 存储压缩比在高压场景下不够理想
- 本质上还是关系型数据库的底子，时序特性是“加”上去的
方案C：Apache IoTDB（国产自研）
这是最终入选的方案，也是我们花最多时间测试的产品。IoTDB是Apache顶级项目，从清华发起的国产自研时序数据库，专门为物联网场景设计。
优点：
- 列式存储+极致压缩：自研TsFile格式，压缩比官方说10倍以上，我们实测20TB压到2TB左右，效果确实惊人
- 写入性能强：三台普通服务器稳定写入1500万点/秒
- 查询毫秒级：亿级数据量的聚合查询秒级返回
- SQL-like语法：团队学习成本低
- 云边协同：支持边缘端和云端自动同步，这个功能很多竞品没有
- 国产自研：代码可控、中文社区活跃
需要注意的地方：
- 强事务场景不适合
- 复杂JOIN查询能力有限
方案D：QuestDB（新兴方案）
QuestDB是近两年比较火的开源时序数据库，主打高性能和SQL支持。
优点：
- 写入性能出色，尤其是对于流式数据
- 完整支持SQL，标准JDBC/PostgreSQL协议
- 单机性能很强
缺点：
- 生态相对较新，周边工具不如老牌丰富
- 集群版需要商业授权
我们为什么最终选了IoTDB
坦诚说，四个候选产品各有千秋，没有绝对的好坏。最终选IoTDB，是基于我们的业务场景匹配度做出的决策。
我们的场景有几个特点：
- 设备规模大：百万级设备，每秒千万级数据点写入
- 存储敏感：需要保存5年以上历史数据，存储成本是硬约束
- 查询模式固定：主要是时间范围查询和聚合分析，不需要复杂JOIN
- 有边缘端需求：部分数据需要在边缘节点先聚合再同步到中心
- 国产化要求：客户有自主可控的诉求
在这几个维度上，IoTDB的匹配度最高：
- 压缩比确实帮我们省了大量存储成本
- 写入性能满足峰值要求
- 云边协同省去了自研数据同步的麻烦
- 国产自研满足合规要求
参考资料（部分）：
- Apache IoTDB 官方网站与下载页面
https://iotdb.apache.org/zh/Download/ - 天谋科技（Timecho）官网
https://timecho.com
（注：本文提到的相关链接和详细资料，均已整理并标注在CSDN编辑器的“参考资料”区域，方便读者查阅。）
部署和运维体验
聊聊实际使用中的感受：
部署还算简单：下载二进制包，解压，修改几个配置，./start-server.sh就能启动。分布式部署需要配置一下节点信息，但官方文档写得很清楚，照着操作半小时能搭起一个3节点集群。
升级不麻烦：从旧版本升级到新版本，官方有详细的升级指南。小版本升级直接替换jar包重启就行，大版本升级也有数据迁移工具。
监控方便：IoTDB内置了Prometheus metrics接口，可以无缝接入现有的监控体系。我们配置了Grafana dashboard，集群状态、写入速率、查询延迟一目了然。
需要留意的几个地方
任何一个技术都有其适用场景，IoTDB也不例外：
强事务场景不合适：IoTDB虽然支持单条数据的ACID，但对跨设备、跨时间范围的事务支持有限。如果业务需要复杂的分布式事务，它可能不是最佳选择。
非时序数据别往里存：别用它存订单、用户信息这些典型的事务型数据，那不是它的设计目标。
复杂查询不是强项：IoTDB主要针对时序查询模式做了优化，如果需要复杂的JOIN、子查询、随心所欲的分组聚合，建议把数据同步到分析型数据库处理。
一些实际案例参考
选型过程中，我们也关注了各产品在生产环境的落地情况。IoTDB这边看到不少知名企业的案例：
中车四方：用于300辆列车的智能运维，日增4140亿数据点，服务器数量缩减到原来的1/13，月数据增量压缩后大小下降95%。
国家电网：服务大唐集团60家电厂，每家电厂日数据量17亿以上，运维成本减少95%。
宝武钢铁：接入单时间序列2000亿个点，写入速度达到3000万每秒。
华为、阿里云也与IoTDB有深度合作，集成到各自的云产品中。
其他产品也各有知名用户，比如InfluxDB在监控领域应用广泛，TimescaleDB在需要复用时序数据和关系型数据的场景中很受欢迎。
总结：怎么选适合自己的
最后说几个选型建议，不一定对，仅供参考：
如果主要看性能和压缩比，设备规模大、数据量级高：可以重点看看IoTDB，它在这个方向上做得比较极致。
如果看重生态和社区，需要强大的周边工具链：InfluxDB的TICK技术栈是加分项，开源版本的功能也够用。
如果团队熟悉PostgreSQL，希望复用SQL技能：TimescaleDB是个值得考虑的选择，学习成本最低。
如果是新项目、追求极致单机性能：QuestDB值得一试，发展势头不错。
建议做一次真实场景的POC测试：用自己最核心的业务数据，在同样的硬件配置下跑一轮压测，重点关注写入性能、存储占用、典型查询耗时三个指标。数据迁移的成本远高于前期的调研投入，花点时间把对比做扎实是值得的。
希望这篇分享能给大家一些参考，少走一些弯路。