数据库设计和图像文件系统管理？ [关闭]答案

【问题标题】：Database design and image file system management? [closed]数据库设计和图像文件系统管理？ [关闭]
【发布时间】：2012-04-16 15:09:06
【问题描述】：

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

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

images/{userid}/{userid}_{md5(timestamp)}.jpg

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

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

【问题讨论】：

【解决方案1】：

基本上你的方法还不错，但是我给你的建议是：

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

【讨论】：

我认为用时间戳存储文件名是一个好习惯，因为它会使所有文件名都是唯一的。
这是真的，但我想我的意思是不要依赖它们来获得准确的时间戳。但我想如果它们是 md5 无论如何你都不能：P 无论如何，使用 rand() 生成随机字符串比 md5(time()) 性能更好
我会使用没有 md5() 的时间戳，这在所有情况下都是唯一的。
在流量足够大的网站上，时间戳不一定是唯一的。
@TobyAllen 感谢您指出这一点。我没想到。

【解决方案2】：

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

此外，它不限制您构建文件的方式，也许您不会总是希望通过用户名保存，如果每个文件都有一个与数据库相关联的 ID，这可能会简单得多。

user/{database_id}.jpg

【讨论】：

【解决方案3】：

有点依赖：

如果上述大多数数字都很小，那么您的方法可能会持续足够长的时间，让您走得更远，并且至少可以让您开始。

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

也就是说……

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

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

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

如果有可能由不同的人上传相同的图像（跨多个文件夹重复），您建议的方法将不是最节省空间的方法，在这种情况下，您最好使用数据（例如 md5sum）并仅存储一份副本（是的，然后删除存在管理问题）。

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

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

【讨论】：