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

1. 概述

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

强租户化：一个用户 / 一个代码仓库 / 一个知识库就是一个独立检索库，租户数从万级走向亿级，且冷热极端倾斜——绝大多数长期沉睡，少数突发活跃。
极致规模化：Agent 需求爆发式增长，单租户的数据规模与租户数量被同步推高。系统要能随之持续扩展，规模越大，查询延迟与召回越不能下滑。
数据实时涌入、负载起伏大：代码提交、文档编辑随时产生新数据，写入即需可查；批量接入新租户时写入陡增，查询流量又随用户活跃大幅波动——写入与查询相互争抢、资源需求频繁伸缩。

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

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

2. AI 应用面临的检索挑战

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

💰 成本高：向量索引常驻内存、数据多副本，千亿向量需上万分片、100TB 以上内存；绝大多数租户长期沉睡，资源照付。
📉 规模化能力弱：向量数据库租户上限数万，搜索引擎到十万级租户即瓶颈；大规模下检索劣化到秒级，召回率随数据量下滑。
⚡ 弹性能力弱：扩缩容要搬数据，时间以小时计；故障靠副本重建，恢复慢。
🔀 读写互相影响：写入、建索引、合并与查询争抢同一批节点，写入洪峰引发查询抖动；

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

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

OSS 是唯一持久存储（数据、WAL 日志、元数据）；计算节点无状态，本地 Memory / SSD 只作缓存。
写入以 WAL 落 OSS 为确认点，确认即持久；建索引与合并全部后台异步。
查询经 Memory / SSD 两级缓存按需加载，只读目标租户的数据。
一个租户 = 一个 Slice，存储上物理聚簇；Slice Collection 把亿级租户自动分布到多组物理索引，业务只见一个集合名。

3.1 对比业界竞品

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

对比维度	自建 ES	开源 Milvus	本方案（阿里云 ES）
千亿向量成本	高（内存索引 + 多副本 + 运维）	高（按内存计价）	低（OSS 单份存储，冷租户零常驻）
租户规模	十万级即瓶颈	上限数万	亿级租户
大规模检索性能	劣化至秒级	劣化至秒级	毫秒级查询，召回稳定
读写隔离	无，互相影响	弱	读写分离，互不影响
弹性	小时级，需搬数据	运维复杂	分钟级，无数据搬迁
全文 + 过滤 + 聚合	完整	较弱	完整，且与向量检索混合

4. 核心技术

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

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

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

10×	平滑	2 层
索引构建速度约为 HNSW 的 10 倍	内存受限时性能平滑退化，HNSW 则断崖	查询最多探两层质心，IO 可预测

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

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

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

5. 核心能力

成本：整体成本相比自建 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 分支。

6. 典型应用场景和实际案例

为海量租户、极端冷热倾斜的 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 下首次写入自动建库：

# 单文档写入知识库 kb-42
PUT /kb-search/_doc/doc-1?_slice=kb-42
{ "title": "报销制度", "content": "……", "status": "published", "embedding": [0.02, 0.13, …] }
# 批量写入，每条 item 指定所属知识库
POST /_bulk
{ "index": { "_index": "kb-search", "_id": "d1", "_slice": "kb-42" } }
{ "title": "……", "content": "……", "embedding": [ … ] }
{ "index": { "_index": "kb-search", "_id": "d2", "_slice": "kb-87" } }
{ "title": "……", "content": "……", "embedding": [ … ] }

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

# 在知识库 kb-42 内做「全文 + 向量 + 过滤」混合检索
GET /kb-search/_search?_slice=kb-42
{
  "query": {
    "bool": {
      "must":   { "match": { "content": "如何申请报销" } },
      "filter": { "term":  { "status":  "published" } }
    }
  },
  "knn": {
    "field": "embedding",
    "query_vector": [0.03, 0.11, …],
    "k": 10,
    "num_candidates": 100
  }
}
# 跨多个知识库检索
GET /kb-search/_search?_slice=kb-42,kb-87
{ "query": { "match": { "content": "年假天数" } } }

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

成本和性能收益

7. 总结与展望

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

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

秒级零拷贝分支（Branching）：基于 commit 的 copy-on-write 模型，为任意租户在常数时间内创建独立数据分支，不复制、不下载任何数据；创建后源库与分支读写互不影响，天然适配评测、灰度、A/B 与回滚。
自动弹性（Scale to Zero）：计算层随负载自动伸缩，空闲租户与集群可缩容至接近零，成本进一步向真实活跃负载对齐，把“不访问不付费”做到极致。
融入阿里云 Elasticsearch 生态：依托完整的 ES 生态能力，与 mem-0（Agent 记忆）、FalconSeek、SearchLake 等能力深度结合，构建面向 Agent 的一体化检索、记忆与数据底座。

技术交流群：(群号) 35183864

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

1. 概述

2. AI 应用面临的检索挑战

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

3.1 对比业界竞品

4. 核心技术

5. 核心能力

6. 典型应用场景和实际案例

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

7. 总结与展望

检索分析服务 Elasticsearch版

热门文章

最新文章

相关电子书