InfluxDB 3 开源版发布 alpha 公测，采用 MIT/Apache 2 许可证

阅读《2024 中国开源开发者报告》赢大奖，扫码申请享特权

本文翻译自：https://www.influxdata.com/blog/influxdb3-open-source-public-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 查询引擎，同时保持对我们开源社区的承诺。

我将深入探讨这两个产品，重点关注它们如何填补时间序列数据开发者工具集中的关键空白。我还会详细讨论以下相关主题：

InfluxDB 3.0 开源版将被称为 InfluxDB 3 Core，这是一个持久化 Parquet 文件并允许查询最近 72 小时数据的实时数据引擎。[编辑者注：对历史数据的限制已取消。更多信息请见 2025 年 1 月 27 日的更新。] Core 的开发将继续在宽松的 MIT 或 Apache 2 许可证下进行。
除了发布 InfluxDB 3 Core，我们还发布了 InfluxDB 3 Enterprise，这是开源 Core 产品的商业版本。
Core 和 Enterprise 的关键特性以及它们在时间序列工具集中填补的独特位置，包括无盘架构、快速访问近期数据处理以及支持使用 Python 编写插件和触发器。
与 InfluxDB 旧版本的兼容性、迁移工具以及从 1.x/2.x 升级时应期待的内容。
我们对开源的承诺，宽松的许可协议，以及InfluxData持续关注在开源产品和商业产品之间保持清晰的界限。

如果您想立即下载并使用该软件，您可以找到Core和Enterprise的入门指南。您可以在这里找到InfluxDB 3 Core的开源仓库。

在alpha测试期间，您可以通过免费限时的试用来访问InfluxDB 3 Enterprise。对于企业版，我们在设置过程中只要求您提供电子邮件地址，这样您就可以在不与任何人交谈的情况下开始使用。

InfluxDB 3 Core 关键特性

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

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

InfluxDB 3 核心版旨在以本地磁盘和无需依赖的方式运行，或者“无盘”模式，使用对象存储（例如，S3）来存储所有数据。搭配内置的 Python 虚拟机以编写插件以及最后值和唯一值缓存，InfluxDB 3 核心版是一款有用的数据收集器、监控代理和最近时间序列数据库，它将数据持久化到 Parquet 文件中，以便长期存储和第三方系统的访问。

无盘架构

核心版（以及企业版）的一个关键特性是它们能够在“无盘”模式下运行，使用对象存储作为唯一的持久化层。虽然它们仍然能够仅使用本地磁盘运行，但仅使用对象存储运行的无状态选项使得操作环境更加动态。在这些环境中，第三方系统可以无缝访问对象存储来读取数据。

写入数据库的数据经过验证并缓冲到内存中的WAL（Write-Ahead Log）中，每秒刷新一次到对象存储。写入者可以选择在刷新后接收响应，从而保证数据的持久性，或者验证后立即接收响应。刷新后的数据被放入内存中的Arrow缓冲区，该缓冲区是可查询的。

WAL会定期进行快照，将内存中的Arrow缓冲区持久化到对象存储上的Parquet文件。这个过程会删除已持久化到Parquet的WAL文件，并写入包含已持久化数据摘要的快照文件。这有助于保持WAL的大小在可控范围内。

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

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

第三方查询引擎、数据湖和数据仓库可以直接查询Core存储在对象存储中的Parquet文件，使用户有更多方式访问他们的历史时间序列数据。我们选择Parquet作为持久化格式，正是因为它在数据生态系统中得到了广泛的应用。随着Iceberg目录格式的流行，这一点变得更加重要。InfluxDB 3是实时数据在对象存储和Iceberg目录中落地的优秀代理。

快速访问近期数据

InfluxDB 3 设计了针对快速访问近期数据的特性。这包括内存缓冲区、Parquet 缓存、最后值缓存和唯一值缓存。我们的性能目标是查询最后值和唯一值在10毫秒以内完成，查询最后1小时的数据在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，是因为其广泛的采用以及大多数大型语言模型编写简短Python脚本的能力。

