由IOx驱动的InfluxDB的4个独特时序工作负载

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

不同的时序工作负载

数据有点像牛顿的第一定律。数据就是那样，除非受到其他事物的作用。因此，时序数据是从数据中导出的。我们通常从数据中导出时序数据来记录关于物理或虚拟系统的历史观察（例如，分别考虑传感器和服务器）。然而，并非所有时序数据都是相同的。时序数据有不同的用例，并且每个都有其自己的工作负载需求。数据库存储和处理这些数据的方式因用例而异。

让我们明确一点——同时处理所有不同类型的时间序列数据和它们各自的工作负载是非常困难的，但这并不意味着这是不可能的。如果我们回到从数据推导时间序列的想法，当我们存储这些推导时，我们得到指标。但下面讨论的其他工作负载——原始事件、跟踪和日志——它们的基础数据仅仅是……数据。我们对底层数据执行的查询最终决定了生成、处理和分析结果时间序列所需的工作负载。

随着新的InfluxDB IOx数据库引擎，InfluxDB扩展了它可以处理的时间序列数据用例的数量。让我们快速了解一下一些关键类型的可观察性数据以及InfluxDB如何帮助用户从中获取价值。

指标

这是我们的先前解决方案表现卓越的领域，而新的InfluxDB IOx存储引擎使它变得更好。指标本质上是在固定时间间隔对现有事件流进行轮询，以了解系统、过程或其他数据源。这类数据是许多可观察性流程的基础。InfluxDB可以每秒摄取数十亿数据点，并使数据实时分析成为可能。

原始事件

原始事件与指标相关，但InfluxDB由IOx驱动的全新功能意味着用户无需简单地轮询事件数据流。相反，现在用户可以简单地收集所有这些原始事件数据，无论其粒度如何，并在实时计算指标。这是因为我们优化了新的查询引擎，以快速对这类数据进行分析查询。再次强调，这与仅仅收集指标的工作负载不同。但鉴于InfluxDB由IOx驱动是一个列式数据库，它使用内存存储层来缓存最前沿的“热”数据，这可以实现毫秒级的查询响应。

这意味着用户可以查看过去三小时内特定桶中数据的百分位数等。他们可以实时生成这些摘要并根据需要扩展这些类型查询的规模。这里的关键点是，通过查询整个数据流，而不仅仅是指标，用户可以以任何方式跨不同维度切片和切块他们的数据。

跟踪

分布式跟踪是InfluxDB的前几版在技术上可以处理的用例，但往往在性能上有所挣扎。原因在于基数问题。跟踪的关键信息之一是跨度ID，它最适合作为InfluxDB 数据模型中的标签。

虽然您的应用程序可能只有有限数量的跨度，但每个ID的值可以是任何东西。具有无界标签值会创建失控的基数，这会影响整体性能。因此，为了启用跟踪，我们必须解决基数问题，我们通过InfluxDB IOx引擎做到了这一点。

请查看这篇帖子以了解新引擎在技术层面上如何解决基数问题。不用说，高基数为跟踪创建了一个非常不同的工作负载，但InfluxDB IOx具有处理跟踪工作负载而不会降低性能的能力。

日志

虽然日志数据仍然是时间序列数据，但它们在本质上是完全不同的。InfluxDB IOx 引擎可以处理日志数据，但尚未针对日志工作负载进行优化。日志数据与跟踪数据在通常具有非常高的基数方面有相似之处。然而，这种高基数数据的结构在跟踪数据中是不同的。

对于日志而言，不仅标签值是无限的，标签键也是无限的。InfluxDB IOx 引擎将每个标签或字段值存储在其自己的列中，这使得存储、压缩、访问和分析该数据更快。这也减少了列的总数，因为标签和字段键往往是一致的。然而，无限的标签键会增加写入磁盘的列的数量。

想象一下，您正在从以 JSON 格式收集应用程序的调试日志。可能有许多参数会导致错误。由于有多个开发者构建应用程序并且保持一致的参数命名方案具有挑战性，因此会存在许多变化。参数名称的每个变化都会创建一个新的标签键。这些键值对的标签值也可以是非常长的字符串，这进一步增加了基数。

与现实生活中的任何事情一样，这种实现方式将因您收集的日志数据类型、您如何解析它以及参数和错误名称类型的一致性而有所不同。

结束语

时间序列数据结构可能因数据源和您最终想要实现的目标而大不相同。在可观测性、监控、事件、跟踪和日志中，所有这些都发挥着关键作用，并且通常是相互关联的。同时，考虑每种数据类型的不同工作负载也很重要。幸运的是，我们构建并优化了由 IOx 驱动的 InfluxDB，以最大限度地提高单个数据库中可用的时序工作负载的数量和类型。InfluxDB IOx 引擎已经解锁了使用用例，这些用例在使用以前的数据库引擎时要么不可能实现，要么非常困难，并且使它们变得可行和高效。

您正在使用由 IOx 驱动的 InfluxDB 构建什么？告诉我们，您甚至可能获得一些免费的礼品！