至于作者，来自 Elastic Yannis Roussos 及 Bharath Aleti

样的。

如果你统计一下技术栈中的数据引擎数量。就会发现全文搜索运行在一个程序中，而分析运行在数据仓库中。指标存储在时序数据库中，日志则放在日志聚合器里向量检索又有专用的向量数据库。说起来，于是同一类运营数据的五种形态对应着五套引擎。而许可证费用反而是最便宜的部分。

我们之前在《Elasticsearch 为什么正在成为列式数据库》中介绍过整合这些数据形态背后的架构。这篇文章关注的是账本的另一面：这种拆分要付出什么代价？而“在一个网站上进行搜索和分析”究竟代表着什么？我们希望把这些问题讲清楚，让它们经得起概念验证的检验。

运行五套数据引擎的实际成本

痛点：维护两套相同业务账本时时间与资源被严重分散，导致“一周时间都花在保持一致性上”。

任何同时维护两套相同业务账本的人都知道，时间究竟花在哪里。按理说，创建第二本账很快，但让两本账保持一致才是真正耗费一周时间的事情。

痛点：双重摄取导致数据延迟、故障模式翻倍还有字段漂移。

每套引擎都需要自己的数据摄取方法，所以同一批事件需要被解析两次并发送两次。这代表着你需要面对两套故障模式；当消息代理变慢时还需要处理两套积压数据。会产生数据漂移：某个字段重命名可能先出现在其中一个副本中，而另一个副本还没有更新。于是在一段时间内，这两个程序对同一小时的数据会给出不同的结果。其实，解决这种不一致是真实的工程工作。但在商业成本分析中却很少被计算进去。

痛点：查询语言与运维知识碎片化，维护成本翻倍。

每套引擎还会带来一套查询语言，而真正的成本并不在语法本身，而在于所有使用这种语言编写的内容。包括 Dashboard、告警规则、保存的查询、运行手册，还有当周负责值班的人员所掌握的运维知识。两套语言代表着所有这些东西都要各维护一套，并行维护。

痛点：跨程序手动关联导致故障排查效率低下。

接下来是数据关联问题。你在日志聚合器中找到失败的请求，接着切换到数据仓库。统计它本周发生了多少次接下来再切换到指标存储，检查发生故障时主机是否已经达到资源饱和。这些切换中的每一次关联，都是由一个处于高压状态的人手工完成的一次 Join。而每一次都可能让故障排查多花几分钟。

痛点：不同保留策略导致历史数据缺失或查询困难。说起来，

数据保留策略会进一步放大这些问题。每个程序都有自己的生命周期策略，所以那个成本较低的程序可能还保留着数据。而成本较高的程序早在几周前就已经删除了这些数据。等到你真正需要查看历史数据时却发现数据存在于那个无法快速回答你问题的引擎中。其实，

为什么搜索和分析会拆分到两个程序

痛点：为满足不同查询需求而使用多套工具。使团队学习曲线陡峭且治理复杂。话说回来，

这种拆分是对现实约束的一种合理回应。文档引擎和列式引擎最初就是为了回答不同的问题而建立的。其实，文档引擎擅长查找符合查询条件的记录。 并按照相关性对它们进行排序；列式引擎擅长从数十亿行的数据中读取特定列并进行聚合。

多年来同时运行两套程序是合理的选择，因为没有任何单一程序能够让人信服地同时做好这两类工作。Elasticsearch 引入完整的列式引擎后这种拆分就从必需变成了可选。说起来，想了解完整的发展历程还有具体变化，可以查看《列式存储》文章。

一个统一网站在实践中代表着什么

痛点：统一网站必须满足查询语言、存储基座与运维程序三方面的一致性，否则只能停留在概念层面。

1. 统一查询语言

   E​S|QL可以跨日志、指标、traces、安全事件和文档运行。这代表着只需要掌握一套技能，并维护一套 Dashboard。由于它使用的是一种统一语言，而不是将多个程序联合起来所以查询可以组合：时间序列聚合可以与 LOOKUP JOIN 或 INLINE STATS 放在同一个查询中。而仅围绕 PromQL 建立的程序无法做到这一点。

