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

导航至

不同的时序工作负载

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

需要明确的是——很难找到一种解决方案,可以同时处理所有不同类型的时序数据及其各自的工作负载,但这并不意味着不可能。如果我们回到从数据中衍生时序的想法,当我们存储这些衍生数据时,我们得到指标。但是下面讨论的其他工作负载——原始事件、追踪和日志——所有这三者的底层数据都只是……数据。我们对底层数据运行的查询最终决定了生成、处理和分析结果时序所需的工作负载。

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

指标

这是我们之前的解决方案擅长的领域,而借助新的 InfluxDB IOx 存储引擎,它变得更好了。指标本质上是以固定间隔轮询现有事件流,以获得对系统、流程或其他数据源的可见性。这种类型的数据是许多可观测性流程的基础。InfluxDB 每秒可以摄取数十亿个数据点,并支持对这些数据进行实时分析。

原始事件

原始事件与指标相关,但由 IOx 驱动的 InfluxDB 的新功能意味着用户无需简单地轮询事件数据流。相反,现在用户可以简单地收集所有原始事件数据,无论其粒度如何,并动态计算指标。这之所以成为可能,是因为我们优化了新的查询引擎,以便对此类型的数据执行快速分析查询。同样,这与简单地收集指标是不同的工作负载。但由于由 IOx 驱动的 InfluxDB 是列式数据库,它使用内存存储层来缓存前沿的“热”数据,从而实现亚秒级查询响应。

这意味着用户可以查看过去三个小时内特定存储桶中数据的百分位数等内容。他们可以动态地导出这些摘要,并根据需要扩展这些类型的查询。这里的关键点在于,通过拥有可用于查询的整个数据流,而不仅仅是指标,用户可以按照他们想要的任何方式跨不同维度对数据进行切片和切块。

追踪

分布式追踪是以前版本的 InfluxDB 在技术上可以做到的用例,但通常在性能方面表现不佳。造成这种情况的原因是基数问题。追踪中的关键信息之一是 span ID,它最适合作为 InfluxDB 数据模型中的标签。

虽然您的应用程序中可能只有有限数量的 span,但每个 ID 的值可以是任何值。拥有无限制的标签值会产生失控的基数,从而影响整体性能。因此,为了启用追踪,我们必须解决基数问题,而我们通过 InfluxDB IOx 引擎做到了这一点。

查看这篇文章,了解有关新引擎如何在技术层面上解决基数的更多详细信息。毋庸置疑,高基数会为追踪创建非常不同的工作负载,但 InfluxDB IOx 具有处理追踪工作负载的能力,而不会导致性能下降。

日志

虽然日志仍然是时序数据,但它完全是另一种事物。InfluxDB IOx 引擎可以处理日志数据,但尚未针对日志工作负载进行优化。日志数据与追踪数据有一些相似之处,因为它通常具有非常高的基数。但高基数数据的结构与追踪数据不同。

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

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

与任何事物一样,这在现实中如何发挥作用将取决于您收集的日志数据类型、您如何解析它以及参数和错误名称类型的一致性。

结束语

时序数据的结构可能因您的数据源和您最终想要实现的目标而异。在可观测性方面,监控、事件、追踪和日志都发挥着关键且通常相互关联的作用。与此同时,重要的是要考虑围绕每种数据类型的不同工作负载。幸运的是,我们构建并优化了由 IOx 驱动的 InfluxDB,以最大限度地增加单个数据库中可用的时序工作负载的数量和类型。InfluxDB IOx 引擎已经解锁了以前的数据库引擎无法实现或非常难以实现的用例,并使它们成为可能且性能卓越。

您正在使用由 IOx 驱动的 InfluxDB 构建什么?告诉我们,您甚至可能会获得一些免费赠品!