共计 3415 个字符，预计需要花费 9 分钟才能阅读完成。
小 T 导读：在欧圣达的物联网智能设施平台我的项目中，需反对数百万以上物联网表具和智能终端的接入治理，反对分布式部署且具备良好扩展性。在规定引擎场景下，TDengine 提供了很好的查问和存储性能，成为本我的项目实现实时告警和监控服务的重要一环。本篇文章分享了欧圣达在数据库调研和搭建阶段的思考和教训，供参考。
公司简介
哈工欧圣达是深圳市欧圣达科技有限公司和哈工大机器人团体的合资公司，总公司深圳市欧圣达科技有限公司成立于 2010 年 5 月，总部位于深圳，下设合肥研发核心、华东分公司（合肥）和东北分公司（成都）。公司始终致力于燃气、供热等公共事业畛域的智慧化解决方案研发和利用推广，领有超过 10 余项自主知识产权的、基于 5G/NB-IoT 和大数据的“一体化平台 + 智能平安终端”智慧燃气解决方案，作为核心成员参加制订并公布 2019、2020 年 5G 智慧燃气行业标准。
某燃气公司拟建设一套物联网智能设施平台来满足各类物联网设施接入以及数据的采集、存储、剖析、展现等各类需要，我的项目需包含数据采集模块、数据分析模块、监控告警模块、预付费实时结算模块、API 接口模块、大屏 \ 地图显示模块、后盾治理模块、手机 App 功能模块。
该平台的搭建目标是为了取代各燃气表厂原有的数据接管服务器，实现对各表厂物联网表具（含 FSK、GFSK、LoRa、GPRS、4G、5G、NB-IoT 等技术标准）读数、压力、温度、监控报警、气价调整、零碎参数设置等远传管制和治理。零碎需反对数百万以上物联网表具和智能终端的接入治理，1 秒内刹时并发连接数不低于 5 万，零碎反对分布式部署，且具备良好的扩展性，可能依据业务须要，灵便的扩大零碎性能和接入能力。
一、选型调研
以上是典型的时序物联网场景，因而咱们调研了国外的支流时序数据库 InfluxDB，但思考到国家基础设施建设平安，咱们最终把眼光投向了国产开源数据库 TDengine。咱们联合业务数据量对 TDengine 进行了数百万设施的压测，满足本我的项目的数据存储和性能要求。具体测试后果如下：
从测试后果来看，TDengine 的整体硬件耗费资源比拟低，且能满足数百万设施的并发写入。此外相比 MongoDB，其压缩率能够晋升至 1/10 – 1/20，也为咱们节约了大量存储老本。最有吸引力的一点是 TDengine 具备欠缺的开源社区生态，不仅反对集群版部署，更有欠缺的中国服务团队及多元化的服务模式，能够做到实时响应。
二、业务架构部署
在具体搭建上，咱们将不同厂家、不同型号设施定义为产品，不同产品的通信机制、上报数据项、指令内容、上报频次都是不同的，咱们应用 TDengine 对不同产品创立对应的超级表，应用设施 ID 创立子表。
技术架构图如下图所示：
具体门路上，传感器数据通过 MQ 缓存、结构化解析后进入到 TDengine，供后续业务进行查问应用。规定引擎依据已有的规定参数，进行传感器数据订阅，实时判断传感器是否触发了报警规定，从而实现我的项目的实时监控和报警需要。同时，规定引擎还会依据传感器数据，触发对应的指令操作（如复原服务、暂停服务指令），通过 MQ 异步传播给传感器。TDengine 在规定引擎场景下，提供了很好的查问性能，是实现实时告警和监控服务的重要一环。
建模思路
在本我的项目中，每种设施的协定及上报数据参数都是不同的，咱们将公共属性（如所属公司、所属分公司、所属厂家、是否预付费等）作为超级表 tags，将共有参数（如阀门状态、最新读数、抄表工夫、温度、压力、电量、信号强度等）作为一般列，通信工夫戳 + 工夫漂移作为 TDengine 主键，其余非共有参数（如一些设施会上报刹时工况流量、一些会上报抄表模块电池电量等）作为子表字段。以本我的项目的其中一张表作为示例，构造如下：
show create stable device_meter_record\G;
create table device_meter_record (receive_time TIMESTAMP,meter_readnum DOUBLE,meter_balance INT,meter_volume DOUBLE,meter_time TIMESTAMP,meter_temperature DOUBLE,meter_pressure DOUBLE,meter_instantflow DOUBLE,cust_num BINARY(50),cust_name BINARY(255),company_id BINARY(32),subcompany_id BINARY(32),readingteam_id BINARY(32),subreadingteam_id BINARY(32),area_id BINARY(32),community_id BINARY(32),building_id BINARY(32),user_type BINARY(20),is_holiday BOOL,supplier_id BINARY(32),supplier_device_code BINARY(20),platform_balance INT,platform_last_reading DOUBLE,platform_last_balance INT,platform_price BINARY(15)) TAGS (device_id BINARY(32),device_no BINARY(32),sno BINARY(32),model_id BINARY(32),type_id BINARY(100))
成果展现
最终咱们采纳了 3 节点 8 核 16 G 满足整体业务需要，零碎能够依据时间段范畴、针对单个设施进行数据上报的查问性能，且反对依照小时用量、日用量、月用量、年用量四个维度进行统计分析。 目前单个超级表的压缩率为 2.5%。
三、教训分享与将来布局
在咱们应用 TDengine 的过程中，也遇到了一些小问题，在本文中总结出了一些教训，分享如下：
查问后果字段名的非凡写法
TDengine 的此前版本的设计当中，在查问返回的字段名时应用的是非凡写法：例如 SELECT last_row(ts) FROM stb GROUP BY tbname，这样的设计会导致 MyBatis 等 ORM 框架在映射时无奈间接对上。这种状况下只须要将 keepColumnName 设置为 1，就能够防止。
及时更新版本
在后期应用过程中，咱们已经遇到过 DROP TABLE 就解体的 BUG。和官网沟通后发现，曾经在很早的版本上修复了，倡议各位遇到 TDengine 的新版本也及时更新。
USING 语法
在应用 INSERT INTO table USING stable TAGS() 的语法时，始终认为这里会对 tag 进行从新赋值。到了应用的时候才发现，原来 table 曾经存在的状况下，是不会对 tag 产生批改的。细思一下相对的也是正当的，因为毕竟多一次批改就会多一次性能耗费, 如果跟着 insert 来批改，就会多了 1 : 1 的批改操作。
调整分片策略
在后期写入过程中，发现 CPU 占用只能到 1 核，CPU 资源上不去。和官网沟通后发现，原来默认的分片策略，在小规模设施上只会创立几个 Vnode，因而并不能很好地把全副核数利用起来。官网告知能够通过这两个参数来调整分片策略：tableIncStepPerVnode 50minTablesPerVnode 50 前者决定的是何时采纳下一个 Vnode 来寄存新的 table，后者决定的是何时创立下一个 Vnode 来寄存新的 table。
写入内存 blocks 很重要
在写入过程中，官网的巡检发现数据写入的“碎片化”很重大。通过排查发现，调配给写入过程的内存太小（block 默认 6，意味着 1 个 Vnode 只有 96 MB 用于写入）。因为 TDengine 在写入原理上是依赖于内存来做部分排序的，因而内存小了就会频频触发落盘，从而导致数据的落盘区块的均匀条数很小，须要频繁 IO 来读取数据。基于此，各位尽量设置较大的 block 来防止这个问题。
将来布局
物联网、车联网等波及时序数据存储、剖析的场景，应用 TDengine 能够大大降低零碎架构复杂度，在晋升性能和开发效率的同时还可能升高学习和运维老本。之后咱们也会联合业务需要在我的项目中充分发挥 TDengine 的劣势，利用其来长期存储设备上报的无效读数数据，以及进行计费、抄表、用量统计分析。
想理解更多 TDengine 的具体细节，欢送大家在 GitHub 上查看相干源代码。
