时序数据库 TimescaleDB 和 InfluxDB 对比

时间序列数据库

顾名思义,时间序列数据库旨在存储随时间变化的数据。这可以是对时间收集的任何类型的数据。他可能是从某些系统收集的指标,实际上,所有趋势系统均是时间序列数据的示例。

对于不同类型的时间序列数据库,我该如何选择?

本文中,我们主要讨论 TimescaleDB 和 InfluxDB 两个时序数据库的区别。

InfluxDB

InfluxDB 是由 InfluxData 创建的。它是用 Go 语言编写的自定义、开源、NoSQL 的时间序列数据库。数据存储区提供了一种类似 SQL 的查询语言,称之为 InfluxQL,这使开发人员可以轻松地将其集成到其应用程序中。它还具有一种称之为 Flux 的新的自定义查询语言,该语言可以是执行某些任务变得更容易,但在采用自定义查询语言时总会有一条学习曲线。

如下是一个 Flux 查询的示例:

from(db:"testing")
|> range(start:-1h)
|> filter(fn: (r) => r._measurement == "cpu")
|> exponentialMovingAverage()

在该数据库中,每个测量结果都包含一个时间戳,以及一组与之关联的标签和一组字段。该字段表示实际测量读取值,而标签表示描述测量的原数据。字段数据类型仅限于 float, int, string 和 boolean,不重写数据就无法更改。标记值被编入索引。他们以字符串表示,无法更新。

InfluxDB 入门非常容易,因为你不必担心创建原型或索引。但是,它非常严格死板和受限,无法创建额外的索引、连续字段上的索引、事后更新原数据、强制数据验证等。

他并非没有原型。它会根据输入的数据自动创建一个基础模型。

InfluxDB 必须从头开始实施多种容错工具,例如多副本、高可用性和备份/还原,并且要对磁盘的可靠性负责。我们仅限于使用这些工具,并且其中许多功能(如 HA)仅在企业版中可用。

InfluxDB 备份工具可以进行完整或增量备份,并且可以用于时间点恢复。

InfluxDB 还提供了比 PostgreSQL 和 TimescaleDB 更好的磁盘压缩。

TimescaleDB

TimescaleDB 是一个开源的时间序列数据库,已针对支持全面 SQL 的快速提取和复杂查询进行了优化。它基于 PostgreSQL ,并且为时间序列数据提供了最好的 NoSQL 和 关系世界。

如下是一个 TimescaleDB 查询示例:

SELECT time,
exponential_moving_average(value, 0.5) OVER (ORDER BY time)
FROM testing
WHERE measurement = cpu and time > now() - '1 hour';

作为 PostgreSQL 扩展,TimescaleDB 是一个关系数据库。这使得新用户有一个较短的学习曲线,并且可以继承 pg_dump 或 pg_backup 之类的工具进行备份,还继承了高可用性的工具,相比其他时间序列数据库这是一个优势。它还支持将流复制作为主要的复制方式,可以将其用于高可用性设置中。在故障转义和备份方面,你可以使用 ClusterControl 之类的外部系统来自动执行。

在 TimescaleDB 中,每个时间序列测量值都记录在自己的行中,时间字段后面跟着任意数量的其他类型字段,包括 浮点数,整数,字符串,布尔值,数组,JSON,地理空间尺寸,日期 / 时间 / 时间戳,货币,二进制数据等。

你可以在任意字段(标准索引)或多个字段(符合索引)上或在函数等表达式上创建索引,甚至可以将索引限制为行的自己(部分索引)。这些字段中的任何一个都可用作辅助表的外键,然后改辅助表可以存储其他原数据。

这样,你需要选择一个原型,并确定系统需要哪些索引。

性能

如果我们谈论性能,那么可以查看 TimescaleDB 博客。在那里,您可以通过图表和指标对两个数据库之间的性能进行详细比较。现在让我们看看该博客中的一些最重要的信息。

You can create indexes on any field (standard indexes) or multiple fields (composite indexes), or on expressions like functions, or even limit an index to a subset of rows (partial index). Any of these fields can be used as a foreign key to secondary tables, which can then store additional metadata.

In this way, you need to choose a schema, and decide which indexes you’ll need for your system.

插入性能

时序数据库 TimescaleDB 和 InfluxDB 对比_第1张图片

  • 对于基数非常低的工作负载(例如 100 个设备),InfluxDB 的性能优于 TimescaleDB。
  • 随着基数的增加,InfluxDB 插入性能下降的速度快于 TimescaleDB。
  • 对于中到高基数的工作负载(例如,100 个设备发送 10 个指标),TimescaleDB 的性能要优于 InfluxDB。

时序数据库 TimescaleDB 和 InfluxDB 对比_第2张图片

读取性能

时序数据库 TimescaleDB 和 InfluxDB 对比_第3张图片

  • 对于简单查询,结果相差很大:在某些情况下,一个数据库明显优于另一个数据库,而其他数据库则取决于数据集的基数。此处的差异通常在一位数到两位数的毫秒数范围内。
  • 对于复杂的查询,TimescaleDB 的性能大大优于 InfluxDB,并支持范围更广的查询类型。这里的差异通常在几秒到几十秒之间。
  • 考虑到这一点,正确测试的最佳方法是使用计划执行的查询进行基准测试。

稳定性

  • InfluxDB 在基数高(100K +)时存在稳定性和性能问题。
总结

如果您的数据适合 InfluxDB 数据模型,并且您不希望将来发生变化,那么您应该考虑使用 InfluxDB,因为该模型更容易上手,就像大多数使用面向列方法的数据库一样,提供比 PostgreSQL 和 TimescaleDB更好的磁盘压缩。

但是,关系模型比 InfluxDB 模型具有更多的通用性,并提供更多的功能,灵活性和控制力。随着应用程序的发展,这一点尤其重要。在规划系统时,您应该考虑当前和将来的需求。

在此博客中,我们可以看到 TimescaleDB 和 InfluxDB 之间的简短比较,并且可以说 TimescaleDB作为 PostgreSQL 扩展,看起来很成熟并且功能丰富,因为它从 PostgreSQL 继承了很多东西。但是您可以根据本博客前面提到的优缺点来做出自己的决定,并确保对自己的工作负载进行基准测试。在这个新的时间序列数据库世界中祝您好运!

你可能感兴趣的:(翻译)