InfluxDB 3 开源版本现已公开发布 Alpha 版，采用 MIT/Apache 2 许可证

作者：Paul Dix / 产品
2025 年 1 月 13 日

导航至

全新 InfluxDB 3 Core 和 InfluxDB 3 Enterprise 产品现已可用于 Alpha 测试。

今天，我们激动地宣布 InfluxDB 3 Core (下载) 的 Alpha 版本发布，这是 InfluxDB 3 产品线中的全新开源产品，以及 InfluxDB 3 Enterprise (下载)，这是一个基于 Core 基础构建的商业版本。InfluxDB 3 Core 是一个用于时间序列和事件数据的最新数据引擎。InfluxDB 3 Enterprise 增加了历史查询能力、读取副本、高可用性、可扩展性和细粒度的安全性。

对于开源，我们知道构建一个可以作为单个进程运行的产品非常重要，这样可以轻松设置并立即开始使用。我们还意识到，我们的许多客户都希望有一个操作简单的数据库作为选项，以替代或补充我们的可扩展分布式系统。最终成果是开源的 InfluxDB 3 Core（双重许可，采用 MIT 或 Apache 2 许可证）和 InfluxDB 3 Enterprise，这是核心开源产品的商业版本。

这些产品基于四年多的开发，并由 FDAP 堆栈（Apache Flight、DataFusion、Arrow 和 Parquet）驱动，并在我们重建的时间序列数据库架构上交付。它们提供了 InfluxDB 3 的所有关键功能，包括无限基数、原生对象存储支持和强大的 SQL 查询引擎，同时保持我们对开源社区的承诺。

我将深入探讨这两款产品，重点介绍它们如何解决时间序列数据开发者工具集中的关键差距。我还将详细讨论以下几个相关主题

  1. InfluxDB 3.0 开源版本将被称为 InfluxDB 3 Core， 这是一个最新的数据引擎，持久化 Parquet 文件，并支持对最近 72 小时数据的查询。[编者注：历史数据限制已取消。请参阅 2025 年 1 月 27 日的更新以获取更多信息。] Core 的开发将继续在宽松的 MIT 或 Apache 2 许可证下进行
  2. 除了发布 InfluxDB 3 Core 之外，我们还将发布 InfluxDB 3 Enterprise， 这是开源 Core 产品的商业版本。
  3. Core 和 Enterprise 的主要功能 以及它们在时间序列工具集中独特的定位，包括无盘架构、快速的最新数据处理以及用于插件和触发器的嵌入式 Python。
  4. 与之前 InfluxDB 版本的兼容性、 迁移工具以及从 1.x/2.x 升级时的预期。
  5. 我们对开源的承诺 、宽松的许可，以及 InfluxData 持续关注在开源产品和商业产品之间保持明确区分。

如果您有兴趣立即下载并使用该软件，您可以找到 Core 和 Enterprise 的入门指南。 您可以在此处找到 InfluxDB 3 Core 的开源仓库。在 Alpha 测试期间，可以通过免费的限时试用访问 InfluxDB 3 Enterprise。对于 Enterprise，我们仅在设置过程中要求您提供电子邮件地址，以便您可以开始使用，而无需与任何人交谈。

InfluxDB 3 Core 的主要功能

InfluxDB 3 Core 为开发者提供了一个用于时间序列数据管理的新工具——一个高性能的最新数据引擎，针对查询最近 72 小时的数据进行了优化[编者注：历史数据限制已取消，请参阅更新]。这种专注的方法使 Core 能够为实时监控、数据采集和流式分析用例提供卓越的性能。通过专门针对这种模式进行优化，我们实现了最后值查询低于 10 毫秒的响应时间，以及小时范围查询低于 50 毫秒的响应时间。

“通过针对最常见的用例进行优化，我们创建了一个系统，该系统在提供卓越性能的同时，仍然保持真正的开源和宽松的许可。”

InfluxDB 3 Core 旨在与本地磁盘一起运行且无依赖项，或者“无盘”运行，使用对象存储（例如，S3）存储所有数据。InfluxDB 3 Core 配备了用于编写插件的嵌入式 Python VM 以及最后值和不同值缓存，是一个有用的数据收集器、监控代理和最新的时间序列数据库，可将数据持久化到 Parquet 文件中，以供长期存储和第三方系统访问。

无盘架构

Core（和 Enterprise）的一个关键特性是它们能够在“无盘”模式下运行，使用对象存储作为唯一的持久层。虽然它们保持了仅使用本地磁盘运行的能力，但仅使用对象存储进行无状态运行的选项使动态操作环境成为可能。在这些环境中，第三方系统可以从对象存储中无缝访问数据。

