Elasticsearch 为何正转型为列式数据库

Elasticsearch 为何正转型为列式数据库

体验 Elastic 开箱即用的领先功能。深入了解 Elasticsearch Labs 代码库 中的示例 Notebook，开始 免费云试用，或立即在您的 本地机器上试用 Elastic。

Elasticsearch 正在成为一流的列式数据库。在 9.5 版本中，我们推出了 Columnar Mode，这是一种全新的索引模式，它以列式形式存储数据一次，不产生冗余副本，也不创建工作负载不需要的索引。

Columnar Mode 适用于数据写入量大、需要进行分析查询并长期保留的工作负载，包括：日志和可观测性、安全遥测、指标和追踪、操作数据上的业务分析以及大规模 AI 检索。对于这些工作负载，这意味着：从第一天起就显著减小存储占用空间，并为更快的摄入、更快的分析查询和更长时间的数据保留奠定基础，随着相关工作的成熟，这些优势将日益凸显。

Columnar Mode 将与现有模式并行发布，而非取而代之。API、仪表板、应用程序或下游集成均无需更改。这是一种新的索引模式，您可以在其适用且有帮助的数据上采用它。

最终结果是，Elasticsearch 在同一个集群中，使用相同的数据，在同一个操作管理体系下，成为一个世界级的搜索引擎和列式分析引擎。通过这种方式，Elastic 能够在列式架构重塑数据经济效益的背景下，保持其作为存储操作数据最有用的平台地位。

本文的其余部分将解释我们为什么要这样做，以及它会改变什么和不会改变什么。

Elasticsearch 为何要新增列式模式

在过去的 15 年里，几乎所有值得关注的通用数据系统都做出了相同的架构决策：当任务是读取、聚合和分析大量数据时，数据应该按列组织，而不是按行或文档组织。

Elasticsearch 现在也做出了这个决定。

除了其文档模型、搜索传统以及在整个行业可观测性、安全和搜索应用中的核心地位，Elasticsearch 现在还在同一平台内增加了第二种思考数据的方式。我们称之为 Columnar Mode。它使 Elasticsearch 成为唯一一个能够在相同数据上，以相同的操作方式，同时提供相同水平的搜索、检索和分析能力的主要平台。

要理解这一点，我们需要指出三点：第一，Elasticsearch 是如何发展到今天，以及为何文档模型是正确的选择。第二，数据世界的其他部分是如何并行地趋向于一种完全不同的数据形态，以及这种转变为何如此成功。第三，这两个世界现在如何在用户的系统中融合，以及将列式存储引入 Elasticsearch 为何是正确的答案。

Elasticsearch 如何成为文档数据库（以及为何这是正确的选择）

要理解我们走向何方，首先必须了解我们从何开始。

十六年前，当 Elastic 的创始人 Shay Banon 编写 Elasticsearch 的第一个版本时，数据世界正处于一场悄然进行的革命之中。JSON 正在吞噬网络。Web 应用程序发送和接收数据的方式不再是严格类型化的、定义明确的表格行，而是灵活的半结构化文档（一个客户订单、一条聊天消息、一个产品列表、一条日志行、一个食谱），每个文档都是一个包含字段、子字段、数组和嵌套对象的独立小世界。

当时的关系型数据库是基于一个非常不同的假设构建的：预先定义严格的模式、将数据分解为规范化的表格，并在查询时使用连接重新组装数据。这对于它所设计的用例（事务系统、银行、企业资源规划系统）非常有效，但却给新一代的 Web 和移动应用程序带来了巨大的摩擦。添加一个字段意味着一次迁移，存储可变形状的数据则意味着要么是一个脆弱的模式，要么是一堆可为空的列。

作为回应，一类新的系统应运而生：文档数据库。其理念很简单：接收数据时，以接近其原生形状的方式存储。不要让开发人员为了表达其领域模型而与数据库抗争。MongoDB 在操作端成为了这一理念的旗手，而 Elasticsearch 则在搜索端扛起了同样的旗帜。

对于 Elasticsearch 而言，文档模型不仅仅是一个开发者体验的选择，更是一个深刻的架构承诺。其引擎的设计理念是：一条记录就是一个文档，一个文档有字段，字段有类型，并且您应该能够将几乎任何内容放入其中，并获得有用的行为（全文搜索、结构化过滤、排序、聚合、排名），而无需预先完美地建模数据。

