作者：来自 Elastic Yannis Roussos

Elasticsearch 正在成为一款一流的列式数据库。列式模式（ Columnar Mode ）将在 9.5 中推出，只需存储一次数据即可与现有模式并存，在减少存储占用的同时，加快分析查询的速度。

体验 Elastic 开箱即用的前沿功能。深入了解我们在 Elasticsearch Labs repo 中提供的示例 notebook，开始免费的云试用，或立即在你的本地机器上体验 Elastic。

---

Elasticsearch 正在成为一款一流的列式数据库。在 9.5 中，我们将推出 列式模式（ Columnar Mode ），这是一种新的索引模式，以列式格式存储一次数据，没有冗余副本，也没有工作负载不需要的索引。

列式模式面向这样一类工作负载：数据以大规模写入、以分析方式查询，并长期保留。这包括日志与可观测性、安全遥测、指标与追踪、运营数据上的业务分析，以及大规模 AI 检索（ retrieval ）。对于这些工作负载，它意味着从第一天起就能显著减少存储占用，同时也为随着相关能力不断成熟而实现更快的数据写入、更快的分析查询以及更长的数据保留周期奠定基础。

列式模式是与现有模式并行提供（ alongside ）的，而不是取代它们。API、仪表板、应用程序或下游集成均无需做出任何更改。它是一种新的索引模式，你可以在合适的数据上、在能够带来收益的场景中采用它。

最终，Elasticsearch 将成为一款世界级的搜索引擎和列式分析引擎，在同一份数据上、同一个集群中、同一套运维体系下运行。这正是 Elastic 在列式架构重塑运营数据经济性的时代，持续成为存放运营数据最佳平台的方式。

本文接下来的内容将解释我们为什么要这样做，以及它带来了哪些变化，又有哪些方面保持不变。

为什么 Elasticsearch 要增加列式模式

在过去 15 年里，几乎所有值得关注的通用数据系统都做出了相同的架构决策：当工作目标是读取、聚合并分析海量数据时，数据应按列（ column ）而不是按行或文档（ document ）进行组织。

如今，Elasticsearch 也正在做出这一决定。

除了文档模型、搜索基因，以及作为整个行业可观测性、安全和搜索应用核心平台的地位之外，它现在还将在同一平台内增加另一种数据组织方式。我们称之为列式模式（ Columnar Mode ）。它使 Elasticsearch 成为唯一一个能够在同一份数据上，以同等能力完成搜索（ search ）、检索（ retrieval ）和分析（ analytics ）的主流平台，并通过统一的运维体系进行管理。

为了说明这一点，我们需要阐述三个方面。第一，Elasticsearch 是如何发展成为今天的样子，以及为什么文档模型是当时正确的选择。第二，与此同时，整个数据领域如何逐渐收敛到一种完全不同的数据组织方式，以及为什么这种演进如此成功。第三，为什么这两个世界如今正在用户的系统中逐渐融合，以及为什么将列式能力引入 Elasticsearch 是正确的答案。

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

要理解我们的发展方向，首先必须了解我们的起点。

16 年前，当 Elastic 创始人 Shay Banon 编写第一个版本的 Elasticsearch 时，数据领域正经历着一场悄然发生的革命。 JSON 正迅速成为网络数据交换的标准。Web 应用程序发送和接收的数据，不再是定义明确表中的严格类型化行，而是灵活的半结构化文档（例如客户订单、聊天消息、商品列表、日志记录或菜谱），每个文档都是一个自包含的小世界，包含字段、子字段、数组和嵌套对象。

当时的关系型数据库建立在完全不同的假设之上：预先定义严格的模式，将数据拆分为规范化的表，并在 query 时使用连接（ join ）重新组装数据。这种方式非常适合它最初设计的使用场景（事务系统、银行系统、企业资源规划系统），但对于新一代 Web 和移动应用来说，却带来了巨大的阻力。新增一个字段意味着需要执行一次模式迁移，而存储结构不固定的数据，则意味着要么采用脆弱的模式，要么维护大量允许为空的列。

