关于后端:从落地效果看转转选择TDengine的三个理由

3次阅读

共计 2377 个字符，预计需要花费 6 分钟才能阅读完成。

作者 | 赵运周

在转转的业务中，咱们应用了 Nginx 作为咱们的反向代理，为保障代理层可用性，须要对 Nginx 进行实时状态监控。在服务器的根底监控的抉择上，咱们将 OpenFalcon 逐渐替换为夜莺，对 Nginx 的 reqstat 监控最后也应用了这两种。然而这两大监控都有一个独特毛病，即在展现时有条数限度，导致域名数量和机器数量相乘后数据量增多的状况下，无奈满足需要。

为了解决这个问题，咱们思考对现有监控模块进行降级革新，从新进行数据库选型，在预研和分析阶段，依据以后的业务需要咱们从开源的数据库中抉择了两款时序数据库，别离是 InfluxDB 和 TDengine，这两款都能够实现高性能地查问与存储时序性数据，但 TDengine 相比于 InfluxDB 还存在三点劣势：

集群性能曾经开源，反对横向扩大以及高可用
性能和老本之间的均衡达到最优化，运维难度显著升高
其超级表特地适宜咱们这个以域名为维度的监控计划

通过综合比照，咱们初步选定 TDengine 作为监控模块的数据库。此外，涛思官网的测试结果显示，TDengine 的写入速度高于 InfluxDB，这一点也更加动摇了咱们抉择 TDengine 的决定。

而且 TDengine 反对多种数据接口，蕴含 C /C++、Java、Python、Go 和 RESTful 等。转转之前的服务用的是 Python，所以这也不便咱们仍旧连续应用 Python connector。

作为一款结构化的时序数据库，为了可能达到最优的性能体现，TDengine 在接入数据前须要依据数据的个性设计 schema。

Nginx 监控性能数据个性如下：

数据格式固定：配置好 req_status_zone 之后，日志文件就固定住了，但总的字段数是无限的，样例如下：

数据极少须要更新或删除
- 属于服务拜访的事实数据，只有不是脏数据，就不会删除
须要采集的数据标签不多，而且固定
单条数据量约在 1KB
保留 6 个月以上

此外，TDengine 的文档显示：

TDengine 对每个数据采集点独自建表，但在理论利用中常常须要对不同的采集点数据进行聚合。为高效的进行聚合操作，TDengine 引入超级表（STable）的概念。超级表用来代表一特定类型的数据采集点，它是蕴含多张表的表汇合，汇合里每张表的模式（schema）完全一致，但每张表都带有本人的动态标签，标签能够有多个，能够随时减少、删除和批改。

依照其倡议的数据模型，咱们须要建设一个超级表。联合咱们的数据特点和应用场景，创立数据模型如下：

超级表：以指标作为超级表
子表：每个域名做一个子表
- 标签 tag：间接将标签信息作为超级表的标签列
- 列 column：监控数据自身除去标签局部

具体示例如下：

因为是交融一个全新的数据库，在真正的落地施行时不可避免会遇到一些问题点，以下三点是咱们汇总的施行教训，放在本篇文章中给大家做参考：

数据写入
在数据写入的阶段，咱们开始设计的是一个域名一个子表，然而间接应用域名做表名不合乎保留字符的标准，所以须要将域名转换一下。
查问问题
因为写入的数据是实时的值，而监控业务更多地是须要获取前后差值，因而须要用上 TDengine 自带的函数 DIFF。官网从 2.1.3.0 版本开始，DIFF 函数能够由 GROUP BY 划分出独自工夫线的状况下用于超级表（也即 GROUP BY TBNAME）。而且 TDengine 的超级表极大水平上简化了查问代码，其分片个性也保障了同时查问多个域名可能做到充沛地多核并发。
容量布局
在落地过程中，咱们发现数据类型、数据规模对 TDengine 的性能影响比拟大，最好依据每个场景的个性进行容量布局，影响因素包含：
1. 表数量
2. 数据长度
3. 正本数
4. 表活跃度等
  从这些因素登程调整配置参数可能确保最佳性能，在与涛思数据工程师沟通后，咱们确定了当初的容量布局计算模型。值得注意的是，TDengine 容量布局的难点在于内存的布局，须要在内存的应用和读写性能之间进行均衡。

连贯 TDengine 后，咱们目前零碎的拓扑构造如下：

应用 TDengine 实现革新后，线上的监控状态达到预期，满足以后业务需要，目前运行十分稳固。且配合 Grafana 后，每个域名的流量、连接数、响应工夫等信息都可能实时监控到。

总而言之，无论是在老本和性能层面，还是在应用的便利性方面，TDengine 都具备十分大的劣势，在咱们的实际中也失去了证实，尤其是老本管控上成果十分显著。同时，也非常感谢涛思数据的小伙伴们提供的业余、及时的帮忙，咱们也心愿将来 TDengine 可能开辟出更多更加优良的新个性。当然，作为 TDengine 的使用者，咱们也会在 GitHub 上为 TDengine 做代码奉献。

此外，从本身我的项目和实际登程，咱们也有一些针对于 TDengine 期盼改良的性能点：

对表名反对更敌对：可能缩小对特殊字符的屏蔽（据说在后续版本中会实现，这样就更贴近场景，省去了利用端的非凡解决）
反对更加丰盛的 SQL 语句：可能针对少有的场景，提供更加灵便的 SQL 语句，便于做更加简单的计算剖析，这也是 AIOps 的进阶局部
灰度平滑降级：目前 TDengine 放弃着 2 周一次的发版节奏，还是冀望可能疾速用上新的个性。然而每次停机降级又会是一个麻烦的事件，期待官网早日反对滚动降级
可实现自定义聚合办法：因为工夫问题，没赶上官网的 UDF 个性。冀望官网的 UDF 可能早日公布，好实现更加简单的聚合计算
子表主动清理性能：因为域名会存在下线问题，目前的 TTL 策略只是针对数据而不是 Table 自身，淘汰子表还须要人工运维染指

只管还存在有余，但作为首次尝试，TDengine 的体现能够说是相当不错了，咱们也很期待将来可能在更多场景中和 TDengine 开展单干，包含更多监控项以及业务时序数据库需要的接入尝试。最初，衷心祝愿 TDengine 越来越好！

正文完