写入数据库的数据会经过验证并缓冲到内存 WAL 中，该 WAL 每秒刷新一次到对象存储。写入器可以在刷新后收到响应，从而保证持久性，或者在验证后立即收到响应。刷新后，此数据将放入内存 Arrow 缓冲区中，该缓冲区可查询。

WAL 会定期进行快照，将内存中的 Arrow 缓冲区持久化到对象存储上的 Parquet 文件中。此过程会删除 WAL 文件中已持久化到 Parquet 的数据，并写入快照文件，其中包含已持久化的内容的摘要。这可以减小 WAL 大小并使其易于管理。

第三方查询引擎、数据湖和数据仓库可以直接查询 Core 落在对象存储中的 Parquet 文件，从而为用户提供更多访问其历史时间序列数据的方式。

每个将数据写入对象存储的主机都将所有文件持久化，其路径以用户在启动时分配的唯一标识符开头。由于所有数据都保存在对象存储中，因此我们获得了随之而来的所有好处：多可用区持久性保证、备份实用程序以及整个第三方对象存储工具生态系统。如果写入主机由于某种原因宕机，则可以使用旧主机的标识符启动新主机，并在其停止的位置继续。

第三方查询引擎、数据湖和数据仓库可以直接查询 Core 落在对象存储中的 Parquet 文件，从而为用户提供更多访问其历史时间序列数据的方式。我们选择 Parquet 作为持久化格式，主要是因为它在数据生态系统中得到了广泛采用。随着 Iceberg Catalog 格式越来越受欢迎，这一点变得更加重要。InfluxDB 3 是将实时数据落地到对象存储和 Iceberg Catalog 的绝佳代理。

快速访问最新数据

InfluxDB 3 具有旨在快速访问最新数据的功能。这包括内存缓冲区、Parquet 缓存、最后值缓存和不同值缓存。我们的性能目标是在 10 毫秒内查询最后值和不同值，在 50 毫秒内查询最近一小时的数据，以及在几百毫秒内查询过去 72 小时内的数据 [注：历史数据限制已取消]。通过使用对象存储进行持久化来实现这一点意味着我们有各种内存缓存。

内存缓冲区充当 WAL 中尚未转换为 Parquet 并持久化的数据的快速查询路径。它以 Arrow 格式保存在构建器中，并在数据到达时附加到其中。当数据从 WAL 快照、缓冲到 Parquet 并持久化到对象存储时，我们会将其写入内存 Parquet 缓存，然后再从缓冲区中清除。这意味着对于最新数据，我们永远不必访问对象存储来回答查询。

最后值缓存是一项新功能，允许用户配置数据库以缓存为单个序列、特定列值或层次结构看到的最后 N 个值。这可以基于每个表或整个数据库来完成。例如，如果您有传感器数据，并且您有列 site_name、machine_id 和 sensor_id，您可以配置最后值缓存以保留该层次结构（站点 -> 机器 -> 传感器）上的值，然后快速获取特定传感器的最后两个值、机器内所有传感器或整个站点内所有传感器。缓存充当内存循环数据库，在 WAL 刷新发生时（默认情况下每秒）填充。

不同值缓存是另一项新功能，允许用户配置数据库以缓存列或列层次结构所看到的不同值，类似于最后值缓存的工作方式。它在 WAL 刷新时（每秒）填充，就像最后值缓存一样。虽然可以通过 SQL 引擎针对原始数据访问相同的此信息，但不同值缓存旨在在 10 到 30 毫秒内返回值，使其非常适合构建快速 UI 体验。

通过嵌入式 Python 实现插件和触发器

作为此 Alpha 版本发布的一部分，我们正在测试一个新的插件系统的体验，该系统允许用户定义 Python 脚本，这些脚本可以直接在数据库中动态收集、处理、转换和监控数据。它带有一个全新的 API 和开发流程。它仍处于非常早期的阶段，因此我们将迭代其功能和确切的开发者体验——在此期间可能会有破坏性的 API 更改。

“我们对插件系统将实现的一系列可能性感到兴奋，特别是当它与快速的最新数据查询引擎和最后值缓存结合使用时。我们选择 Python 是因为它被广泛采用，并且大多数 LLM 都可以编写简短的 Python 脚本。”