为了解决这些问题，一类新的系统应运而生：文档数据库。它们的理念很简单：按照数据到达时的原始形态进行存储，不要让开发者为了表达自己的业务领域而不断迁就数据库。 MongoDB 成为了这一理念在事务型数据库领域的代表，而 Elasticsearch 则在搜索领域举起了同样的旗帜。

对于 Elasticsearch 来说，文档模型不仅仅是为了改善开发者体验，更是一项深层次的架构承诺。整个引擎围绕这样的理念设计：一条记录就是一个文档；文档包含多个字段；字段具有类型；你几乎可以写入任何内容，并在无需提前完美建模数据的情况下，获得有用的行为（全文搜索、结构化过滤、排序、聚合、排名）。

这正是我们所说的 Elasticsearch 的 “文档行为（ document behavior ）”：

• 引擎会记住你发送的数据。原始记录会被保存，并且始终能够按照原始内容完整返回。

• 默认情况下，每个字段都会以多种方式变为可查询：针对快速精确查找、快速文本搜索、快速范围查询、快速排序以及快速分组进行了优化。

• 模式具有很高的灵活性。新增字段可以在写入时自动接收。即使数据模型设计得 “不够正确”，代价也很低。

• 文档是工作的基本单位。 索引（ Indexing ）、检索以及大多数 API 都围绕着 “给定一个文档，执行某项操作” 或 “给定一个查询，返回文档” 来设计。

这种模型源于搜索。Elasticsearch 所构建于其上的存储库 Apache Lucene，就是为了让一种工作负载达到极致性能：接收一个查询，找到少量匹配的文档，按照相关性进行排序，并返回结果。为了做到这一点，它构建了倒排索引（ inverted indexes ）：这种数据结构将问题反转过来，不再询问 “这个文档包含什么内容？”，而是询问 “哪些文档包含这个词项？”，并能在毫秒级返回答案。同时，它还保留原始文档，因为找到文档之后，通常还需要展示它或从中提取更多信息。

对于 Elasticsearch 最初服务的工作负载（站内搜索、日志搜索、应用搜索、安全事件查询，以及 “在大海捞针中找到目标” 这样的场景）来说，这种数据组织方式过去是、现在仍然是最佳选择。这也是为什么全球数十万家组织都在生产环境中使用 Elasticsearch。

但是，文档模型本身也存在内在成本，而这一成本正是后续所有变化的起点。

为了兑现快速搜索、灵活模式以及忠实保存原始记录的承诺，引擎最终需要以多种不同的形式、多次存储同一份数据，每一种形式都针对不同的问题进行了优化。原始文档会被保存；每个字段中的文本会建立搜索索引；每个字段的值还会单独存储在一种称为 doc values 的按字段列式存储中，以便进行聚合、排序和分组。系统默认会为每个字段同时维护所有这些结构，因为在写入时，它并不知道你在读取时究竟需要哪些能力。

对于 Elasticsearch 最初设计面向的数据集（内容相对丰富、数据量相对较小，而且每一次读取都具有较高价值），这种权衡非常合理。你只需付出适度的存储和写入成本，就能够获得极其丰富的功能能力。

但对于如今 Elasticsearch 越来越多承载的数据集（数十亿条日志、数万亿个指标点、海量遥测数据，其中绝大多数数据只写入一次、却很少被读取），这种权衡开始呈现出完全不同的意义。

而这正是我们希望解决的摩擦点。

另一段故事：数据世界如何走向列式架构

当 Elasticsearch 不断完善文档模型的同时，分析领域也在发生另一场革命。它始于学术界，随后实现商业化，如今已经成为几乎所有用于读取和分析海量数据系统的默认架构。为了更清楚地说明列式模式（ Columnar Mode ）的定位，我们需要先讲述这段历史。

列式存储背后的理念简单得几乎像一个技巧。它不再按 行（ row ）存储数据（记录一、记录二、记录三……），而是按列（ column ）存储数据（所有 timestamp 的值，然后所有 host_name 的值，再然后所有 status_code 的值……）。

正是这一项决定，改变了一切。

