我使用amazon s3作为存储用户configuration文件图片。 我发现许多网站会生成大量的随机文件名，并将它们放在同一个根目录中，如：
http://xxx.us-east-1.amazonaws.com/aHR0cHM6Ly9mYmNkbi1wcm9maWxlLWEuYWthbWFpaGQubmV0L2hwcm9maWxlLWFrLWFzaDIvMjczMzkxXzEwMDAwMDMxMjAxMzg5OV81NTk3MjM4Mzdfbi5qcGc.jpg 而我的问题是：这种方法有什么优点和缺点？
如果我把它们放在不同的目录中，我将来会遇到什么问题？
http://xxx.us-east-1.amazonaws.com/users/id/username.jpg
要么
http://xxx.us-east-1.amazonaws.com/users/id/random_number.jpg
谢谢！
正如你使用S3，文件的数量不应该是一个问题。 但是，请考虑当您需要手动查找单个文件时会发生什么情况。在浏览器中列出一些gazillion文件将不会很有趣。
因此，对于这种情况，您应该有一些“可人工浏览”的树结构，最终的子目录包含合理数量的文件。
我build议要么扩大和分裂的ID（假设它是数字）或前缀分裂的用户名。
ID示例：
id1 = 123 id1_expanded = 000/000/000/123 http://xxx.us-east-1.amazonaws.com/users/000/000/000/123/username.jpg id2 = 1000002 id2_expanded = 000/001/000/002 http://xxx.us-east-1.amazonaws.com/users/000/001/000/002/username.jpg
用户名示例：
username1 = luccas http://xxx.us-east-1.amazonaws.com/users/l/lu/luc/luccas/random_number.jpg username2 = ukautz http://xxx.us-east-1.amazonaws.com/users/u/uk/uka/ukautz/random_number.jpg
在任何情况下，为存储结构devise发明的大部分策略都试图解决在S3中根本没有的问题：每个目录的文件数量，跨存储服务器分片……类似的东西。
编辑 ：你所描述的长文件名往往是出于“安全”的原因 – >只要你不使用一个algorithm从用户名+编号派生它，所以文件和特定用户之间的任何关系被隐藏（只给出文件名）。 再次：使用某种子目录策略（由于上述原因）。
这取决于你要使用多less图像。 如果您的应用程序使用数百万的图像，则最好将它们集群到另一台服务器上，以便负载均衡。 您还可以根据用户configuration文件的types划分图像。 根据类别放置所有用户configuration文件。 在一天结束的时候，你只需要知道你的服务器如何负载平衡请求。 这只是理论上的假设。 具有硬件和图片数量的说明是有意义的。