2. 统一存储基座

   D​oc values` 是 Elasticsearch 自 2010 年以来内置的列式存储，也是每种 index mode 底层读写的数据结构。不同模式会针对不同的数据形态对这一存储基座进行调优。Elasticsearch 的时间序列引擎在 8.x 中实现了完全列式化。这是目前最明确的证据，证明这种方法可行。Columnar Mode 和 Columnar Logs 在 Elasticsearch 8.x 中均处于 technical preview，它们进一步将相同处理方式 到分析型和日志型数据。

3. 统一运维程序

   使用的是同一个集群、相同的 API、集成、agents、访问控制、备份和升级方法，这些都是已经在运行中的基础设施。不需要为每种业务再额外部署独立运维团队或监控程序。

多种 index mode 共享同一个列式存储，一种查询语言可以在单个集群中查询所有这些数据。这比“一个引擎解决所有问题”的说法更加严谨，也更经得起实际测试。

什么时候专用数据库仍然是正确的选择？

痛点：If your workload is 单一且高度调整，专用数据库往往提供更好的性能与资源利用率。

专用程序在专门的基准测试中始终会占据优势。如果你的工作负载只有一种数据形态和一种查询模式，那么大概率会有一个专门为此建立的引擎胜过通用网站。与其假装并非如此，我们更愿意坦诚地承认这一点。

The value of integration lies in cross‑data‑shape use cases – which is reality for most production environments.

The unified platform does not mean it will be second best in every shape. We have already walked this curve once. TSDB has been part of Elasticsearch since early versions;its early focus was storage efficiency rar than competing head‑to‑head with dedicated metric stores.

A series of releases from Elasticsearch 7.x → 8.x turned it into a columnar metric engine: today an OpenTelemetry metric point costs only ~30 bytes . Storage cost is ~5× lower than Promeus and ~10× lower than ClickHouse;query throughput for gauges and counters can be several times higher than Promeus/Mimir. In high‑cardinality benchmarks Elasticsearch scans>1 billion time‑series rows in under 5 seconds where or systems need>20 seconds. See “比 Promeus 快 10×：Elasticsearch 如何重构为领先的列式指标数据存储”。怎么说呢，

The Columnar Mode is at start of this same trajectory. It’s available as a technical preview in Elasticsearch 8.x and will become GA in a future release,with incremental improvements to storage layout。ingest pipelines and query performance.

哪些工作负载应该继续使用文档模式

• 以搜索为主要的应用
• - 商品目录、知识库等，需要返回排名前 N 条相关文档；文档模式天然调整此类召回与打分逻辑。
• 频繁进行单个文档更新
• - 实时编辑或状态标记场景；文档模式提供高效单体写入方法。
• - 当业务模型依赖嵌套结构时应继续使用文档模式；Columnar Mode 会将字段扁平化为 key/value 对，不支持 nested。也不支持 semantic_text 与 dense_vector 等向量字段。目前向量检索仍然只能走文档模式或等待后续列式方案发布。

The adoption of Columnar Mode is **per‑index** and must be explicitly enabled. Existing indices continue to run unchanged;APIs remain stable and dashboards stay functional.

Columnar Mode 的现状：Elasticsearch Preview → 发布

Pain point:If you cannot quantify hidden cost of “five tools”,you’ll keep over‑investing in ops overhead.

The storage & performance details will be covered in a separate technical deep‑dive article. To give feedback on workloads you’d like to see supported,use public roadmap issues for Columnar Mode and Columnar Logs.

If you want to actually measure cost of “five tools”。start by counting two things:

1. The number of ingest pipelines that duplicate events across multiple targets.
2. The number of dashboards that answer same question using two different query languages.

A majority of production environments are surprised by how large second number becomes.

这篇文章所述任何功能或特性的发布时间均由 Elastic 决定。目前不可用或计划外功能可能永不会交付