时间序列数据、基数和 InfluxDB

作者：Jason Myers / 产品
2023 年 3 月 15 日

导航至

什么是基数？

在数据库领域，基数指的是数据库中存储的唯一数据集的数量。更深入地理解，我们可以将基数视为表列或数据库等效项中可能存在的唯一值的总数。

在考虑时间序列数据时，我们可以提出一些关于基数的具体问题。基数在实践中是什么样的？基数何时成为问题？我们如何预防基数问题？

本文将探讨这些问题以及更多。我们将研究基数问题的根源，并最终讨论 InfluxDB 的 IOx 数据库引擎如何解决时间序列数据的基数问题。

InfluxDB 中的基数

为了理解基数问题是如何发生的，我们首先需要理解 InfluxDB 的数据模型，称为 Line Protocol。

Line Protocol 包含四个组成部分

  1. Measurement（测量）：这相当于关系数据库中的表。
  2. Tags（标签）：这些是由键值对组成的元数据，用于关联您的数据。InfluxDB 会索引标签，并且标签值可以是字符串。
  3. Fields（字段）：字段是键值对，表示您正在收集的实际数据点。字段可以是整数、浮点数、字符串或布尔值。
  4. Timestamp（时间戳）

Measurement 和标签集的每个唯一组合都会在 InfluxDB 中创建一个序列。如果您有很多这样的唯一组合，那么您就拥有高基数。现在，重要的是要记住，高基数本身并不是问题。

您可能拥有大量 Measurement/标签组合的原因是您的标签值包含无界数据。

让我们看一个例子。在传统的网络监控用例中，假设我们正在监控一些服务器机架。我们想确定服务器的地理位置，因此我们可能会得到一个类似 location=CA1 的标签。我们还需要跟踪每个单独的服务器机箱，包括与每个单元关联的唯一 IP 地址。如果我们有一个标签键 ip，则标签值可能是 1.1.1.1、1.1.0.1，从而产生键值对 ip=1.1.1.1、ip=1.1.0.1 等。每个唯一的标签值都可能创建一个新的 Measurement/标签集组合，从而增加数据集的基数。

那么，这为什么重要呢？InfluxDB 的 TSM 引擎将序列键存储在内存索引中，该索引会定期持久化到磁盘。因此，您的硬件决定了您的基数阈值，因为一旦磁盘填满，它会对数据库性能产生负面影响。

Schema（模式）和基数

为了避免基数问题，有必要考虑您的数据模式。

现在，InfluxDB 是一个 schema-on-write (写入时模式) 数据库。这意味着您不必在将数据放入 InfluxDB 之前创建结构化模式。如果您的数据遵循 Line Protocol，InfluxDB 会自动创建模式。如果您在流程中引入新的设备/传感器/源，并带有新的标签或字段键，InfluxDB 会自动调整模式以整合新数据。

具有如此数据形状灵活性的数据库迫使您考虑基数，这有点讽刺。尽管如此，这与关系数据库和其他数据库截然不同，后者要求用户在写入数据之前定义模式。如果您的数据形状发生变化，在这些解决方案中，更新模式可能是一件麻烦事。

但是，如果您想在 InfluxDB 中调整模式，那会是什么样的呢？嗯，这通常归结为您分配为标签的值以及您分配为字段的值。如上所述，标签值仅为字符串类型。如果您的数据生成无界标签值，那会增加高基数。某些用例，例如 tracing（追踪）和 logs（日志），往往会产生这种类型的高基数数据。

与此同时，将标签值更改为字段值可能对您来说没有意义。那该怎么办呢？

解决基数问题

InfluxDB 一直以来都能很好地处理指标，但由于基数问题，tracing（追踪）等用例可能会时好时坏。InfluxDB 的 TSM 引擎将每个序列存储为磁盘上的一个列。为了使 InfluxDB 能够应对全方位的时间序列用例，我们重建了核心数据库引擎。

我们构建了 InfluxDB，由 IOx 提供支持，作为一个列式数据存储，使用各种开源工具（Apache Arrow、Apache Parquet 等）来设计一个可以摄取高容量、高基数时间序列数据而不会影响性能的数据库。IOx 引擎不是将每个序列存储在一个列中，而是将每个标签和字段存储为一个列。这大大减少了列的总数，从而提高了性能。

有了这项新技术为 InfluxDB 提供支持，用户现在可以期望在各种时间序列工作负载中获得一致的性能，无论他们处理的是指标、原始事件数据、tracing（追踪）还是 logs（日志）。

IOx 引擎仍然存在一些模式方面的考虑，但围绕它们的基本问题要简单得多：您的模式是太宽还是太稀疏？

宽模式有很多列，这可能会影响性能。这正是最初整个基数问题的基础。为了确保查询保持高性能，InfluxDB IOx 存储引擎对每个 Measurement（测量）的列数限制为 200 列。解决宽模式的一个快速方法是将您的数据拆分为多个 Measurement（测量）。例如，如果您正在收集工厂中机器的数据，与其将来自工厂车间的所有数据转储到一个 Measurement（测量）中，不如为每台单独的机器创建一个 Measurement（测量）。

稀疏模式是指许多行包含空值的模式。这迫使查询引擎在执行时评估所有这些空列，从而为存储和查询数据增加了不必要的开销。

结论

长期以来，基数一直是 InfluxDB 的眼中钉。当然，它仍然可以运行，但不如它本可以的那样舒适。借助 InfluxDB IOx 引擎，性能至关重要，并且随着基数不再是曾经的问题，InfluxDB 可以实时摄取和分析大型工作负载。

因此，无论您是经验丰富的 InfluxDB 专家，还是刚开始接触它，都可以试用新的 InfluxDB IOx 引擎，看看它如何加速您的 Time to Awesome (达成精彩成就的时间)。