共计 2371 个字符，预计需要花费 6 分钟才能阅读完成。
小 T 导读：昌盛优选须要通过实时产生的数据来判断设施是否工作、检测通信是否延时、观测 SNMP OID 流量是否失常等，从而保障运维与网络人员及时发现问题并修复。为高效解决各类时序数据，保障服务的稳固运行，在比照了 Elasticsearch、InfluxDB 和 TDengine 三款产品之后，他们抉择并落地了 TDengine。
企业介绍
湖南昌盛优选电子商务有限公司（简称昌盛优选），总部位于湖南长沙，是一家关注民生的互联网“新批发”平台，次要定位是解决家庭消费者的日常需要，提供包含蔬菜水果、肉禽水产、米面粮油、日用百货等全品类精选商品。昌盛优选依靠社区实体便利店，通过“预售 + 自提”的模式为用户提供服务，是社区电商中惟一一家估值超过 150 亿美金的“独角兽”。
业务背景
为了保障互联网服务的高效和稳固，咱们须要监控公司所有的节点服务器（包含云服务器）、交换机及路由器。咱们须要通过实时产生的数据来判断设施是否工作、检测通信是否延时、观测 SNMP OID 流量是否失常等，从而保障运维与网络人员及时发现问题并修复。
这类数据是十分典型的时序数据，应该如何高效地解决呢？当初市面上有几款十分风行的时序数据库（Time Series Database）产品。应该如何评估并抉择适宜咱们业务场景的技术平台呢？
产品调研
针对该业务场景，咱们调研了如下几个产品：Elasticsearch、InfluxDB 和 TDengine。具体比照如下。
Elasticsearch
- 长处：能够分布式部署，能够无障碍插入，反对任意的字段类型，查问速度快。
- 毛病：只适宜记录日志且并发数据量不大的状况，对于海量设施的时序数据写入有性能问题。
InfluxDB
- 长处：反对无模式（Schemaless 写入），限度较少。
- 毛病：当面对大批量的数据同时插入或读取时，内存容易被占满，导致死机。尤其是其中的轮询机制，在测验过期数据时，内存占用特地大。此外，在读取数据时，读出来的是列表，可读性差，解析比拟麻烦。
TDengine
- 长处：列式存储以及“一个设施一张表”的模型与咱们业务场景非常符合。此外，还能够兼容咱们以前应用 InfluxDB 时所习惯的插入方式，代码可读性强，反对强绑定参数。在执行海量数据的查问时，响应速度比 InfluxDB 更快。
- 毛病：Schemeless 的反对还在继续欠缺之中。
因为该我的项目将来须要监控咱们公司的所有服务器，均匀每台对应的 OID 会有几百个，如果每 1-5 秒采集存储一次，并发数据量会十分大。因而，咱们从候选中淘汰了 Elasticsearch。
接下来咱们又持续比照了 InfluxDB 和 TDengine。InfluxDB 单节点性能有余，集群闭源且性能未知。反观 TDengine，其集群性能是开源的，且保留了企业版的局部外围性能。这让咱们能够间接十分深刻地理解 TDengine 的优劣。从这方面思考，咱们抉择了 TDengine。而且在理论应用中，咱们又发现了 TDengine 的一大劣势，其“一个设施一张表”的模型非常符合咱们的理论场景。
零碎架构
在引入 TDengine 之后，咱们的零碎架构如下图所示。
在该架构下，前端制订好规定下发（例如：流量阈值，延时阈值），后端看是否须要存储规定，或查看规定是否发生变化，而后把规定下发给 ETCD 来做定时任务调度。咱们共有三个程序工作，通过 ETCD 治理，定时和各类设施通信，依据不同规定别离抓取各自须要的数据：
- SNMP 引擎通过 OID 监控网络设备各项指标
- TCPing 引擎用于监控服务器 TCP 端口状态
- ICMP 引擎重点采集接管或返回数据的工夫
这三大类数据采集之后，会通过对立解决，再写入 TDengine。
咱们应用 5 个节点搭建了一套 TDengine 集群：
咱们抉择了无模式写入，在写入时主动建表，具体写入形式可参考官网。这样一来，每一台服务器对应的类型都是一张超级表，咱们抉择尽量地分表，晋升查问速度。
对于 SNMP 类型的超级表来说，每一个子表就是一个 OID。对于 TCPing 类型，咱们依照 TCP 端口来区分子表。对于 ICMP 类型的超级表，咱们以 task_id 和 task_type 作为区分子表的根据：
目前咱们曾经存储了 500 万张子表，均匀算下来设施上报频率大略为 3 秒 1 行，总数据量达到了百亿级别，而占用的存储空间只有 70GB 左右。这应该得益于 TDengine 针对性地应用了列式压缩，存储资源占用很小，压缩率大略为 8% 左右。TDengine 能够很好地顶住写入和存储压力。而查问方面，咱们会批量查问局部表的特定工夫的值，大部分数据用于实时的监控报警。
经验总结
在应用过程中，花工夫绝对较多的大略是无模式插入的摸索吧。
对于从 InfluxDB 切换过去的用户，初期可能会有一些不适应。因为 TDengine 最后并不是依照 Schemaless 来设计的，这个性能是前期退出的，零碎最终还是会把无模式转化成 SQL 再进行写入，只是简化了用户的操作。不过 TDengine 始终在欠缺相干的生态适配，比方对于大小写的特殊字符的存储，欠缺元数据管理，收纳各种模式的数据类型，也在逐渐向 InfluxDB 的自由式写入凑近。
除此之外，咱们也遇到过一个问题，目前 Go 连接器的查问 API 临时不反对将多条 SQL 拼接在一起对立执行。因而咱们采取了并发读取，但性能可能会受到一点影响，期待后续的版本可能解决。
最初，TDengine 的反对团队相当负责，配合踊跃，让咱们疾速上手了这款轻便易用、性能超高的时序数据库。目前咱们只接入了一部分服务器及设施，后续咱们打算把公司全国范畴内所有的服务器都接入进来，也会举荐公司更多部门应用。一切顺利的话，咱们也会思考包含仓库运货机器人，物流线设施等更多利用场景。
想理解更多 TDengine Database 的具体细节，欢送大家在 GitHub 上查看相干源代码。
