实现雨量监测预警，TDengine在智慧水务大数据中的应用

1. 时序数据类型及规模

在水环境综合治理运维系统中，使用TDengine的数据存储各类终端设备的采集数据，比如硫化氢、电压、电流、雨量、温度、液位、闸门、风机、排风扇、溶解氧等信息。

目前系统上存在20个点每个点有80+个监测数据上传，每日新增的监测数据量约为100MB。如果按照此类设备的增量，后面会达到2000个点每天将近10G的数据量。

现场设备监测数据图例：

目前已每个监测点的id作为TAGS创建了超级表STable。

首先创建超级表：

CREATE TABLE DevTagValue (createTime timestamp,sampleTime timestamp,tagName binary(100),updateTime binary(50),tagValue binary(50),devID binary(50),Id binary(50)) 
TAGS (location binary(100))

创建子表：

CREATE TABLE devtagvalue_300219010764 USING DevTagValue TAGS ('300219010764');
CREATE TABLE devtagvalue_300219030026 USING DevTagValue TAGS ('300219030026');

选择TDengine的理由

在系统前期的版本中，我们使用了MySQL数据库来存储设备上报数据。但接入系统的设备量日益增长、用户对数据实时性反馈的要求也越来越高，MySQL已经无法满足业务需求。我们发现将设备数据转移到时序数据库TDengine中存储是个更好的解决方案。

刚开始MySQL中存储了一个点上报的所有数据频率普遍在秒级，对一个表的插入与查询的压力过大，然后以站点进行了分表操作。效果好了点，由于数据量太大查询效率极低。总结规律后根据监测数据的类型进行分表操作，这样对于一个点效果明显提升，但是业务在不断扩张，站点在不断增加的情况下频繁的跨表操作MySQL查询出现了延时甚至超时死锁的情况。

时序库的选型

OpenTSDB + HBase

这个方案目前使用的人比较多，但有写缺陷。

1. HBase集群配置要求高，需要很好的调优，需要专门精通人员去维护增加了不少人员成本。

2. OpenTSDB默认的compaction策略每到整点都会对上一小时的数据查询出来compact成一行，写入到HBase，删除原始数据，这个相当耗费cpu。即使关闭compaction，修改tsd.storage.enable_appends = true 启用append的方式低配机器 cpu也是相当高。综合考虑人员及服务器等成本还是放弃了。

TDengine是一个简单快捷高性能的时序数据库，提供高性能的同时大大降低了安装、部署、维护的成本，是当前水环境综合运维系统底层采用的变量数据存储引擎。TDengine解决了我们几个之前较为头疼的问题。

1. 安装简单

下载rpm包，一个命令安装完毕即可运行。

2. 性能强劲

测试场景：

十万张点表，每个点表1s需要存储1条记录。在实际测试过程中，使用http接口，采用单机4C16G的配置，8线程每次写500条记录，10万条记录写入只需要300ms（如果使用java客户端更快）；单变量采样查询基本在2ms内完成。整个测试持续了48小时，测试期间cpu在20%-30%之间，内存维持在6G左右，写入相当稳定，没有出现超时。

综合考虑，使用TDengine硬件成本和开发维护成本大大降低，写入和查询速度还比OpenTSDB等高一个级别。

总结

万朗智水采用TDengine后节省了其他方案搭建集群的费用，并且在写入速度和查询性能方面完全满足了业务的需求，作为一款为物联网场景设计的时序数据库，TDengine确实展现了在设备多、采集频率高的情形下显示出其性能高、架构简答的优势。相同的设备实时数据查询场景。其超级表的设计省去了不少联表查询逻辑，大大简化了业务层的开发工作。我们当前的系统已经发挥出其数据缓存和时序索引的能力，会在后面继续探索使用下TDengine的流式计算和订阅的功能，充分发挥底层数据库的功能，再进一步优化平台的系统架构。

来源 https://www.modb.pro/db/168901