存储少量图像：blob或fs？

Question

我正在向我的网站添加一些功能，以便用户可以上传自己的个人资料图片，所以我想知道是将它们作为BLOB存储在数据库中，还是将它们放在文件系统中。

我在这里发现了一个类似这样的问题：Storing images in DB: Yea or Nay，但给出的答案更多地针对期待成千上万乃至数百万图像的人，而我更关心的是小图像（JPEG可能高达150x150像素）以及其中的一小部分：可能高达一两千。

对于这种情况，DB BLOB vs Filesystem有什么感受？客户端如何从数据库缓存图像或从文件系统缓存图像？

如果存储在DB中的BLOB是要走的路 - 有什么我应该知道的关于的地方要存储它们吗？由于我想大多数用户不会上传图片，因此在需要时，我应该创建user_pics表（外部）加入常规users表吗？

---

编辑：我重新打开了这个问题，因为它不是那些您连接到两个的副本。这个问题具体是关于使用数据库或FS用于少量图像的优点/缺点。正如我上面所说，另一个问题是针对那些需要存储成千上万张大型图像的人。

Answer 1

要回答你的问题的部分：

如何客户缓存图像去从DB VS从文件系统？

对于数据库：在数据库中有一个last_modified字段。使用Last-Modified HTTP标头，以便客户端的浏览器可以正确缓存。当浏览器请求一个图像“if newer”（不能记起它所谓的;一些HTTP请求标头）时，一定要发送适当的响应。

对于文件系统：执行相同的操作，但文件的修改时间相同。

如果存储在数据库中的BLOB是要走的路 - 有什么我应该知道在哪里存储它们？因为我想大多数用户不会上传图片，我应该在需要时创建一个user_pics表（外部）加入常规用户表吗？

我会把BLOB和相关的元数据放在它自己的表中，它与你的用户表之间有某种关系。这样做可以更轻松地为数据优化表存储方法，使事情更加整洁，并为可扩展性留下空间（例如，一般的“文件”表）。

Answer 2

从提供服务，编写代码服务于他们，备份过程等角度来看，更方便吗？你想给你正确的答案，而不是别人的正确答案。

Answer 3

从我的角度来看，任何可能留在数据库之外的东西都应该留在外面。它可能是文件系统或单独的表，您不需要每天复制或备份。它使数据库变得更轻，增长更慢，更容易理解和维护。

如果您在MSSQL上，请确保blob存储在单独的数据文件中。不像其他一切一样在主体上。

Answer 4

在Windows上，尽可能多地放入数据库。文件系统有点慢，有时甚至不可靠。

在Linux上，您有更多选项。在这里，您应该考虑将大文件移动到文件系统中，并将名称保存在数据库中。如果您使用Ext3或ReiseFS等现代文件系统，您甚至可以创建许多性能相当不错的小文件。

您还需要考虑如何访问数据。如果您拥有数据库中的所有内容，则您拥有一条访问路径，无需担心另一组权限，但您必须处理读取/写入BLOB的额外复杂性。在许多DB中，BLOB不能被搜索。

在文件系统上，您可以在您的数据上运行其他工具，如果这些文件存储在数据库中，则这是不可能的。

Answer 5

我曾经遇到过一个类似的问题，用于一个小型的DMS文件。该场景与您的场景不同：最多可能是100个文件，每个文件的大小最多为10 MB，而不是您对个人资料照片的期望值。但朋友给我的回答也适用于您的情况：

使用每个存储系统来设计它的目的。

商店数据在数据库。商店文件在文件系统。

这不是最终答案（*），但它对初学者来说是一个很好的经验法则。

我从来没有听说过Windows FS缓慢，有时不可靠，正如Aaron Digulla在他的回答中所述。如果存在这样的问题，这当然需要考虑。但是对于头像图片来说，这并不意味着我很重要。

（*）我知道，我知道，42 ...

Answer 6

我将它们存储在数据库中：

1. 备份/恢复是容易的（如果你的备份文件，并在数据库中，时间点恢复更加复杂）
2. db中的交易意味着你永远不应该指向一个不存在的文件名
3. 更少的机会有人会想出一个鬼鬼祟祟的方式来放置一个脚本到你的服务器上，通过一个狡猾的图像上传黑客

由于您在谈论少量图像，因此易用性/管理应优先考虑链接问题中讨论的性能问题。

Answer 7

我认为存在将它们存储在数据库中的可管理性优势;他们可以备份并与其他数据一致地恢复 - 您不会忘记删除过时的（可能，但可能性稍差），并且如果将数据库迁移到另一台计算机，则图像将随它。