1

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

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

图片/{userid}/{userid}_{md5(timestamp)}.jpg

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

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

4

3 回答 3

2

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

  • 不要在文件名中使用时间戳，因为您已经将文件名存储在数据库中，只需为时间戳 <-> 文件关系创建额外的列。这样可以更轻松地管理原始创建、上次修改甚至到期日期等内容。
  • 确保您存储的文件名的列是唯一的。您不想意外存储重复的文件名
  • 对文件的接受情况进行交叉检查。如果文件成功保存到服务器但查询失败，请确保在失败时删除文件。或者，如果您的操作顺序颠倒了，如果文件无法保存到服务器，请删除数据库中的条目。
  • 如果不允许公开访问图像，您可以拒绝正常查看图像，而是将用户引导至文件名作为 GET 变量的链接（PHP 文件）。然后您可以检查 SESSIONS 和/或 COOKIES 以确定他们是否有权查看它。如果是，您可以将输出的标题设置为 jpeg 或他们正在查看的任何类型的文件的标题。
于 2012-04-16T06:16:29.653 回答
0

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

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

user/{database_id}.jpg
于 2012-04-16T06:41:16.197 回答
0

有点取决于：

  • 每个用户有多少张图片？
  • 每张图片的大约尺寸范围？
  • 有多少用户？
  • 你期望什么样的并发？

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

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

那就是说...

如果在您的系统中，您希望用户上传大量文件，您可能会遇到文件系统的限制或性能问题。

如果您在 Windows 上托管，请注意8.3 文件名问题（当目录变大时非常慢），因为您的文件名肯定会比 8.3 长:)

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

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

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

Another question: will you always be serving out only the original image, or you'll send back re-scaled copies sometimes? You'd probably want to scale once and return the pre-scaled version always, in which case you'd need to take storage of those scaled copies into account too.

于 2012-04-16T07:09:06.033 回答