随着业务数据量级的上升，理想汽车的物联网场景业务对数据存储性能的要求不断提高。我们内部团队也在积极探索不同的数据库与不同场景的佳实践匹配，本文将分享TDengine在我们的物联网场景的落地经验。

首先我们来了解一下业务场景。

一、业务场景介绍

我们有信号上报业务，需要将标记时间戳和采集点的信息，通过云端写入到后端数据库中，有一定的聚合查询需求。这是典型的高并发插入场景，写多读少。目前的压力为7万的写入QPS，预计未来3年将达到20万以上。

我们之前的系统用的是MongoDB。业务存储放在MongoDB，后来因为MongoDB的局限性，我们将业务迁移到了TiDB，方便进行扩缩容。

迁移到TiDB之后，在目前使用百度云SSD虚拟机的情况下，TiDB集群纯写入性能并不能达到我们的业务期望预期（HTAP场景数据库对纯高并发写入支持不好，与该业务场景的适配性不高），需要不断的资源扩容。整体来看，TiDB适合TP或者轻AP场景，而且TiDB对硬件配置要求很高。对于时序数据，写入用TiDB的话性价比很低。另外对业务有入侵性，底层库表要按照月份来建表，还要针对每个采集点打上标签。一次性大批量写入场景也不太适配。

总的来说，当前架构主要存在如下痛点和新需求：

• 持续高并发写入，带有tag，时间戳有时会乱序；

• 业务数量级膨胀极快，需求无感知scale-out；

• 对基于时间戳范围的聚合查询有一定的需求；

• 因为数据量非常大，所以需要支持数据压缩，降本增效；

• 希望可以不用针对月份数据进行分库分表，需求TTL机制；

• 希望可以针对采集点单独建表；

• 希望支持批量数据写入，且业务期望写入延时较低。

  
  

• 两级存储结构，数据插入性能高，资源利用率高；

• 对时序数据压缩率极高；

• 针对采集点单独建表，匹配业务场景；

• 支持大批量数据写入；

• 无感知的scale-out和scale-in；

• 支持TTL。

  
  

2.1 迁移过程

1. 先切写流量到TDengine，历史读流量在TiDB的方案

2. 逐步将历史数据格式化导入到TDengine

3. 部署方案: 采用域名—>LB—>firstEP+SecondEP的方式，具体可以参

   考《TDengine容器化部署的佳实践》这篇博客。

   
   

• 非常的时序数据库，性能比InfluxDB要强出许多，两级存储架构

  设计(行存与列存)很棒；

• 适配物联网的大数据存储场景(TDengine从超级表概念的引入到架构

  设计，决定了其适配的场景)；

• 非常低廉的机器使用成本；

• 方便的弹性扩缩容，引入了firstEP机制；

• 对聚合类查询的速度支持也很快；

• 有TTL和标签机制，对业务透明。

• 监控指标的完整性有待提高，只有基础的监控指标，性能排查还要看

  日志，写入延时要通过业务监控去看；

• 周边生态工具支持待完善，对于运维管理人员不是很方便；

• 应用端和客户端要求强一致，如果升级版本，则客户端也要一起升级，重新打包进K8s node，滚动批次更新多个客户端，这点不是很友好；

• 各类报错信息还需要进一步完善，对用户更友好一些，方便排查问题；

• Go的SDK不支持prepare statement（新版本已经支持——编者注）；

• 账号隔离支持有待完善，为了避免互相影响，只能从业务上约束，或者一套业务一个集群。

来源 https://www.modb.pro/db/168852