这一理念起源于 20 世纪 90 年代初，来自阿姆斯特丹数学与计算机科学中心（ Centrum Wiskunde & Informatica ）的研究项目 MonetDB。到了 21 世纪初，它又在麻省理工学院 Michael Stonebraker 主导的 C-Store 项目中得到进一步发展，并最终成为 Vertica 的基础。Sybase IQ 则将同样的理念带入了早期商业市场。到了 2010 年代初，几乎所有严肃的数据分析厂商都已经拥有自己的列式架构方案。如今，这一技术谱系延续到了云数据仓库领域的 Amazon Redshift、Google BigQuery 和 Snowflake；延续到了 Apache Parquet 与 Apache ORC 等开放文件格式，它们已经成为数据湖的通用语言；延续到了 Apache Arrow 这样的内存标准；也延续到了 ClickHouse 和 DuckDB 这样的高性能运营分析列式引擎。

为什么这种方式能够取得如此彻底的成功？

因为当你的工作是读取并分析海量数据时，列式存储几乎能够让成本和性能的每一个维度（ dimension ）都朝着有利的方向发展。

你只读取真正需要的数据。真实的分析查询几乎从来不会读取所有字段，它们通常只需要 50 个字段中的 3 个，或者 200 个字段中的 1 个进行聚合。按行存储的数据必须依次经过所有其他字段，才能到达你真正关心的字段。而列式存储只读取查询涉及到的列。对于宽表数据集，这通常可以减少 90% 甚至更多的 I/O。

你可以获得显著更高的压缩率。当同一个字段的所有值连续存放在一起时，这些值天然具有相同的数据类型，并且通常包含大量重复和相似的结构。例如，同一小时内的时间戳、一列几乎全部都是 200 的状态码，或者来自有限主机集合的主机名。压缩算法最擅长处理这种高度同质的数据。按行存储通常只能实现 1.5 到 3 倍压缩，而列式系统通常可以达到 5 到 10 倍，对于低基数字段，20 到 30 倍压缩也十分常见。这不仅仅是调优带来的提升，而是进入了完全不同的经济模型。

你可以在无需读取数据的情况下跳过大量内容。由于数据按同一列中的值组织成数据块，引擎可以为每个数据块维护极少量的元数据（最小值、最大值、数量、不同值等），并在查询时利用这些信息直接裁剪整个数据块。例如，查找最近一小时内的错误？那么所有时间范围早于这一小时的数据块都可以直接跳过。查找某个特定主机名？所有不包含该主机名的数据块都无需读取。系统能够提前知道哪些工作毫无意义，因此避免执行这些工作。

你可以充分发挥现代 CPU 的能力。现代处理器专门针对长而规则、可预测的数据数组进行了优化，这正是缓存、流水线以及 vector 单元最擅长处理的场景。而列本身正是这样一种数组。列式引擎执行查询时，会将一批批数据交给紧凑且经过向量化处理的操作符，而不是逐条查找记录。这种性能提升不是渐进式的。从 Abadi 等人在 Column-Stores vs. Row-Stores（ SIGMOD 2008 ）中的开创性研究，到之后的大量综合研究，列式引擎在分析型工作负载上的性能，相比按行存储系统，持续展现出一个到三个数量级的优势。

你会尽可能延迟重建原始记录。由于数据已经按照查询真正关心的方式组织（读取这一列、过滤那一列、聚合另一列），因此在绝对必要之前，无需重新构造完整的一行数据。而绝大多数情况下，根本不需要这样做，尤其是在只关心少数几个列聚合结果的分析查询中更是如此。

正是这些特性的叠加，使得所有云数据仓库都采用列式架构，也使得所有现代数据湖都使用 Parquet 或 ORC 存储文件。这也是为什么几乎所有新一代运营分析引擎都毫无例外地选择了这种数据组织方式。对于 “如何让海量数据查询既便宜又快速” 这一问题，列式架构已经成为一种结构性的答案，而且几乎在所有场景中，这个答案都是相同的。

