保存图像:文件还是blob？

Question

当你保存你的图像时(你有很多这样的图像)你会在数据库中存储为blob,还是作为文件存储？为什么？

Answer 1

我通常将它们存储为文件,并将路径存储在数据库中.对我来说,这比将它们作为blob推入数据库更容易,更自然.

将它们存储在数据库中的一个理由:完全备份要容易得多,但这取决于您的需求.如果您需要能够轻松获取数据库的完整快照(包括图像),那么将它们作为blob存储在数据库中可能就是要走的路.否则,您必须将数据库备份与文件备份配对,并以某种方式尝试将两者关联,这样,如果必须执行还原,则可以知道要还原哪一对.

Answer 2

这取决于图像的大小.

Microsoft Research有一个关于这个主题的有趣文档

该文档的摘要是文件系统(ntfs)对于大于1mb的文件往往表现更好,并且db对于小于1mb的文件(越小越好)表现越好. (13认同)
这篇论文是 2006 年的，现在是 11 年前。所以今天的情况可能会有所不同。实际上，结论是：“(...) 如果对象平均大于 1 MiB，则 NTFS 比 SQL Server 具有明显优势。如果对象小于 256 KiB，则数据库具有明显优势。在此范围内，这取决于 ...” (3认同)

Answer 3

我试图使用db(SQL Server和MySQL)来存储中(<5mb)文件,而我得到的是很多麻烦.

1)某些DB(SQL Server Express)具有大小限制;

2)一些DB(MySQL)变得非常慢;

3)当你必须显示一个对象列表时,如果你无意中做了SELECT*FROM表,那么大量数据会尝试从数据库中上下移动,导致响应速度慢或内存失败;

4)一些前端(ruby ActiveRecord)处理blob有很大的麻烦.

只需使用文件.不要将它们全部存储在同一目录中,使用某种技术将它们放在几个目录上(例如,您可以使用GUID的最后两个字符或int id的最后两个数字)然后将路径存储在db上.

Answer 4

数据库服务器的性能损失是一个没有实际意义的问题。如果您需要文件系统的性能优势，您只需在第一次请求时将其缓存在那里。然后可以通过直接链接直接从文件系统提供后续请求（对于 Web 应用程序，您可以在刷新输出缓冲区之前使用它重写 HTML）。

这提供了两全其美的：

没有必要为了不会一直变化的东西不断敲打数据库，但重要的是用户数据都在那里，而不是分散在不同的地方，使多服务器操作和部署变得一团糟。我一直提倡“数据库作为用户数据存储，除非”方法，因为它在架构上更好，并且有效缓存不一定更慢。

话虽如此，使用文件系统作为权威存储的一个很好的理由是当您确实需要使用外部独立工具来访问它时，例如 SFTP 等。