基于this resource向S3密钥添加伪随机前缀将增加您的GET性能而不是具有常量前缀。
这是表格的一个关键：
bucket/$randomPrefix-key.txt
在GET中的表现会比
更好 bucket/$date-key.txt
这也意味着公共前缀部分并不重要。来自文章：
您可以选择在哈希字符串之前的密钥名称中为组对象添加更多前缀。以下示例将动画/视频/前缀添加到键名称。
examplebucket /动画/ 232A-2013-26-05-15-00-00 / cust1234234 / animation1.obj examplebucket /动画/ 7b54-2013-26-05-15-00-00 / cust3857422 / animation2.obj examplebucket /动画/ 921C-2013-26-05-15-00-00 / cust1248473 / animation3.obj examplebucket /视频/ ba65-2013-26-05-15-00-00 / cust8474937 / video2.mpg examplebucket /视频/ 8761-2013-26-05-15-00-00 / cust1248473 / video3.mpg examplebucket /视频/ 2e4f-2013-26-05-15-00-01 / cust1248473 / video4.mpg examplebucket /视频/ 9810-2013-26-05-15-00-01 / cust1248473 / video5.mpg examplebucket /视频/ 7e34-2013-26-05-15-00-01 / cust1248473 / video6.mpg examplebucket /视频/ C34A-2013-26-05-15-00-01 / cust1248473 / video7.mpg ...
所以形式的关键
bucket/foo/bar/baz/$randomPrefix-key.txt
显然可以和（1）一样好用。
我的问题：如果伪随机前缀位于密钥的中间，该怎么办？这有效吗？
例如：
bucket/foo/bar/baz-$pseudoRandomString-key.txt
答案 0 :(得分：2)
您的示例与文档中的示例没有什么不同，原因很重要：斜杠/对S3没有内在意义。
S3中没有文件夹。 foo/bar.txt和foo/baz.jpg不在“同一文件夹中”。
从技术上讲，它们只是两个对象，其键具有共同的前缀。
控制台将它们显示在一个文件夹中，仅为了方便组织。
Amazon S3具有扁平结构，没有您在典型文件系统中看到的层次结构。但是，为了简化组织，Amazon S3控制台支持将文件夹概念作为对对象进行分组的方法。
http://docs.aws.amazon.com/AmazonS3/latest/UG/FolderOperations.html
此外：
Amazon S3数据模型本身不支持文件夹的概念，也不提供任何用于文件夹级操作的API。但Amazon S3控制台支持文件夹以帮助您组织数据。
http://docs.aws.amazon.com/AmazonS3/latest/UG/about-using-console.html
因此/对S3索引没有特殊意义，相对于随机前缀的位置没有特殊含义。
但是，随机前缀前的字符保持不变是很重要的，这样就可以在随机字符的开头就完成分区拆分。
S3必须能够分割以第一个随机字符开头的键列表，并在（<）左侧和（>=）右侧找到分割点的工作余额。
如果你有这个......
fix/ed/chars/here-then-$random/anything/here
...然后S3对自己说“嗯......看起来example-bucket/fixed/chars/here-then-*似乎占用了大量的流量，但看起来下一个角色总是0 1 2 3 4 5 6 7 8 9 abcdef并且它们非常平衡，所以我将它分成“8”，以便...then-0*到...then-7*在一个分区中并...then-8通过...then-f在另一个“和#boom中，潜在的性能瓶颈得以解决。
分区完全自动且透明。
以下是不的示例。
logs/2017-01-23/$random/...
logs/2017-01-24/$random/...
logs/2017-01-25/$random/...
在这里，热点每天都以不同的前缀形成，这使得S3没有很好的选择来创建有效的分区拆分以减轻任何过载。在这种情况下，任何拆分总是会在所有未来上传的左侧（词法上都小于） - 在某种程度上 - 所以不是有效的拆分。相比之下，上面的分割将工作量的一半<和另一半>=分成一个字符。
还值得注意 ...如果您不希望持续工作负载＆gt;至少100 req / sec，这根本不会给你带来任何好处。您的密钥空间中的自然随机性也可能足够，并且当与CloudFront结合使用时，S3读取可以基本上无限制地扩展而不进行这些优化（并且通常更快且通常稍微便宜，因为CloudFront带宽定价在某些区域略低于S3，可能是因为它减轻了潜力来自S3区域的因特网连接的因特网拥塞）。当S3连接到CloudFront时，S3将其带宽费用按$ 0.00 / GB Out计入Internet，而CloudFront按其费率而不是S3计费。