图片上传存储策略

Question

当用户将图像上传到我的网站时,图像会经历此过程;

• 用户上传图片
• 在db中存储pic元数据,为图像提供唯一ID
• 异步图像处理(缩略图创建,裁剪等)
• 所有图像都存储在同一个上传文件夹中

到目前为止,该网站非常小,上传目录中只有大约200,000张图片.我意识到我远远不及目录中文件的物理限制,但这种方法显然无法扩展,所以我想知道是否有人对上传/存储策略有任何建议来处理大量的图像上传.

编辑: 创建用户名(或更具体地说,用户ID)子文件夹似乎是一个很好的解决方案.通过更多的挖掘,我在这里找到了一些很棒的信息; 如何在您的文件系统中存储图像
但是,如果将CDN购买到等式中,这个用户ID方法是否会很好地扩展？

Answer 1

我以前回答了类似的问题,但我找不到,也许OP删除了他的问题......

无论如何,到目前为止,Adams解决方案似乎是最好的,但它不是防弹的,因为images/c/cf/(或任何其他目录/子目录对)仍然可以包含多达16 ^ 30个独特的哈希值,如果我们计算图像扩展名,则至少可以包含 3倍的文件,比任何常规文件系统都能处理的要多得多.

AFAIK,SourceForge.net也将此系统用于项目存储库,例如"fatfree"项目将放置在projects/f/fa/fatfree/,但我相信它们将项目名称限制为8个字符.

我会将图像哈希与DATE/ DATETIME/ TIMESTAMP字段一起存储在数据库中,以指示图像上传/处理的时间,然后将图像放在如下结构中:

images/
  2010/                                      - Year
    04/                                      - Month
      19/                                    - Day
        231c2ee287d639adda1cdb44c189ae93.png - Image Hash

要么:

images/
  2010/                                    - Year
    0419/                                  - Month & Day (12 * 31 = 372)
      231c2ee287d639adda1cdb44c189ae93.png - Image Hash

除了更具描述性之外,这个结构足以容纳数十万(取决于你的文件系统限制)的图像每天数千年,这是Wordpress和其他人这样做的方式,我认为他们在这方面做得对一.

可以在数据库上轻松查询重复的图像,您只需创建符号链接即可.

当然,如果这对您来说还不够,您可以随时添加更多子目录(小时,分钟......).

我个人不会使用用户ID,除非您的数据库中没有该信息,因为:

1. 在URL中公开用户名
2. 用户名是易变的(您可以重命名文件夹,但仍然......)
3. 用户可以假设上传大量图像
4. 没有用处(？)

关于CDN,我认为这个方案(或任何其他方案)没有任何理由不起作用......

Answer 2

MediaWiki生成上传文件名称的MD5总和,并使用MD5的前两个字母(例如,"c"和"f"之和"cf1e66b779​​18167a6b6b972c12b1c00d")来创建此目录结构:

images/c/cf/Whatever_filename.png

您还可以使用映像ID获取每个目录的文件数的可预测上限.也许需要floor(image unique ID / 1000)确定父目录,每个目录1000个图像.