文章目录
- 1、前言
- 2、概述
- 2.1 时序数据库的定义
- 2.2 时序数据库的概念
- 2.3 时序数据库的趋势
- 3、时序数据库对比
- 3.1 influxdb
- 3.2 Prometheus
- 3.3 TDengine
- 3.4 DolphinDB
- 4、选型结论
1、前言
时序数据治理是数据治理领域核心、打通IT与OT域数据链路,是工业物联网基石、大数据价值创造的关键、企业管理提升的发动机、是数字化转型的重要支撑。
工业企业在生产经营过程中,会运用物联网技术,采集大量的数据并进行实时处理,这些数据都是时序的,而且具有显著的特点,比如带有时间戳、结构化、没有更新、数据源唯一等。
时序数据处理应用于智慧城市、物联网、车联网、工业互联网领域的过程数据采集、过程控制,并与过程管理建立一个数据链路,属于工业数据治理的新兴领域。
时序数据库的应用场景在物联网和互联网APM等场景应用比较多,下面是列举了一些时序数据库的应用场景,但不是全部:
- 公共安全:上网记录、通话记录、个体追踪、区间筛选;
- 电力行业:智能电表、电网、发电设备的集中监测;
- 互联网:服务器/应用监测、用户访问日志、广告点击日志;
- 物联网:电梯、锅炉、机械、水表等各种联网设备;
- 交通行业:实时路况、路口流量监测、卡口数据;
- 金融行业:交易记录、存取记录、ATM、POS机监测。
2、概述
2.1 时序数据库的定义
时序数据是随时间不断产生的一系列数据,简单来说,就是带时间戳的数据。时序数据库 (Time Series Database,TSDB) 是优化用于摄取、处理和存储时间戳数据的数据库。此类数据可能包括来自服务器和应用程序的指标、来自物联网传感器的读数、网站或应用程序上的用户交互或金融市场上的交易活动。
其主要数据属性如下:
- 每个数据点都包含用于索引、聚合和采样的时间戳。该数据也可以是多维的和相关的;
- 写多读少,需要支持秒级和毫秒级甚至纳秒级高频写入;查询通常是多维聚合查询,对查询的延迟要求比较高
- 数据的汇总视图(例如,下采样或聚合视图、趋势线)可能比单个数据点提供更多的洞察力。例如,考虑到网络不可靠性或传感器读数异常,我们可能会在一段时间内的某个平均值超过阈值时设置警报,而不是在单个数据点上这样做;
- 分析数据通常需要在一段时间内访问它(例如,给我过去一周的点击率数据);
虽然其他数据库也可以在数据规模较小时一定程度上处理时间序列数据,但 TSDB可以更有效地处理随时间推移的数据摄取、压缩和聚合。简而言之,时序数据库是专门用于存储和处理时间序列数据的数据库,支持时序数据高效读写、高压缩存储、插值和聚合等功能。
2.2 时序数据库的概念
时序数据库是专门处理时序数据的数据库,因此其相关概念是和时序数据紧密联系的,下面是时序数据库的一些基本概念。
- 度量 Metric:Metric 类似关系型数据库里的表(Table),代表一系列同类时序数据的集合,例如为空气质量传感器建立一个 Table,存储所有传感器的监测数据。
- 标签 Tag:Tag 描述数据源的特征,通常不随时间变化,例如传感器设备,包含设备 DeviceId、设备所在的 Region 等 Tag 信息,数据库内部会自动为 Tag 建立索引,支持根据 Tag 来进行多维检索查询;Tag 由 Tag Key、Tag Value 组成,两者均为 String 类型。
- 时间戳 Timestamp:Timestamp代表数据产生的时间点,可以写入时指定,也可由系统自动生成;
- 量测值 Field:Field描述数据源的量测指标,通常随着时间不断变化,例如传感器设备包含温度、湿度等Field;
- 数据点Data Point: 数据源在某个时间产生的某个量测指标值(Field Value)称为一个数据点,数据库查询、写入时按数据点数来作为统计指标;
- 时间线 Time Series :数据源的某一个指标随时间变化,形成时间线,Metric + Tags + Field 组合确定一条时间线;针对时序数据的计算包括降采样、聚合(sum、count、max、min等)、插值等都基于时间线维度进行;
2.3 时序数据库的趋势
时序数据库的发展趋势,可以从DB-engines(Knowledge Base of Relational and NoSQL Database Management Systems)获取获取到,下图是DB-engines收录的数据库近24个月的发展趋势,其中时序数据库的活跃度最高,且随时间呈现越来越活跃的趋势。
参考资料:https://db-engines.com/en/ranki…
3、时序数据库对比
3.1 influxdb
-
基本情况
目前开源排名最高的时序数据库,是单独的数据库,主要就是用来写入和查询数据。数据采集使用push模式(数据源主动将数据写入influxdb)。
-
优势
- 高效的时间序列数据写入性能,其性能测试报告:https://www.influxdata.com/blog/influxdb-markedly-elasticsearch-in-time-series-data-metrics-benchmark/
- 自定义TSM引擎,快速数据写入和高效数据压缩。
- 无额外存储依赖。
- 简单,高性能的HTTP查询和写入API。
- 以插件方式支持许多不同协议的数据摄入,如:graphite,collectd,和openTSDB
- SQL-like查询语言,简化查询和聚合操作。
- 索引Tags,支持快速有效的查询时间序列。
- 保留策略有效去除过期数据。
- 连续查询自动计算聚合数据,使频繁查询更有效
- 无schema, 适合多值模式,对复杂业务模型更适合
-
劣势
- 目前集群版已经闭源商业化,开源版仅支持单机模式。
- 单机版性能逊于集群版, 同时没有集群的冗余,当服务器不可用时,写入和查询会立即失败
- 性能相比新兴的时序数据库要差一些。
-
总结
官方给出的单机版的数据要求:
- 写入:每秒不超过 750,000 次的字段写入
- 查询:每秒不超过 100 个中等查询( 有多个函数和一两个正则表达式、有group by 或多个星期的时间范围)
- 数据量: 不超过 10,000,000 个系列的基数
机器配置,参考官方建议如下,磁盘必须是SSD,否则性能得不到保证。
使用InfluxDB单机社区版来支撑目前的实时异常检测业务,数据存储时间不超过3个月,应该问题不大。需要做好集群状态监控和数据备份,保障单机状态宕机最小损失。
参考资料:https://docs.influxdata.com/inf
3.2 Prometheus
-
基本情况
Prometheus作为一个独立地开源监控系统和告警工具,提供了一整套的监控体系,包括数据的采集存储报警等。
-
优势与劣势:
同InfluxDB相比:
- 在场景方面:PTSDB 适合数值型的时序数据。不适合日志型时序数据和用于计费的指标统计。InfluxDB面向的是通用时序平台,包括日志监控等场景。而Prometheus更侧重于指标方案。两个系统之间有非常多的相似之处,包括采集,存储,报警,展示等等
- Influxdata的组合有:telegraf+Influxdb+Kapacitor+Chronograf。Promethues的组合有:exporter+prometheus server+AlertManager+Grafana
- 采集端prometheus主推拉的模式,同时通过push gateway支持推的模式。influxdata的采集工具telegraf则主打推的方式。
- 存储方面二者在基本思想上相通,关键点上有差异包括:时间线的索引,乱序的处理等等。
- 数据模型上Influxdb支持多值模型,String类型等,更丰富一些。
- Kapacitor 是一个混合了 prometheus 的数据处理,存储规则,报警规则以及告警通知功能的工具.而AlertManager进一步提供了分组,去重等等。
- influxdb之前提供的cluster模式被移除了,现在只保留了基于relay的高可用,集群模式作为商业版本的特性发布。prometheus提供了一种很有特色的cluster模式,通过多层次的proxy来聚合多个prometheus节点实现扩展。同时开放了remote storage,因此二者又相互融合,Influxdb作为prometheus的远端存储。
-
总结
Prometheus很强大,广泛用于Kubernetes集群的监控系统。但因为目前监控体系基于zabbix,不便于再部署一套同类型的监控系统,增加运维和管理成本。
3.3 TDengine
-
基本情况
TDengine是涛思数据专为物联网、车联网、工业互联网、IT运维等设计和优化的大数据平台。除核心的快10倍以上的时序数据库功能外,还提供缓存、数据订阅、流式计算等功能,最大程度减少研发和运维的复杂度,且核心代码,包括集群功能全部开源。
-
优势(性能指标)
- 10倍以上的性能提升:定义了创新的数据存储结构,单核每秒能处理至少2万次请求,插入数百万个数据点,读出一千万以上数据点,比现有通用数据库快十倍以上。完整的性能测试报告:https://www.taosdata.com/downloads/TDengine_Testing_Report_cn.pdf
- 硬件或云服务成本降至1/5:由于超强性能,计算资源不到通用大数据方案的1/5;通过列式存储和先进的压缩算法,存储空间不到通用数据库的1/10。
- 全栈时序数据处理引擎:将数据库、消息队列、缓存、流式计算等功能融为一体,应用无需再集成Kafka/Redis/HBase/Spark/HDFS等软件,大幅降低应用开发和维护的复杂度成本。
- 强大的分析功能:无论是十年前还是一秒钟前的数据,指定时间范围即可查询。数据可在时间轴上或多个设备上进行聚合。即席查询可通过Shell, Python, R, MATLAB随时进行。
- 与第三方工具无缝连接:不用一行代码,即可与Telegraf, Grafana, EMQ, HiveMQ, Prometheus, MATLAB, R等集成。后续将支持OPC, Hadoop, Spark等,BI工具也将无缝连接。
- 零运维成本、零学习成本:安装集群简单快捷,无需分库分表,实时备份。类标准SQL,支持RESTful,支持Python/Java/C/C++/C#/Go/Node.js, 与MySQL相似,零学习成本。
-
劣势
- 比较复杂的sql功能还不支持,超级表等概念在使用时有歧义(反正我有)。
- 从测试报告的结果看,tdengine的WAL只是写缓存,没有真正刷到磁盘上。
- TD在快速的版本迭代过程中,难免会有一些问题不能第一时间解决(需要提Issue,社区版的解决速度也会比预期的要慢一些),所以在实际使用中,会频繁的进行版本升级。
- 轻量级的社区版免费,高可靠和线性扩展的企业版收费。
- 没有互联网大厂背景。
-
总结
从性能上来说,TDengine当属物联网时序数据库领域性能最强。2021年5月其刚完成B轮4700万美元融资,但产品还是处于快速的迭代完善中,目前我们小体量的应用,不便于跟随其一起踩坑发展。本人在使用中节点挂掉过几次,没有查明原因。因此考虑HA、数据可靠性,还得考虑运维难度和成本,否则性能再高,也只是个PPT产物。
参考资料:https://www.taosdata.com/cn/
3.4 DolphinDB
-
基本情况
DolphinDB,读音/ˈdɒlfɪn/DB,是由浙江智臾科技有限公司研发的一款高性能分布式时序数据库,集成了功能强大的编程语言和高容量高速度的流数据分析系统,为海量结构化数据的快速存储、检索、分析及计算提供一站式解决方案,适用于量化金融及工业物联网等领域。
-
优势
DolphinDB具有运行快、部署快、开发快、学习快这四大优势,使其适用于大数据分析管理的诸多应用场景,主要可以归纳为以下四类:数据仓库、研发工具、实时数据处理及批处理作业。
-
劣势
目前Dolphin主要应用在金融领域,大的金融机构比较多,闭源,而且客单价比较高
2021年1月才完成数千万人民币A轮融资,其产品还在不断地迭代中 -
总结
DolphinDB虽然有社区免费版,但会限制CPU数量和内存大小,功能上也有阉割。总的来说其专为有钱的客户定制。针对我们这些小体量的应用,其官方也建议采用其他开源的方案。
参考资料:https://www.dolphindb.cn/
4、选型结论
基于上述各数据库的特点分析,总结如下:
数据库 | 优势 | 劣势 |
---|---|---|
Influxdb | 应用最广泛,认可度最高,成功案例丰富 | 集群版收费,单机版适用于小数据集 |
Prometheus | 独立地开源监控系统和告警工具,广泛应用于Kubernetes生态 | 前监控体系基于zabbix,不便于再部署一套同类型的监控系统 |
TDengine | 性能强悍,国产自主研发,集群版免费,也有附加功能的收费版 | 缺少大厂的最佳实践案例,还在持续迭代开发 |
DolphinDB | 高性能、分布式,支持快速存储、检索、分析及计算提供一站式解决方案 | 完全收费,适用于金融领域 |