关于S3 API ListObjectV2（带delimiter）的成本与性能机制问询

场景背景 #

我有一个存储了数十亿文件的大型S3存储桶，采用类文件系统的层级结构组织。关注类似ls操作的性能，比如执行等效于ls /的命令：

$ aws s3api list-objects-v2 --bucket my-huge-bucket --delimiter /
{
    "CommonPrefixes": [
        {
            "Prefix": "dir1/"
        },
        {
            "Prefix": "dir2/"
        }
    ],
    "RequestCharged": null
}

文件系统中执行ls /只需遍历根inode关联的子inode，无需扫描所有对象即可响应，但S3通过包含/的对象键实现“虚拟目录”，无inode概念，因此有以下两个疑问：

1. 执行带delimiter参数的ListObjectV2操作成本是多少？
2. 该操作性能如何？S3后台是否会扫描所有对象键来计算当前路径的下一级目录，还是仅处理根目录开头的前缀？

一、操作成本 #

• 请求次数计费：ListObjectsV2属于S3标准API请求，按请求次数计费。单次调用算1次请求；如果返回的一级前缀数量超过1000（S3默认单页返回上限），则需要分页请求，每一次分页调用都单独计费。
• 数据传输成本：仅传输返回的CommonPrefixes列表及少量响应元数据，不会传输对象实际内容，数据传输成本极低，可忽略不计。
• 无额外存储成本：该操作仅读取S3内部维护的对象键索引，不会产生额外存储费用。

二、性能与后台实现 #

S3不会扫描存储桶中的所有对象键，而是基于内部的分布式键索引做高效前缀匹配：

• S3的对象键按字典序存储在分布式索引中，当指定delimiter=/且未设置prefix（默认根路径）时，S3会直接在索引中查找所有以第一个/为分隔的前缀，仅遍历到第一个/的位置就停止，快速聚合出所有一级虚拟目录（即CommonPrefixes）。
• 这种实现类似数据库的前缀索引查询，性能不会随存储桶内对象总数线性下降。即使是数十亿对象的存储桶，根目录的一级前缀查询也能在毫秒级完成（只要一级前缀数量不多）。
• 若一级前缀数量超过1000触发分页，后续分页请求依然是基于索引的范围查询，不会全量扫描所有对象。

内容的提问来源于stack exchange，提问作者João Pedro Schmitt