插件系统是早期版本 InfluxDB 中功能的逻辑继承者，例如持续查询、任务、Kapacitor 和 Telegraf。虽然 Kapacitor 和 Telegraf 继续与 InfluxDB 3 一起工作，但插件系统将此功能直接引入数据库。该系统能够实现

  • 自定义数据采集和转换
  • 实时监控和警报
  • 与第三方服务集成
  • 计划任务执行
  • 降采样和聚合
  • 为自定义 API 创建 HTTP 端点

用户可以定义由数据库中各种数据生命周期事件触发的插件。插件 API 包括查询数据库、将数据写回数据库以及连接到通过 Python 的库和工具生态系统启用的任何第三方服务的能力。插件的触发点是

  • 在 WAL 刷新时 ，每秒（可配置）向插件发送一批写入数据。
  • 按计划 执行用户配置的计划上的插件，对于数据采集和死信监控非常有用。
  • 按请求 将插件绑定到 /api/v3/plugins/<name> 的 HTTP 端点，其中请求标头和内容发送到插件，然后插件可以解析、处理数据并将其发送到数据库或第三方服务

我们对插件系统将实现的一系列可能性感到兴奋，特别是当它与快速的最新数据查询引擎和最后值缓存结合使用时。我们选择 Python 是因为它被广泛采用，并且大多数 LLM 都可以编写简短的 Python 脚本。我们认为，借助当今可用的工具，即使是非程序员也能够在数据库中创建插件来解决其特定领域的问题。

InfluxDB 3 Enterprise

InfluxDB 3 Enterprise 是我们今天宣布的第二款产品，它基于 Core 的基础构建，具有以下功能

  • 高可用性配置
  • 读取副本，用于查询和插件处理的可扩展性
  • 增强的安全功能
  • 历史数据压缩和索引，以实现更快地查询超过一小时的数据
  • 行级删除支持（即将推出）
  • 集成管理 UI（即将推出）

Enterprise 专为操作简单而设计，无论部署在裸机、虚拟机、容器还是 Kubernetes 上。其架构实现了不同工作负载的隔离，同时仅共享对象存储上的文件，使其成为自定义部署架构的理想选择。

我们将提供从以前版本的 InfluxDB 迁移历史数据的工具。

与之前 InfluxDB 版本的兼容性

虽然我们无法向前移植以前版本 InfluxDB 的所有功能，但我们已努力将一些旧的 API 引入新版本。我们保持了与以下现有 InfluxDB 功能的兼容性

  • 支持 InfluxDB 1.x 和 2.x 写入 API
  • InfluxDB Line Protocol 支持
  • InfluxQL 查询支持（以及 v1 查询 API）

但是，与 v1 和 v2 相比，InfluxDB 3 在数据摄取方面确实存在一些限制。对于 Core，服务器上数据库的硬性限制为五个，表的硬性限制为 2,000 个。对于 Enterprise，限制为 100 个数据库和 4,000 个表。我们这样做是为了限制资源利用率以及在快照缓冲区时需要持久化到对象存储的单个 Parquet 文件数量。根据这些限制对我们用户的工作方式，我们将来可能会努力增加这些限制。

虽然 InfluxDB 3 仍然支持写时模式，但它不支持在创建表后添加新的标签列。这是因为标签集和时间代表表中的主键。但是，可以随时添加新字段。在 InfluxDB 3 中创建架构时，只有行的唯一标识信息应放在标签中，而其他所有内容都应是字段。一般来说，最好将字段用于数据，而不是标签。

我们将致力于 InfluxDB Enterprise 的数据迁移工具。由于开源版本仅设计用于最近 72 小时内的数据，因此我们对迁移到开源版本的建议是将旧版本的写入镜像到新的运行中的开源实例，然后在 72 小时后切换。[注：历史数据限制已取消。]

很遗憾，目前我们无法为 Flux 用户提供兼容层。我们希望 Python 插件系统、SQL 和 InfluxQL 的组合能够为用户提供他们之前使用 Flux 拥有的所有功能。

FDAP 堆栈：InfluxDB 3 的核心组件

四年多前，我们开始开发 InfluxDB 3，围绕 FDAP 堆栈（Apache Arrow Flight、Apache DataFusion、Apache Arrow 和 Apache Parquet）构建了一个新的基于 Rust 的核心。投资 Apache 软件基金会项目并围绕它们构建 InfluxDB 3 是我们开源开发战略的一部分。我们认为开源的存在是为了创造广泛使用的商品——可以免费使用、改进、构建、商业化和启发衍生项目。具体来说，我们认为具有解析器、规划器、优化器和向量化执行的先进、高性能 SQL 引擎应该免费提供给任何用户或公司用于任何目的，即使是 InfluxDB 的竞争对手也可以使用。

