作者 | 温金雄、彭涛、周玉峰
小 T 导读：为了解决宽广新能源汽车车主面临的充电效率问题，协鑫能科打造了以换电为外围业务的挪动能源品牌「协鑫电港」，须要对各种数据流进行科学管理、正当使用与智能调度，在数据库的抉择上尤为重要。本文分享了他们对于数据库架构的搭建思考以及 TDengine 的利用心得。
企业简介
协鑫能源科技股份有限公司（证券简称：协鑫能科 002015.SZ）系协鑫（团体）控股有限公司旗下企业，主营业务为清洁能源经营、挪动能源经营以及综合能源服务。公司倾力打造从清洁能源生产、补能服务到储能的便捷、经济、绿色的出行生态圈，为电动化出行提供一体化能源解决方案，致力于成为当先的挪动数字能源科技运营商。
1、业务痛点
随着新能源汽车的宽泛遍及，补能的效率问题逐步成为了宽广车主面临的痛点难题。为了解决此难题，作为一家头部的新能源公司，协鑫能科翻新冲破，切入能源服务畛域，打造了以换电为外围业务的挪动能源解决方案品牌「协鑫电港」。
因为这是一个在全新畛域中打造的全新我的项目，想要获得成功，须要对各种数据流进行科学管理、正当使用与智能调度，所以针对该场景，咱们一开始便把量级最大的物联网数据处理计划锁定在了时序数据库（Time Series Database）上，重点比照了 InfluxDB、OpenTSDB 以及 TDengine。
最终，TDengine 以其独特而迷信的设计和优良的测试体现成为咱们选中的时序数据处理引擎，承当了用户车辆数据、电池设施数据以及换电港工作设施等的海量数据存储剖析工作，为咱们解决了该我的项目上难度最大的一个环节。最终，咱们决定应用 TDengine 2.4.0.10 版本，并在电信的天翼云上落地了该我的项目。
2、架构与搭建
从流量削峰以及数据安全的角度登程，咱们会先通过应用某 MQTT 音讯服务器把这些不同品种的设施数据先对立转发给到 Kafka。其中不同类型的数据，将会别离上传到不同的 Kafka topic，最初再通过 Java 连接器把数据写入 TDengine。具体架构如下图所示：
在整体架构上，除了 TDengine，也有一些其它数据库独特支持系统服务，其中 MySQL 负责存储订单、流水等须要精密查问的关系型数据，但因为 MySQL 能够接受的数据量比拟无限，为了做一些大表的连贯查问，因而咱们也接入了 TiDB，负责剖析报表类数据的存储。
目前接入 TDengine 最次要的入库数据是车辆传感器（如：车辆里程、经纬度等）以及换电站电池相干的传感器（电池的各种指标）数据。以后共有 55 张超级表，子表数量达到 11 万张。
咱们以后在 TDengine、TiDB、MySQL 中存储的数据量比例大略为 6:3:1，仅仅应用了三台 4C+16G 的服务器，TDengine 便挑起了整个零碎数据存储的大头，轻松撑持起了咱们的服务。 在数据库的抉择上，咱们始终认为不同数据库之间术业有专攻，不得不抵赖，TDengine 在存储引擎上的独特设计，在降低成本方面的成果非常显著。
对于 TDengine，咱们一开始应用的是单节点，在稳固经营了几个月后，于往年 3 月实现了动静扩容，倒退到了 3 节点集群模式，把数据库也降级到了三正本（从图中能够看进去）。
TDengine 的动静扩大十分不便，只有确保一些必要的参数保持一致，就能够间接通过“create dnode”把新的计算资源加进来。退出后，再通过“alter database iot replica 3”这个命令，即可间接在线令数据库变为 3 正本，从而实现数据的备份及高可用。
3、成果剖析
以后，咱们在 TDengine 中一共存储了数百亿级别的数据量（因为表构造各异，不不便统计，不在本篇文章中展现），存储空间大略占用 600GB 左右（200GB*3），CPU 日常应用为 15% 左右，内存应用在 20% 左右。
在查问方面，在此列举一些咱们罕用的 SQL，TDengine 的响应速度都很快，齐全能够满足咱们的需要：
select max(pmk)-min(pmk) from aodong_109 where sid='P42100001' and sd=0 and ts>'2021-12-01 00:00:00'select last(sv),last(st) from aodong_112 where bn='001PB0GM000002B3L0300067';4、对于 TDengine 的一些思考
因为咱们业务是 24*7 不间断运行，所以没有工夫做版本升级。咱们首先打算抽出工夫把 TDengine 版本升级到比拟新的版本，再做一些碎片重组压缩的工作来增强查问效率。此外，咱们还打算应用 Flink 从 TDengine 中读取数据做流式计算（看到了官网公布了 Flink 适配 TDengine 的文章）。
随着业务快速增长，TDengine 集群存储的数据量也会越来越大，而数据又须要长期保留，大数据量的运维对于 TDengine 来说将是一个微小的挑战。随同数据量级的增长，备份、迁徙、库、表的运维都会受到影响，也有可能遇到咱们之前没有经验过的问题，这就须要 TDengine 集群实现降级、扩大、拆分、保护等运维操作。将来咱们心愿能积攒更多的教训分享给社区，让更多的人理解 TDengine。
对于 TDengine 将来的倒退，咱们也有本人的期待：
- 心愿能减少动静批改参数性能，缩小停机保护次数。
- 实现相似慢 SQL 日志性能，升高高负载、调优预先剖析定位、回溯故障起因。
- 进一步衡量 udp 带来的益处和导致的各种问题。咱们常常连贯报错 Ref is not there，目前来看在客户端增加 rpcForceTcp 1 应该是无效的。
- 加强报错信息可读性，很多报错提醒不够明确，无奈疾速判断出具体起因。
总而言之，心愿 TDengine 前面越来越好，也心愿咱们的单干能更上一层楼。
想理解更多 TDengine Database 的具体细节，欢送大家在 GitHub 上查看相干源代码。