小 T 导读：在对多款时序数据库进行了选型测试后，同程旅行自研的“夜鹰监控”搭载 TDengine 代替了现有存储设备，缩小运维老本。本文分享了他们对建表模型的计划抉择思路，接入 TDengine 后所遇到问题的解决教训以及落地成果展现。
同程旅行有一套自研的根底监控零碎“夜鹰监控”。目前夜鹰监控应用状况为百万级别 endpoint、亿级 metric、每秒 200 万并发写入以及 2 万并发查问。其存储组件基于 RRD 存储，RRD 存储尽管领有很好的性能，却也存在着一些问题——基于内存缓存定期写入 RRD，在机器重启后会失落局部数据。
呈现这一问题的起因是 RRD 写入为单点写入，当机器故障后无奈实现主动切换，这一存储个性也导致无奈展现更长时间的原始数据。针对此问题，夜鹰监控做了很多高可用设计，但还是很难满足业务的需要，之后又进行了如下革新：
- 引入了 ES 存储，为夜鹰监控提供 7 天内原始数据的查问，目前部署的 2 套存储。
- RRD 提供给 API 调用，调用量在几万级 TPS。
- ES 提供给夜鹰面板应用，保留 7 天原始数据，调用量在几百 QPS。
但随着根底监控零碎接入指标的增长，目前 2 套存储系统在资源耗费方面始终在增长，同时业务对监控也提出了更多的聚合计算性能要求。基于此，咱们须要寻找一个新的时序数据库来代替现有的存储系统，以缩小运维老本。
在进行时序数据库选型时，理论需要次要有以下三点：
- 性能强，能够反对千万级别并发写入、10 万级的并发读取
- 高可用，能够横向扩大，不存在单点故障
- 性能强，提供四则运算、最大、最小、均匀、最新等聚合计算性能
通过比照 InfluxDB、TDengine、Prometheus、Druid、ClickHouse 等多款市面风行的时序数据库产品后，最终 TDengine 从中怀才不遇，能满足咱们所有的选型要求。
一、基于 TDengine 的建表模型
夜鹰监控零碎不仅存在零碎指标数据，同时也会存在业务指标数据。前者诸如 CPU、内存、磁盘、网络一类，这类信息是能够预测的指标，其指标名是固定的，总数约为 2000 万个。后者则会通过夜鹰监控的 API 上传业务本身定义的指标，指标名是无奈预测的，其特点是并发量不大却存在长尾效应，随着工夫累积，一年能够达到一亿级。
而 TDengine 在创立表之前须要先规划表的构造，从下面的数据存储背景来看，如果要将海量的指标数量间接一次性扁平化全副创立，则会造成性能的降落。通过和 TDengine 技术支持人员沟通，他们给出了两个建表计划：
其一，将零碎类根底指标聚合到一个超级表，一张表寄存一个节点，多个指标一次性写入。这个形式的益处是表的数量能够升高到千万级别，但因为夜鹰监控的数据是单条上传的，很难做到一个表外面全副指标集齐再写入。并且不同的指标上传频率不同，如果再依据频率建不同的超级表，运维治理老本会十分高。
其二，将不同的指标建成一个一个的子表，5 千万个左右的指标汇聚成一个集群，分多个集群接入。这种形式的益处是表构造简略，但运维治理多个集群会很麻烦。不过咱们也理解到涛思数据明年会公布 TDengine 3.0 版本，能反对超过上亿张表，那么这一计划就能够很好的进行数据迁徙了。
最终，咱们抉择了第二个计划。同时为了缩小搭建集群的数量，筹备写个程序定期清理掉过期的子表。目前夜鹰监控的超级表构造如下。
夜鹰监控接入 TDengine 后，架构图如下。
二、接入 TDengine 之后的成果展现
在进行数据迁徙时，咱们先是将夜鹰监控数据转移到 Kafka 中，之后通过生产转换程序将 Kafka 的数据格式转为了 TDengine SQL 格局。这个过程还遇到了如下三个小问题，解决思路放在这里给大家参考：
- 连贯形式问题 。刚开始咱们应用的是 go-connector sdk 的形式接入 TDengine，跑起来后发现，go-connector 依赖于 taos client 包以及 taos.cfg 配置文件外面的链接配置，同时因为 FQDN 的设置难以使用 VIP 负载平衡的配置形式。咱们思考到前面生产程序会部署到容器中，不宜产生过多的依赖，因而还是放弃了 go-connector 的连贯形式，改为了 HTTP RESTful 的连贯形式。
- Kafka 生产数量问题 。因为夜鹰监控上传到 Kafka 外面的数据是一条一个指标，再加上 200 万左右的并发，连接数很快就耗光了。通过和 TDengine 技术支持人员沟通，理解到能够革新成批量 SQL 的形式写入，最佳的实际成果是 400-600K 单个 SQL 的长度。通过计算，咱们上传的指标条数大略为 5000 条左右，大小为 500K。
- 读取速度问题 。因为每次要等到生产 5000 条数据，才会触发一次写入，这种状况也导致读取速度较慢。TDengine 技术支持人员再次给出了解决方案——应用 Taos 本人实现的 Queue，代码地址为:github.com/taosdata/go-demo-kafka/pkg/queue，有须要的同学能够自行获取。
聚焦到实际效果上，TDengine 数据写入性能很强。 本来咱们的单套存储系统须要 10 多台高配机器，IO 均匀 30% 最高 100% 的状况下能力写完数据；当初只须要 7 台机器，并且 CPU 耗费在 10% 左右、磁盘 IO 耗费在 1% 左右，这点十分的棒 !
同时，其数据读取接入过程也很顺利。应用 RESTful 接口后，联合 TDengine 自带的弱小聚合函数性能，很容易就能计算出想要的后果。
三、写在最初
在咱们的我的项目中，TDengine 展现出了超强的性能和多元化的性能，不仅具备高效的写入性能、压缩率，其聚合函数性能也十分齐全，反对 Sum/Max/Min/Avg/Top/Last/First/Diff/Percentile 等多种函数，在架构上也设计的很正当，能够实现很好地横向扩大。同时，其本身监控也做的很不错，打造了基于 Grafana 的 TDengine 零依赖监控解决方案 TDinsight，在监控零碎本身状态上展现出了很好的成果。
将来，咱们也心愿与 TDengine 开展更深层次的单干，在此也为其提出一些小小的倡议，助力 TDengine 往更好的方向倒退：
- 官网文档还不够欠缺，新版的性能在文档中没有体现，很多用法短少代码示例，集体了解起来比拟艰涩难懂
- 社区用户教训传递不是很多，遇到一些问题时，Google 比拟难以找到社区的解决案例
在接入的过程中，非常感谢 TDengine 的技术支持人员的全力支持。尽管目前 TDengine 还处于倒退初期，也存在一些问题须要优化，不过其优异的性能还是给了咱们一个大大的惊喜！总而言之，TDengine 是个十分不错的存储系统，置信在陶老师的率领下会倒退的越来越好！
想理解更多 TDengine 的具体细节，欢送大家在 GitHub 上查看相干源代码。