共计 1656 个字符，预计需要花费 5 分钟才能阅读完成。
对于作者
郑赫扬，现实汽车数据库高级开发工程师。目前负责公司分布式数据库的业务落地和运维平台产品开发。
随着业务数据量级的回升，现实汽车的物联网场景业务对数据存储性能的要求一直进步。咱们外部团队也在积极探索不同的数据库与不同场景的最佳实际匹配，本文将分享 TDengine 在咱们的物联网场景的落地教训。
首先咱们来理解一下业务场景。
1. 业务场景介绍
咱们有信号上报业务，须要将标记工夫戳和采集点的信息，通过云端写入到后端数据库中，有肯定的聚合查问需要。这是典型的高并发插入场景，写多读少。目前的压力为 7 万的写入 QPS，预计将来 3 年将达到 20 万以上。
咱们之前的零碎用的是 MongoDB。业务存储放在 MongoDB，起初因为 MongoDB 的局限性，咱们将业务迁徙到了 TiDB，不便进行扩缩容。
迁徙到 TiDB 之后，在目前应用百度云 SSD 虚拟机的状况下，TiDB 集群纯写入性能并不能达到咱们的业务冀望预期（HTAP 场景数据库对纯高并发写入反对不好，与该业务场景的适配性不高），须要一直的资源扩容。整体来看，TiDB 适宜 TP 或者轻 AP 场景，而且 TiDB 对硬件配置要求很高。对于时序数据，写入用 TiDB 的话性价比很低。另外对业务有入侵性，底层库表要依照月份来建表，还要针对每个采集点打上标签。一次性大批量写入场景也不太适配。
总的来说，以后架构次要存在如下痛点和新需要：
- 继续高并发写入，带有 tag，工夫戳有时会乱序；
- 业务数量级收缩极快，需要无感知 scale-out；
- 对基于工夫戳范畴的聚合查问有肯定的需要；
- 因为数据量十分大，所以须要反对数据压缩，降本增效；
- 心愿能够不必针对月份数据进行分库分表，需要 TTL 机制；
- 心愿能够针对采集点独自建表；
- 心愿反对批量数据写入，且业务冀望写入延时较低。
基于这些需要，咱们决定尝试一下时序数据库 TDengine。通过跟官网的深刻业务封闭式测试，该数据库产品的性能超出预期。在此也特别感谢肖波、陈伟灿和杨丽娜三位老师的大力支持。
TDengine 的以下特点可能很好地满足咱们的场景：
- 两级存储构造，数据插入性能高，资源利用率高；
- 对时序数据压缩率极高；
- 针对采集点独自建表，匹配业务场景；
- 反对大批量数据写入；
- 无感知的 scale-out 和 scale-in；
- 反对 TTL。
TDengine 极其优良的高并发写入和数据压缩能力，极大升高了业务老本和业务压力，因而咱们决定从 TiDB 迁徙至 TDengine。
2. 业务迁徙过程与应用老本
2.1 迁徙过程
迁徙计划：
- 先切写流量到 TDengine，历史读流量在 TiDB 的计划
- 逐渐将历史数据格式化导入到 TDengine
- 部署计划: 采纳域名—>LB—>firstEP+SecondEP 的形式，具体能够参考《TDengine 容器化部署的最佳实际》这篇博客。
2.2 应用老本比照
3.TDengine 集体总结
长处：
- 十分优良的时序数据库，性能比 InfluxDB 要强出许多，两级存储架构设计 (行存与列存) 很棒；
- 适配物联网的大数据存储场景(TDengine 从超级表概念的引入到架构设计，决定了其适配的场景)；
- 十分低廉的机器应用老本；
- 不便的弹性扩缩容，引入了 firstEP 机制；
- 对聚合类查问的速度反对也很快；
- 有 TTL 和标签机制，对业务通明。
待改善的中央：
- 监控指标的完整性有待进步，只有根底的监控指标，性能排查还要看日志，写入延时要通过业务监控去看；
- 周边生态工具反对待欠缺，对于运维管理人员不是很不便；
- 利用端和客户端要求强统一，如果降级版本，则客户端也要一起降级，从新打包进 K8s node，滚动批次更新多个客户端，这点不是很敌对；
- 各类报错信息还须要进一步欠缺，对用户更敌对一些，不便排查问题；
- Go 的 SDK 不反对 prepare statement（新版本曾经反对——编者注）；
- 账号隔离反对有待欠缺，为了防止相互影响，只能从业务上束缚，或者一套业务一个集群。
最终，无论是 MySQL、MongoDB、TiDB 还是 TDengine，都是优良的数据库产品，然而没有一种数据库产品是银弹，还是业务场景为王，适配业务的才是好产品。
