共计 2006 个字符，预计需要花费 6 分钟才能阅读完成。
小 T 导读：此前，韵达应用 MySQL 分区 + 索引解决订单数据的形式蒙受到了挑战，面对每日亿级的数据量，MySQL 显然曾经无奈满足当下的数据处理需要。为更好地倒退业务，在此基础上韵达新增了 TDengine 的数据源，用业余的数据库来进行时序数据的解决。
作为一家头部物流公司，韵达每日的订单扫描量能达到上亿级，这也是目前公司数据量最大的一块业务。要保障业务的失常运作，零碎就须要汇总统计全国网点的扫描数据（韵达的所有订单数据），并实时反馈给用户。此外，这些数据也会给到网点、分拨核心的外部员工应用，用于集体工作量、站点扫描量等统计工作。
在业务尚未扩张之前，咱们采纳的是 MySQL 分区 + 索引形式进行此类数据的解决，但随着企业的倒退、业务量的减少，面对每日亿级的数据量，MySQL 显然曾经无奈满足当下的数据处理需要。
在这种背景下，咱们决定进行数据库选型。思考到目前业务次要是统计各个网点设施实时上传的数据，无需再进行批改等操作，是典型的时序数据。通过一番调研，咱们发现时序数据库 TDengine 就很合乎当下的业务要求，其数据模型与咱们的场景非常符合，基于百亿千亿级大数据量的查问性能也很强悍。在对 TDengine 进行理论测试与应用后，理论的成果也让咱们很称心。
一、落地实际与成果展现
以后咱们的架构是 Spring Boot + MyBatis + MySQL + TDengine，TDengine 负责解决时序数据，MySQL 则负责非时序数据的存储及利用，整体架构如下：
因为咱们的架构未做迁徙，只是新增了 TDengine 的数据源，因而没有减少很多工作量就实现了数据架构的降级。
咱们目前应用 TDengine2.2.2.0 版本，在三台 16C 64G 的服务器上部署了集群，数据写入速度大略为每秒 2000 行。依据“一个扫描枪一张表”的模型建表，把设施的地点和站点类型设置为标签。
为了避免设施更换地点导致标签值发生变化，咱们抉择在建表的时候把地点也放进表名中，这样一来，当地点发生变化后，也能通过新建一张表白到同样的应用成果。比方：scan_6100000000265_790117，代表的就是设施编号为 6100000000265 所在地址为 790117 的扫描枪，当这把扫描枪更换地位的时候，咱们能够新建一张 scan_6100000000265_800000 的子表，和旧表辨别开，并且同时保留两份数据。
以后，这个超级表上面曾经有了近百万子表，通过 1 个多月的正式应用，保留了大概 200 亿行的数据量。
值得一提的是，基于 TDengine 罕用的查问根本能够在 1 秒之内实现，一些特定查问甚至能够达到毫秒级：
select location,sum(weight_info) as weightSum,count (waybill_barcode) as ticketNum from base.scan_data where ts>=’2022-04-07 00:00:00′ and ts<=’2022-04-07 23:59:59′ group by location;
展现成果如下：
select waybill_barcode,location,scanning_person,scan_category,remark,weight_info weight,scan_time,volume from base.scan_data where ts>=’2022-04-07 00:00:00′ and ts<=’2022-04-07 23:59:59′ and site_type=3 limit 0,10;
展现成果如下：
在存储上能够看到，咱们的超级表是 20 个字段，大部分是 int 类型，有 5 个左右是 varchar 类型，最大的字段是一个用来存储中文的 500 长度的 nchar，大概占用 300GB 不到的磁盘。而此前应用 MySQL 时，光硬盘应用就须要几个 TB，这还没有算上内存和 CPU 等资源，由此可见 TDengine 带来的降本增效是如许显著。
写在最初
当然，TDengine 的测试应用过程中也并非一帆风顺，咱们也遇到了一些问题，放在这里供大家参考：
- 因为对数据并发量预估有余，咱们应用的默认毫秒工夫精度常常会呈现工夫戳反复的景象，导致数据没能胜利入库，后续依附减少精度解决。
- 超级表如果新增标签，已有数据的标签为 null，须要手动为每个子表更改标签，不够敌对。
- 因为 TDengine 建表是单线程所以是有瓶颈的，大略每秒是万张以下，所以在初步搭建环境的时候不倡议应用主动建表，如果表数据量不多就无所谓了。
在与 TDengine 的社区工作人员反馈之后，以上问题最终都通过参数的配置优化或者正当的应用形式失去了解决，之后咱们会思考把 TDengine 扩大到更多业务中去。置信随着 3.0 的优化，TDengine 能够更好地融入到韵达的应用场景中，将来咱们会有更加严密的单干。
想理解更多 TDengine 的具体细节，欢送大家在 GitHub 上查看相干源代码。
