蓝格赛(中国)用TDengine落地聚合查询场景,效果如何?

2022-05-23 00:00:00 数据 集群 技术 项目 聚合

本次项目为某市政供水水厂的数字化项目,数据来源于包括水泵、阀门、电表、液位计、流量计等多种设备近6000测点。该平台需要实现以下功能:数据秒级采集,历史数据留存3年,为上层应用提供数据支撑,包括所有测点的瞬时数据、聚合分析、数据报表等。值得注意的是,在本项目中聚合查询的使用场景非常的多,页面上图表不论大小有上百张之多,因此聚合查询的实现也是本项目的关键之处。


根据本项目特点,从整体架构的具体实现效果出发,我们对存储技术提出了很高的要求,甚至可以说,存储技术的选择会直接影响项目后续的推进乃至成败,这是一个决定平台“脊梁”硬不硬的组件。考虑到这一问题,团队在技术选型上着实花费了一些功夫,本次选型也相对更加慎重。

在选型过程中我们共调研了20多个开源存储技术,从开源组织、授权协议、数据模型、社区成熟度、开发语言、组件依赖、性能、稳定性、聚合友好、操作系统、集群支撑、副本策略等多个角度进行了对比,终选择了TDengine作为海量数据存储引擎

01

 从7个优点看选择TDengine的原因

事实上,我们初选择的是单纯以InfluxDB作为本次项目的核心存储组件,不过这一设想在进行技术验证时却发现难以继续推进。

主要原因是在技术验证的过程中,我们发现了InfluxDB存在的几个问题,其中重要的两个是:
  • 首先,社区版本仅支持单节点。这个可以说是InfluxDB非常不友好的一个点了,多数项目采用的都是集群设计方案,如果数据只能在其中一个节点上存储,浪费其他节点存储空间不说,一旦所在节点出现故障,对整个项目的影响是灾难级的。
  • 其次,随着数据量及存储时长的提升,InfluxDB的聚合性能出现了巨大的瓶颈,我们在实际测试的时候,模拟了百万测点近1年的数据,当聚合请求比较多的时候,基本上就很慢了,这点也对本项目影响很大。

由于以上两个问题的存在,从架构实现的角度来讲,我们必须对存储技术进行重新选择。恰好此时TDengine也开放了集群版本,偶然的契机下又听到了陶老师对于时序数据的特点总结,感觉研究的非常深入,总结的也很全面。

后经与团队沟通,在技术选型调研时就一并把TDengine包含在了调研范围之内。简单尝试之后,我们发现TDengine的数据模型真的非常适合工业场景,总结来说有以下几个优点。

 优点:

  1. 社区版本支持集群:可以比较好的利用集群的存储空间,数据也可以分散开来。
  2. 聚合性能优越:由于TDengine的数据模型特定及对集群的支撑,在模拟测试过程中,基本上没有遇到聚合瓶颈。随着数据量的增加及存储时长的延长,聚合性能也非常稳定。
  3. 简单易用:在工业场景中,组件低耦合是很必要的,TDengine开箱即用的特性很“香”,学习成本低,上手快速。
  4. 数据模型:在工业场景中,设备及测点的增减非常的普遍,TDengine的超级表及子表的概念很好地解决了这个问题,单列模式的场景对本项目来说非常友好。
  5. 查询语义具有普适性:TDengine的查询语句与InfluxDB非常接近,这点也非常好。
  6. 版本升级简单:卸载原有版本,安装新版本即可,无需数据迁移。
  7. 社区支持:普通的问题基本上都可以在issue上得到答复,遇到紧急问题的时候,涛思数据的同事甚至可以亲自远程解决,为他们点赞,在使用的时候放心不少。

02

 10个看板页面,近百个聚合请求

选型确定之后,我们就正式开始了搭建。搭载TDengine之后的架构图如下所示:
采用该方案的很大一部分原因是InfluxDB和TDengine在查询语义上的天然一致性。我们为TDengine外层包装了一层SDK,对应用层开放SDK,使应用层对存储技术无感,在SDK内部通过查询的时间跨度、组件健康程度等多个因素自动选择查询引擎,这样可以保障其中一个技术在出现问题的时候,另一个技术随时顶上来,大大降低了由于技术稳定性所带来的风险。

在数据处理的具体分工上,当前我们主要使用TDengine支持数据聚合的场景。在本次项目中,数据看板是功能的核心,同时也是用户看中的地方,而这部分的数据聚合基本上都依赖于TDengine——目前其共支持应用端约10个看板页面,合计近百个聚合请求,是本项项目落地的关键。

TDengine在本项目中运行稳定,为项目的具体功能实现提供了关键助力。未来,随着TDengine技术的不断成熟稳定,团队准备将其作为工业数据库的存储引擎运用在其他项目中。在接下来的产品线规划上,TDengine也将作为的重要技术组件。
来源 https://www.modb.pro/db/218275

相关文章