作者：宁龙 华自科技
小 T 导读：华自科技专一于自动化、信息化和智能化技术，为能源、环保、工业管制、水利等畛域用户提供外围软硬件产品与零碎解决方案，是多能物联技术领航企业。公司在电站及泵站自动化管制设施市场占有率寰球当先，是联合国工业倒退组织国内小水电核心管制设施制作基地。
物联网数据平台是电站及泵站智慧运维平台的外围组成，其整体架构如下：
物联网数据平台的数据起源次要为电站、水厂、储能站，通过数据网关，将各场站端的设施运行数据传输至云平台的音讯队列（MQ）中，数据处理服务订阅 MQ 的音讯，依据设定的规定引擎，进行实时数据处理，之后将数据存储落盘。数据服务 API 则依据业务需要提供蕴含实时数据和历史数据在内的数据 API。
一、现状及痛点
对于历史数据，目前咱们采纳的 MySQL 分库分表计划来存储；实时数据会存储在 Redis 中。在测点数较少或者集控需要不是很多的场景下，根本满足需要。
历史数据
历史数据用 MySQL 存储，一个站点对应一个数据库；一个测点对应一张表，建表语句大抵如下：
CREATE TABLE `yc_测点 id` (
`ts` datetime NOT NULL,
`val` double NOT NULL
);实时数据
实时数据缓存到 Redis 中，以测点 Id 为 key，同时缓存数据上报的工夫、测量值和品质值等信息。
数据计算查问
咱们利用 MySQL 的各种函数、多表连贯、应用程序内存计算等形式，计算出后果返回给前端，对于月、年等报表类的计算，则采纳定时工作生成。
痛点
随着平台业务的倒退，接入的站点越来越多，或者单站的测点数越来越多，问题逐步凸显进去了。具体能够演绎为如下几个方面：
运维难
- 对于新接入的站点，首先得为这个站建设好数据库、数据表，减少了接站的工作量；
- 因为一个站对应着一个数据库，随着平台接入的站点越来越多，数据库一直减少，数据库的治理和备份老本一直进步；
- 随着测点的减少，缓存实时数据的单机 Redis 迟早有一天会撑不住，须要思考保护 Redis 集群。
开发难
随着平台的业务倒退，越来越多的站被接入平台，集控需要 (跨站聚合剖析需要) 减少，跨库跨表的查问操作越来越多，这就减少了零碎开发的难度，重大影响了零碎响应速度和稳定性。
老本高
老本次要有两个方面，一个是人力老本高，因为开发、运维的难度减少，造成员工工作量减少，工作效率变低，从企业经营角度看，人力老本变高；另一个是硬件资源老本高，因为服务节点泛滥，占用的主机、内存和磁盘空间也会很多，购买或租用这些硬件资源须要收入更多费用。
二、技术选型
为了解决目前这些问题，咱们决定从新进行技术选型，寻找代替计划，降级目前数据库存储计划。联合平台理论须要，咱们确定了几个选型要求：
- 业务改变小：尽可能减少对现有业务的影响；
- 开源收费：必须是开源的，并且容许收费商用，最好也有商业版；
- 迭代更新：社区沉闷，一直在迭代更新和公布新版本；
- 性能高：单机能反对每秒 10 万以上的插入效率；
- 开销低：服务节点少，占用的内存、CPU 和磁盘空间少；
- 反对集群：可能集群部署，容量可程度扩大；
- 装置保护简略: 数据量较小的状况下，反对单机部署，并且占用资源较少；
咱们理解了多款典型的时序数据库产品，最终 InfluxDB、庚顿、麦杰、TimescaleDB、TDengine 这几款进入了咱们的考查范畴。上面咱们来具体看一下：
1. InfluxDB
在开源时序数据库畛域长期霸榜，社区沉闷，生态也比拟丰盛，性能也算中规中距，惟一的缺点就是集群模块不开源。
2. 庚顿、麦杰
两者都是传统老牌工业畛域的时序数据库王者，性能、性能都十分不错，惟一的毛病就是不开源，只有商业版，而且价格昂贵。
3. TimescaleDB
它是在 PostgreSQL 之上开发的一个插件，是基于关系数据库的时序数据库，对于咱们现有的业务应用简直无感知，下层能够持续用 MyBatis、JPA 等 ORM 框架，但它不是一个纯正的时序数据库；另外，它对集群反对不好，不反对程度扩大。
4. TDengine
反对应用类 SQL 查询语言来插入或查问数据，内嵌音讯队列和缓存机制、无历史数据与实时数据之分、分布式架构，反对线性扩大、反对多正本，无单点故障。看到官网的这些介绍，霎时感觉 TDengine 就是为咱们筹备的，于是马上做了各种验证，结果表明，TDengine 齐全符号咱们的选型要求。
为什么没有采纳传统 Hadoop 生态
提到大数据，人们可能第一反馈就会想到 Hadopp 生态。因而咱们后期也考查过腾讯云的 TBDS 数据套件。说实话那一套货色真的是太轻便了，Hadoop、HBase、HDFS、ZooKeeper、Hive、Spark\Flink 这系列的货色搞下来，还真不是个别团队能玩得转的，另外我司的业务场景不止云端服务，还有可能会私有化部署在站内，硬件条件可能也就是一两台情况个别的服务器。
三、TDengine 存储模型设计
因为 TDengine 能够设置将最新一条数据存储在内存中，因而咱们利用这个个性替换掉了用 Redis 存储实时数据这个环节，改成实时数据间接查问 TDengine。
TDengine 里有超级表的概念，每种设施对应一个超级表。这个超级表只负责存储这种类型的设施数据，数据存储采纳横表存储。然而，这显然不合乎咱们的场景，因为在咱们的场景里没有固定的某一设施对象，且每个测点的频率都可能不统一。
同时为了尽可能减少对现有业务的影响，咱们将超表设计成如下构造：
CREATE STABLE IF NOT EXISTS stb_站点 id (ts timestamp, val double) TAGS (测 id nchar(64))TDengine 的子表，能够在插入数据时动态创建，这是 TDengine 的一个很好用的性能。这样能省去创立子表的业务环节，升高了业务复杂度。子表构造如下：
insert into 测点类型_测点 id USING stb_站点 id (测点 id) VALUES (ts, val,q) eg: insert into yc_15143115161750995367 USING stb_站点 id ('15143115161750995367') VALUES (ts, val,q)四、应用到的 TDengine 个性
- 缓存（Cache）
咱们间接应用 TDengine 提供的缓存（Cache）性能，替换了原有零碎中的 Redis。创立数据库间接开启 cachelast=1，将每张表的最初一条记录缓存，应用程序通过 last_row 函数疾速获取实时数据。
- 数据订阅(Publisher/Subscriber)
在咱们的业务场景中有一类数据叫 SOE 事件告警数据，这类数据要实时动静在前端页面上滚动。原有做法是通过页面轮训来实现的，当初间接应用 taos 的数据订阅性能，配合 WebSocket，能够优雅地实现这一性能，大大晋升了用户体验。
- 其它一些很用的性能
比方降采样查问、多表聚合查问、各种规范函数等。
五、革新迁徙
因为 TDengine 采纳了类 SQL 的语法，反对 MyBatis 等 ORM 框架，因而对于老的业务，咱们在代码层面的改变非常少，改变最多的就是将原来的 MySQL 函数联合利用代码的一些计算逻辑间接用 TDengine 的函数替换掉。
在试运行阶段，因为咱们都是通过自研数据网关将数据通过 TCP 发送上来的，所以咱们利用 tcp-copy，将数据复制一份存到 TDengine 集群，而后通过业务零碎察看和验证各项性能是否失常。
验证失常之后，就是历史数据的迁徙了。因为 TDengine 的表构造与原来的 MySQL 存储构造根本相似，因而咱们采纳 DataX 的 TDengine 插件，很不便就将历史数据迁徙过去了。
至此，咱们就用 TDengine 替换了原有的存储架构。
总结
初始接触一个新产品，难免会遇到一些艰难。好在方法总比艰难多，在共事们的反对下，在 TDengine 的工程师们的反对下，咱们总算是根本实现了这次实时数据存储查问的降级革新。
以后我的项目数据测点大略在 18 万左右，革新后数据存储周期由原来的 5 分钟缩小到 1 秒钟，存储的数据维度更精密了，能为平台的智能诊断、智能剖析服务提供更精确的数据反对，同时各业务场景下的计算查问性能也晋升了不少，数据库服务器由原来的 6 台缩小到目前的 3 个节点集群。
最初来个小广告
TD-Workbench 是一个基于 Electron 构建的，针对时序数据库 TDengine 的图形化管理工具。具备跨平台、易于应用、版本适应性强等特点。(gitee 地址：https://gitee.com/bhdweb/tden…)
TD-Workbench 是自己利用周末的工夫，参考开源社区局部优良代码设计并实现的，目前曾经开源。这个仅代表我自己的业余好爱，与公司或某个组织无关，欢送大家去 star/fork。因为 TDengine 官网并未提供客户端 GUI 工具，社区目前能找到的两款工具都不是很欠缺。本工具是在 TDengineGUI (https://gitee.com/skyebaobao/…) 根底上革新而来，局部源码来自此处。
作者介绍：
宁龙，码云昵称【村口的大爷】，目前就任于华自科技。后端程序猿一个，混迹 Java 界十余年，就爱写点代码。一杯茶一首歌，一个参数秀一天。
🌟近期 taosAdapter 已正式公布，反对从 OpenTSDB 等时序数据库向 TDengine 无缝迁徙，欢送浏览 TDengine 此前公布的技术文章，理解体验 taosAdapter！