这就是我们所说的 Elasticsearch 的“文档行为”：

• • 引擎会记住您发送给它的内容。原始记录被存储，并且始终可以按其原始形式返回。
• • 默认情况下，每个字段都可以通过多种方式进行查询：针对快速精确查找、快速文本搜索、快速范围查询、快速排序和快速分组进行优化。
• • 模式是灵活的。新字段在写入时被吸收。数据模型“错误”的成本很低。
• • 工作单元是文档。索引、检索和大多数 API 都以“给定一个文档，执行 X”或“给定一个查询，返回文档”的形式进行。

这是一个源于搜索的模型。Apache Lucene，Elasticsearch 所基于的存储库，旨在使一种工作负载极其快速：接收一个查询，找到少量匹配的文档，按相关性对其进行排名，并返回它们。为了做好这一点，您需要构建倒排索引：一种将问题反转的结构，这样您就不是问“这个文档里有什么？”而是问“哪些文档包含这个词？”并在毫秒内得到答案。您还需要保留原始文档，因为一旦找到它，您通常希望展示它或从中检索更多信息。

对于 Elasticsearch 成长过程中所服务的那些工作负载（网站搜索、日志搜索、应用程序搜索、安全事件查找，“大海捞针”式的查找），这曾是，且仍然是，正确的形态。Elasticsearch 在全球数十万组织中投入生产使用，原因正在于此。

但文档模型存在固有的成本，而这一成本正是后续一切的起点。

为了兑现其快速搜索、灵活模式和忠实存储原始记录的承诺，引擎最终会多次存储数据，并以多种形态存储，每种形态都针对不同的查询进行了优化。原始文档被存储，每个字段中的文本都被索引以供搜索。每个字段中的值也单独存储在一个名为 doc values 的每字段列式存储中，以便可以进行聚合、排序和分组。系统默认情况下在每个字段上并行维护所有这些结构，因为在写入时，它不知道您在读取时会需要哪些功能。

对于 Elasticsearch 最初设计的那类数据集（相对丰富、相对低量的文档，其中每次读取都很有价值），这种权衡是极好的。您支付适度的存储和摄入成本，换来巨大的功能覆盖面。

对于 Elasticsearch 如今越来越多存储的那类数据集（数十亿日志行、数万亿指标点、海量遥测数据，其中大部分只写入一次且很少读取），这种权衡开始显得截然不同。

这正是我们要解决的摩擦点。

另一个故事：数据世界如何走向列式存储

当 Elasticsearch 完善文档模型时，一场平行的革命正在分析领域发生。它始于学术界，随后商业化，现在已成为几乎所有为读取和分析大型数据集而构建的系统的默认架构。为了清晰地定位 Columnar Mode，我们必须讲述这个故事。

列式存储背后的理念如此简单，以至于听起来几乎像个小把戏：不是逐行存储数据（记录一、记录二、记录三……），而是逐列存储（所有 timestamp 值，然后所有 host_name 值，然后所有 status_code 值……）。

这一个决定改变了一切。

它始于 20 世纪 90 年代初，起源于阿姆斯特丹数学与计算机科学研究中心（Centrum Wiskunde & Informatica）的 MonetDB 等研究系统。2000 年代中期，麻省理工学院（MIT）由 Michael Stonebraker 领导的 C-Store 项目使其更加完善，该项目后来成为 Vertica 的基础。Sybase IQ 将同样的理念带入了早期商业市场。到 2010 年代初，地球上所有重要的分析供应商都拥有了列式存储方案。如今，这一血统贯穿了云数据仓库领域的 Amazon Redshift、Google BigQuery 和 Snowflake；贯穿了已成为数据湖通用语言的 Apache Parquet 和 Apache ORC 等开放文件格式；贯穿了 Apache Arrow 等内存标准；以及 ClickHouse 和 DuckDB 等快速操作列式引擎。

为什么这种方法能如此彻底地取得胜利？

因为当您的工作是读取和分析大量数据时，列式存储几乎将成本和性能的每个维度都转化为您的优势。

