对于新用户而言，这是运行高质量向量搜索的最快方式。如果您已在使用 Elasticsearch，这款新产品能够在您的数据所在平台上实现向量搜索，您无需引入任何新系统。Elasticsearch 向量数据库支持多种应用场景，例如为大型语言模型 (LLM) 提供事实依据，为 AI 智能体赋予检索与记忆能力，以及处理数千亿个向量等。立即创建新项目，只需几分钟即可开始使用。

一个引擎，满足所有向量应用场景

Elasticsearch 向量数据库专为使用向量构建应用程序的用户而设计：

• RAG：通过密集和稀疏向量检索为您的 LLM 检索适当的上下文，或者采用结合向量检索和词汇检索的混合搜索。您的生成质量会随着检索质量的提升而提高。

• AI 智能体：为智能体提供针对文档和对话记忆的快速筛选检索，满足多步智能体循环所需的低延迟要求。

• 语义搜索：根据含义而非关键字进行匹配，只需一种字段类型且无需任何管道代码。

• 推荐和相似度：针对产品、图像或任何内容大规模查找最近邻。

您的向量工作负载所需的一切，开箱即用且经过优化

构建基于向量的应用程序意味着将多个独立部分连接起来：设置并托管嵌入模型，通过这些模型为您的文档编制索引，高效存储向量，将嵌入模型应用于每个查询，与向量存储进行匹配，以及最后检索匹配项背后的文档。Elasticsearch 向量数据库可为您处理所有这些操作，无需进行额外配置或设置。

使用 vectordb_document 索引模式进行向量索引

vectordb_document 索引模式是一种专为向量优先型工作负载构建的新索引配置，默认启用，因此您可以获得专家会选择的设置。以下是它会启用的功能：

• 默认使用 bfloat16：向量的存储大小仅为 float32 的一半，对召回率的影响可忽略不计，甚至在考虑量化之前，就能将您的磁盘占用空间大致减半。

• 排除源向量：在 Elasticsearch 中，您的嵌入向量已存在于用于搜索的索引结构中；在 _source 中保留第二份原始副本只会增加存储占用并降低获取结果的速度。我们排除了重复项，以便更快获得响应并减少存储空间。

• 将正确的文件预加载到缓存中：向量查询最先访问的数据结构会提前预热到内存中，从而确保无论是第一次查询还是第一千次查询，速度都快如闪电。

• 并行合并：合并可将分段整合为组织更有序的向量结构，从而同时提升召回率并改善延迟，而以多线程方式运行这些合并则可以更快达成这一目标。

向量存储、压缩和自动调优

• 您的向量会自动压缩。更好的二进制量化 (BBQ) 可在保持召回率的同时将向量的内存占用最多减少 32 倍，而 DiskBBQ 则能针对大规模工作负载进一步降低内存需求。 

• 选择启用自动校准，该功能会根据您的数据调整每个分段的量化参数，并在数据发生漂移时在每次合并时重新调整。在 18 个数据集上的测试结果显示，每秒查询数 (QPS) 平均提升了 16.7%，且大多数数据集的召回率也有所提高。

托管 GPU 推理上的嵌入

• 通过原生 Jina AI 嵌入和重排序模型生成嵌入向量，或引入第三方模型；所有模型均在 Elastic Inference Service (EIS) 提供的托管 GPU 上运行，无需运维模型服务器。如果您愿意，您也可以选择自行托管。

• semantic_text 字段类型可自动处理分块和嵌入以及查询，这是市面上实现语义搜索的最简单途径。 

混合搜索和过滤向量搜索

• 混合搜索是内置功能，可在单个查询中结合全文检索和向量检索。您可以使用倒数排序融合 (RRF) 或您所需的任何其他融合机制来融合结果。在混合搜索中，向量搜索部分的配置往往最具挑战性；而借助 Elasticsearch 向量数据库，这一难题迎刃而解，您的整个混合技术栈也会变得更加出色。 

• 借助带过滤功能的向量搜索，将元数据过滤作为向量检索过程本身的一部分来实施，而不是将其作为事后补救措施，从而避免损害召回率。

从第一天起即面向企业

您还可以获得基于角色的访问控制 (RBAC)、审计日志，以及纯向量数据库通常缺乏的合规性认证。

扩展时经济实惠且具有可预测性

Elasticsearch 向量数据库旨在让您随着业务增长仍可负担：BBQ 和 DiskBBQ 压缩可使存储线性增长并保持较低内存占用，这意味着即使扩展到数千亿个向量，费用也不会大幅攀升。您实际支付的费用由您已知的数字决定：存储的数据量、索引的数据量，以及所需的搜索容量。估算您的文档数量、向量维度和查询负载，您便可在创建项目之前算出所需费用。您还可以在月底逐项了解账单明细。没有不透明的计算单元，也不会因后台操作产生意外费用。

如何开始使用 Elasticsearch 向量数据库

创建无服务器向量数据库项目

创建新的 Elastic Cloud 无服务器向量数据库项目。将数据指向终端，即可开始编入索引。

使用 semantic_text 创建索引

向量索引模式负责处理向量配置。使用 semantic_text 意味着系统会在托管 GPU 推理上为您管理嵌入和分块设置以及索引设置，无需构建嵌入管道。

采集文档

索引文本，系统便会为您生成嵌入。

运行语义搜索查询

查询您刚刚创建的相同语义字段：

然后您会获得返回的结果：

语义搜索只是开始。运行纯文本查询，或将两者结合为混合查询。您甚至可以构建自己的向量查询，实现完全控制。请参阅文档中的语义搜索快速入门，获取完整说明。

Elasticsearch 中向量搜索的未来展望

我们已经在着手进行后续改进：

• 更出色的多租户处理：如果您的数据需要按租户保持隔离，我们将为您提供一种速度更快、代码量更少的方法来实现这一目标。

• 自动索引优化：从“全新索引”到“完全优化”，无需过多人工干预。

• 持续的基础架构改进：对向量数据库的设置和基础架构进行持续调优，确保您始终获得最佳吞吐量和最快响应。

在 Elastic Cloud Serverless 上试用 Elasticsearch 向量数据库

仅需数分钟，您即可从零开始构建支持混合检索与过滤功能的向量查询应用，并利用生产级默认配置自动完成性能调优。您可以构建快速、可扩展的 AI 应用，无需构建基础架构。

开始使用 Elastic Cloud Serverless，或深入了解完整文档和 API 参考。

Elastic Cloud Serverless 已经消除了管理基础架构和版本升级的麻烦。CPS 则更进一步。我们用简单的链接模型取代了复杂的网络对等连接和人工证书管理。现在，您可以将 Elastic Cloud Serverless 项目视为数据的简单命名空间。无论您是在应对严格的数据驻留法律、隔离租户数据，还是只是试图避免由于复制日志而产生的巨额跨区流量费，CPS 都支持您通过单次查询在数据所在的位置搜索数据。

在这篇文章中，我们将介绍 CPS 的工作原理、如何使用项目标签控制搜索，以及这种新模式与传统的跨集群搜索 (CCS) 有何不同。

如何链接项目以进行跨项目搜索

如要开始跨项目搜索，请在 Elastic Cloud 控制台或 API 中链接项目。链接过程非常简单，而且是单向的：选择一个源项目，然后连接它应该搜索的项目。这些链接可以跨越区域、云服务提供商和项目类型，因此您的数据可以在不放弃统一搜索体验的情况下保留在原位置。

链接创建完成后，通常会在一分钟左右生效。如果您已经打开了 Kibana，请刷新页面以查看新的跨项目搜索功能。

跨项目搜索如何默认查询所有链接项目

一旦项目被链接起来，跨项目搜索就会将独立的项目变成一个单一的逻辑搜索面。如果日志跨越多个项目，则类似 FROM logs* 这样的查询会搜索源项目和有匹配数据的任何链接项目。您不必事先为每个远程目标命名。

这比跨集群搜索有了重大改进。在 CCS 中，访问本地和远程数据通常意味着编写类似 FROM logs*,*:logs* 的内容。对于用户来说，这意味着查询复杂性降低。对于团队而言，这让我们离实现跨分布式数据的真正“单一视图”更近了一步。

有关更多信息，请参阅 CPS 搜索模型文档。

如果您有兴趣了解我们如何构建此功能的技术细节，请参阅跨项目搜索 (CPS) 在 Elasticsearch Serverless 中如何工作。

通过项目路由控制搜索

默认情况下跨所有关联项目进行搜索，对于许多工作流而言既便捷又实用；然而，并非每一次搜索都应当覆盖所有范围。跨项目搜索引入了项目路由，这是一种将查询限制到特定项目子集的方式。

它通过 Elastic Cloud 中定义的项目标签工作。每个项目都有内置属性，例如其别名、云服务提供商和区域。您还可以添加自己的标签，以反映您的组织对其数字资产的划分方式，如 environment:prod, environment:test、业务单元或客户名称。Elasticsearch 可以使用该元数据来决定哪些链接的项目应参与搜索。

所有支持跨项目搜索的 Elasticsearch 终端都接受 project_routing 参数。在技术预览版中，路由功能仅限于使用项目别名。例如，将 project_routing 设置为 _alias:my-linked-project 将会把查询仅发送到该关联项目，而设置为 _alias:_origin 则会将查询保留在源项目内。随着时间的推移，这个模型将为更丰富的路由功能打开大门，届时，查询范围将完美契合贵公司的逻辑架构，而不再受制于基础设施的物理布局。

请参阅项目路由文档了解示例和更多关于工作原理的信息。

Kibana 空间层级的默认项目路由

关于您的查询路由为何需要更精准的范围，举例而言，盲目查询所有链接项目可能会导致您的 Kibana 检测规则触发大量误报，或者让您现有的仪表盘数据变得极其混乱。如要解决这个问题，您可以在 Kibana 中设置 空间层级的默认项目范围。这相当于为该特定空间设置了一个安全预设——这意味着所有仪表板、Discover 会话和告警规则都会自动遵循该设置。分析师在调查过程中如果需要更广泛的视角，仍可手动调整覆盖范围。

这对于共享中央项目的团队（例如 MSP、MSSP 和卓越中心）来说很重要：您可以为每个团队分配自己的 Kibana 空间，并将其限制为仅查询其特定的客户项目，从而保证租户特定的体验。分析师在调查过程中如果需要更广泛的视角，仍可手动调整覆盖范围。

您在云用户界面中链接项目之前或之后可以配置此空间默认设置。但由于 CPS 在链接建立后立即开启“全局搜索”行为，因为先设置 Kibana 默认值可以确保现有的检测规则不会突然在海量全球数据下产生误报或导致团队不堪重负。

在搜索中使用标签

除了使用标签进行项目路由，您还可以在 ES|QL 和搜索查询中使用标签。这可以用来识别结果集中每条记录或行的来源，或者按这些标签进行排序、过滤或聚合。

例如，如果您想查看 ES|QL 响应中每一行数据来自哪个项目，可以将 _project._alias 标签添加到 ES|QL 查询中：

这样一来，您就可以在查询的其他部分（包括 KEEP 子句）中使用 “_project._alias”，在查询的其他部分（包括 KEEP 子句）中，从而使其呈现在最终结果中。

有关在查询中使用标签的更多示例，请参阅此文档，其中介绍了如何在搜索 API 和 ES|QL 中使用标签。

如果您有兴趣了解如何为搜索和 ES|QL 查询添加标签的技术细节，请参阅在 Elasticsearch Serverless 中使用项目标签和路由加快跨项目搜索。

跨项目搜索如何平等地处理源项目和链接项目

如果您用过CCS，您可能知道本地群集与远程群集的处理方式有所不同。

• 本地群集错误的处理方式与远程群集错误的处理方式不同。特别是，CCS 使用 skip_unavailable 设置来控制来自远程群集的错误的行为方式，但本地群集不存在该设置。

• 本地集群没有“集群别名”，因此索引表达式 *:logs* 搜索所有远程项目，但会跳过本地集群。如要同时搜索两者，您必须使用索引表达式 logs*,*:logs*。

在 CPS 中，我们已经改变了这两种行为，使原始项目和链接项目处于更加平等的地位。

首先，在 Elastic Cloud Serverless 中不使用 skip_unavailable 设置。相反，您可以通过在 _search 或 _async_search 中使用 allow_partial_search_results 参数，或在 ES|QL 中使用 allow_partial_results 参数，来控制是否希望在搜索时获得部分结果。

其次，在 Elastic Cloud Serverless 中，源项目有一个项目别名。它在 Elastic Cloud 中定义，就像所有项目标签一样。因此，在 CPS 中，下面的所有查询都是等价的，它们针对的都是有“日志”索引的所有项目：

注意：在针对缺失索引的错误处理方面，限定索引表达式 *:logs 和非限定表达式 logs 之间存在重要区别。有关详细信息，请参阅公共文档中的非限定和限定搜索表达式。

跨项目搜索的访问控制和安全模型

Elastic 创建了一种新的基于云的安全模型，即通用身份和访问管理 (UIAM)，它实现了跨项目搜索的一个关键原则：您可以访问的项目和数据不依赖于您访问它的位置。

无论您是从主要的可观测项目还是从临时分析项目启动搜索，您对链接数据的访问都保持一致，因为这些访问权限已在集中位置进行了统一定义。该云端认证与授权模型利用云 UIAM 服务，确保无论源自哪个项目，您的访问权限均保持统一。

试用跨项目搜索

最终，Elastic Cloud Serverless 和 CPS 可共同减少操作摩擦，为您提供更多基于逻辑而非物理或操作因素来组织数据的选择。跨项目搜索允许您的用户纯粹关注数据的逻辑组织，提供统一的搜索体验，而不受过去物理复杂性的限制。

如今，这一切变得简单得多。Elastic Cloud API 密钥现在可以直接在 Elastic Cloud Serverless 上对 Elasticsearch 和 Kibana API 进行身份验证。您现在可以使用单一凭证来管理组织的资源并执行数据操作，例如 Elasticsearch 查询语言 (ES|QL) 查询、数据摄取和告警。

下面我们来看看我们构建这一功能的原因、如何设计全局分布式身份层来实现这一目标，以及它如何为跨项目搜索奠定基础。

秘密管理负担

围绕数据平台构建可靠的 CI/CD 管道、GitOps 工作流或 Terraform 自动化，都伴随着一项隐性成本：秘密信息蔓延。

在旧模式下，开发人员面临割裂的身份验证体验：

• 控制平面 (Elastic Cloud API 密钥)：组织级密钥，组织级作用域的密钥，用于通过 Elastic Cloud API 创建项目、邀请用户和管理计费。

• 数据平面（Elasticsearch API 密钥）： 项目范围密钥是在特定的 Serverless 项目中创建的，用于与 Elasticsearch 和 Kibana API 进行交互。

这意味着您的部署脚本必须对 Elastic Cloud 进行身份验证，配置 Serverless 项目，从该特定项目中提取新生成的 Elasticsearch API 密钥，然后将该密钥注入下游应用程序或自动化工具，从而导致复杂的管道、分散的审计日志以及更高的凭证泄露风险。

Elastic Cloud Serverless 中的统一身份验证

通过此次发布，Serverless 项目的拆分问题将不复存在。您现在可以创建一个明确授权用于 云、Elasticsearch 和 Kibana API 的 Elastic Cloud API 密钥。

• 以前：Elastic Cloud API 密钥严格来说是控制平面令牌。它可以创建项目、管理计费和邀请用户，但存在一个硬边界：它不能用于调用这些项目内部的 Elasticsearch 或 Kibana API。您始终需要第二个特定于项目的密钥来执行数据操作。

• 现在： 在创建 Elastic Cloud API 密钥时，选择 Cloud、Elasticsearch 和 Kibana API 访问权限，Serverless 的硬边界就被移除了。该 API 密钥成为一个真正统一的凭证。它保留了管理组织基础架构的能力，同时获得了跨任何已授权 Serverless 项目进行查询、摄取和分析数据的原生访问能力。

通过将这一切统一到单个 Elastic Cloud API 密钥之下，您获得了一个统一的身份，可以作为一个整体进行范围限定、审计、轮换和撤销。每个 API 调用——无论是配置新项目还是运行 ES|QL 查询——都会在审计日志中显示为使用同一凭证，从而在事件调查或合规性审查期间为您提供单一的追踪线索。凭证轮换成为一步操作，而无需跨独立的控制平面和数据平面秘密信息进行协调更新。而且由于角色分配是按项目进行的，一个密钥可以跨多个项目使用——在您的可观测项目中管理数据摄取，在安全项目中运行查询——无需为每个项目分别管理不同的凭证。

重要的是，统一并不意味着全部权限。通过使用 role_assignments 有效负载，您可以将统一密钥严格限定到单个项目和特定角色（例如只读），从而确保即使凭证泄露，其影响范围也能得到完全控制。如果某位开发人员离职或某个应用程序被停用，您可以在 Elastic Cloud Console 中撤销单个密钥，立即终止对控制平面以及所有关联 Elasticsearch 项目的访问。