当然，我们也应该看到列式系统所做出的取舍。它们并不是为了支持 “获取一条特定记录并原地更新” 这样的操作，也不是为了提供单行级别的事务一致性。通常来说，它们也不是为了像搜索引擎那样执行全文相关性排序而设计的。它们针对的是另一种工作负载，这正是它们存在的意义：不同的工作负载，需要不同的默认设计。

很长一段时间以来，用户可以针对一种工作负载选择一种工具，再针对另一种工作负载选择另一种工具，因此整个世界运转良好。

而这样的时代，正在结束。

为什么搜索与分析正在走向融合

过去五年发生了三件事情，改变了整个局面。

第一，用户生成的数据量发生了爆炸式增长。受微服务、容器、 OpenTelemetry 、 AI 工作负载以及安全遥测的推动，行业估计显示，大型企业每天摄取的可观测性和日志数据已经达到数 TB 的规模，并且连续多年保持着三位数的年增长率。

第二，存储和查询这些数据的成本已经成为基础设施预算中的核心问题。行业调查和实践报告持续指出，可观测性和遥测已经成为现代基础设施预算中规模最大、增长最快的支出项目之一，而其中相当大的一部分支出用于那些被写入、长期保留，却从未被查询过的数据。

前两个因素已经推动市场给出了答案：面向分析而构建的现代列式系统（最具代表性的是用于 Web 日志的 ClickHouse，以及面向更广泛分析场景的云数据仓库）重新定义了用户对于每 TB 存储成本以及每次查询成本的预期。如今，Elasticsearch 在保持自身核心优势的同时，也达到了这一标准。

第三，搜索工作负载与分析工作负载之间的边界已经消失。几乎所有现代运营场景都同时需要两者：找到这一条具体事件，然后分析它周围的所有数据；查看这一条日志，然后绘制产生它的趋势图；检索这一份文档，然后统计还有哪些内容与它匹配。

那些将日志、指标、追踪、安全事件以及搜索语料库（ corpus ）存储到 Elasticsearch 中的用户，并不是希望我们只做搜索引擎，或者只做分析引擎。他们希望的是：使用同一个引擎，在同一份数据上，同时完成这两类工作；拥有统一的运维体系；并且达到现代列式系统所提供的成本水平。

这是一个非常高的目标，而要实现这一目标，我们必须从根本上改变 Elasticsearch 组织数据的方式。

事实上，很长一段时间以来，Elasticsearch 的底层一直拥有列式存储。自 2013 年以来，我们就在引擎中按列存储数据，但始终将它视为构建在文档模型之上的辅助结构。当文档模型是真实数据来源，而列式层只是性能优化时，这种设计完全合理。

但是，对于如今数量庞大且持续增长的用户数据来说，情况已经发生了变化：列式结构本身才是真实数据来源，而文档模型反而成为绝大多数用户并不需要的优化层。

这正是 列式模式（ Columnar Mode ） 存在的原因。

列式模式（ Columnar Mode ）：赋予 Elasticsearch 第二种思考数据的方式

我们所做出的这一决定，在表面上的变化刻意保持保守，而在实际影响上则极具雄心。

我们不会构建一个全新的产品，不会要求用户迁移，也不会改变 API、查询语言、管理界面、集成、可视化层，或任何影响用户日常运维体验的内容。Elasticsearch 仍然是 Elasticsearch。

我们真正引入的是一种新的模式，用户可以按索引逐个启用，使 Elasticsearch 在适合的数据上成为一款真正的一流列式系统。

在列式模式（ Columnar Mode ）中，引擎将改变默认行为：

• 数据只存储一次，并保存在我们的列式存储（ doc values ）中。不再默认保留原始文档的并行副本，也不再默认构建额外的数据结构。每个字段负责存储自身的数据，引擎不再为工作负载不需要的能力付出成本。

• 搜索索引只在真正有价值时才会创建。例如，日志中的消息字段仍然默认建立索引，以支持全文搜索。而对于仅用于聚合的数值字段，则无需建立索引，也无需额外存储，更不会增加写入成本。默认情况下，引擎将更加轻量，你可以根据实际价值选择启用相应能力。

