（ChinaIT.com讯）随着营业数据量级的上升，抱负汽车的物联网场景营业对数据存储性能的要求不停进步。我们内部团队也在积极探究差别的数据库与差别场景的最佳实践立室，本文将分享TDengine在我们的物联网场景的落地履历。

起首我们来相识一下营业场景。

一、营业场景先容

我们有信号上报营业，必要将标志时间戳和收罗点的信息，通过云端写入到后端数据库中，有必然的聚合盘问需求。这是典范的高并发插入场景，写多读少。现在的压力为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.1 迁徙历程

迁徙方案：

1. 先切写流量到TDengine，汗青读流量在TiDB的方案
2. 渐渐将汗青数据款式化导入到TDengine
3. 摆设方案: 采纳域名—>LB—>firstEP+SecondEP的方法，详细可以参考《TDengine容器化摆设的最佳实践》这篇博客。

2.2 利用本钱

TDengine与TiDB的利用本钱比拟

三、TDengine利用总结

长处：

• 非常优异的时序数据库，性能比InfluxDB要强出很多，两级存储架构设计(行存与列存)很棒；
• 适配物联网的大数据存储场景(TDengine从超等表观点的引入到架构设计，决定了其适配的场景)；
• 非常低廉的呆板利用本钱；
• 便利的弹性扩缩容，引入了firstEP机制；
• 对聚合类盘问的速率支持也很快；
• 有TTL和标签机制，对营业透亮。

待改进的地方：

• 监控指标的完备性有待进步，只有底子的监控指标，性能排查还要看日记，写入延时要通过营业监控去看；
• 周边生态东西支持待美满，对付运维治理职员不是很便利；
• 应用端和客户端要求强同等，假如升级版本，则客户端也要一路升级，重新打包进K8s node，转动批次更新多个客户端，这点不是很友爱；
• 各种报错信息还必要进一步美满，对用户更友爱一些，便利排盘问题；
• Go的SDK不支持prepare statement（新版本已经支持——编者注）；
• 账号断绝支持有待美满，为了幸免相互影响，只能从营业上束缚，大概一套营业一个集群。

终极，无论是MySQL、MongoDB、TiDB照旧TDengine，都是优异的数据库产物，但是没有一种数据库产物是银弹，照旧营业场景为王，适配营业的才是好产物。

泉源：TDengine