Question

我正在构建一个后端来接受用户上传的图像，重命名它们并将它们存储在文件系统中（不，它不是Instagram）

我在考虑简单地重命名图像并存储在用户文件夹中：

图像/ {用户ID} / {用户id} _ {MD5（时间戳）}。JPG

这些关联也将包含在数据库中。

这是一个好/充足的模型吗？

Answer 1

基本上你的方法很好，但这是我给你的建议：

不要使用文件名中的时间戳，因为您已经将文件名存储在数据库中，只需为时间戳创建额外的列＆lt; - ＆gt; 文件关系。这样就更容易管理像原始的东西创建，最后修改，甚至到期日期。
确保您存储的文件名列是唯一的。你不想意外地存储重复的文件名
对接受文件进行交叉检查。如果文件成功保存到服务器但查询失败，请确保删除文件失败。或者，如果您的操作顺序颠倒过来，请删除如果文件无法保存到服务器，则为DB中的条目。
如果不允许公开访问图像，则可以拒绝正常查看图像，而是将用户引导至链接（PHP文件），文件名为GET变量。然后你可以检查SESSIONS和/或COOKIES以确定它们是否有权使用查看它。如果是，则可以设置输出的标题他们正在查看的jpeg或任何类型的文件。

Answer 2

为什么不使用数据库中的唯一ID，这样可以更容易地找到文件。

它也不限制你的文件结构，也许你不会总是想用用户名保存，如果每个文件都有一个绑定到数据库的ID，这可能会简单得多。

user/{database_id}.jpg

Answer 3

有点取决于：

如果上面的大部分数字都很小，那么你的方法可能会很长，以便让你有一个很长的路要走，并且至少会让你开始。

我知道使用MySQL blob存储获取bad press，但这也是一种简单的入门方式，您可以对数据库进行分片以获得一些扩展，而无需进行任何巧妙的编码。 / p>

那说......

如果在您的系统中，您希望用户上传大量文件，则可能会遇到limits or performance issues文件系统。

如果您在Windows上托管，请注意8.3 filename problem（当目录变大时非常慢），因为您的文件名肯定会超过8.3：）

如果许多人同时上传/下载 - 比如在高峰使用期 - 你将需要注意I / O争用。如果您使用的是RAID 10卷，那么您将获得更多，并且更好地使用SSD（但那时您可能会遇到存储容量问题）。

如果有可能相同的图像可能被不同的人上传（在多个文件夹中复制），那么您建议的方法将不是最节省空间的，在这种情况下，您最好通过以下功能进行键控：数据（例如md5sum）并且只存储一个副本（是的，然后存在删除管理问题）。

如果您期望来自许多人的大量图像，您最终将不得不考虑扩展底层存储。您可以通过不同卷或机器上的{userid}和分片的某些功能对数据进行分区。这也会为您带来更好的并发吞吐量。

另一个问题：您是否始终只提供原始图像，或者您有时会发回重新缩放的副本？您可能希望缩放一次并始终返回预缩放版本，在这种情况下，您还需要考虑这些缩放副本的存储。