当搜索索引搬上 S3,架构如何重塑?

What changes when your search index lives on S3?

当搜索索引搬上 S3,架构如何重塑?

在 Infino,我们构建检索引擎以应对 Agent 的大规模查询需求。传统搜索引擎如 Lucene 依赖本地磁盘,假设随机读取成本极低,但将索引迁移至 S3、GCS 或 Azure Blob Storage 后,每一次随机读取都意味着昂贵的网络往返。因此,我们的设计核心从优化 CPU 和字节转向极致减少网络请求。通过引入 Superfile 单文件架构、预缓存元数据的 Manifest 以及全局 Term Index,我们实现了按需读取和智能跳过。即使面对海量数据,查询也能精准定位,避免无效请求,让对象存储上的搜索既快又经济。

在对象存储上构建搜索引擎时,最稀缺的资源并非 CPU 或字节,而是你向对象存储发起的往返次数。
  1. mlhpdx

    将反向索引与大型聚合日志对象一同存放在 S3 上,这已经是一种行之有效的模式,沿用超过十年了。将对象存储在廉价访问模式,而将索引存储在访问成本更低的模式中,其成本效益远超大多数其他方案(廉价的 S3 克隆版除外)。

    我手头最早实现这一模式的代码似乎可以追溯到 2012 年。

    计算与存储的分离真是个绝妙的模式。

  2. MattPalmer1086

    好吧,它确实回答了技术层面的问题:当你把搜索索引放到更慢、更昂贵的存储上时,会发生什么变化——但它没有解释你为什么要这么做。

  3. tilt_error

    这难道不就是 Elasticsearch 的可搜索快照(searchable snapshots)吗?

同日更多故事

2026-10-17