• 原始记录可以按需从列式存储重新生成。无需再保留一份冗余副本。希望为了查询方便而保留原始副本的用户仍然可以这样做；而管理 PB 级数据的用户则可以选择彻底移除这份副本，以进一步节省存储空间。

• 数据模型真正采用列式设计。字段采用扁平的键值对（ key/value ）结构，而不是嵌套对象树。多值字段、基数（ cardinality ）以及空值支持（ nullability ）都成为映射中的一等概念，这些也是纯列式系统能够高效运行的基础能力。

• 提供针对特定工作负载的专用配置。首个配置是 列式日志（ Columnar Logs ），这是面向日志场景的列式模式变体，默认对日志消息建立索引，并针对按时间排序的数据提供合理的默认配置。未来我们还将推出适用于其他工作负载的配置，包括最终推出基于同一套基础架构构建的面向向量检索的列式配置。

对于 Elasticsearch 来说，这些都是全新的能力；但从整个行业来看，其理念并不新鲜。

真正重要的是，我们是在不放弃任何已有能力的前提下完成这一切。针对列式模式索引运行的同一个查询，无需任何修改，也可以直接运行在文档模式索引上。同样，现有的仪表板、 agent、集成、服务级别目标（ SLO ）、告警、规则以及机器学习任务都能够像以前一样正常工作。希望保留文档行为的用户，仍然可以在适合的索引上继续使用文档模式；而希望在适合的索引（通常是集群中最大的那些索引）获得列式效率的用户，也可以直接享受到这些优势。

这正是我们与纯列式引擎之间最大的区别。纯列式引擎通常只能完成其中一种工作，并要求你再引入另一套系统来完成另一项任务。而 Elasticsearch 是一个能够同时完成这两项工作的统一平台。

列式模式（ Columnar Mode ）适用于哪些场景

列式模式（ Columnar Mode ）并不是一种通用默认模式，而是专门为那些大规模写入、以分析查询为主、并且需要长期保留数据的工作负载而设计。这类工作负载包括：

大规模日志与可观测性。每天处理数十 TB 甚至数百 TB 日志的用户，其可观测性预算的大部分都花费在存储以及支撑仪表板、服务级别目标（ SLO ）和速率计算的聚合查询上。列式日志（ Columnar Logs ）之所以成为第一个专用配置，正是因为这一场景能够获得最显著的收益。在 PB 级数据规模下，列式模式改变了经济可行性的边界 —— 意味着能够实现更长的数据保留时间、更完整的原始数据保真度，以及更少因成本而被迫做出的妥协。

安全事件存储与威胁狩猎。安全遥测与日志具有相似的数据特征，但更强调多维探索、临时关联分析以及针对入侵指标（ indicators of compromise ）的深度历史查询。列式模式在保持完整数据保真度、降低存储成本的同时，依然保留了安全分析师在查询和关联分析中所需的搜索相关性能力，并利用同一个引擎同时完成这两项工作。

指标、追踪以及统一可观测性基础平台。时间序列数据已经在 TSDB（ Elasticsearch 的时间序列数据库）中采用列式存储。未来推出的列式配置将使日志、指标和追踪共享同一套底层存储架构，让三类数据都能够运行在同一个引擎、同一个基础平台之上，同时又不会牺牲各自工作负载所需的特定能力。统一可观测性平台不仅在架构上更加优雅，也将在经济上真正变得可行。

应用数据上的运营分析与业务分析。除了可观测性之外，这还包括针对数百万条订单、交易、用户事件以及物联网（ IoT ）数据构建仪表板。过去，许多工作负载不得不将同一份数据复制到独立的分析型数据仓库，仅仅是为了降低分析查询成本。而借助列式模式，这些数据可以继续保留在 Elasticsearch 中，无需再迁移到其他系统。

大规模 AI 检索。向量工作负载天然适合列式存储。未来推出的面向向量检索的列式配置，将结合通用列式模式的高密度存储效率，以及检索所需的索引结构，使 检索增强生成（ retrieval augmented generation， RAG ）和语义搜索工作负载，与集群中其他类型数据一样，拥有相同的成本优势。

