我们是否需要目录结构逻辑来在 Amazon S3/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

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

任何指导将不胜感激。

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

根据您当前的照片数量以及可能的访问模式,考虑一种加快 S3 键名查找速度的方法可能是有意义的,确保对照片的操作分布在多个分区上。AWS 博客上有一篇很棒的文章解释了所有细节。

您不需要在 s3 上设置该结构,除非您是为了自己的方便而这样做。您在 s3 上创建的所有文件夹对您来说实际上都只是一种错觉,文件存储在一个大的连续容器中,因此如果您没有理由在伪文件夹层次结构中组织文件,请不要打扰。

如果您需要根据文件夹结构控制对不同人群的访问,这可能是保留结构的原因,但除此之外可能没有好处/

相关内容

最新更新