(注意：对于 Elastic Cloud Hosted / 托管部署，Cloud API 密钥仍仅用于控制平面管理。计划在未来的版本中支持将其扩展到托管堆栈 API。）

自动化您的工作流

入门很简单。您可以完全通过 Elastic Cloud 控制台进行配置，也可以使用 Elastic Cloud API 对其进行自动配置。

UI 流程保持不变，但现在您可以在项目角色分配下选择 Cloud、Elasticsearch 和 Kibana API 访问权限。

下面说明如何使用 Elastic Cloud API 以编程方式创建统一密钥。请注意 application_roles 数组，正是它授予了密钥对 Elasticsearch 数据平面的原生访问权限：

一旦创建，您只需在 Authorization: ApiKey 标头中向 api.elastic-cloud.com 以及您的特定 Serverless Elasticsearch 终端传递完全相同的这个密钥即可。

底层实现：构建分布式身份层

使一个 Cloud API 密钥能够在控制平面和数据平面同时工作，并不像传递一个令牌那么简单。这需要解决一个根本性的分布式系统挑战。

过去，Cloud API 密钥存储在一个中心化的全局安全集群中。这对于可以接受较高延迟的控制平面操作来说没有问题。然而，Elasticsearch 数据请求要求超低延迟。我们不能为了验证每个搜索查询或摄取请求而在全局范围内往返访问中央控制平面。

为了解决这个问题，我们引入了一种由全局分布式数据存储提供支持的新身份验证架构。下面的序列图展示了一个客户端使用 Elastic Cloud API 密钥发送 Elasticsearch 查询的过程，说明了身份验证完全在本地区域内完成，无需往返全局控制平面。Elasticsearch 将身份验证委托给区域 IAM 服务，该服务针对全局分布式数据库的本地副本验证密钥并解析其角色分配。一旦授权通过，Elasticsearch 执行查询并将结果返回给客户端。

全局分布式持久化

Elastic Cloud API 密钥及其关联的角色定义不再仅依赖集中式安全集群，而是持久化存储在全球分布的高可用数据库中。该数据库在全球控制平面与实际运行您的 Serverless 项目的区域数据平面之间同步身份与访问管理 (IAM) 数据。

使用区域 IAM 进行本地验证

当您的客户端使用 Elastic Cloud API 密钥向 Elasticsearch 发送请求时，该请求不会返回全局控制平面。相反，它会被路由到新的区域 IAM 服务。它会验证本地数据库副本中的密钥，确保身份验证几乎无延迟，并且完全不受全局控制平面故障的影响。

动态角色映射

身份验证只是成功的一半；系统还需要对请求进行授权。区域 IAM 服务可立即将您的云端角色分配 (例如 application_roles) 转换为原生 Elasticsearch 权限。Elasticsearch 随后可在本地授权并执行请求，完全无需本地 .security 索引。

跨项目搜索的基础

这种分布式身份架构是 Elastic 平台未来发展的基础构建块。

由于身份和访问权限现在统一且全局同步，我们拥有了在不同项目之间安全传递您身份所需的框架。这为 Serverless 即将推出的 跨项目搜索 (CPS) 功能提供了支持。

借助 CPS，您将能够查询跨越多个远程 Serverless 项目的数据，例如将安全负载和可观测负载组合起来，就像它们是单一数据集一样简单。通过依赖统一 API 密钥，系统可以自动评估您在所有项目上的权限，而无需您在每个目标项目上配置复杂的信任关系、证书或重复的凭证。

了解详情

准备好简化您的技术栈了吗？

• 请参阅 Elastic Cloud API 密钥文档，了解如何分配堆栈访问权限。

• 请参考 Create API key（Elastic Cloud API） 文档，以实现密钥自动生成。

• 查看 Elastic API 密钥，了解 Elastic 平台中各类密钥的完整对比。

立即开始在 Elastic Cloud 上构建或继续您的构建之旅。

免责声明

本文中描述的任何功能或功能性的发布和时间均由 Elastic 自行决定。当前尚未发布的任何功能或功能性可能无法按时提供或根本无法提供。

派对越来越拥挤了

您要举办一个披萨派对。您有几位朋友协助您招待宾客，他们分别在房间的不同位置。您把披萨分给每位朋友，他们会在饥饿的宾客陆续到来时开始分发披萨。

起初，一切运行顺利。有几位宾客陆续进来，朋友们端上披萨片，大家都很开心。但随后关于您的披萨的消息传开了。门铃一直在响。宾客们蜂拥而至。很快，人群聚集在您的一位朋友周围，就是那个拿着意式辣味香肠披萨的朋友，似乎大家都想要那块披萨。

您那位拿着意式辣味香肠披萨的朋友感到不知所措。宾客们正在等待，变得不耐烦了，还排起了长队。与此同时，您的朋友手持玛格丽特披萨站在那里，几乎没有人要一片。

您需要怎么做？

您又点了几份意式辣味香肠披萨，并把它们分给其他朋友。现在有三位朋友在拿着意式辣味香肠披萨分发，而不再只是一个人。人群散开了，突然间您就能一次性接待三倍数量的宾客。

随着您举办的派对越来越多，有几件事会变得越来越清晰：

• 并非所有披萨都同样受欢迎。有些供不应求，有些则鲜有人问津。您不需要为那些不受欢迎的披萨准备多余的“份数”。您需要为那些排队的披萨准备更多“份数”。

• 在排队人数变多之前多点几份披萨。如果您等到朋友已经忙得不可开交、客人都气得离场时才行动，那就太晚了。最好是在看到人群聚集时，就提前加点一份披萨。

• 别太快把披萨撤走。即使意式辣味香肠披萨周围的人群散开了五分钟，也不代表高峰期已经过去。也许他们只是在加饮料，甚至只是在聊天（现在还是这样吗？）。把多余的披萨准备好。如果冷场确实持续了一段时间，那时再撤走也不迟。

• 您能分发的披萨数量取决于有多少朋友来帮忙。如果您只有四个朋友在帮忙，十张披萨也改变不了结果。一次只能供应四份。将您的披萨数量与可用人手相匹配。

• 当一个朋友离开时，记得接管他的披萨。如果您的朋友需要离开，请立即拿走他们的披萨。披萨不能无人看管地放置。将它交给其他人，或者妥善收好。

我们已经聊完了披萨和副本

现在让我们把这些生动的小故事映射回 Elasticsearch。

在我们的类比中，披萨是副本（索引分片的副本），帮助提供服务的朋友是搜索节点，饥肠辘辘的宾客是搜索查询，而人头攒动的热门披萨则是搜索负载较高的热门索引。

当特定索引的搜索流量增加时，我们会创建额外的副本，并将它们分发到搜索节点上。任何副本都可以为该索引的任何查询提供服务，就像任何拿着意式辣味香肠披萨的朋友都可以分发意式辣味香肠披萨片一样。更多副本意味着更高的吞吐量：三个副本每秒处理的查询量是单个副本的三倍。

衡量饥饿程度

在决定订购多少披萨之前，我们需要了解人群的饥饿程度。

Elasticsearch 会跟踪每个分片的搜索负载。这是一个度量指标，用于衡量分片正在处理的搜索活动的数量。我们将此汇总到索引的所有分片中，以了解总的搜索需求。

最重要的是相对搜索负载：您的项目总搜索流量中，每个索引所占的比例是多少？如果一个索引的搜索量为 60%，而另一个索引的搜索量为 5%，我们就知道应该在哪里增加容量。

披萨背后的数学原理

我们按照以下公式计算最佳副本数量：

其中：

• L = 索引的相对搜索负载（介于 0 和 1 之间）。

• N = 项目中所需搜索节点的数量。

• S = 索引中的分片数量。

• X = 用于避免热点的阈值（默认值：0.5）。

示例：四个搜索节点，具有两个主分片的一个索引，接收 80% 的搜索流量：

这个热索引有四个副本，分布在各个搜索节点上。

阈值 X（默认为 0.5）非常重要。我们不会等到副本完全不堪重负才采取行动；当副本的负载达到一半容量时，我们就会进行扩展。当看到人群聚集时再分发额外的披萨，而不是等到宾客已经开始离开的时候。

快速扩展，缓慢收缩

当搜索负载增加时，我们立即添加副本。没有理由让用户等待。

当搜索负载下降时，我们会等待一段时间再采取行动。在减少副本之前，我们需要看到持续约 30 分钟的低需求。（这是为了应对流量高峰，因为短暂的平静并不意味着派对结束。）

这很重要，因为添加副本是有成本的。在高效提供查询之前，新的副本会复制数据并预热其缓存。过于急切地移除副本意味着在流量自然波动时持续支付这种启动成本。

尊重拓扑边界

副本永远不能超过搜索节点的数量。拥有比节点更多的副本并不会带来任何好处（您能送出的披萨数量取决于帮忙的朋友数量）。

从您的项目中移除节点时，我们会立即减少副本数量以进行匹配。无需等待冷却时间，因为您无法拥有未分配的副本。朋友离开的那一刻，我们就会移除他们的披萨。

无服务器的全貌

用于搜索负载均衡的副本与其他自动缩放系统协同工作：

• 搜索自动缩放可调整搜索节点的数量（有多少朋友在帮忙）。

• 用于搜索负载均衡的副本通过调整每个索引的副本数量来分发流量（我们需要每种披萨的数量）。

• 数据流自动分片优化了写入的分片数量（如何将每个披萨切片，详情见上一篇文章）。

一个重要的设计原则：用于负载均衡的副本不会直接触发搜索自动扩展。相反，通过将搜索请求分发给更多副本，可以提高搜索节点的资源利用率。这种更高的利用率会触发我们现有的自动扩展逻辑，以便在需要时增加容量。用于负载均衡的副本可让自动扩展发挥作用，确保搜索节点真正得到使用，而不是将所有流量都集中在单个副本上造成瓶颈，而其他节点却处于闲置状态。

这对您意味着什么

您无需预测哪些索引会更受欢迎。当流量模式发生变化时，您无需手动调整副本。您无需因为流量激增导致最繁忙的索引不堪重负，而不得不凌晨 3 点起床进行处理。

系统会观察排队的地点，并为这些地点订购更多披萨。冷索引不会在不必要的副本上浪费资源。热门索引会获得所需的容量。您的预算用在了最重要的地方。

结论

在自动分片文章中，我们确保您的披萨切得恰到好处。现在，有了用于搜索负载均衡的副本，我们可以确保在饥饿的人群到来时，有足够的披萨送到他们手中。

试用 Elastic Cloud Serverless，让我们来处理披萨分发事宜。

代理正凭借其提升效率和改善客户体验方面的潜力而日益受到重视。但在实践中，为代理提供正确的上下文是困难的，尤其是在处理杂乱无章的非结构化企业数据时。开发人员必须管理工具、提示、状态、推理逻辑、模型，最重要的是从业务来源检索相关上下文，以提供准确的结果和操作。Elastic Agent Builder 提供这些核心组件，用于开发安全、可靠、上下文驱动的代理。

Agent Builder 核心功能

Agent Builder 利用 Elastic 在搜索相关性和检索增强生成方面的长期投入，并致力于将 Elasticsearch 打造成最佳的向量数据库，从而简化以数据为中心的上下文 AI 代理的开发。

Agent Builder 允许您：

• 立即开始使用内置的会话代理，它可以回答问题、执行分析并驱动对 Elasticsearch 中任何数据的调查。

• 快速从复杂的非结构化数据转变为具有基于配置的开发体验的自定义代理。

• 利用内置的 ES|QL 或自定义工具，利用最佳的混合搜索相关性来提高上下文质量和代理可靠性。

• 将复杂的工作流（预览）作为可重复使用的工具来执行，以丰富数据、更新记录、发送消息等，实现基于规则的自动化。

• 使用工作流和 MCP 连接 Elasticsearch 外部的数据源，以关联和整合代理的上下文。

• 使用通过 MCP 提供的内置和自定义工具与任何代理或应用程序框架集成，并能够连接到外部 MCP（预览版）、支持 A2A 和提供完整的 API 支持。

• 通过与第三方解决方案（如用于复杂文档处理的 LlamaIndex 或用于安全、结构化工具访问的 Arcade.dev）集成，扩展 Agent Builder 的功能。

为了进一步扩展 Agent Builder 的功能，我们推出了 Elastic Workflows，这是我们新的基于规则的自动化功能，目前处于技术预览阶段。对于组织任务，代理有时需要基于规则的操作的确定性和可靠性，这通常是实现特定业务逻辑所必需的。Elastic Workflows 为代理提供了一种简单、声明式的方式，用于编排内部和外部系统，以执行操作、收集和转换数据和上下文。工作流是完全可组合、事件驱动且灵活的，并且可以通过 MCP 作为工具提供给代理。

从数据到代理仅需几分钟

开发代理可能需要花费数周的前期工作来整合独立的数据存储、构建手动管道、调整查询和管理复杂的编排。Agent Builder 不需要单独的数据存储、向量数据库、RAG 管道、搜索层、查询转换器和工具编排器，从而减少了开发代理的时间，使您能够专注于代理逻辑和应用程序交付。

Agent Builder 原生集成了 Elasticsearch 平台的基元，从而加快了代理开发的速度。

• 首先，内置的对话代理可以立即与您的索引数据进行聊天和推理。

• 通过 Kibana、API 或 MCP 和 A2A 进行交互式访问，将代理集成到应用程序、仪表板或 CI/CD 系统中。

• 使用默认工具进行构建，以了解您的数据结构，选择适当的索引，生成优化的混合、语义和结构化查询，并根据自然语言提示使用 ES|QL 创建可配置的可视化。

要深入了解，请尝试完整的实践演练。

基于 Elasticsearch 构建，这是一个用于上下文工程的完整数据平台

对于 AI 代理，上下文质量对于提供有效的推理和降低幻觉的风险至关重要。对于许多企业 AI 代理而言，执行任务所需的业务数据是最关键的上下文信息。作为大规模可扩展数据存储、向量数据库和相关性领域的领导者，Elasticsearch 已经提供了许多强大的上下文工程原语。上下文工程超越了简单的检索增强生成，允许您定制和扩展数据获取、排序、筛选和呈现给代理的方式，有助于减少噪音和歧义。

Elasticsearch 提供的上下文引擎结合了词汇搜索、向量搜索和结构化筛选，通过确保模型在相关且精确的上下文中运行，显著提高了 LLM 性能。这种功能由代理检索提供支持，同时还具备内置工具和搜索逻辑，能够自动选择正确的索引，并将自然语言转化为针对上下文优化的查询。

利用 Agent Builder，您可以确保代理首先获得最有用的上下文，并设有相关性和排名控制，从而允许您微调评分、排名和筛选逻辑。Elasticsearch 可让您控制重要内容、重要原因以及优先级，而非依赖不透明的检索行为。这一切都由 Elasticsearch 作为可扩展性平台提供支持，可以在单个平台上存储和扩展来自文本、向量、元数据、日志等的所有数据，从而更轻松地管理代理的上下文。

将复杂的工作流作为可重复使用的工具来执行

虽然 AI 代理可以对复杂的任务进行推理，但许多自动化工作都依赖于可靠地执行基于规则的操作，以强制实施特定的业务逻辑。Elastic Workflows 提供了一种简单、声明式的方式来编排内部和外部系统，以执行操作、收集上下文或数据，并将其整合为代理的一部分。在 YAML 中定义的工作流是完全可组合的，这使得它们能够根据任务需求变得简单或复杂。这为代理提供了在 Elasticsearch 平台和解决方案以及第三方应用程序中执行操作的有效方式。

使用 Agent Builder 集成工作流可通过三个步骤完成（先决条件：启用工作流，详情请参阅此处）

1. 使用内置自动完成和测试功能的基于 YAML 的简单编辑器创建并保存新的工作流。

2. 在 Agent Builder 中创建一个类型为“工作流”的新工具，并提供说明，帮助代理确定何时使用工作流工具。

3. 将工作流工具添加到您的自定义代理。

4. 就是这样！现在，代理可以在对话中调用工作流。

您的代理，您的规则

Agent Builder 不会将您限制在单一的开发范式中。相反，它旨在为代理提供开放、灵活的开发方法，使代理能够完全掌控数据、相关性、模型、互操作性、安全性和代理设计。

自定义代理定义可让您准确选择代理可访问的工具、嵌入自定义系统提示、定制代理的指令并定义安全边界。代理仍然与模式无关，让您能够灵活配置首选的本地和跨更广泛生态系统的 LLM，而无需受限于单一提供商。

构建可扩展的工具，将特定领域的逻辑（例如特定的索引筛选器、ES|QL 连接、分析管道）封装起来，并对其加以约束，以确保其在生产环境中安全使用。完整的 API 支持实现了与其他代理框架的互操作性，并原生支持模型上下文协议 (MCP)。A2A 集成意味着您可以将 Elastic 代理提供给其他框架、服务和客户端应用，从而在各种集成中重复使用相同的数据和上下文工程逻辑。

Agent Builder 支持灵活、开放的开发，可与流行的代理框架和平台轻松集成。这些集成对于提供高效的代理至关重要。正如 Arcade.dev 的联合创始人 Sam Partee 所描述的那样，

"如今，代理系统之所以失败，是因为将 AI 与工具和数据连接起来非常复杂。Elastic Agent Builder 与 Arcade.dev 结合，为开发者提供了一种结构化且安全的方式来处理代理如何检索上下文、进行推理和采取行动，从而将代理从演示级别提升至生产级别。”

Agent Builder 还利用了 Elasticsearch 的可扩展性来处理复杂数据。正如 LlamaIndex 首席执行官 Jerry Liu 所描述的那样，

“从非结构化数据源中解锁企业上下文是建立有效代理的关键。Elastic Agent Builder 与 LlamaIndex 复杂文档处理相结合，强化了关键的上下文层，帮助团队检索、处理和准备数据，从而使代理能够更准确地推理并提供更好的结果。”

您可以构建什么？

Agent Builder 已用于各种用例。以下是一些示例和参考架构，可帮助您开始使用代理：

• 基础设施自动化：在支持场景中，代理已被用于读取、思考和聊天，但迄今为止，它们还无法触及可能需要管理的基础设施。Elastic 的工程团队在黑客马拉松中构建了一个用于自动化基础设施管理的代理。代理会主动调查应用程序基础设施的问题，并采取自动化操作。它使用工作流来优化配置、响应问题并扩展资源，所有这些都基于对基础设施日志的智能理解。

• 安全威胁分析：已使用 Elastic Agent Builder、MCP 和 Elasticsearch 开发了一个安全漏洞代理。它通过将内部安全数据与外部威胁情报关联起来，自动进行威胁分析。该代理对历史事件和配置进行语义搜索，使用实时互联网数据增加结果，并应用 LLM 推理来评估环境相关性、确定风险优先级并生成可操作的补救措施。请参阅参考架构。

• 技术客户支持：代理可以执行多项支持任务，包括案例汇总、问题重复检测和创建，以及深入的技术调查。Agent Builder 可通过多步骤混合搜索实现这一功能，仅查找最相关的相关问题、解决方案和程序，并制定根本原因假设和补救计划。Agent Builder 可以简化复杂支持系统的架构，并加快交付时间。

• 产品和内容发现：Agent Builder 简化了将复杂的产品目录用于对话式体验的过程，同时允许组织保持灵活性，以纳入其自身的业务逻辑和要求。

• 构建您自己的系统：参加 Agent Builder 黑客松活动，该活动将于 2026 年 1 月 22 日至 2 月 27 日举行。与社区合作，构建基于上下文的多步骤 AI 代理，将搜索、工作流、工具和推理相结合，以自动执行现实世界中的任务*

现在开始构建自定义代理

开始 Elastic Cloud 试用，并在此处查看文档。对于现有客户，Agent Builder 可在 Cloud Serverless 中使用，也可在 Elastic Cloud Hosted 和自主管理的企业层中使用。

*点击此处查看黑客松的完整条款、条件和资格要求

我们已为在 AWS 上运行的所有 Elastic Cloud Serverless 项目完成了一次重大基础设施升级，迁移到了更新、更快的硬件上。此更改已自动推广至所有无服务器项目。它为 AWS 上的 Elasticsearch、Elastic Observability 和 Elastic Security 无服务器项目提供了更高的吞吐量和更低的延迟。

为开发人员带来的关键性能优势

新的 AWS 硬件基础设施支撑着您使用 Elastic Cloud Serverless 所做的一切，为您的应用程序的速度和响应能力带来切实的好处。

降低查询延迟……提高吞吐量

改进后的硬件显著提升了计算资源的速度，这意味着您的搜索查询处理速度比以往任何时候都要快。

• 搜索和向量搜索：无论您是运行传统的全文本查询，还是在生成式 AI 和 Retrieval-Augmented Generation (RAG) 应用中使用尖端的向量搜索，您都会发现延迟明显减少。内部基准测试显示，搜索延迟平均减少了 35%。

• 索引速度更快：数据摄取速率得到优化，使您能够以更高的吞吐量为海量数据和复杂文档建立索引。这对于需要近实时数据可见性的应用程序至关重要。内部基准测试显示，索引吞吐量平均提高了 26%。

在负载下保持稳定性能

无论您的工作负载如何，Elastic Cloud Serverless 都能实时动态地自动扩展，以满足需求，最大限度地减少延迟。通过这次硬件升级，这种扩展性现在变得性能更强且响应更迅速。

• 轻松应对流量高峰：无论您面临的是用户流量的突然激增，还是大规模批量数据的摄取，新的基础设施都能确保您的搜索和索引资源更高效地扩展，从而保持一致的低延迟。

• 优化的计算存储解耦：无服务器架构将计算与存储分离，使工作负载能够独立扩展，从而实现最佳性能和成本效益。速度更快的硬件增强了计算层，最大限度地提高了这种解耦设计的效率。

幕后揭秘：内部基准测试结果

为了量化 AWS 基础设施升级的影响，Elastic 工程团队针对一系列无服务器工作负载进行了全面的内部基准测试。这些工作负载为性能改进提供了经验证据，无论您的用例如何，您都可以期望在应用程序中获得性能提升。

基准测试方法

我们将测试重点放在直接影响开发者体验和应用程序响应速度的关键指标上：响应时间（即延迟）和搜索与索引操作的吞吐量。

• 测试的工作负载：测试包括面向用户的应用程序中典型的高并发搜索操作、复杂的向量搜索查询以及用于可观测性和安全用例的大量数据摄取/索引。特别是，我们的测试方法使用了 Elastic 基准测试工具 Rally 的公开可用的数据集。

  • wikipedia：一个从维基百科文本内容的快照中提取的数据集，用于衡量通用文本搜索性能。

  • MSMARCO-Passage-Ranking：一个源自 Microsoft 机器阅读理解 (MS MARCO) 的数据集，用于衡量稀疏向量字段上的搜索性能。

  • OpenAI_Vector：一个源自 BEIR 的 NQ 并通过 OpenAI 的 text-embedding-ada-002 模型生成的嵌入进行丰富的数据集，用于衡量密集向量字段上的搜索性能。

• 测量：我们比较了新旧基础设施的性能，测量了第 99 百分位数 (P99) 的延迟，以捕捉最坏情况下的尾部延迟性能和每秒操作数。为确保结果的一致性，每个硬件配置文件的每条测试路径都运行了五次。

• 目标：我们的目标是验证基础设施即使在快速自动扩展期间也能持续提供更快、更可预测的全面性能的能力。

性能数据摘要

结果证实，效率和速度都有了明显提高。由于能够使用更少的计算资源完成相同的工作量，这些收益直接转化为更短的用户响应时间和更低的运营成本。

下表详细列出了数量上的改进。数值越大，吞吐量越高；数值越小，延迟越低。

搜索基准测试结果：

基准

对比

旧版基础设施

新的基础设施

差别

`wikipedia` (纯文本)

搜索操作吞吐量 (ops/s)

729

1107

+52%

`wikipedia` (纯文本)

搜索操作延迟（p99，毫秒）

56

35

-37%

`MSMARCO-Passage-Ranking`（稀疏向量）

搜索操作吞吐量 (ops/s)

220

31

+40%

`MSMARCO-Passage-Ranking`（稀疏向量）

搜索操作延迟（p99，毫秒）

108

67

-38%

`OpenAI_Vector`（密集向量）

搜索操作吞吐量 (ops/s)

475

624

+31%

`OpenAI_Vector`（密集向量）

搜索操作延迟（p99，毫秒）

35

220

-37%

索引基准测试结果：

基准

对比

旧版基础设施

新的基础设施

差别

`wikipedia` (纯文本)

搜索操作吞吐量 (ops/s)

2,845

3220

+13%

`wikipedia` (纯文本)

搜索操作延迟（p99，毫秒）

1,769

1,120

-37%

`MSMARCO-Passage-Ranking`（稀疏向量）

搜索操作吞吐量 (ops/s)

7,087

8900

+26%

`MSMARCO-Passage-Ranking`（稀疏向量）

搜索操作延迟（p99，毫秒）

824

677

-18%

`OpenAI_Vector`（密集向量）

搜索操作吞吐量 (ops/s)

2,972

3,187

+7%

`OpenAI_Vector`（密集向量）

搜索操作延迟（p99，毫秒）

2,946

2,944

0%

额外收获：成本降低

虽然我们的重点是提供低延迟性能，但新硬件的效率也对 Elasticsearch 项目的成本产生直接的积极影响。

Elasticsearch Serverless 的定价是基于使用量的，这意味着您只需为您所使用的摄取和搜索资源付费。由于更新、更快的硬件效率更高，您的工作负载通常能用更少的资源完成任务，从而降低大多数项目的固有成本。您无需支付高昂的价格，就能获得卓越的性能提升——这就是优化效率的定义。

这对您，开发者来说意味着什么？

此次基础设施升级完全由 Elastic 管理，因此您无需亲自操作——无需迁移，也无需更改配置。改进效果立竿见影，并自动应用于您所有基于 AWS 的无服务器项目。

此升级赋予您以下能力：

• 构建更快的应用程序：专注于功能开发速度，确保您的底层搜索平台能够提供用户所需的速度。

• 自信创新：部署新的搜索、可观测性和安全功能（包括向量搜索和相关性排序等复杂的 AI 功能），并确保平台能够以最高性能处理负载。

• 简化堆栈：使用完全托管的服务来处理基础设施管理、容量规划和扩展，这样您就可以专注于代码和数据。

1. 克隆版本库：使用git clone https://github.com/elastic/elasticsearch-labs/supporting-blog-content/serverless-ai-agent a 从 GitHub 下载该工具的代码，然后使用cd serverless-ai-agent 导航到该目录。

2. 设置环境： 使用python -m venv venv 创建虚拟环境（可选）并激活（Windows 上为source venv/bin/activate 或venv\Scripts\activate ）。然后，使用pip install -r requirements.txt 安装必要的 Python 软件包。

3. 配置凭证： 在项目根目录下创建.env 文件，并在其中填入 Elasticsearch API URL (ES_URL)、API 密钥 (API_KEY)、地区 (REGION) 和 OpenAI API 密钥 (OPENAI_API_KEY)。

4. 运行工具： 在终端运行python main.py ，执行该工具。这将启动人工智能代理，并提示您执行命令。

5. 用自然语言管理项目：使用纯英文命令与工具交互，如"Create a serverless project named my\_project","Get status of the serverless project named my\_project", 或"Delete the serverless project named my\_project" 。人工智能将解读您的命令并执行相应的功能。

背景

这个小命令行工具能让你用简单的英语管理你的无服务器 Elasticsearch 项目。它会与人工智能（本例中为 OpenAI）对话，以了解您的意思，并使用 LlamaIndex 调用正确的函数！

Elasticsearch Serverless AI 代理能做什么

• 创建项目：启动一个新的无服务器 Elasticsearch 项目。

• 删除项目删除现有项目（是的，它会在你删除后进行清理）。

• 获取项目状态：查看项目进展情况

• 获取项目详情：获取项目的所有细节。

在GitHub上查看代码。

Elasticsearch Serverless AI 代理如何工作

当您输入以下内容时

"创建一个名为 my_project 的无服务器项目"

......下面是幕后花絮：

• 用户输入& 上下文：您的自然语言命令将发送给人工智能代理。

• 功能描述：人工智能代理已经知道一些函数，如创建项目、删除项目、获取项目状态和获取项目细节，因为我们给了它详细的说明。这些说明会告诉人工智能每个函数的作用以及需要的参数。

• LLM 处理：将您的查询和功能信息发送给 LLM。这意味着人工智能可以看到

  • 用户查询：您的简明指令

  • 可用功能& 说明：详细说明每个工具的功能，以便选择正确的工具。

  • 上下文/历史聊天信息：既然是对话，就会记住之前说过的话。

• 函数调用& 响应：人工智能会找出要调用的函数，传递正确的参数（如项目名称），然后执行函数。回复会以友好的格式发回给您。

简而言之，我们将您的自然语言查询和详细的工具描述列表同时发送给 LLM，这样它就能 "理解 "并为您的请求选择正确的操作。

设置人工智能代理

先决条件

运行人工智能代理之前，请确保已设置好以下内容：

1. 已安装Python（v3.7 或更高版本）。

2. 在 Elastic Cloud 上设置Elasticsearch 无服务器账户。

3. OpenAI 账户与语言模型进行交互。

步骤：

1.克隆版本库：

2.创建虚拟环境（可选但推荐）：如果遇到与环境相关的问题，可以建立虚拟环境进行隔离：

3.安装依赖项：运行以下命令，确保已安装所有必需的依赖项：

4.配置环境：创建 .env文件，其中包含以下变量下面是一个.env.example 文件示例，希望对您有所帮助：

确保ES_URL 、API_KEY 和OPENAI_API_KEY 的值正确无误。您可以在相应的服务仪表板中找到您的 API 密钥。

5.项目文件：该工具使用projects.json 文件来存储项目映射（项目名称与其详细信息）。如果该文件不存在，将自动创建。

运行人工智能代理

您会看到这样的提示

输入指令，人工智能代理就会施展魔法！完成后，请输入exit 或quit 离开。

更多细节

• LLM 集成：LLM 可同时收到您的查询和每个可用功能的详细说明。这有助于它理解上下文，并决定是调用create_ess_project 还是delete_ess_project 等。

• 工具说明：每个函数工具（使用 FunctionTool.from_defaults 创建）有一个友好的描述。该说明包含在发送给 LLM 的提示中，以便 LLM "知道 "有哪些可用的操作，以及每个操作的期望值。

• 持久性：项目及其详细信息保存在 projects.json 中、这样您就不必每次都重新输入信息了。

• 详细记录：代理被设置为 "详细 "模式，非常适合调试和查看指令如何被转换为函数调用。

Elasticsearch 人工智能代理利用示例

我们的起点

Elasticsearch的第一个版本于 2010 年发布，它是一个分布式可扩展搜索引擎，允许用户快速搜索并浮现关键见解。十二年过去了，Elasticsearch 的提交次数已超过 65,000 次，它将继续为用户提供久经考验的解决方案，以解决各种搜索问题。在包括数百名 Elastic 全职员工在内的 1,500 多名贡献者的努力下，Elasticsearch 不断发展，以应对搜索领域出现的新挑战。

在 Elasticsearch 诞生之初，当数据丢失的问题被提出时，Elastic 团队经过多年的努力，重写了集群协调系统，以确保确认的数据得到安全存储。当发现在大型集群中管理索引是一件麻烦事时，团队开始实施广泛的ILM 解决方案，通过允许用户预先定义索引模式和生命周期操作来实现这项工作的自动化。由于用户发现需要存储大量的度量和时间序列数据，因此增加了各种功能，如更好的压缩功能，以减少数据量。由于搜索大量冷数据的存储成本越来越高，我们投资创建了可搜索快照，作为在低成本对象存储上直接搜索用户数据的一种方式。

这些投资为 Elasticsearch 的下一步发展奠定了基础。随着云原生服务和新协调系统的发展，我们决定是时候对 Elasticsearch 进行进化，以改善使用云原生系统时的体验。我们相信，这些变化为在 Elastic Cloud 上运行 Elasticsearch 带来了改进运行、性能和成本的机会。

我们的目标--采用无状态架构

运行或协调 Elasticsearch 时面临的主要挑战之一是，它依赖于大量持久状态，因此是一个有状态的系统。这三个主要部分是 translog、索引存储和集群元数据。这种状态意味着存储必须是持久的，不会在节点重启或更换时丢失。

Elastic Cloud 上现有的 Elasticsearch 架构必须在多个可用性区域内重复索引，以便在发生故障时提供冗余。我们打算将这些数据的持久性从本地磁盘转移到对象存储，如 AWS S3。通过依靠外部服务来存储这些数据，我们将不再需要进行索引复制，从而大大减少了与摄取相关的硬件。由于 AWS S3、GCP Cloud Storage 和 Azure Blob Storage 等云对象存储跨可用区复制数据的方式，这种架构还能提供非常高的耐用性保证。

将索引存储卸载到外部服务中还能让我们通过分离索引和搜索职责来重新构建 Elasticsearch。我们打算建立一个索引层和一个搜索层，而不是让主实例和副本实例同时处理这两种工作负载。将这些工作负载分开，可以使它们独立扩展，并使硬件选择更有针对性，以满足各自的使用情况。它还有助于解决一个长期存在的难题，即搜索和索引负载会相互影响。

经过为期数月的概念验证和实验阶段，我们确信这些对象存储服务能够满足我们对索引存储和集群元数据的要求。我们的测试和基准测试表明，这些存储服务可以满足我们在 Elastic Cloud 中看到的最大集群的高索引需求。此外，将数据备份到对象存储区可降低索引成本，并可对搜索性能进行简单调整。为了搜索数据，Elasticsearch 将使用久经考验的可搜索快照（Searchable Snapshots）模型，在该模型中，数据永久保存在云原生对象存储中，而本地磁盘则用作频繁访问数据的缓存。

为了帮助区分，我们将现有模型描述为"节点对节点" 复制。在该模型的热层中，主分片和副本分片都承担着处理摄取和提供搜索请求的重任。这些节点是"有状态的" ，因为它们依靠本地磁盘安全地持久化所托管分片的数据。此外，主分片和副本分片不断进行通信，以保持同步。它们的做法是将主分区上执行的操作复制到副本分区上，这意味着这些操作的成本（主要是 CPU 成本）会在指定的每个副本上产生。同样的分片和节点在为收录工作提供服务的同时，也在为搜索请求提供服务，因此在进行配置和扩展时必须考虑到这两种工作负载。

除了搜索和摄取，节点到节点复制模型中的分片还负责处理其他密集型任务，如合并 Lucene 片段。虽然这种设计有其优点，但根据我们多年来从客户那里了解到的情况以及更广泛的云生态系统的演变，我们看到了很多机会。

新架构可实现许多直接和未来的改进，包括

1. 在相同的硬件上，你可以大幅提高摄取吞吐量，或者换个角度看，在相同的摄取工作负载下，大幅提高效率。这一增长来自于消除了每个副本的重复索引操作。CPU 密集型的索引操作只需在索引层上进行一次，然后将生成的段传送到对象存储区。这样，搜索层就可以按原样使用数据了。

2. 您可以将计算与存储分开，以简化集群拓扑结构。如今，Elasticsearch 拥有多个数据层（内容层、热层、温层、冷层和冻结层），可将数据与硬件配置文件相匹配。热层用于近实时搜索，冷冻层用于搜索频率较低的数据。这些层级在提供价值的同时，也增加了复杂性。在新架构中，不再需要数据层，从而简化了 Elasticsearch 的配置和操作。我们还将索引与搜索分离开来，这进一步降低了复杂性，并使我们能够独立扩展这两种工作负载。

3. 通过减少必须存储在本地磁盘上的数据量，索引层的存储成本可以得到改善。目前，Elasticsearch 必须在热节点（主节点和副本节点）上存储完整的分片副本，以便编制索引。采用无状态方法，直接在对象存储区建立索引，只需要部分本地数据。对于只进行追加的用例，只需存储某些元数据以编制索引。这将大大减少索引所需的本地存储空间。

4. 您可以降低与搜索查询相关的存储成本。通过将 "可搜索快照 "模式作为搜索数据的本机模式，与搜索查询相关的存储成本将大大降低。根据用户对搜索延迟的需求，Elasticsearch 将允许对频繁请求的数据进行调整，以增加本地缓存。

基准测试 - 75% 索引吞吐量改进

为了验证这种方法，我们实施了一个广泛的概念验证，其中数据仅在单个节点上编制索引，并通过云对象存储实现复制。我们发现，通过消除对索引复制专用硬件的需求，我们可以将索引吞吐量提高 75% 。此外，仅从对象存储中提取数据所需的 CPU 成本远低于编制数据索引和本地写入数据的成本，而这正是目前热层所必需的。这意味着搜索节点可以将其 CPU 全部用于搜索。

这些性能测试是在一个双节点集群上针对三大公共云提供商（AWS、GCP 和 Azure）进行的。我们打算在实现无状态生产的过程中，继续建立更大的基准。

索引吞吐量

CPU 使用率

我们无国籍，你们有储蓄

Elastic Cloud 上的无状态架构可让您减少索引开销，独立扩展摄取和搜索，简化数据层管理，并加快扩展或升级等操作。这是实现弹性云平台实质性现代化的第一个里程碑。

成为 Elasticsearch 无状态愿景的一部分

有兴趣抢先尝试这种解决方案吗？您可以在讨论区或我们的社区休闲频道与我们联系。我们希望您能提供反馈意见，帮助我们确定新架构的方向。