您只读取所需的数据。 实际的分析查询几乎从不需要所有字段；它们可能只需要 50 个字段中的 3 个，或者聚合 200 个字段中的 1 个。行式存储在访问您关心的字段时，必须遍历所有其他字段。列式存储只读取查询涉及的列。在宽数据集上，这通常能将查询的 I/O 减少 90% 或更多。

压缩效果显著提升。 当您将一个字段的所有值放在一起时，这些值本质上是同类型的，通常具有重复性和相似的结构；例如，同一小时的时间戳列、几乎总是 200 的状态码列，或取自一小部分主机名的列。压缩算法在这种同质性上表现出色。行式存储通常实现 1.5-3 倍的压缩率，而列式系统通常能达到 5-10 倍，对于低基数（low-cardinality）字段，常见的是 20-30 倍。这不仅仅是调优的改进；这是一种不同的经济模式。

您可以跳过大量数据而无需读取。 由于数据是按同一列的值块组织的，引擎可以为每个块携带少量元数据（最小值、最大值、计数、不同值），并在查询时利用它们来修剪整个数据块。想查找过去一小时的错误？跳过所有时间戳范围更早的数据块。想查找特定的主机名？跳过所有不出现该主机名的数据块。系统通过预先知道某项工作是无意义的，从而避免了不必要的工作。

您可以充分利用现代 CPU 的强大功能。 现代处理器旨在对长、规则、可预测的值数组进行操作；这是缓存、流水线和向量单元发挥最佳性能的地方。列恰好就是这样的数组。列式引擎通过将批量值传递给紧凑的向量化运算符来运行查询，而不是一次查找一条记录。速度提升不是渐进式的：从 Abadi 等人的开创性论文《Column-Stores vs. Row-Stores》（SIGMOD 2008）以及随后的综合调查中，学术基准测试一直表明，列式引擎在分析工作负载上比行式系统具有一到三个数量级的优势。

您尽可能地延迟原始记录的物化。 由于数据已经按照查询的实际操作（读取此列、过滤彼列、聚合此列）进行组织，因此在绝对必要之前，无需重建完整的行。大多数情况下，您根本不需要这样做，特别是当您运行只关心聚合少数列的分析查询时。

这些特性累积效应的结果是，每个云数据仓库都是列式的，并且每个现代数据湖都将其文件存储为 Parquet 或 ORC 格式。这也是新的操作分析引擎几乎无一例外地选择这种形态的原因。它是对“如何使大型数据查询变得廉价且快速？”这个问题的结构性答案，而且这个答案在几乎所有地方都表现出一致性。

我们还应该注意到列式系统放弃了什么。它们并非为“给我一条特定记录并原地更新它”或为单个行的事务一致性而设计。通常，它们并非旨在像搜索引擎那样进行全文相关性排名。它们针对不同类型的工作负载进行了优化，这正是关键所在。不同的工作负载，不同的默认设置。

长期以来，世界之所以能够正常运转，是因为用户可以为一种工作负载选择一种工具，为另一种工作负载选择另一种工具。但那个世界正在终结。

为什么搜索和分析现在正在融合

在过去五年中，有三件事改变了这种局面。

首先，用户生成的数据量呈爆炸式增长。 在微服务、容器、OpenTelemetry、AI 工作负载和安全遥测的推动下，行业估计，大型企业每天的可观测性和日志数据摄入量达到数 TB，并且多年来年增长率已远远超过三位数。

其次，存储和查询这些数据的成本已成为一个首要关注点。 行业调查和从业者报告一致指出，可观测性和遥测是现代基础设施预算中最大且增长最快的支出项目之一，其中相当一部分支出用于写入、保留但从未查询过的数据。

前两个压力已经在市场上产生了相应的解决方案：为分析而构建的现代列式系统（最突出的是用于网络日志的 ClickHouse 和用于更广泛分析的云数据仓库）重新定义了用户对每 TB 存储和每次查询所需支付的期望。Elasticsearch 现在正达到这一标准，同时不放弃其作为 Elasticsearch 的核心优势。

第三，搜索工作负载和分析工作负载之间的界限已经模糊。 几乎所有现代操作用例都同时需要这两种功能：查找此特定事件，然后聚合其周围的所有数据；显示此日志行，然后绘制导致该日志行的趋势图；检索此文档，然后对其他匹配项进行分组。

