导读基于 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 的逐项对比对比维度自建 ES开源 Milvus本方案阿里云 ES千亿向量成本高内存索引 多副本 运维高按内存计价低OSS 单份存储冷租户零常驻租户规模十万级即瓶颈上限数万亿级租户大规模检索性能劣化至秒级劣化至秒级毫秒级查询召回稳定读写隔离无互相影响弱读写分离互不影响弹性小时级需搬数据运维复杂分钟级无数据搬迁全文 过滤 聚合完整较弱完整且与向量检索混合四、核心技术逐项应对成本、规模化、弹性与读写互扰四大挑战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 接续写入层整体不可用时索引自动转只读可查查询不中断。五、核心能力成本整体成本相比自建 ES 降低 70%存储较多副本 SSD 降低一个数量级不活跃租户零计算、零缓存成本。规模千亿级向量、亿级租户性能召回率 ≥ 0.95不随规模衰减数据可按租户预热冷查询首访后即转热。典型数据集下的查询延迟P99向量检索1024 维 · 10M 文档 · ~40GB热 ~30ms1M/ ~60ms10M冷 ~500ms1M/ ~1.5s10M。全文检索BM25 · 10M 文档 · ~9GB热 ~20ms1M/ ~50ms10M冷 ~470ms1M/ ~700ms10M。读写分离读写路径独立扩缩写入层不可用时查询不中断。弹性分钟级扩缩容无数据搬迁亚分钟级故障恢复。完整搜索能力全文、向量、过滤、聚合混合检索租户级导入、预热、清理与秒级 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下首次写入自动建库# 单文档写入知识库 kb-42PUT /kb-search/_doc/doc-1?_slicekb-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?_slicekb-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?_slicekb-42,kb-87{query:{match:{content:年假天数}}}④ 缓存预热对可预测访问用户打开知识库时用POST /{collection}/_warm_slice?_slice知识库 ID主动预热。成本和性能收益七、总结与展望本方案以 OSS 对象存储为唯一持久层彻底解耦存储与计算用一套统一架构同时化解了 Agent 时代检索面临的成本、规模、弹性与读写互扰四大难题支撑亿级租户与千亿级向量、活跃库毫秒级响应且成本只与活跃数据线性相关。它完全兼容 Elasticsearch 生态全文、向量、过滤与聚合可混合检索让业务无需在能力与成本之间取舍。围绕这一底座后续 Roadmap 将进一步释放对象存储原生架构的潜力秒级零拷贝分支Branching基于 commit 的 copy-on-write 模型为任意租户在常数时间内创建独立数据分支不复制、不下载任何数据创建后源库与分支读写互不影响天然适配评测、灰度、A/B 与回滚。自动弹性Scale to Zero计算层随负载自动伸缩空闲租户与集群可缩容至接近零成本进一步向真实活跃负载对齐把“不访问不付费”做到极致。融入阿里云 Elasticsearch 生态依托完整的 ES 生态能力与 mem-0Agent 记忆、FalconSeek、SearchLake 等能力深度结合构建面向 Agent 的一体化检索、记忆与数据底座。