贯穿所有这些场景的共同点在于：当数据主要以追加方式写入、查询主要属于分析型，并且访问模式以按列读取为主时，列式模式就是最佳选择。

而对于不满足这些条件的工作负载，例如以搜索为核心、文档本身就是价值单位的应用；需要频繁更新单条记录的事务型流程；或者任何依赖丰富文档结构作为用户语义表达的场景，面向文档的模式仍然是最合适的默认选择，我们也将继续投入资源不断完善它们。

从一开始，我们始终坚持一个原则：不同的工作负载，需要不同的默认设计。而列式模式，正是这一原则真正落地的体现。

列式模式（ Columnar Mode ）对 Elasticsearch 用户有哪些变化？

对于 Elasticsearch 用户来说，变化如下：

• 成本将显著降低。列式模式（ Columnar Mode ）只会在真正有价值的地方构建倒排索引（ inverted index ），并停止在每个字段上多次存储数据。最终结果是在相同工作负载下，存储占用更小。用户可以在两种模式形态之间进行选择：列式日志（ Columnar Logs ）会在消息字段上保留倒排索引（ inverted index ），因为大部分日志查询实际上都集中在该字段上；纯列式模式变体则会在字符串类型字段上完全移除这一默认索引。后续的技术深入文章将发布基准测试结果以及具体的存储节省数据。这种节省会随着规模增长而不断累积，并会立即体现在实际运维成本中：对于自建集群，表现为不再需要购买的磁盘和机器；对于 Elastic Cloud，则直接体现在账单中。

• 这种架构同样会在读取和写入方面带来收益。让列式模式具备存储效率的相同设计选择（数据只存储一次、仅在有价值的地方建立索引，以及基于列执行向量化计算），也会影响它在读取路径和写入路径上的表现。能够获得最大收益的工作负载，正是可观测性、安全、商业智能以及 AI 检索中占主导地位的那些场景。

• 模型变得更加简单。列式模式默认采用明确的设计理念。对于分析型工作负载，正确的行为应该开箱即用，就像我们通过 TSDB 为指标数据所实现的方式一样，只不过现在覆盖所有类型的数据。配置面会在那些多年前就应该简化的地方进一步收缩。

• 迁移路径不会造成中断。用户可以按索引逐步采用列式模式。集群、构建在 Elasticsearch 之上的应用程序以及仪表板都无需改变。这是一种增量式模型：在用户已经信任的现有行为之外，新增一种在适合场景中可使用的数据处理方式。

最终，Elasticsearch 将变得更加轻量、更快，同时对于一直正常工作的场景，不需要做任何改变。

启用列式模式（ Columnar Mode ）后不会发生什么变化

• 面向文档的模式不会被弃用。所有现有模式仍然可用、受支持，并会持续投入开发。依赖文档行为的用户（典型搜索应用、应用搜索、安全工作流，以及任何以原始记录结构为核心价值的场景）可以继续保持这种行为。

• 现有模式会变得更快，而不是更慢。列式模式背后的工作，本质上是围绕 Elasticsearch 的列式存储 doc values 展开的，而所有模式底层都会使用它。随着列式模式发布的压缩、编码、查询执行以及向量化改进，对于存储在 doc values 中的字段，这些能力同样会让文档模式索引受益。LogsDB、TSDB 以及标准索引都会因为这些工作而获得更快的分析查询性能，无需用户执行任何操作或迁移。投资列式模式，就是投资所有模式。

• API 不会发生变化。用户或合作伙伴依赖的所有接口（ REST API、查询语言、管理界面、数据采集 agent、集成以及 SDK ）都会像今天一样继续工作。列式模式只是一个索引设置，而不是产品分叉，下游组件无需学习任何新内容。

• 搜索相关性（ search relevance ）、向量搜索（ vector search ）以及语义检索不会受到影响。这些仍然是引擎的一等能力，并且会受益于许多与列式模式共享的查询和索引性能优化。