将日志、指标、追踪、安全事件和搜索语料库放入 Elasticsearch 的用户，并不是要求我们只做一个搜索引擎或只做一个分析引擎。他们要求我们成为一个能够同时处理这两种任务的引擎，在相同的数据上，以相同的操作方式，并以他们期望的现代列式系统的成本基础来完成。

这是一个很高的门槛，要达到这个目标，我们需要从根本上改变 Elasticsearch 组织数据的方式。

长期以来，Elasticsearch 在底层一直具备列式存储能力。自 2013 年以来，我们一直在引擎中存储每列数据，但我们始终将其视为叠加在文档模型之上的辅助结构。当文档模型是事实来源而列式层是优化时，这很有道理。但当对于我们用户数据中庞大且不断增长的一部分而言，列式形态才是事实来源，而文档模型是大多数人不需要的优化时，这种做法的意义就减弱了。

这正是 Columnar Mode 的用途。

Columnar Mode：Elasticsearch 思考数据的第二种方式

我们正在做出的决定，在表面积上是刻意保守的，但在影响上却是雄心勃勃的。

我们不会构建新产品，不会要求用户迁移，也不会更改 API、查询语言、管理界面、集成、可视化层或任何触及用户操作现实的东西。Elasticsearch 仍然是 Elasticsearch。

我们正在做的是引入一种新模式，用户可以逐索引应用它，将 Elasticsearch 变为一个一流的列式系统，适用于那些列式存储更适合的数据。

在 Columnar Mode 中，引擎翻转了其默认设置：

• • 数据一次性存储在我们的列式存储（doc values）中。 没有原始文档的并行副本，也没有默认构建的辅助结构。每个字段负责自己的存储，引擎不会为工作负载不需要的功能付费。
• • 搜索索引只在真正需要时才构建。 日志的 message 字段仍然默认索引以支持自由文本搜索。仅用于聚合的数值字段意味着不创建索引，从而节省额外存储空间和写入时间成本。引擎默认变得更精简，让您可以选择性地启用值得付费的功能。
• • 原始记录可以按需从列式存储中重新生成，而不是作为冗余副本保留。希望为查询便利而保留存储副本的用户可以选择这样做；而在 PB 级别操作的用户可以选择完全删除它，以进一步节省存储空间。
• • 数据模型是真正的列式。 字段是扁平的键/值对，而不是嵌套的对象树。多值字段、基数和可空性都是一流的映射概念，与使纯列式系统高效的原始类型相同。
• • 专业配置文件在其之上发布。 第一个配置文件是 Columnar Logs，它是该模式的一个面向日志的变体，在日志消息上启用了索引，并为时间有序数据设置了正确的默认值。我们将陆续推出适用于其他工作负载的配置文件，包括最终用于向量检索的列式配置文件，使用相同的构建块。

所有这些对于 Elasticsearch 来说都是新的，尽管在行业中并非概念上的新事物。

这之所以重要，是因为我们这样做是不抛弃任何东西。对 Columnar Mode 索引运行的查询，可以原封不动地对文档模式索引运行。此外，相同的仪表板、代理和集成、服务级别目标 (SLO)、警报、规则和机器学习作业都照常工作。希望保留文档行为的用户，可以在其适用的索引上始终保持这种行为。希望在其适用的索引上（通常是集群中最大的索引）获得列式效率的用户，也能如愿以偿。

这就是我们与纯列式引擎的区别。纯列式引擎只做其中一项工作，并要求您为另一项工作引入另一个系统。Elasticsearch 是一个能够同时处理这两项任务的平台。

Columnar Mode 的适用场景

Columnar Mode 旨在处理数据写入量大、需要进行分析查询并长期保留的工作负载，而非作为普遍的默认设置。这些工作类别包括：

大规模日志和可观测性。 每天处理数十或数百 TB 日志的用户，其大部分可观测性预算都花在存储和驱动仪表板、SLO 和速率计算的聚合查询上。Columnar Logs 是第一个专门的配置文件，正是因为这是影响最严重的地方。在 PB 级别，Columnar Mode 改变了经济上可行的范围，即更长的保留期、更高的原始保真度以及因成本而被迫做出的更少妥协。

安全事件存储和威胁搜寻。 安全遥测与日志具有相同的形态，但更侧重于多维度探索、即时关联以及深入的历史查找以发现入侵指标。Columnar Mode 使全保真存储变得经济实惠，同时保留了安全分析师在查找和枢纽分析所需的相关性搜索行为，使用相同的引擎处理这两种任务。

