从落地效果看，转转选择TDengine的三个理由

小 T 导读：此前转转使用的服务器基础监控有夜莺和OpenFalcon两种，但是都碰到了同一个问题，因此决定尝试使用时序数据库，对InfluxDB和TDengine进行了预研和分析，基于三点主要优势，最终转转选用了TDengine。那在具体落地实施中他们又有哪些经验可以传递呢？

在转转的业务中，我们使用了Nginx作为我们的反向代理，为保证代理层可用性，需要对Nginx进行实时状态监控。在服务器的基础监控的选择上，我们将OpenFalcon逐步替换为夜莺，对Nginx 的reqstat监控最初也使用了这两种。但是这两大监控都有一个共同缺点，即在展示时有条数限制，导致域名数量和机器数量相乘后数据量增多的情况下，无法满足需求。

为了解决这个问题，我们考虑对现有监控模块进行升级改造，重新进行数据库选型，在预研和分析阶段，根据当前的业务需求我们从开源的数据库中选择了两款时序数据库，分别是InfluxDB和TDengine，这两款都可以实现高性能地查询与存储时序性数据，但TDengine相比于InfluxDB还存在三点优势：

• 集群功能已经开源，支持横向扩展以及高可用
• 性能和成本之间的平衡达到最优化，运维难度显著降低
• 其超级表特别适合我们这个以域名为维度的监控方案

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

而且TDengine支持多种数据接口，包含C/C++、Java、Python、Go和RESTful等。转转之前的服务用的是Python，所以这也方便我们依旧延续使用Python connector。

使用TDengine进行数据库建模

作为一款结构化的时序数据库，为了能够达到最优的性能表现，TDengine在接入数据前需要根据数据的特性设计schema。

Nginx监控功能数据特性如下：

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

 
  
 
zone_name   key max_active  max_bw  traffic requests    active  bandwidthserver_addr 192.168.187.164 2    432    17K 18  1    0server_name 192.168.187.164 2    432    17K 18  1    0server_url  192.168.187.164/    1    0   0  8   0    0server_url  192.168.187.164/index.html  1    0  11K 8   0    0server_url  192.168.187.164/req-status  1    0   0  1   1    0server_url 192.168.187.164/req_status 1 0 5680 1 0 0
  

• 数据极少需要更新或删除

• 属于服务访问的事实数据，只要不是脏数据，就不会删除

• 需要采集的数据标签不多，而且固定
• 单条数据量约在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越来越好！

---

👇点击阅读原文，体验TDengine！