关于数据库:一个扫描枪一张表韵达选择-TDengine-应对每日亿级数据量

58次阅读

共计 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 的测试应用过程中也并非一帆风顺，咱们也遇到了一些问题，放在这里供大家参考：