指标、追踪和统一可观测性基础。 时间序列数据在 Elasticsearch 的时间序列数据库 TSDB 中已经是列式的。未来的列式配置文件将共享日志、指标和追踪的相同存储构建块，让这三者在同一个引擎上使用相同的基础设施，而无需任何一个在工作负载特定行为上做出妥协。统一的可观测性平台将变得不仅在架构上优雅，而且在经济上可行。

应用程序数据的操作和业务分析。 除了可观测性之外，这还意味着对数百万订单、交易、用户事件和物联网 (IoT) 读数进行仪表盘展示。许多历史上迫使用户将相同数据发送到单独分析仓库的工作负载，仅仅是为了使查询经济实惠，现在通过 Columnar Mode 可以在数据已有的位置进行处理。

大规模 AI 检索。 向量工作负载本质上是列式的。未来用于向量检索的列式配置文件将结合通用模式的密集存储效率和检索所需的索引结构，将检索增强生成 (RAG) 和语义搜索工作负载置于与集群中所有其他数据类型相同的成本基础上。

贯穿所有这些的共同点是，当数据主要是追加式写入、查询是分析性的且访问模式是按列时，Columnar Mode 是正确的答案。对于不符合这些条件的工作负载，例如以搜索为中心的应用程序（其中文档是价值单位）、更新单个记录的事务流，或任何依赖丰富文档结构作为面向用户语义的工作负载，面向文档的模式仍然是正确的默认设置，并且将继续得到投入。

从一开始，原则就是不同的工作负载需要不同的默认设置，而 Columnar Mode 正是使这成为现实的关键。

Columnar Mode 将如何改变 Elasticsearch 用户体验？

对于 Elasticsearch 用户来说，以下是会发生的变化：

• • 成本显著降低。 Columnar Mode 仅在真正需要时才构建倒排索引，并停止在每个字段上多次存储数据。结果是，相同工作负载的存储占用空间更小。用户可以在两种模式形态之间进行选择：Columnar Logs 在 message 字段上保留一个倒排索引，这是大部分日志查询实际查找的地方；纯 Columnar Mode 变体则完全取消了字符串类型字段上的这一默认设置。后续的技术深度探讨将发布基准测试和确切的存储节省数据。这些节省随着规模的扩大而累积，并立即在自管理集群的磁盘和不再需要的机器上，以及在 Elastic Cloud 的账单中体现出来。
• • 架构在读写方面也带来回报。 使 Columnar Mode 存储高效的相同选择（数据一次性存储、仅在需要时构建索引以及对列进行向量化执行）也塑造了其在读写路径上的行为。受益最大的工作负载是那些在可观测性、安全性、商业智能和 AI 检索中占据主导地位的工作负载。
• • 模型变得更简单。 Columnar Mode 默认是具有特定倾向的。开箱即用就能获得分析工作负载的正确行为，就像我们为指标数据提供的 TSDB 一样，但适用于所有类型的数据。配置界面在某些应该精简的地方变得更加精简。
• • 路径是非破坏性的。 用户可以逐索引地采用 Columnar Mode。集群、基于 Elasticsearch 构建的应用程序和仪表板不会改变。该模型是增量式的：一种新的行为方式，在有帮助的地方可用，同时保留了他们已经信任的行为。

结果是，一个更精简、更快速的 Elasticsearch，同时在一直运行良好的地方没有任何改变。

开启 Columnar Mode 后，哪些内容保持不变？