• 不存在迁移断层。现有索引会继续工作，新索引可以根据工作负载选择最合适的模式。用户可以按照符合自身组织节奏的方式逐步迁移。

• Elastic Cloud Serverless 也会以相同方式获得列式能力。在 Serverless 中，用户管理的是项目而不是索引，因此列式模式会成为项目类型配置的一部分。随着该模式不断成熟，可观测性和日志密集型项目类型将逐步采用列式默认配置，而项目创建和管理方式不会对用户产生任何变化。

这一点非常重要，因为当一家公司做出重大架构决策时，很容易将其宣传为新的唯一正确答案，同时低估现有引擎的优势。但我们无需做这样的取舍。Elasticsearch 现有模式并不是遗留技术；它们是一款经过十多年大规模生产实践不断完善、经过验证的面向文档的搜索引擎。列式模式正是为了补足那些它从未针对设计的工作负载所缺少的能力。

为什么列式存储对 Elasticsearch 的未来如此重要

在过去大约十年中，主流模式一直是碎片化：例如，搜索使用搜索引擎，分析使用数据仓库，指标使用时间序列数据库。此外，还包括用于日志的日志聚合器、用于 AI 检索的向量数据库（ vector database ），以及用于关系分析的图数据库。每一个系统都有自己的数据采集流程、查询语言、运维体系和账单。这种复杂性给用户带来的成本极其巨大，同时也为整个行业带来了更高的支出。

正在取代这种模式的新趋势是融合（ convergence ）：人们逐渐认识到，现代数据引擎的正确架构应该是一次接收数据，高效存储数据，并根据应用实际需要提供不同能力，无论是搜索、检索、聚合、排序，还是向量相似度计算。这种融合是数据基础设施行业最重要的发展趋势，也是 Elasticsearch 未来发展的核心方向。

列式模式（ Columnar Mode ）是我们朝这个方向迈出的核心一步，同时也结合了围绕索引吞吐量（ throughput ）、Elasticsearch 查询语言（ ES|QL，Elasticsearch 的分析查询语言）、向量检索，以及可观测性和安全一体化解决方案展开的相关工作。这是一项能够解锁其他能力的架构决策，因为如果没有一流的列式层，Elasticsearch 在融合最有价值的工作负载上，就无法具备有竞争力的经济模型。

通过列式模式，Elasticsearch 成为了行业中唯一一个能够真正实现以下目标的主流平台：在同一份数据上、同一个集群中、同一套运维体系下，同时成为你可以运行的最佳搜索引擎和具有竞争力的列式分析引擎。虽然针对单一工作负载，始终会存在专门系统能够在某个专用基准测试（ benchmark ）中取得优势，但当运营数据同时涉及多种数据形态和工作负载时，Elasticsearch 正是这些数据应该归属的平台。

这就是我们的选择，而我们相信这是正确的方向。

关于 Elasticsearch 作为列式数据库的总结

16 年前，对于一个搜索引擎来说，让它像文档存储系统一样工作是正确的选择。我们做出了这个选择，并构建出了业内使用最广泛的数据平台之一。

如今，对于未来十年的运营数据（可观测性、安全、AI 检索、应用搜索以及业务分析），正确的选择是让同一个引擎具备一种一流的列式思维方式，让用户可以在适合的数据上选择使用，同时无需放弃他们已经依赖我们的任何能力。

这就是列式模式（ Columnar Mode ）。它是 Elasticsearch 本十年最重要的架构变化，也是让 Elasticsearch 成为用户未来依然愿意选择的引擎的关键一步，即使他们当前偏好的工具已经被其他方案取代。

我们正在走向列式架构。这个方向有充分的理由，而且迁移路径不会造成中断。列式模式将在 Elasticsearch 9.5 中进入技术预览阶段，并在 Elasticsearch 9.6 中正式发布。Elastic 的每个产品团队都正在基于这一基础进行构建。我们并不是等待数据系统的未来到来；我们正在构建它。

这部分内容对你有多大帮助？

原文：Elasticsearch columnar database: one platform for search and analytics - Elasticsearch Labs