Question

我正在创建一个网站，要求为每个用户上传个人资料图片以及调整大小的版本。我将使用mysql存储图像的ID和其他信息。我不想要重新安排静态文件，所以我们假设这个网站有数千个用户。我想知道存储图像的最佳目录结构是什么？

我之前已经看过几种提到过的方法：

1）md5（image_id），如果散列是49f68a5c8493ec2c0bf489821c21fc3b，则结构为/ 49 / f6 / 8a / 5c / 84/93 / ec / 2c / 0b / f4 / 89/82 / 1c / 21 / fc / 3b.jpg（或..... 3b / filename.jpg）。这种方式似乎能够处理很多，但看起来它可能会创建一些太多的目录。可能是这种方法的变种？

2）/年/月/日/（可能是小时）/id.jpg

那该怎么办？

Answer 1

在这样的独特哈希上向下钻取子目录是一个很好的解决方案，但是示例中的子目录数方式太多。每两个字符子目录可以支持256个条目，所以如果你将拥有5000个用户，那么当你只需要一个深度时，每个子目录只能获得大约20个文件，这是完全合理的。两层深度可以轻松处理数百万用户。

另外，我不会将文件名剪切为散列中的剩余字符。使用文件名的完整哈希，无论你走多少级别。如果您需要（例如）将文件移动到新商店，文件将更容易管理。即，不要这样做：

49/f68a5c8493ec2c0bf489821c21fc3b.jpg

这样做：

49/49f68a5c8493ec2c0bf489821c21fc3b.jpg

Answer 2

我通常将密钥存储在图像记录旁边的数据库中，格式如下：

userid/md5(image_id)_time.ext

这很好，因为它可以让人们在不做大量工作的情况下“窃取”整个系列。此外，它还有助于命名冲突，以防您更新原始图片并希望将“旧”图片存储一段时间（这在某些情况下可能是有益的）。此外，您可以将其设置为永不过期，因为您永远不会再次更新它。您可能会定期进入并刷新“旧”文件，但这是一个不同的问题。

Answer 3

如果我使用文件名存储图像只是一个id，我倾向于使用以下结构;

/0/1.jpg
/500/501.jpg
/1000/1001.jpg
/1500/1501.jpg

想法是创建不超过500个图像的文件夹，并将基本文件夹编号为起点。这不需要任何特殊的DB字段或散列，您可以选择多于或少于500。

Answer 4

图片/ md5的前两个字符（user_id）/ user_id / * .jpg

这样你就没有包含数千个其他文件/目录的目录，并且避免使用过多的嵌套树

e.g。

images/a9/1000/foo.jpg
images/a9/1000/bar.jpg
images/a9/107/baz.jpg
images/1f/24/goo.jpg

处理大量上传图像的最佳目录结构是什么？

4 个答案: