蓝格赛（中国）用TDengine落地聚合查询场景，效果如何？
本次项目为某市政供水水厂的数字化项目，数据来源于包括水泵、阀门、电表、液位计、流量计等多种设备近6000测点。该平台需要实现以下功能：数据秒级采集，历史数据留存3年，为上层应用提供数据支撑，包括所有测点的瞬时数据、聚合分析、数据报表等。值得注意的是，在本项目中聚合查询的使用场景非常的多，页面上图表不论大小有上百张之多，因此聚合查询的实现也是本项目的关键之处。
根据本项目特点，从整体架构的具体实现效果出发，我们对存储技术提出了很高的要求，甚至可以说，存储技术的选择会直接影响项目后续的推进乃至成败，这是一个决定平台“脊梁”硬不硬的组件。考虑到这一问题，团队在技术选型上着实花费了一些功夫，本次选型也相对更加慎重。在选型过程中我们共调研了20多个开源存储技术，从开源组织、授权协议、数据模型、社区成熟度、开发语言、组件依赖、性能、稳定性、聚合友好、操作系统、集群支撑、副本策略等多个角度进行了对比，终选择了TDengine作为海量数据存储引擎。事实上，我们初选择的是单纯以InfluxDB作为本次项目的核心存储组件，不过这一设想在进行技术验证时却发现难以继续推进。主要原因是在技术验证的过程中，我们发现了InfluxDB存在的几个问题，其中重要的两个是：- 首先，社区版本仅支持单节点。这个可以说是InfluxDB非常不友好的一个点了，多数项目采用的都是集群设计方案，如果数据只能在其中一个节点上存储，浪费其他节点存储空间不说，一旦所在节点出现故障，对整个项目的影响是灾难级的。
- 其次，随着数据量及存储时长的提升，InfluxDB的聚合性能出现了巨大的瓶颈，我们在实际测试的时候，模拟了百万测点近1年的数据，当聚合请求比较多的时候，基本上就很慢了，这点也对本项目影响很大。
由于以上两个问题的存在，从架构实现的角度来讲，我们必须对存储技术进行重新选择。恰好此时TDengine也开放了集群版本，偶然的契机下又听到了陶老师对于时序数据的特点总结，感觉研究的非常深入，总结的也很全面。后经与团队沟通，在技术选型调研时就一并把TDengine包含在了调研范围之内。简单尝试之后，我们发现TDengine的数据模型真的非常适合工业场景，总结来说有以下几个优点。 优点：
- 社区版本支持集群：可以比较好的利用集群的存储空间，数据也可以分散开来。
- 聚合性能优越：由于TDengine的数据模型特定及对集群的支撑，在模拟测试过程中，基本上没有遇到聚合瓶颈。随着数据量的增加及存储时长的延长，聚合性能也非常稳定。
- 简单易用：在工业场景中，组件低耦合是很必要的，TDengine开箱即用的特性很“香”，学习成本低，上手快速。
- 数据模型：在工业场景中，设备及测点的增减非常的普遍，TDengine的超级表及子表的概念很好地解决了这个问题，单列模式的场景对本项目来说非常友好。
- 查询语义具有普适性：TDengine的查询语句与InfluxDB非常接近，这点也非常好。
- 版本升级简单：卸载原有版本，安装新版本即可，无需数据迁移。
- 社区支持：普通的问题基本上都可以在issue上得到答复，遇到紧急问题的时候，涛思数据的同事甚至可以亲自远程解决，为他们点赞，在使用的时候放心不少。
选型确定之后，我们就正式开始了搭建。搭载TDengine之后的架构图如下所示：采用该方案的很大一部分原因是InfluxDB和TDengine在查询语义上的天然一致性。我们为TDengine外层包装了一层SDK，对应用层开放SDK，使应用层对存储技术无感，在SDK内部通过查询的时间跨度、组件健康程度等多个因素自动选择查询引擎，这样可以保障其中一个技术在出现问题的时候，另一个技术随时顶上来，大大降低了由于技术稳定性所带来的风险。在数据处理的具体分工上，当前我们主要使用TDengine支持数据聚合的场景。在本次项目中，数据看板是功能的核心，同时也是用户看中的地方，而这部分的数据聚合基本上都依赖于TDengine——目前其共支持应用端约10个看板页面，合计近百个聚合请求，是本项项目落地的关键。TDengine在本项目中运行稳定，为项目的具体功能实现提供了关键助力。未来，随着TDengine技术的不断成熟稳定，团队准备将其作为工业数据库的存储引擎运用在其他项目中。在接下来的产品线规划上，TDengine也将作为的重要技术组件。来源 https://www.modb.pro/db/218275