在包含大量键的 S3 存储桶中，通过 REST api 列出键是一个非常缓慢的过程，因为
鉴于制作 100 个并发键列表 REST 请求不应减慢任何单个请求的速度，否则此过程将成熟，可以通过并行化进行优化。但是如果我的算法是“愚蠢的”并且只是将可能的密钥空间拆分为预定义的标记（例如，''，'a'，'b'，'c'，'d'，'e'...... ) 它不会真正加快在每个键都以“images/”开头的存储桶中列出键的速度
所以我想知道是否有人真正体验过 S3 知道更好的方法来遍历存储桶的密钥空间，或者是否有人尝试过自适应（即“不愚蠢”）算法来改进并发密钥列表。
也许某种形式的“二分搜索”算法会有所帮助？EG 以 '' 和 'm' 的前缀开始，然后是中途，等等。我认为您最终最多会获得每个键两次左右 - 当您已经拥有 'nextmarker' 时，您不再要求更多。
如何选择从多少开始？我认为也许在每个周期细分：启动 '' 然后当这些结果返回时，如果 '' 结果表明更多键，则在该搜索中启动 'nextmarker' 加上在 'nextmarker' 和 'z' 之间的新搜索. 重复。使用类似哈希的东西只存储一次所有密钥。
由于所有请求都来自不同的线程等，因此您需要锁定才能添加所有密钥。然后你有一个问题是保持锁足够打开不会减慢速度，所以这取决于你使用的语言等。
如果您的进程在与 S3 文件位于同一区域的 EC2 实例上运行，您可能能够更快地完成此操作。假设文件是美国“标准”。那么你很幸运，你可以使用 ruby 和 Ironworker 之类的东西进入那里并下载所有密钥。完成后，它可以发布到您的服务器，或在 S3 上创建一个文件，该文件是所有密钥的列表，或类似的列表。对于不同的区域或语言，您可能必须启动自己的 EC2 实例。
我发现在 EC2 实例上列出 S3 密钥要快得多，因为每个请求都有大量带宽（您无需在 EC2 上付费）。S3 不会压缩响应，这些响应是超级蓬松的 XML，因此您和 S3 之间的带宽至关重要。