阿里云 ES AI 引擎版：面向 Agent 场景，为亿级租户、千亿规模向量设计的搜索引擎

导读：基于 OSS 的无状态多租户搜索方案：全文、向量混合检索，亿级租户、千亿级向量，成本只与活跃数据线性相关，完全兼容 Elasticsearch 生态。

一、概述

搜索正在成为 AI 应用的核心基础设施，agent 场景搜索需求爆发式增长。与传统搜索相比，Agent 场景的搜索有三个鲜明特点：

● 强租户化：一个用户 / 一个代码仓库 / 一个知识库就是一个独立检索库，租户数从万级走向亿级，且冷热极端倾斜——绝大多数长期沉睡，少数突发活跃。

● 极致规模化：Agent 需求爆发式增长，单租户的数据规模与租户数量被同步推高。系统要能随之持续扩展，规模越大，查询延迟与召回越不能下滑。

● 数据实时涌入、负载起伏大：代码提交、文档编辑随时产生新数据，写入即需可查；批量接入新租户时写入陡增，查询流量又随用户活跃大幅波动——写入与查询相互争抢、资源需求频繁伸缩。

以企业知识库为例：平台同时托管数百万个知识库，每个企业 / 团队就是一个独立检索库、文档更新后需秒级可查，但同一时刻只有少数知识库在被问答访问。客户真正需要的不是单次向量查询更快，而是知识库数量与文档量持续增长时检索性能依然稳定、活跃库新增文档秒级可查，占绝大多数的沉睡库几乎不产生成本。

这些特点叠加在一起，恰恰是传统检索架构难以承受的地方。

二、AI 应用面临的检索挑战

面对这样的负载，传统检索架构有四个瓶颈：

●  成本高：向量索引常驻内存、数据多副本，千亿向量需上万分片、100TB 以上内存；绝大多数租户长期沉睡，资源照付。

●  规模化能力弱：向量数据库租户上限数万，搜索引擎到十万级租户即瓶颈；大规模下检索劣化到秒级，召回率随数据量下滑。

●  弹性能力弱：扩缩容要搬数据，时间以小时计；故障靠副本重建，恢复慢。

●  读写互相影响：写入、建索引、合并与查询争抢同一批节点，写入洪峰引发查询抖动；

三、阿里云 ES 基于 OSS 的无状态多租户搜索方案

写入层、查询层、OSS 对象存储

● OSS 是唯一持久存储（数据、WAL 日志、元数据）；计算节点无状态，本地 Memory / SSD 只作缓存。

● 写入以 WAL 落 OSS 为确认点，确认即持久；建索引与合并全部后台异步。

● 查询经 Memory / SSD 两级缓存按需加载，只读目标租户的数据。

● 一个租户 = 一个 Slice，存储上物理聚簇；Slice Collection 把亿级租户自动分布到多组物理索引，业务只见一个集合名。

3.1 对比业界竞品

同一负载下，与自建 ES、开源 Milvus 的逐项对比

四、核心技术

逐项应对成本、规模化、弹性与读写互扰四大挑战

对象存储原生的存算分离：以 OSS 为唯一数据源，而非冷数据分层：数据单份存储，较多副本 SSD 降低一个数量级；不被访问的租户不占任何计算与缓存；多 Bucket 存储池突破单桶带宽上限。

磁盘原生向量索引 DiskBBQ：不走 HNSW"向量与图常驻内存"的路线：分层 K-means 聚簇 + BBQ 量化，查询最多探两层质心、按块顺序读取命中簇，IO 可预测，天然适配 SSD 缓存与对象存储。

租户级物理隔离与集合扩展：同一租户的倒排、向量、行存、列存聚簇为连续区间，查询、缓存、预热、清理都以租户为边界——单租户检索成本只取决于自身数据量。Slice Collection 把亿级租户分配到多组物理索引，统一入口、集中治理。

读写分离与 WAL 实时写入：写入层与查询层独立伸缩，写入洪峰不影响查询延迟，反之亦然；WAL 同步落 OSS 即确认，建索引与合并不占读写路径。

