哪个时间序列数据库更好：TimescaleDB与InfluxDB_数据库_博客_测评&博客

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

我们有不同类型的时间序列数据库，应该使用哪些数据库？

在此博客中，我们将看到两个主要选项TimescaleDB和InfluxDB之间的主要区别是什么。

InfluxDB

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

这是一个Flux查询示例：

1个

from(db:"testing")

|> range(start:-1h)

|> filter(fn: (r) => r._measurement == "cpu")

|> exponentialMovingAverage()

在此数据库中，每个度量都有一个时间戳，以及一组关联的标签和一组字段。该字段代表实际的测量读数值，而标签代表描述测量的元数据。字段数据类型仅限于浮点数，整数，字符串和布尔值，并且如果不重写数据就无法更改。标签值被索引。它们以字符串表示，无法更新。

InfluxDB入门非常容易，因为您不必担心创建模式或索引。但是，它非常严格且受限制，无法创建其他索引，在连续字段上建立索引，事后更新元数据，强制执行数据验证等。

它不是无模式的。有一个从输入数据自动创建的基础架构。

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

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

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

时标数据库

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

这是一个TimescaleDB查询示例：

1个

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 blob，地理空间尺寸，日期/时间/时间戳，货币，二进制数据等。

您可以在任何字段（标准索引）或多个字段（复合索引）上创建索引，也可以在函数之类的表达式上创建索引，甚至可以将索引限制为行的子集（部分索引）。这些字段中的任何一个都可以用作辅助表的外键，然后该表可以存储其他元数据。

这样，您需要选择一个模式，并确定系统需要哪些索引。

性能

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

插入物

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

读取延迟

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

稳定性问题

InfluxDB在基数高（100K +）时存在稳定性和性能问题。

结论

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

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

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