保存图像：文件还是 blob？答案

【问题标题】：Saving images: files or blobs?保存图像：文件还是 blob？
【发布时间】：2010-11-23 18:20:59
【问题描述】：

当您保存图像时（假设您有很多图像），您是在数据库中存储为 blob 还是文件？为什么？

重复：Storing Images in DB - Yea or Nay?

【问题讨论】：

【解决方案1】：

我通常将它们存储为文件，并将路径存储在数据库中。对我来说，这是一种比将它们作为 blob 推入数据库更容易、更自然的方法。

将它们存储在数据库中的一个论点是：进行完整备份要容易得多，但这取决于您的需要。如果您需要能够轻松地获取数据库（包括图像）的完整快照，那么将它们作为 blob 存储在数据库中可能是可行的方法。否则，您必须将数据库备份与文件备份配对，并以某种方式尝试将两者关联起来，这样如果您必须进行恢复，您就知道要恢复哪对。

【讨论】：

如果你有一个 web 应用程序，文件是要走的路，你可以使用来自数据库的路径信息构建 HTML，该路径信息指向存储在客户端浏览器将从中下载的文件.
我正在构建一个离线应用程序。我发现存储 blob 可以轻松复制数据库。只是一个想法！
我编写了一个小型运输系统并将图像粘贴到数据库中。一旦它变得很大，数据库备份就会变得非常有问题（30,000 个图像）。最终，数据库和任何返回图像的查询都停止了。数据库引擎 SQL 服务器出现严重问题，必须清除查询缓存来修复它。最后我最终重构了它。添加一些磁盘管理是值得的，我再也不会将图像粘贴到 SQL Server 数据库中。
如果文件更好，那么我该如何保护它们呢？同样，我存储了非常敏感的信息 ss#、银行对账单、纳税申报表等。这更多是我的问题。如果我可以获得所需的安全级别，我不介意使用文件。基于下面的 cmets，获得我需要的安全性的最佳方法是 blob，即使以速度为代价。请指教。

【解决方案2】：

如果我在一台 Web 服务器上运行并且只会在一台 Web 服务器上运行，我会将它们存储为文件。如果我在多个 webheads 上运行，我将图像的引用实例放入数据库 BLOB 并将其作为文件缓存在 webheads 上。

【讨论】：

【解决方案3】：

这取决于图像的大小。

微软研究院对此主题有一个interesting document

【讨论】：

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

【解决方案4】：

Blob 在 db/scripts 上可能很重，为什么不只存储路径。我们使用 blob 的唯一原因是它是否需要合并复制或资产的超严格安全性（例如除非登录或其他情况，否则无法提取图像）

【讨论】：

对你来说，我需要“超严密的安全性”。所以我认为像纳税申报表这样的安全文件是最好的，不是吗？那么所有非安全项目（如图像等）都可能在一个文件夹中？

【解决方案5】：

鉴于您可能希望将图像连同名称、简要说明、创建日期、创建者等一起保存，您可能会发现保存在数据库中会更好。这样，一切都在一起了。如果您保存了相同的信息并将图像存储为文件，您将不得不从两个地方检索整个“图像对象”......并且在路上，您可能会发现自己遇到同步问题（找不到某些图像） .希望这是有道理的。

【讨论】：

【解决方案6】：

保存是指使用它们在网页或类似内容中显示？如果是这种情况，更好的选择是使用文件，如果您使用数据库，它将不断受到照片请求的影响。而且这种情况不能很好地扩展。

【讨论】：

没有图片。这些只是与交易相关的文件，因此每次有人访问该网站时都不会提取任何内容，例如徽标或其他东西。这些是客户文件，只有在专业人员或客户试图查看它们时才会被拉下。

【解决方案7】：

我尝试使用 db（SQL Server 和 MySQL）来存储中等（

1) 一些 DB (SQL Server Express) 有大小限制；

2) 一些数据库（MySQL）变得非常缓慢；

3）当你必须显示一个对象列表时，如果你不小心做了SELECT * FROM table，大量的数据会尝试从db中上下，导致响应缓慢或内存失败；

4) 一些前端（ruby ActiveRecord）在处理 blob 时遇到了很大的麻烦。

只使用文件。不要将它们全部存储在同一个目录中，使用一些技术将它们放在多个目录中（例如，您可以使用 GUID 的最后两个字符或 int id 的最后两个数字），然后将路径存储在 db 中。

【讨论】：

你在SELECT * FROM table 上卖给了我——我定期使用它进行测试，仅此一项就可能让我非常头疼。文件给我！

【解决方案8】：

问题是，您的应用程序是否像处理其他应用程序数据一样处理 BLOBS 或其他文件？您的用户是否将图像与其他数据一起上传？如果是这样，那么您应该将 BLOB 存储在数据库中。它可以更轻松地备份数据库，并在出现问题时恢复到事务一致的状态。

但是，如果您指的是属于应用程序基础结构而不是用户数据的图像，那么答案可能是，不。

【讨论】：

【解决方案9】：

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

这提供了两全其美：

权威商店是数据库，保持事务性和参照完整性
您可以通过以下方式部署所有用户数据只需部署数据库
清空此缓存（例如，通过添加 Web 服务器）只会导致临时性能受到打击自动重新填充。

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

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

【讨论】：

虽然我个人仍然使用基于文件的系统，但我认为这是一个非常好的答案。

【解决方案10】：

使用文件系统更好，因为在将图像存储为 blob 时将提供的基本功能是 1. 图像不需要的可变性，因为我们不会更改图像的二进制数据，我们将只删除整个图像 2. 索引搜索：图片不需要索引，因为图片的内容不能被索引，索引搜索搜索的是BLOB的内容。

在这里使用文件系统是有益的，因为 1.它更便宜 2. 使用CDN快速访问

因此一种方法是将图像存储为文件并在数据库中提供其路径

【讨论】：

【解决方案11】：

我建议选择文件系统。首先，让我们讨论一下为什么不是 Blob？因此，要回答这个问题，我们需要思考 DB 相对于文件系统为我们提供了哪些优势？

可变性：我们可以修改存储后的数据。 不适用图片。图像只是一系列 1 和 0。每当我们更改图像时，都不会更改几个 1 和 0，因此，修改相同的图像内容是没有意义的。最好是删除旧的，并存储新的。
索引：我们可以创建索引以加快搜索速度。但它不适用于图像，因为图像只是 1 和 0，我们无法对其进行索引。

那为什么是文件系统？

更快的访问：如果我们将图像存储在数据库中的 Blob 中，那么获取完整记录的查询 (select *) 将导致查询的性能非常差，因为大量的数据将进出数据库。相反，如果我们只是将图像的 URL 存储在 DB 中，并将图像存储在分布式文件系统 (DFS) 中，它会快得多。
大小限制：如果 DB 存储图像，并且图像很多很多，那么它可能会面临性能问题，并且会达到其内存限制（很少有 DB 有）。

【讨论】：