要做还是不做：将图像存储在数据库中

Question

要做还是不做：将图像存储在数据库中

在Web应用程序的上下文中，我的老板总是说要在数据库中引用图像，而不是图像本身。我倾向于同意在DB中存储url与映像本身是一个好主意，但在我现在工作的地方，我们在数据库中存储了很多图像。

我能想到的唯一原因也许是它更安全？你不想有人和网址有直接联系？但是，如果是这样的话，您总是可以让网站/服务器处理图像，就像ASP.NET中的处理程序一样，这样用户就需要进行身份验证才能查看图像。我还认为从数据库中提取图像会影响性能。为什么将图像存储在数据库中可能是一个好/不太好的主意，还有其他原因吗？

Answer 1

如果你偶尔需要检索图像，它必须在几个不同的Web服务器上可用。但我想差不多就是这样了。如果它不必在多个服务器上可用，最好将它们放在文件系统中。如果它必须在多个服务器上可用，而且系统中实际上有某种负载，那么您将需要某种分布式存储。我们在这里讨论的是一个边缘案例，您可以通过利用数据库来避免给系统增加额外的复杂性。除此之外，别这么做。

Answer 2

在数据库中放置图像的优点。交易。当您保存BLOB时，您可以像任何其他DB数据一样提交它。这意味着您可以将BLOB与任何关联元数据一起提交，并确保两者是同步的。如果磁盘空间用完了呢？不承诺。文件没有完全上传？不承诺。愚蠢的应用错误？不承诺。如果保持映像及其相关的元数据相互一致对您的应用程序很重要，那么DB可以提供的事务可能是一件好事。一个要管理的系统。需要备份元数据和BLOB吗？备份数据库。需要复制吗？复制数据库。需要从部分系统故障中恢复吗？重新加载DB并向前滚动日志。DBS给一般数据带来的所有优点(卷映射、存储控制、备份、复制、恢复等)适用于你的斑点。更一致，更容易管理。保安。数据库具有非常细粒度的安全特性，可以利用这些特性。模式、用户角色，甚至是诸如“只读视图”之类的东西，以提供对数据子集的安全访问。所有这些特性都适用于包含气泡的表。集中管理与#2相关，但基本上DBA(似乎没有足够的能力)可以管理一件事情：数据库。现代数据库(特别是大型数据库)可以很好地工作，可以跨几台机器安装大型数据库。单一的管理来源简化了程序，简化了知识转移。大多数现代数据库都处理得很好。有了数据层中BLOB的一级支持，就可以轻松地将BLOB从DB流到客户端。虽然有些操作可以同时“吸”整个BLOB，但如果您不需要该工具，那么就不要使用它。研究DB的SQL接口并利用它的特性。没有理由把它们当作“大字符串”，它们被一刀切地处理，然后把你的气泡变成大的、记忆的、吞食的、高速缓存的炸弹。就像您可以为图像设置专用文件服务器一样，您也可以在数据库中设置专用的BLOB服务器。为它们提供专用磁盘卷、专用模式、专用缓存等。DB中的所有数据都不是相同的，行为也不一样，没有理由对其进行完全相同的配置。良好的数据库具有良好的控制水平。从DB提供BLOB的主要NIT是确保HTTP层实际利用所有HTTP协议来执行服务。许多简单的实现只是抓取BLOB，然后将它们从套接字中大量丢弃。但是HTTP有几个非常适合流图像的重要特性，特别是缓存头、eTags和块传输，以允许客户端请求BLOB的“片段”。确保您的HTTP服务正确地响应了所有这些请求，并且您的DB可以是一个非常好的Web公民。通过将文件缓存到由HTTP服务器提供服务的文件系统中，您可以“免费”获得其中的一些优点(因为一个好的服务器无论如何都会对“静态”资源这样做)，但是要确保如果这样做，就必须遵守修改日期等图像的要求。例如，有人请求Spaceeshuttle.jpg，这是2009年1月1日创建的图像。最终缓存在请求日期的文件系统上，比如2009年2月1日。稍后，图像将从缓存(FIFO策略或其他什么)中清除，稍后，有人在2009年3月1日再次请求它。现在它有了2009年3月1日的“创建日期”，尽管它的创建日期实际上是1月1日。所以，您可以看到，特别是如果您的缓存发生了很大的变化，使用if修改的头的客户端可能会获得比他们实际需要的更多的数据，因为服务器认为资源已经改变了，而实际上它没有改变。如果将缓存创建日期与实际创建日期保持同步，这可能会减少问题。但关键是，要想成为一个“优秀的网络公民”，并为你和你的客户节省一些带宽等，就必须仔细考虑整个问题。我刚刚为一个为DB提供视频的Java项目进行了所有这些工作，这一切都很好。