• • 面向文档的模式不会被弃用。 所有现有模式都将继续可用、受支持并得到投入。依赖文档行为的用户（典型的搜索应用程序、应用程序搜索、安全工作流以及任何以原始记录结构为核心的场景）将保留该行为。
• • 现有模式会变得更快，而不是更慢。 Columnar Mode 背后的工作，其核心是对 doc values（Elasticsearch 的列式存储）的改进，而所有模式在底层都使用 doc values。随 Columnar Mode 发布的数据压缩、编码、查询执行和向量化改进，将使文档模式索引以及列式索引中存储在 doc values 上的字段受益。LogsDB、TSDB 和标准索引将因此项工作而显著加快分析查询速度，无需用户采取任何操作或进行迁移。投资 Columnar Mode 就是投资所有模式。
• • API 不变。 用户或合作伙伴集成的每个接口（REST API、查询语言、管理 UI、数据收集代理、集成和 SDK）都将保持与今天完全相同的工作方式。Columnar Mode 是一种索引设置，而不是产品分叉，下游组件无需学习任何新知识。
• • 搜索相关性, 向量搜索 和语义检索不受影响。 这些仍然是引擎的一流功能，并且它们受益于 Columnar Mode 所依赖的许多相同的查询和索引性能改进。
• • 没有迁移障碍。 现有索引将继续工作，新索引可以根据其工作负载选择任何模式创建。用户可以按照适合其组织的速度进行迁移。
• • Elastic Cloud Serverless 也以同样的方式获得列式能力。 在 Serverless 上，用户管理项目而非索引，Columnar Mode 成为项目类型配置的一部分。随着模式的成熟，可观测性强和日志密集型项目类型将转向列式默认设置，用户在项目创建或管理方式上没有任何可见的变化。

这很重要，因为当一家公司做出一个重大的架构决策时，很容易将其过度宣传为新的福音，而低估引擎的现有优势。我们不必做出这种权衡。Elasticsearch 的现有模式并非遗留系统；它们是经过十多年大规模使用而完善的、成熟且经过生产验证的面向文档的搜索引擎。Columnar Mode 则是它们在从未设计过的那些工作负载上所缺失的部分。

为什么列式存储对 Elasticsearch 的未来至关重要

在过去十年中的大部分时间里，主导模式一直是碎片化：例如，一个搜索引擎用于搜索，一个数据仓库用于分析，一个时间序列数据库用于指标。这还包括一个日志聚合器用于日志，一个 向量数据库 用于 AI 检索，以及一个图数据库用于关系。每个都有自己的摄入管道、查询语言、操作故事和账单。这种对用户施加的复杂性成本是巨大的，而它为行业带来的开销甚至更大。

开始取代它的模式是融合，即认识到现代数据引擎的正确架构是：一次性接收数据，高效存储，并将其暴露给应用程序可能需要的任何工作负载，无论是搜索、检索、聚合、排名还是向量相似性。这种融合是数据基础设施行业最重要的趋势，也是 Elasticsearch 未来所依赖的趋势。

Columnar Mode 是我们朝着这个方向迈出的核心一步，同时进行的还有索引吞吐量、Elasticsearch 查询语言（ES|QL，Elasticsearch 的分析查询语言）、向量检索以及可观测性和安全作为集成解决方案方面的工作。这是解锁其他一切的架构决策，因为如果没有一流的列式层，Elasticsearch 的经济效益在融合最有价值的工作负载上根本无法竞争。

通过 Columnar Mode，Elasticsearch 成为业内唯一能够真正做到您可以运行的最佳搜索引擎和具有竞争力的列式分析引擎的平台，在相同的数据上，在同一个集群中，在同一个操作管理体系下。尽管总会有专门的系统在针对特定工作负载的基准测试中胜出，但当操作数据涉及多种形态和工作负载时，Elasticsearch 才是其归属之地。

这就是我们的赌注，我们相信这是正确的。

Elasticsearch 作为列式数据库的总结

十六年前，对于搜索引擎来说，表现得像一个文档存储是正确的选择。我们做出了这个选择，并构建了业界使用最广泛的数据平台之一。

今天，对于未来十年操作数据（可观测性、安全性、AI 检索、应用程序搜索、业务分析）来说，正确的选择是为同一引擎提供一种列式思维方式，作为用户可以在适用数据上选择的一流模式，同时不放弃他们已经依赖我们的任何功能。

这就是 Columnar Mode。它是我们本十年将对 Elasticsearch 进行的最重要的架构变革，也是使 Elasticsearch 成为当用户当前首选工具被取代时，仍会继续使用的引擎的关键举措。

我们正在走向列式存储。推理是合理的，路径是非破坏性的。Columnar Mode 将在 Elasticsearch 9.5 中发布技术预览版，并在 Elasticsearch 9.6 中全面可用 (GA)，Elastic 的每个产品团队都在此基础上进行构建。我们没有等待数据系统未来的到来；我们正在构建它。