internet时间服务器(比较时间序列数据库InfluxDB)

时间序列数据库的高级概述,以比较特征、功能、成熟度和性能黄一泰-11分钟阅读照片:Tech Daily on Unsplash我们正生活在数据库的黄金时代,因为资金正以历史性的速度流入该行业(例如,Snowflake、MongoDB、Cockroach Labs、Neo4j)。如果说关系型与非关系型或在线分析处理(OLAP)与在线交易处理(OLTP)之间的争论统治了过去十年,那么一种新类型的数据库一直在稳步增长。根据DB-Engines(一个收集和展示数据库管理系统信息的倡议),自2020年以来,时间序列数据库是增长最快的领域。时间序列数据库(TSDB)是为摄取、处理和存储有时间戳的数据而优化的数据库。这些数据可能包括来自服务器和应用程序的指标,来自物联网传感器的读数,用户在网站或应用程序上的互动,或金融市场的交易活动。时间序列工作负载通常具有以下特点。每个数据点都包括一个时间戳,可用于索引、聚合和采样。这种数据也可以是多维的和相关的。 高写入速度(摄取)是首选,以便在高频率下捕获数据。 数据的汇总视图(例如,下采样或汇总视图,趋势线)可能比单一数据点提供更多的洞察力。例如,考虑到网络的不可靠或传感器读数的异常值,我们可以在一段时间内某些平均值超过阈值时设置警报,而不是在单个数据点上这样做。 分析数据通常需要在某个时间窗口内访问它(例如,给我过去一周的点击率数据)。虽然其他数据库也能在一定程度上处理时间序列数据,但TSDB的设计考虑到了上述特性,以更有效地处理数据的摄入、压缩和按时间聚合。那么,随着云计算、物联网和机器学习的发展,对时间序列数据的需求不断爆发,架构师应该如何选择TSDB?在这篇文章中,我们将比较一些流行的TSDB以及市场上的新玩家,以帮助你做出决定。InfluxDBInfluxDB于2013年首次发布,现在是TSDB领域当之无愧的市场领导者,超过了之前的Graphite和OpenTSDB。与许多开放源码数据库公司一样,InfluxDB以MIT许可的方式授权给单节点,InfluxDB云和InfluxDB企业的付费计划则提供了集群和其他生产就绪的功能。图片来源:influxdata, (MIT)在2019年InfluxDB 2.x发布之前,InfluxDB平台由TICK栈组成。Telegraf(收集和报告指标的代理)、InfluxDB、Chronograf(从InfluxDB查询数据的接口)和Kapacitor(实时流数据处理引擎)。如下图所示,InfluxDB 1.x主要专注于来自服务器和网络应用的时间序列数据。在Prometheus出现并抢占这一领域的市场份额之前,InfluxDB拥有最大的社区和集成,可以收集、存储和查看应用程序的指标。图片来源:influxdata, (MIT)InfluxDB 2.x在很大程度上简化了架构,将TICK堆栈捆绑到一个单一的二进制文件中,并引入了新的功能,使收集(如本地Prometheus插件)、组织(如组织和桶)和可视化(如数据浏览器)数据与它的Flux语言。为了理解InfluxDB的工作原理,我们需要掌握以下关键概念。数据模型(标签集模型)。除了时间戳字段外,每个数据元素由各种标签(可选、可索引的元数据字段)、字段(键和值)和测量(标签、字段和时间戳的容器)组成。下面的例子采取了蜜蜂和蚂蚁的普查数据,由科学家Anderson和Mullen在Klamath和Portland收集。这里位置和科学家是标签,属于蜜蜂和蚂蚁的普查测量,有字段/值对。图片来源:influxdata, (MIT)数据模式(TSM和TSI):数据元素存储在时间结构的合并树(TSM)和时间序列索引(TSI)文件中。TSM可以被认为是一个LSM树,有写头日志(WAL)和类似于SSTables的只读文件,这些文件是经过排序和压缩的。TSI是InfluxDB内存映射在磁盘上的文件的索引,以利用操作系统的最小最近使用(LRU)内存。这是为了帮助处理具有高cardinality(即集合中的大元素)的数据集。 Flux脚本语言:由InfluxDB开发的特定领域语言,帮助查询数据。Flux有一个sql包,也可以帮助从SQL数据源查询。最值得注意的是,InfluxDB在输入数据之前不强制执行模式。相反,模式是由输入数据自动创建的,从标签和字段中推断出来。这种类似NoSQL的体验既是InfluxDB的优势,也是它的劣势。对于自然适合这种标签集模型的相对较低的数据集(例如,大多数基础设施和应用指标,一些物联网数据,一些金融数据),InfluxDB非常容易上手,而不必担心设计模式或索引的问题。在目标是创建物理资产的数字模型的用例中,它也大放异彩。例如,在物联网中,人们可能需要创建一个数字孪生体来表示传感器的集合,并以一种有组织的方式摄取数据。图片来源:TimescaleDB, (Apache)另一方面,当数据集需要对连续字段进行索引(即InfluxDB不支持数字,因为标签必须是字符串)或数据验证时,"无模式 "可能是一个不利因素。另外,由于标签是有索引的,如果标签经常变化(例如,元数据在最初摄入后可能发生变化的用例),依靠InfluxDB来推断模式可能是昂贵的。最后,InfluxDB决定创建自己的自定义功能数据脚本语言(Flux),为掌握这个生态系统带来了另一层复杂性。InfluxDB的团队指出,从类似SQL的InfluxQL转向Flux有两个动机。时间序列数据符合基于流程的功能处理模型,其中数据流从一个输出转化到下一个。SQL支持的关系代数模型并不能很好地处理这种操作和函数的连锁关系。InfluxDB希望对时间序列数据的常见操作(如指数移动平均)提供一流的支持,而这并不是SQL标准的一部分。Flux的语法肯定需要一些努力来适应,特别是如果你正在寻找简单的SQL查询或不希望学习另一种新的语言。但考虑到InfluxDB的大型社区和集成,Flux的一些优势开始显现,特别是当与内置的仪表盘相结合时。图片来源:influxdata, (MIT)总的来说,如果时间序列数据与标签集模型非常吻合,InfluxDB是一个不错的选择。主要的用例似乎是面向基础设施/应用监控,但作为这一领域明显的市场领导者,InfluxDB也与流行的数据源无缝集成。优点:无模式的摄取,巨大的社区,与流行工具的集成。 缺点:高基数的数据集,自定义查询/处理语言TimeScale数据库InfluxDB选择了从头开始建立一个新的数据库和自定义语言,而另一端是TimescaleDB。TimescaleDB建立在PostgreSQL之上,并增加了一个称为hypertable的中间层,将数据分块到多个底层表格,同时将其抽象为一个单一的大表格,以便与数据进行交互。图片来源:TimescaleDB, (Apache)PostgreSQL的兼容性是TimescaleDB的最大卖点。TimescaleDB完全支持所有的SQL功能(如连接,二级和部分索引),以及流行的扩展,如PostGIS。更重要的是,TimescaleDB继承了几十年来运行SQL查询的开发人员以及大规模运行PostgreSQL的数据库和系统管理员的知识。由于TimescaleDB可以被视为PostgreSQL的扩展,除了TimescaleDB自己的管理产品外,云管理选项(如Azure Database for PostgreSQL,Aiven)也是现成的,更不用说虚拟机或容器上的无数自我管理选项。图片来源:2020年Stack Overflow开发者调查,(ODbL)。因为TimescaleDB一开始是作为一个物联网平台,他们一开始实际上是用InfluxDB来存储他们的传感器数据,它的功能对物联网时间序列数据来说是个好兆头,这些数据往往是突发的,由于网络不可靠而经常失序,并且具有高基数的特点。超量表。TimescaleDB根据时间列以及其他"空间 "值(如设备UID、位置标识符或股票符号)将其超量表划分为若干块。"空间 "值(如这些块可以被配置为在内存中保存最新的数据,按时间列异步压缩和重新排序数据到磁盘(而不是摄取时间),并在节点间进行复制或迁移。 连续聚合。TimescaleDB还支持数据的连续聚合,以使计算关键指标,如每小时的平均值、最小值和最大值变得快速。物联网数据通常在聚合时更有用(例如,给我下午3点和4点之间的平均温度与下午3点的确切温度),所以不需要在每个聚合查询中扫描大量数据,可以帮助创建高性能的仪表板或分析。 数据保留。在传统的关系型数据库中,大量的删除是一个昂贵的操作。然而,由于TimescaleDB将数据存储在块中,它提供了 drop_chunks 功能来快速删除旧数据,而没有同样的开销。由于旧数据的相关性随着时间的推移而减少,TimescaleDB可以与长期存储(如OLAP或blob存储)一起使用,移动旧数据以节省磁盘空间,并保持新数据的高性能。至于性能,TimescaleDB有一个全面的帖子,详细介绍了使用时间序列基准套件(TSBS)比较TimescaleDB 1.7.1版本和InfluxDB 1.8.0(都是OSS版本)的插入和读取延迟指标。这两个数据库现在都有2.x版本,所以这个分析可能有点过时了,但结果显示,随着数据cardinality的增长,TimescaleDB的性能更优越(约3.5倍的性能)。图片来源:TimescaleDB, (Apache)TimescaleDB团队指出,InfluxDB的基于日志结构的合并树系统(TSI)与TimescaleDB的B树索引方法相比,是根本原因。然而,这里的启示不一定是TimescaleDB在性能上优于InfluxDB。性能基准是有意见的,而且受数据模型、硬件和配置的影响很大。相反,这个结果表明,TimescaleDB可能更适合于物联网的使用案例,在那里数据基数很高(例如,给我1000万台设备中的X设备的平均用电量)。总的来说,TimescaleDB非常适合那些正在寻找一个巨大的性能提升而不需要重构的团队,以迁移出他们现有的SQL数据库。尽管TimescaleDB仍然相对较新(2017年首次发布),但在PostgreSQL基础上构建的决定已经提升了其采用数量,达到了前5名的TSDB。从轶事来看,我之前的物联网创业公司也使用TimescaleDB作为中间数据存储,以快速提取跨越几个月的聚合指标,并将旧数据转移到长期存储。由于我们已经在Kubernetes集群上运行PostgreSQL,安装TimescaleDB和迁移我们的工作负载,是一个简单的任务。优点。与PostgreSQL兼容,能很好地扩展数据量,有多种部署模式可供选择。 缺点:固定的模式(增加了一点复杂性,而且在摄入前需要进行数据转换)。QuestDB对于那些希望利用InfluxDB线路协议的灵活性和PostgreSQL的熟悉性的人来说,一个较新的时间序列数据库可能会满足这两个要求而不牺牲性能。QuestDB(YC S20)是一个用Java和C++编写的开源TSDB,虽然它推出不到一年,但现在已经排名前15位。在引擎下,QuestDB利用内存映射文件,在数据提交到磁盘之前支持快速读写。图片来源。QuestDB, (Apache)通过用Java和C++从头开始建立数据库,QuestDB团队专注于三件事。性能。解决摄取的瓶颈,特别是在高cardinality数据集周围。它还支持快速数据检索,方法是始终按顺序存储时间分区数据(通过在内存中洗牌),并且只分析所请求的列/分区而不是整个表。最后,QuestDB应用SIMD指令来并行化操作。 兼容性。QuestDB支持InfluxDB线协议、PostgreSQL线、REST API和CSV上传,以摄入数据。习惯于使用其他TSDB的用户可以很容易地移植他们现有的应用程序,而不需要大幅重写。 通过SQL进行查询。尽管支持多种摄取机制,QuestDB使用SQL作为查询语言,因此不需要学习像Flux这样的特定领域语言。在性能方面,QuestDB最近发布了一篇博文,显示了基准测试结果,实现了每秒140万行的写入速度。QuestDB团队使用TSBS基准,在AWS的m5.8xlarge实例上使用多达14个工程的cpu-only用例(注意:140万的数字来自使用AMD Ryzen5处理器)。图片来源。QuestDB, (Apache)对于具有高基数(>1000万)的数据集,QuestDB的表现也优于其他TSDB,其峰值摄取吞吐量为904k行/秒,在使用英特尔至强CPU的m5.8xlarge实例上使用4个线程,在1000万设备上维持约640k行/秒。当在AMD Ryzen 3970X上运行相同的基准时,QuestDB显示出超过一百万行/秒的摄取吞吐量。图片来源。QuestDB, (Apache)基于数据模型和数据库的调整,性能基准可以是主观的,但它还是为QuestDB描绘了一个引人注目的比较点。由于InfluxDB和TimescaleDB都支持TSBS开箱即用的这些用例,看看结果如何,将会很有趣。QuestDB的另一个有趣的组成部分是支持InfluxDB内联协议和PostgreSQL线程的摄取。对于现有的InfluxDB用户,你可以简单地配置Telegraf以指向QuestDB’的地址和端口。同样,对于PostgreSQL用户,使用现有的客户端库或JDBC将数据写入QuestDB中。无论采用哪种摄取方法,都可以使用标准SQL进行数据查询,但API参考页上列出了一些明显的例外。作为这个领域的新进入者,QuestDB最明显的缺点是缺乏对基础设施功能的支持(如复制、自动备份/恢复)。它确实已经与一些最流行的工具(如PostgreSQL、Grafana、Kafka、Telegraf、Tableau)集成,但它需要一些时间才能达到上述其他TSDB的水平。尽管如此,QuestDB仍是一个很有前途的项目,可以平衡InfluxDB和TimescaleDB的积极因素。优点:快速摄取(特别是对于高cardinality的数据集),支持InfluxDB协议和PostgreSQL线,通过标准SQL进行查询 缺点:社区规模较小,可用的集成,生产准备就绪。总结随着对时间序列数据的需求不断增长,专门处理这些数据的TSDB将被大量采用,同时也将面临激烈的竞争。除了本文涉及的三个开源TSDB,还有来自AWS(AWS Timestream)和Azure(Azure Series Insights)的公共云产品。与所有数据库一样,选择 "完美 "的TSDB主要取决于你的业务需求、数据模型和使用情况。如果你的数据符合taget模型,InfluxDB就能很好地工作,并且有一个丰富的集成生态系统可以使用。TimescaleDB是现有PostgreSQL用户的自然选择。最后,如果性能是主要关注点,QuestDB是一个有前途的项目,正在快速增长。


本文出自快速备案,转载时请注明出处及相应链接。

本文永久链接: https://www.xiaosb.com/beian/36897/