插件系统是InfluxDB早期版本中功能（如连续查询、任务、Kapacitor和Telegraf）的合理继承者。虽然Kapacitor和Telegraf继续与InfluxDB 3协同工作，但插件系统将这一功能直接引入了数据库。该系统使得以下功能成为可能：

自定义数据收集和转换
实时监控和警报
与第三方服务的集成
定时任务执行
下采样和聚合
创建HTTP端点以实现自定义API

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

在WAL刷新时，每秒将一批写数据发送到插件一次（可配置）。
在快照（Parquet文件的持久化）时，将元数据发送到插件以对Parquet数据进行进一步处理或将信息发送到其他地方（例如，添加到Iceberg目录）。
按计划，根据用户配置的计划执行插件，对于数据收集和死亡监控非常有用。
在请求时，将插件绑定到/api/v3/plugins/<name>的HTTP端点，请求头和内容会发送到插件，然后插件可以解析、处理并将数据发送到数据库或第三方服务。

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

InfluxDB 3 企业版

今天我们宣布的第二个产品是InfluxDB 3 企业版，它在Core的基础上增加了以下功能：

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

企业版旨在简化操作，无论是在裸金属、虚拟机、容器还是Kubernetes上部署。其架构能够隔离不同的工作负载，同时只在对象存储上共享文件，使其非常适合定制部署架构。

我们将提供从先前版本的InfluxDB迁移数据到新版本的工具。

与InfluxDB旧版本的兼容性

虽然我们无法将InfluxDB先前版本的所有功能都迁移到新版本中，但我们努力将一些旧API引入新版本。我们保持了以下现有InfluxDB功能的兼容性：

支持1.x和2.x版本的InfluxDB写入API
InfluxDB行协议支持
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，RPC使用Flight和Arrow，文件格式使用Parquet。随着Iceberg目录格式的兴起，Parquet的选择变得更加重要。我们认识到了这一点，甚至向Iceberg规范和实现贡献了纳秒级时间戳，以支持InfluxDB所需的高精度。

在过去的4.5年里，我们帮助构建了DataFusion，使其成为今天的高性能列式查询引擎。在这个过程中，我们开发了、开源了，并将对象存储抽象层捐赠给了Apache软件基金会（ASF），这使得DataFusion能够对任何主流云服务提供商的对象存储中的文件执行操作。我们的努力成果以及许多围绕DataFusion的贡献者，由InfluxData的工程师和项目管理委员会（PMC）主席Andrew Lamb领导，可以在去年的SIGMOD论文中看到，并且DataFusion最近在针对Parquet文件的单一节点查询引擎排名中位居榜首。

这种创新的步伐因DataFusion位于Apache软件基金会（ASF）而不断加速。这使得所有规模的公司都能安全地贡献和改进DataFusion。世界上最大的公司和各种类型的初创企业不仅在使用DataFusion，还在提升引擎的性能、功能和可靠性。这些进步直接流入InfluxDB 3，持续提升其性能，并为我们实现了在踏上这段旅程时所期望的最好结果。与封闭的专有软件相比，这是一种无与伦比的战略——我们通过这种方式加速了成熟度，节省了数年的时间。

从一开始，我们的目标就是让核心引擎尽可能多地被用户和企业采用，甚至超出InfluxDB本身。这种广泛的采用促进了更多贡献者加入，他们推动创新的边界，同时创造更健壮的软件。它在许多不同的环境中经过了实战考验，适用于各种用例，并处理了各种类型的数据。随着我们发布基于这项技术的新版本InfluxDB，我们现在拥有强大的顺风，这将继续推动新功能和性能的发展。

我们的开源理念

随着今天的公告，我们继续承诺支持开源，并保持我们开源项目和商业产品之间的明确区分。我们不是通过许可证限制使用，而是选择通过架构决策来区分，这些决策既有利于我们的开源用户，也有利于商业客户。我们相信这种方法能够促进更加活跃的社区，同时确保我们能够长期持续投资于开源开发。

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

最终，我们将根据社区和客户的反馈进行迭代。我们希望确保InfluxDB的某个版本仍然能够满足家庭和副项目的使用需求。根据我们收到的反馈，我们可能会为Enterprise版本开放一个非商业用途的免费使用层。