“随着我们发布基于这项技术构建的新版本 InfluxDB，我们现在拥有强劲的顺风，这将继续推动新功能和性能的提升。”

我们刻意选择围绕开放标准构建，目标是与第三方项目和产品具有更广泛的兼容性。这促使我们选择了 SQL 作为查询语言，Flight 和 Arrow 作为 RPC，以及 Parquet 作为文件格式。随着 Iceberg Catalog 格式的兴起，Parquet 的选择变得更加重要。我们认识到这一点的重要性，甚至为 Iceberg 规范和实施贡献了纳秒时间戳，以支持 InfluxDB 所需的精度。

在过去的 4.5 年里，我们帮助将 DataFusion 发展成为今天的高性能列式查询引擎。在此过程中，我们开发、开源并捐赠给 ASF 对象存储抽象，使 DataFusion 能够针对任何主要云提供商的对象存储中的文件执行操作。在 InfluxData 员工工程师兼 PMC 主席 Andrew Lamb 的领导下，我们和 DataFusion 周围的许多贡献者的努力成果可以在去年的 SIGMOD 论文和 DataFusion 最近在针对 Parquet 文件的单节点查询引擎排名中名列榜首中看到。

由于 DataFusion 在 ASF 中的地位，这种创新步伐只会加速。这使得各种规模的公司都可以放心地为 DataFusion 做出贡献并改进它。世界上最大的公司和各种初创公司不仅在使用 DataFusion，还在改进引擎本身的性能、功能和可靠性。这些进步直接流入 InfluxDB 3，不断提高其性能，并为我们带来了在开始这段旅程时所能期望的最佳结果。与封闭的专有软件相比，这是一种无与伦比的策略——我们加速了多年的成熟度。

从一开始，我们的目标就是让尽可能多的用户和公司采用核心引擎，甚至超越 InfluxDB 本身。这种广泛的采用培养了更大的贡献者群体，他们在推动创新边界的同时，创造了更强大的软件。它在许多不同的环境、许多用例以及各种数据中都经过了实战检验。随着我们发布基于这项技术构建的新版本 InfluxDB，我们现在拥有强劲的顺风，这将继续推动新功能和性能的提升。

我们的开源理念

通过今天的公告，我们将继续履行我们对开源的承诺，并在我们的开源项目和商业产品之间保持清晰的界限。我们没有通过许可限制使用，而是选择通过架构决策来区分，这些决策既有利于我们的开源用户，也有利于我们的商业客户。我们相信这种方法可以培养更活跃的社区，同时确保我们可以继续为开源开发进行长期投资。

将 Core 专注于近期数据的决定反映了技术和业务考量的仔细权衡。Core 的近期数据优化不仅仅是一个商业边界，它还是一种架构选择，可以为最常见的时间序列工作负载实现更好的性能、可靠性和简单性。通过针对最常见的用例进行优化，我们创建了一个系统，该系统在提供卓越性能的同时，仍然在宽松的许可下保持真正的开源。这种专注的方法使我们能够通过避免开源产品中压缩的复杂性来确保可靠的运行。此外，它通过使用户可以轻松地将 Core 与他们选择的第三方工具结合使用以进行历史分析，从而鼓励生态系统集成。

最终，我们将根据来自社区和客户的反馈进行迭代。我们希望确保某些版本的 InfluxDB 仍然可以服务于家庭和副项目用例。根据我们收到的反馈，我们可能会为 Enterprise 开辟一个非商业用途层，该层可以免费使用。

开发时间表

Alpha 阶段将侧重于广泛的测试和性能验证、整合社区反馈、改进 API 以及增强操作体验。在此期间，我们可能会对文件格式或 API 进行重大更改。我们的目标是在 3 月初过渡到 Beta 版，这将标志着任何潜在的重大更改的结束。计划在 4 月份发布正式版，具体时间取决于 Alpha 和 Beta 阶段的学习成果。

加入社区并提供反馈

这仅仅是一个持续旅程的开始，持续的开发和迭代正在公开进行。请查看我们的 Core 和 Enterprise 入门指南，并加入以下频道以提供反馈

InfluxDB 3 Core 和 Enterprise 的 Alpha 版本代表了我们对时间序列数据未来的愿景以及我们对开源社区的承诺。我们期待您的反馈和参与，共同塑造 InfluxDB 的未来。