无状态计算与自动容灾：节点除缓存外无状态：扩容即接流量，缩容即回收，无数据搬迁；故障由替换节点从 OSS 接续；写入层整体不可用时索引自动转只读可查，查询不中断。

五、核心能力

● 成本：整体成本相比自建 ES 降低 70%；存储较多副本 SSD 降低一个数量级；不活跃租户零计算、零缓存成本。

● 规模：千亿级向量、亿级租户；

● 性能：召回率 ≥ 0.95，不随规模衰减；数据可按租户预热，冷查询首访后即转热。典型数据集下的查询延迟（P99）：

○ 向量检索（1024 维 · 10M 文档 · ~40GB）：热 ~30ms（1M）/ ~60ms（10M），冷 ~500ms（1M）/ ~1.5s（10M）。

○ 全文检索（BM25 · 10M 文档 · ~9GB）：热 ~20ms（1M）/ ~50ms（10M），冷 ~470ms（1M）/ ~700ms（10M）。

● 读写分离：读写路径独立扩缩，写入层不可用时查询不中断。

● 弹性：分钟级扩缩容，无数据搬迁，亚分钟级故障恢复。

● 完整搜索能力：全文、向量、过滤、聚合混合检索；租户级导入、预热、清理与秒级 copy-on-write 分支。

六、典型应用场景和实际案例

为海量租户、极端冷热倾斜的 AI 负载而生

●  企业知识库 / RAG：亿级知识库统一承载，活跃库毫秒级响应，沉睡库零成本。

●  AI Coding：每个代码仓库一个索引库，提交后秒级可检索；亿级仓库下单库延迟稳定。

●  Agent 记忆（Memory）：每个 agent / 会话独立记忆库，实时写入即查，海量 agent 下沉睡记忆零成本。

6.1 场景实例：某企业知识库

某企业知识库平台托管约 10 万个知识库、合计百亿级文档，需全文 + 向量混合检索，且 90% 以上长期冷置——少数库高频问答，绝大多数长期沉睡。

最佳实践

① 一个 SliceCollection 承载全部知识库：业务只面向一个 collection 名读写（PUT /_slice_collection/{name}），每个知识库就是一个 slice。

② 写入：沿用标准 ES API，用 _slice=<知识库 ID>（或 routing=<知识库 ID>）定位知识库，auto_create_slice 下首次写入自动建库：

③ 查询：_search?_slice=<知识库 ID> 只命中该知识库所在的 backing shard，单库检索成本只与自身数据量相关；跨库可传多 slice：

④ 缓存预热：对可预测访问（用户打开知识库时）用 POST /{collection}/_warm_slice?_slice=<知识库 ID> 主动预热。

成本和性能收益

七、总结与展望

本方案以 OSS 对象存储为唯一持久层，彻底解耦存储与计算，用一套统一架构同时化解了 Agent 时代检索面临的成本、规模、弹性与读写互扰四大难题：支撑亿级租户与千亿级向量、活跃库毫秒级响应，且成本只与活跃数据线性相关。它完全兼容 Elasticsearch 生态，全文、向量、过滤与聚合可混合检索，让业务无需在能力与成本之间取舍。

围绕这一底座，后续 Roadmap 将进一步释放对象存储原生架构的潜力：

● 秒级零拷贝分支（Branching）：基于 commit 的 copy-on-write 模型，为任意租户在常数时间内创建独立数据分支，不复制、不下载任何数据；创建后源库与分支读写互不影响，天然适配评测、灰度、A/B 与回滚。

● 自动弹性（Scale to Zero）：计算层随负载自动伸缩，空闲租户与集群可缩容至接近零，成本进一步向真实活跃负载对齐，把“不访问不付费”做到极致。

● 融入阿里云 Elasticsearch 生态：依托完整的 ES 生态能力，与 mem-0（Agent 记忆）、FalconSeek、SearchLake 等能力深度结合，构建面向 Agent 的一体化检索、记忆与数据底座。

郑重声明：此文内容为本网站转载企业宣传资讯，目的在于传播更多信息，与本站立场无关。仅供读者参考，并请自行核实相关内容。