amazon-web-services - 我们是否需要目录结构逻辑来在 Amazon S3/Cloudfront 上存储数百万张图像?

标签 amazon-web-services amazon-s3 amazon-cloudfront

为了支持数以百万计的潜在图像,我们之前遵循了这种目录结构:

/profile/avatars/44/f2/47/48px/44f247d4e3f646c66d4d0337c6d415eb.jpg

文件名经过 md5 哈希处理,然后我们提取字符串中的前 6 个字符并从中构建文件夹结构。

所以在上面的例子中文件名:
44f247d4e3f646c66d4d0337c6d415eb.jpg
产生一个目录结构:

/44/f2/47/

我们总是这样做是为了最大限度地减少任何单个目录中的照片数量,最终有助于文件系统性能。

然而,我们的新应用程序使用 Amazon S3 和 Cloudfront

我的理解是,您在 Amazon S3 上创建的任何文件夹实际上只是引用,而不是文件系统上的目录。

如果这是正确的,是否仍然建议拆分为上述文件夹/目录或类似方法?或者我们可以简单地在我们的应用程序代码中消除这种复杂性并提供像这样的图像链接:
/profile/avatars/48px/filename.jpg

请记住,此应用程序旨在提供数百万张照片中的十张。

任何指导将不胜感激。

最佳答案

尽管 S3 文件夹基本上只是编写 key 名称的另一种方式(正如@E.J.Brennan 在他的回答中已经说过的那样),但有理由考虑“文件夹”的命名结构。

根据您当前的照片数量以及可能的访问模式,考虑一种加速 S3 键名查找的方法可能是有意义的,确保对照片的操作分布在多个分区上。有一个great article on the AWS blog解释所有细节。

关于amazon-web-services - 我们是否需要目录结构逻辑来在 Amazon S3/Cloudfront 上存储数百万张图像?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/19541863/

相关文章:

java - 如何处理 AWS DynamoDB 中的空 Java 字符串集

android - Retrofit - 使用预签名 URL 将图像上传到 S3

hadoop - 使用 Hadoop 读取 s3 时出现 java.lang.NullPointerException(Scalding)

java - NoSuchMethodError : com. amazonaws.services.s3.model.S3ObjectInputStream.readAllBytes()

json - 使用 CloudFront 防止 Amazon S3 上的热链接

重建索引时,带有 Elasticsearch 的 Django haystack 找不到数据库

javascript - AWS Cognito - 离线数据可用性

amazon-web-services - AWS S3 内联显示文件而不是强制下载

node.js - Amazon CloudFront 能否接受 KMS 加密的 URL?

css - CloudFront、S3 和 Apache 的 CORS 配置问题