双重调研测试后，OPPOIoT类产品开始接入TDengine

　　在OPPO的穿戴产品的手环手表类业务中，产生的数据类型为时序数据，具有写入量巨大且存在离线历史数据补录（更新）的处理需求。此前使用的MongoDBMySQL集群方案，后端存储压力较大，需要经常扩盘，针对此痛点，OPPO云计算中心智慧物联云团队尝试调研对比了几款时序数据库（TimeSeriesDatabase）产品，试图寻找一个降本增效的解决方案。
　　除了存储压力外，我们进行数据库替换还有一个比较重要的原因，就是MySQL和MongoDB的各个集群都比较独立，维护和需求开发成本相对较高。
　　以上是三款Database的初步调研结果，TSHouse是OPPO云监控时序数据库，其底层为Prometheus的TSDB存储引擎，目前不支持历史数据和乱序写入；InfluxDB对历史数据写入会进行二次压缩，影响性能，这两款数据库都不满足当下的数据处理需求。初步研究TDengine后，我们发现其作为国产时序数据库开源产品，不仅可以满足历史数据高效写入，还拥有较高的压缩能力。随后，我们选择对TDengine进行了比较详细的产品调研和性能测试。TDengine产品与能力调研产品调研
　　某个数据表的结构如下：
　　我们写入60万行数据，到MySQL（目前部分业务部署在MySQL集群）和TDengine的4C12G容器上，对CPU内存磁盘进行观察。测试发现CPU和内存消耗基本持平的情况下，TDengine的落盘数据是MySQL环境的14左右。
　　同时，我们在不同规格容器及物理机场景下进行TDengine写入测试，部分记录如下：
　　需要说明的是，对于不同业务场景需要进行实际测试，才能确定适合该业务的部署参数。在整个测试过程中，TDengine工程师们也为我们进行了及时答疑和帮助。能力调研
　　随后我们根据TDengine丰富的产品手册，对一些关键能力进行了验证，包括数据管理、数据写入、聚合计算、集群扩容、故障可靠性保证等场景。
　　在数据管理上，TDengine的元数据与业务数据是分离开来的。如下图所示，Mnode负责管理元数据信息；单个Vnode可以存放多个表数据，相当于相当于水平分片，单个表的数据，又可以继续按照日期分片。
　　在数据写入逻辑上，整体和LSM类似：WAL，内存块，磁盘FILE。
　　在TDengine中，数据在文件中是按块连续存储的。每个数据块只包含一张表的数据，且数据是按照时间主键递增排列的。数据在数据块中按列存储，这样使得同类型的数据能够存放在一起，大大提高了压缩比，节省了存储空间。
　　TDengine是10天一组datafile，datafile里的。data文件只进行追加，且后续不会进行压缩。这种好处是：对历史数据和乱序极其友好，非常适用于IoT场景；没有压缩也就减少了写入之后的资源消耗，保证了较好的读写性能。TDengine落地实践
　　在经历了比较充分调研后，我们根据业务写入模型，对生产环境中某一套MySQL集群环境，进行TDengine集群部署，搭建了如下所示的集群：
　　集群为3台AWSEC2容器（8C32GB3。5TBNVME盘）组成，配置为3节点、2副本，写入端使用RESTful请求到VIP节点，转发到数据库服务。图中的V0V2为副本数为2的3组数据分片，M0M2为副本数为3的1组管理节点。
　　配置的Grafana面板展示如下：
　　后台表结构展示如下：
　　目前数据已经开始接入TDengine的数据库，历史数据也在同步导入中。实际效果展示
　　1。使用lastrow（）函数一次性输出38万个设备查询最新状态，结果如下所示。
　　2。使用interval（）查询某个设备每1小时的总步数，结果如下所示。
　　在存储方面，由于目前数据还没有完全导入，针对生产环境的一个6。6TB集群，我们粗略估计了一下前后的压缩比，大概在6。60。4。
　　在我们原来的集群中是没有副本的，单纯就部署了MySQL的5个分库，使用了4C8GB2TB的5台机器，在应用TDengine之后，现在是8C32GB2TB的3台机器。通过TDengine我们构建了多副本和统一的能力，以及后续上混合云的能力，这是整个平台级的一个优化与提升。写在最后
　　在前期调研和集群搭建过程中，TDengineDatabase的工程师伙伴们给我们提供了充分且及时的协助，为我们构建时序数据后端能力提供了很大帮助。目前接入TDengine的数据是海外某集群，后续我们会根据业务进展陆续进行其他集群数据的接入。
　　开源、高性能、分布式、支持SQL的时序数据库TDengine涛思数据点击了解更多TDengineDatabase的具体细节。