共计 3082 个字符，预计需要花费 8 分钟才能阅读完成。
作者：马祥荣
小 T 导读： 作为一家业务遍布多个国家及地区的物流公司，货拉拉面临的技术环境是非常复杂的，在云时代浪潮下基于混合云疾速构建环境搭建零碎成为其必然的抉择。然而在混合云上如何对基于各家云构建的零碎进行无效的治理是个挑战，尤其对处于零碎最底层的数据库层面临的问题、业务诉求、各方痛点，是货拉拉 DBA 团队现下所须要重点解决的。
目前 DBA 团队治理的数据存储包含 MySQL、Redis、Elasticsearch、Kafka、MQ、Canal 等，为了保障监控采样的实时性，咱们自研的监控零碎设置的采样距离为 10 秒，这样每天都会产生宏大的监控数据，监控指标的数据量达到 20 亿 +。后期因为治理实例少，监控数据量也少，所有数据都被寄存到了 MySQL 中；之后随着治理实例越来越多，应用 MySQL 来存储规模日益宏大的监控数据越发力不从心，急需进行降级革新。结合实际具体需要，通过对不同时序数据库进行调研，最终咱们抉择了 TDengine，顺利完成了数据存储监控的降级革新。
一、监控零碎开发中遇到的问题
从存储门路来看，每种数据存储都散布在多个区域，每个区域将监控采样数据投递上报到音讯总线，而后由生产程序统⼀生产，生产程序会将必要的告警数据更新到告警表，同时将监控原始数据存储到 MySQL。比方，针对 Redis 这款数据存储，监控采样距离设置 10 秒，那么每天实例采样次数就会达到 3000 万 +，监控指标累计 6 亿 +，数据量之宏大可见一斑。晚期为了将数据存储到 MySQL 中，同时也能很好地反对监控绘图的应用，每⼀次实例监控采样时都会计算出该实例全量监控项采样数据，而后将本次采样的后果作为⼀条记录存储下来。
即便通过这样的优化解决，在做时间跨度大的监控绘图时，前端仍然会呈现提早卡顿的问题，后端监控数据存储的 MySQL 也压力山大，常常满载，天天被吐槽。因而针对这种时间跨度大的查问，咱们专门开发了⼀系列的数据聚合调度工作——依照不同的时间跨度，提前将 10 秒采集距离的监控数据做好聚合，监控绘图程序再依据不同的时间跨度选取不同的聚合数据表绘图，以此解决长时间跨度监控绘图展现提早卡顿的问题。
但这依然治标不治本。为了压缩监控数据存储空间，原始 10 秒距离的监控数据表只能归档保留 3 天工夫的监控数据，但存储大小也将近有 200GB，加上与之相干的不同时间段的数据聚合表，存储一下子冲破 300GB。这还只是 Redis 监控数据的存储大小，加上其它数据存储的监控数据，至多须要 1TB+ 空间的 MySQL 存储。
数据汇合工作治理简单、前期监控原数据回溯缺失、MySQL 存储空间日益增长带来的隐患，都是亟待解决的问题。
二、时序数据库选型
为了解决 MySQL 监控数据存储的问题，咱们把注意力转移到了适宜存储监控数据的时序数据库上。市面上各种时序数据库产品目不暇接，有老牌的，也有后起之秀，通过⼀系列调研选型，咱们抉择了 TDengine，次要是因为其具备的如下几大长处：
- 采纳分布式架构，可反对线性扩大
- 数据存储压缩率超高
- 集群模式反对多正本，无单点故障
- 单机模式性能强悍
- 装置部署保护简略
- SQL ⽀持工夫维度聚合查问
- 客户端反对 RESTful API
值得一提的是，TDengine 的 SQL 原生语法反对工夫维度聚合查问，同时数据存储压缩率⾼存储空间小，这两点间接切中了咱们的痛点。落地后实测雷同数据的存储空间只有 MySQL 存储空间的非常之⼀甚至更少。 还有⼀个惊喜是，在现有监控数据存储 (MySQL) 顶不住的状况下，⼀台 8C16GB 的单机版 TDengine 轻松就抗下目前所有监控流量和存储压力, 且运行稳固，根本没有故障。
三、革新过程
TDengine 用于存储监控数据的超级表设计准则就是简略高效，字段⼀般都比拟少，每⼀种监控项类型 (INT、FLOAT、NCHAR 等) 的数据存储都须要独自建设⼀个超级表，超级表⼀般都有要害的 ts、type、value 字段，具体监控项由 type 字段标识，加上必要的 tag 及大量其它字段形成。
之前监控数据存储在 MySQL 的时候，每条数据记录蕴含了该实例⼀次监控采样的所有监控项 (25+) 数据。如果采纳通用的监控超级表设计准则，就须要革新采样的数据结构，革新形式有两种：
- 革新监控数据投递的数据结构
- 革新生产程序生产逻辑重组数据结构
但生产端有时效性要求，革新难度大，生产端波及范畴大阻力也不小。通过综合考量，最初咱们决定采纳相似 MySQL 数据存储的表构造来设计超级表，这样的革新对原来零碎入侵起码，革新难度系数最低， 革新大抵过程如下：
-
TDengine，每种数据存储的监控数据独自建库存放
taos> create database redis; taos> create database es; ... ... ... -
TDengine，建超级表，以 Redis 为例
taos> use redis; taos> create table redis_node_meters (created_at TIMESTAMP, qps INT, . ..) TAGS (region NCHAR(10), cluster_name NCHAR(50), ip NCHAR(20), port INT, role NCHAR(15)); -
监控数据生产，因为新增的实例节点是不确定的，比方 Redis 的节点资源是由 Agent 主动发现注册后主动进行监控指标采集，这时写入数据并不确定某个子表是否存在，就须要 TDengine 的主动建表语法来创立不存在的子表，若该子表已存在则不会建设新表只会写入数据。
taos > INSERT INTO tablename USING redis_node_meters TAGS ('China', 't est', '127.0.0.3', 9200, 'master') VALUES ('2021-12-02 14:21:14', 6490 , ...) - 绘图展现，绘图程序没有装置客户端驱动，间接应用了 TDengine 提供的 RESTful API，采纳 HTTP 的形式进行数据查问。在 SQL 查问上大量应用了 TDengine 提供的工夫维度聚合函数 INTERVAL，长时间跨度的数据查问，只须要正当抉择聚合距离，根本都是毫秒级响应， 保障了前端绘图的晦涩稳固。
四、革新后的落地成果
将监控的数据存储由 MySQL 革新为 TDengine 后，不仅顶住了监控数据增长所带来的压力，还节约了存储空间，老本压缩到了原来的非常之⼀甚至更低。历史原生监控数据可回溯工夫也变得更长，之前存储 3 天原生数据及聚合数据的空间，当初可供原始数据存储 45 天。
此外，革新之后不再须要保护简单的数据聚合调度工作，大幅升高了监控零碎、监控数据管理复杂度，同时前端绘图数据查问也变得更加简洁高效。
五、写在最初
随着对 TDengine 越发深刻的理解及教训累积，后续咱们也会逐渐思考将货拉拉大监控零碎、业务数据（行车轨迹）等时序数据均迁徙至 TDengine。为了不便有须要的敌人更好地应用 TDengine，在此也分享一下咱们的一些应用教训：
- 因为 TDengine 不反对太简单的 SQL 查问语法，在设计超级表 tag 的时候须要充分考虑分明，目前只有 tag 的字段反对函数运算后果的分组 (GROUP BY) 查问，一般字段是不反对的。
- 子表 tag 的值是能够扭转的，然而同⼀个子表 tag 的值是唯⼀的，倡议用子表 tag 的组合值来生成子表名。
在本次我的项目中，TDengine 很好地帮忙咱们实现了降本增效，是一款值得尝试的时序数据库产品，将来也心愿其可能施展出越来越丰盛的性能和个性，也期待咱们之后能有更严密深刻的单干。
⬇️点击下方图片查看流动详情，iPhone 13 Pro 等你带回家！
