当搜索索引搬上 S3,架构如何重塑?
What changes when your search index lives on S3?

在 Infino,我们构建检索引擎以应对 Agent 的大规模查询需求。传统搜索引擎如 Lucene 依赖本地磁盘,假设随机读取成本极低,但将索引迁移至 S3、GCS 或 Azure Blob Storage 后,每一次随机读取都意味着昂贵的网络往返。因此,我们的设计核心从优化 CPU 和字节转向极致减少网络请求。通过引入 Superfile 单文件架构、预缓存元数据的 Manifest 以及全局 Term Index,我们实现了按需读取和智能跳过。即使面对海量数据,查询也能精准定位,避免无效请求,让对象存储上的搜索既快又经济。
在对象存储上构建搜索引擎时,最稀缺的资源并非 CPU 或字节,而是你向对象存储发起的往返次数。
HN 评论区
12- mlhpdx
将反向索引与大型聚合日志对象一同存放在 S3 上,这已经是一种行之有效的模式,沿用超过十年了。将对象存储在廉价访问模式,而将索引存储在访问成本更低的模式中,其成本效益远超大多数其他方案(廉价的 S3 克隆版除外)。
我手头最早实现这一模式的代码似乎可以追溯到 2012 年。
计算与存储的分离真是个绝妙的模式。
- MattPalmer1086
好吧,它确实回答了技术层面的问题:当你把搜索索引放到更慢、更昂贵的存储上时,会发生什么变化——但它没有解释你为什么要这么做。
- tilt_error
这难道不就是 Elasticsearch 的可搜索快照(searchable snapshots)吗?