TDengine
小T导读
为了有效处理每日亿级的数据量，早在 2021 年，韵达就选择用 TDengine 替代了 MySQL，并在三台服务器上成功部署和上线了 TDengine 2.0 集群。如今，随着 TDengine 3.0 版本的逐渐成熟，韵达决定将现有的 2.0 版本升级到 3.0 版本，并基于本文为大家分享其在升级过程中所进行的优化措施以及升级后的性能表现。
本文用于分享我司在 TDengine 上使用的历程和心得。
在早些年业务尚未扩张时，我们采用的是 MySQL 分区+索引方式进行扫描枪数据的处理，但随着企业的发展、业务量的增加，面对每日亿级的数据量，MySQL 显然已经无法满足当下的数据处理需求。
在这种背景下，我们决定进行时序数据库（Time Series Database）选型。经过严格的选项测试，我们最终选择了 TDengine 作为核心数据库处理该部分数据。在 2021 年，我们在三台 16C 64G 的服务器上部署上线了 TDengine 2.0 版本集群。（https://www.taosdata.com/tdengine-user-cases/7815.html）
该集群每天要承载日常 6 亿行数据的写入和一定量的查询，“双十一、二”等特殊业务期间，写入/查询量还要上涨 50% 左右，数据需要保留 2 个月。
我们的架构是 Spring Boot + MyBatis + MySQL + TDengine，TDengine 负责处理时序数据，MySQL 则负责非时序数据的存储及应用，如下：
数据库迁移是一项很重大的工作，在此期间，我们仔细梳理了 2.0 版本使用期间的一些使用情况，尝试做出针对性的优化。
在 2.0 时期，我们是根据“一个扫描枪一张表”的模型建表，把设备的地点和站点类型设置为标签。来到 3.0 时期后，我们和官方团队反复调试，选择了“一个站点一张表”的建模方式。这样一来，表数量从百万级直接缩减到了万级。
做这个改动的核心原因有两个：
我们有很多临时的虚拟扫描枪，由于只是临时使用，所以没有几条数据，但却单独占据了一个表。 虽然扫描枪写入频率较低，但是整个站点有很多扫描枪，这样的建模方式使得低频写入转化为了高频写入，降低了存储中碎片数据的比例。
2.x 超级表结构：
除此之外，3.0 由于底层有很多的重构，因此和 2.0 相比出现了很多的参数改动，可以参考：https://docs.taosdata.com/reference/config/，https://docs.taosdata.com/taos-sql/database/。优化思路可以参考这篇文章中的内容：https://www.taosdata.com/tdengine-engineering/21550.html。
最终优化过后，我们的查询速度得到了进一步提升。尤其是下面这类查询优化效果十分明显，该查询的逻辑是：从 6 亿行的当天数据中，通过标签、普通列做出多次筛选，最终返回分页后的十条结果。其中，最为耗时的便是从标签过滤之后的 1.5 亿条数据的普通列筛选。
在 2.6 版本中，这个过程需要大约 10 秒的时间，升级到 3.x 之后，只需要 2-3 秒左右便会返回结果：
select waybill_barcode,location,scanning_person,equipment_code,scan_category,remark,weight_info weight,scan_time,volume,lower_location,lrfs from base.scan_data WHERE ts >= #{beginTime} and ts <= #{endTime} and site_type=#{siteType} and equipment_code = #{equipmentCode} limit 0,10;
对于我们这种集快递、物流、电子商务配送和仓储服务为一体的快递企业，扫描枪设备产生的数据是相当庞大的，而 TDengine 可以轻松高效地处理和存储这些时序数据，它所具备的快速写入和查询的能力，使得我们的系统可以轻松应对高负载和大规模数据的需求。
落实到业务使用方面，通过实时了解包裹状态、配送进度等信息，我们能够更加方便地做出实时决策，物流运营的效率和效果也获得了大幅提高。
往期推荐
👇 点击阅读原文，查看更多 TDengine 用户案例！
