在过去的十年间,我们亲历了关系型、非关系型、在线分析处理(OLAP)型、以及在线事务处理(OLTP)型数据库的市场之争,也注意到了诸如:Snowflake、MongoDB、Cockroach Labs、以及Neo4j等新型数据库的产生和发展。而根据DB-Engines的一项针对数据库管理系统调查的统计(如下图所示),时序型数据库(time series database,TSDB)是自2020年以来,增长最快的数据库类型之一。
时序数据库是针对摄取、处理和存储带有时间戳数据进行优化过的数据库。此类数据可能包括来自服务器和应用程序的参数指标、来自物联网传感器的读数、网站或应用程序上的用户交互、以及金融市场上的各种交易活动。
此处的时序数据通常具有如下属性特征:
- 每个数据点都包含了用于索引、聚合、以及采样的时间戳。此类数据往往是多维的、且相关的。
- 它们主要以高速写入(或称:摄取)的方式,来捕获高频的数据。
- 数据的汇总视图(例如:降采样、聚合视图或趋势线)可以提供比单个数据点更多的洞见。例如,考虑到网络的不稳定性、或传感器读数可能出现的异常,我们需要为在一段时间内,针对超过预定阈值的某些平均值设置警报,而并非仅针对单个数据点。
- 通常需要获取在一段时间内访问某类数据(例如,获取过去一周内的点击率数据),以供深入分析。
虽然其他类型的数据库,也可以在一定程度上处理时序数据,但是TSDB可以在设计上,针对上述数据特性,更有效地处理那些随着时间的推移,而开展的各类数据摄取、压缩、以及聚合活动。
如今随着云计算、物联网、以及机器学习对于时序数据需求的持续爆炸式增长,软件架构师们应该如何选择TSDB呢?本文将综合比较市场上最为流行的三种TSDB--InfluxDB,TimescaleDB和QuestDB,以帮助您做出明智的选择。
于2013年被首次发布的InfluxDB,是TSDB领域的领导者。如下图所示,它甚至超越了之前的Graphite和OpenTSDB。与许多开源(OSS)数据库类似,InfluxDB不但能够为单个节点提供MIT许可,而且提供了InfluxDB Cloud付费计划,以及为企业级用户提供了集群、以及生产环境就绪(production-ready)等功能。
如下图所示,在2019年发布InfluxDB 2.x之前,InfluxDB平台是由TICK技术栈所组成,即:Telegraf(收集和报告参数指标的代理)、InfluxDB、Chronograf(从InfluxDB处查询数据的接口)、以及Kapacitor(实时数据流的处理引擎)。InfluxDB 1.x主要通过社区和集成,收集、存储和查看来自服务器和Web应用的时序数据指标。
InfluxDB 2.x从本质上简化了整体架构。它将TICK栈捆绑到了单个二进制文件中,并且引入了一些新的功能,来执行收集(如:原生的Prometheus插件)、组织(如:各种组织和存储桶)、可视化(如:数据浏览器)数据、及其Flux语言。
在介绍InfluxDB的工作原理之前,让我们先了解如下三个关键概念:
- 数据模型(标签集模型):除了时间戳字段,其实每个数据元素还会包含各种标签(如:可选的、已被索引的元数据字段)、字段(如:键和值)、以及指标(标签、字段和时间戳的容器)。下图示例展示了由科学家Anderson和Mullen在Klamath和Portland两地采集到的、蜜蜂和蚂蚁的数量普查数据。此处的位置(location)和科学家(scientist)标签,被当作蜜蜂和蚂蚁普查范围内的“字段/值(field/value)”对。
- 数据模式(TSM & TSI):是一些存储在时间结构合并树(time-structured merge tree,TSM)和时序索引(time series index,TSI)文件中的数据元素。其中,TSM可以被认为是具有预写日志(write-ahead log,WAL)和类似于SSTable只读文件的LSM树。这些文件通常是经过排序和压缩的。而TSI则是可供InfluxDB内存映射的磁盘文件索引。它可以让操作系统以最少最近使用(Least Recently Used,LRU)内存的方式,来帮助处理具有高基数(high cardinality)的数据集(如,集合中的那些大型元素)。
- Flux脚本语言:是由InfluxDB开发的一种,可用于协助查询数据的特定域语言。同时,Flux也带有一个可协助从SQL数据源进行查询的SQL包。
值得注意的是,InfluxDB在摄取数据之前,不会强制执行某种结构模式。相反,它的结构模式是根据输入的数据被自动创建,以及从标签和字段中推断出来的。这种类似NoSQL的体验,对于InfluxDB来说有利也有弊。对于那些能够自动适合此类标记集模型基数的数据集(如:各种物联网数据、财务数据、以及大多数基础设施和应用程序的参数指标)而言,InfluxDB非常容易上手。用户也无需担心设计模式或索引(如下图所示)。同时,对于那些目标是创建物理资产数字模型的用例而言,它也是非常实用的。例如,在物联网中,人们可能需要创建一个数字孪生,来表示一组传感器,并摄取各种有组织的数据。
另一方面,当数据集需要在连续的字段上建立索引(毕竟InfluxDB不支持数字,而且标签必须是字符串)或验证数据时,这种“无模式”就是一种缺陷。此外,由于标签会被索引,因此如果标签会经常变化(如,元数据可能在初次摄取后,就发生了变化)的话,仅依赖InfluxDB来推断模式,就可能会产生昂贵的开销。
再者,由InfluxDB决定创建其自定义的功能性数据脚本语言(如Flux),会给整个生态系统增加一层复杂性。对此,InfluxDB的团队特别强调了如下两个从类SQL的InfluxQL转换为Flux 的驱动场景:
- 时序数据符合基于流的功能处理模型。其中,数据流是从一个输出转换为下一个输出。而由SQL支持的关系代数模型,则不能处理这种操作和函数的链接。
- 通过InfluxDB为时序数据(如,指数级的移动平均)的常见操作,提供一流的支持,而这并非SQL标准的一部分。
当然,用户需要花时间去熟悉Flux的语法,特别是那些追求简单的SQL查询方式,以及不打算学习另一种新语言的用户,尤为如此。好在InfluxDB已拥有大型的社区与集成,而且Flux能够与内置的仪表板相结合。
总的来说,在面向基础设施和应用监控的需求时,InfluxDB能够与各种数据源无缝地集成。如果时序数据能够与标签集模型非常吻合的话,那么InfluxDB是一个不错的选择。可见,InfluxDB的优缺点可以被归结为:
- 优点:无模式摄取、庞大的社区、与流行工具相集成。
- 缺点:具有高基数、自定义查询/处理语言的数据集。
InfluxDB需要从头开始构建新的数据库和自定义语言,而TimescaleDB则建立在PostgreSQL之上,并添加了一个被称为超级表(hypertables)的中间层。该层将数据分块到多个底层数据表中,并将其抽象为一个可用于数据交互的单个大表。
与PostgreSQL的兼容性是TimescaleDB的最大卖点。TimescaleDB能够完全支持所有的SQL功能(如:连接、二级和部分索引),以及诸如PostGIS之类流行的扩展。作为PostgreSQL的扩展,TimescaleDB不但提供诸如Azure Database for PostgreSQL与Aiven之类的云托管选项,也提供了针对虚拟机或容器的各种自管理选项。
TimescaleDB最初是针对物联网平台,使用InfluxDB来存储它们的传感器数据。由于网络不稳定性,导致了物联网时序数据经常会出现拥堵和失序,因此TimescaleDB在高基数方面具有如下三个特点:
- 超级表(Hypertables):TimescaleDB基于时间列、以及其他“空间”值(如:设备的UID、位置标识符、或股票代号),来将其超级表划分成块。用户可以通过配置这些块,将最新的数据保存到内存中,并按照时间列,将数据异步压缩和重新排序至磁盘(并非摄取时间),以及在节点之间,以事务的方式进行复制和迁移。
- 持续聚合(Continuous Aggregation):通常,物联网数据在汇总时更为实用,因此我们无需在每个汇总查询中去扫描大量的数据。由于支持数据的持续聚合,TimescaleDB能够快速地计算出诸如:小时平均值、最小值和最大值等关键指标(如,计算出下午3点到4点之间的平均温度,或是下午3点时刻的确切温度)。这将有助于创建高性能的仪表板与分析结果。
- 数据保留(Data Retention):在传统关系型数据库中,大量的删除操作往往代价高昂。然而,由于TimescaleDB是以块的形式存储数据的,因此它提供了一种drop_chunks的功能,可以在同等开销下,快速地删除旧的数据。由于旧数据的相关性会随着时间的推移而降低,因此TimescaleDB可以通过与长期存储(如,OLAP或Blob存储)一起使用,来移走旧的数据,节省磁盘空间,进而为新的数据上提供优异的性能。
就性能而言,时序基准套件(Time Series Benchmark Suite,TTSBS,)详细比较了TimescaleDB 1.7.1和InfluxDB 1.8.0(两者都是OSS版本)在插入和读取延迟方面的性能指标。不过,由于如今两者都已经拥有了2.x版本,因此该分析略显过时。从下图比较结果可知,TimescaleDB会随着数据基数的增长(以3.5倍速),提供卓越的性能。
TimescaleDB团队指出,InfluxDB的基于日志结构合并树系统(tree-based system,TSI)与TimescaleDB的B树索引方法,是性能制胜的法宝。当然,我在此并未武断地认为TimescaleDB在性能方面就一定优于InfluxDB。毕竟性能基准测试受到数据模型、硬件、以及配置等多方面的影响较大。该比较结果仅表明,TimescaleDB可能更适合数据基数较高的物联网用例(例如,在1000万台设备中,获悉设备X的平均功耗)。具体有关这两个数据库之间的深度比较,请参见由Timescale自行提供的《TimescaleDB与InfluxDB的比较》。
总体而言,TimescaleDB非常适合那些寻求显著性能提升,而不想通过大量重构来迁移现有SQL数据库的团队。尽管TimescaleDB相对较新(于2017年首次被发布),但是许多物联网初创公司已在使用它作为中间数据存储,以快速提取横跨数月的聚合参数指标,并将旧的数据移至长期存储处。如果您已经在Kubernetes集群上运行着 PostgreSQL,那么安装TimescaleDB和迁移数据的任务都会相对比较容易。
总的说来,TimescaleDB的优缺点可以被归结为:
- 优点:与PostgreSQL兼容性,可以很好地扩展数据基数,并提供各种部署模型。
- 缺点:结构模式固定,而且在摄取之前增加了复杂性和数据的转换工作。
对于那些既希望利用InfluxDB内联协议的灵活性,又熟悉PostgreSQL的人来说,QuestDB(YC S20)作为一个较新的时序数据库,可以满足开发者的这两个要求。它是一个用Java和C++编写的开源TSDB,虽然被推出仅一年多,但是已排名到了前15。从原理上说,QuestDB是利用内存映射文件,在数据提交到磁盘之前,实现快速读写的。
QuestDB通过使用Java和C++,来从头开始构建数据库,其主要特征体现在:
- 性能:解决摄取过程中,特别是在处置高基数的数据集过程中的瓶颈。同时,它还通过顺次存储的时分数据(即,在内存中的混洗),以及仅分析请求的列/分区,而并非以整张表的方式,来支持快速的数据检索。此外,QuestDB还会运用SIMD指令,实现并行化操作。
- 兼容性:QuestDB支持InfluxDB的内联(inline)协议、PostgreSQL wire、REST API、以及CSV上传的方式,来摄取数据。那些习惯了其他TSDB的用户,可以轻松地移植他们的现有应用程序,而无需进行大量的重写工作。
- 通过SQL进行查询:虽然能够支持多种摄取机制,但是QuestDB也会使用SQL作为查询语言,因此用户无需额外地学习Flux之类的特定域语言。
在性能方面,QuestDB最近发布了一篇包含基准测试结果的博文,展示了其每秒140万行的写入速度。QuestDB团队在cpu-only的用例中,使用了TSBS基准测试。其中m5.8xlarge在AWS上的实例中,使用了多达14个work(注意:该140万行的数字,源于使用了AMD Ryzen5的处理器)。
对于具有高基数(超过1000万)的数据集,QuestDB的性能优于其他TSDB。凭借着Intel Xeon CPU,其峰值的摄取吞吐量为904k行/秒,并能够在1000万台设备上使用四个线程,且在m5.8xlarge实例上维持约640k行/秒的性能。而当QuestDB在AMD Ryzen 3970X上运行相同的基准测试时,它具有超过1百万行/秒的摄取吞吐量。
同样,上述基于数据模型和DB调整的性能基准测试也可能不够客观,不过它们在一定程度上体现了QuestDB的性能优势。
QuestDB的另一个有趣的特性是,在摄取中支持InfluxDB内联协议和PostgreSQL的wire。对于现有的InfluxDB用户,您可以将Telegraf配置为指向QuestDB的地址和端口。同理,PostgreSQL用户使用现有的客户端库、或JDBC,将数据写入QuestDB。当然,无论采用何种摄取方法,我们都可以使用标准的SQL去查询数据。值得注意的是,其API参考页面上,显著地列出了一些例外的情况。
作为该领域的新玩家,QuestDB最明显的缺点是,缺乏生产环境就绪的功能(如,复制、备份与恢复等)。同时,它虽然能与诸如:PostgreSQL、Grafana、Kafka、Telegraf、以及Tableau等流行工具相集成,但是需要花时间调试与磨合,方可达到上述其他TSDB的水平。
总的说来,QuestDB的优缺点可以被归结为:
- 优点:快速摄取(特别是对于具有高基数的数据集),支持InfluxDB内联协议和PostgreSQL wire,可以通过标准的SQL查询数据。
- 缺点:在用户社区、可用集成、以及对生产环境就绪等方面,都有待改进。
随着业界对于时序数据需求的不断增长,专门处理此类数据的TSDB将会被大规模地采用,并引发激烈的竞争。除了上面介绍的三大开源TSDB之外,市场上还有AWS(AWS Timestream)和Azure(Azure Series Insights)等公共云产品。
与传统数据库类似,选择TSDB主要仍取决于您的业务需求、数据模型、以及数据用例。如果您的数据适合于具有丰富的、集成生态系统的标签集模型,那么请选择InfluxDB。TimescaleDB则非常适合于现有的PostgreSQL用户。而如果性能是您的首要考虑因素的话,请您考虑选用QuestDB。
原文链接:InfluxDB,TimescaleDB和QuestDB三种时序数据库的比较
本文来自云海天,作者:古道轻风,转载请注明原文链接:https://www.cnblogs.com/88223100/p/InfluxDB_TimescaleDB_QuestDB.html