数据库与文件系统中的图像

StackOverflow https://stackoverflow.com/questions/2517752

题

我们将有一个项目即将到来，我们将建立一个整个后端CMS系统，该系统将用一个包装为整个外部网络和Intranet提供动力。我一直试图找到答案的问题是：在数据库中存储图像（SQL Server 2005），因此我们可能具有完整性，单个复制计划等或存储在文件系统上？

我们遇到的一个问题是，我们有多个服务器负载均衡，始终需要具有相同的数据。到目前为止，我们已经有了SQL复制来解决这个问题，但是文件复制似乎更加困难。我们担心的另一个问题是，我们想拥有相同图像的多个分辨率，我们不确定在文件系统上创建和存储每个版本是否是最好的，或者是动态拉动并创建我们希望根据要求的分辨率图像。

我们的担忧是以下内容：

  • 数据的完整性
  • 数据复制
  • 多个决议
  • 数据库与文件系统的速度
  • 数据库与文件系统的高架负载
  • 数据管理和备份

有人有类似情况还是对建议的内容有任何意见？在此先感谢您的帮助！

没有正确的解决方案

其他提示

Microsoft Research发表了一篇不错的研究论文，称为 要斑点或不斑点 他们查看各种变量和影响的地方。

他们的发现最终：

  • 比文件系统更有效地存储在数据库中256 kb的大小，斑点存储在数据库中
  • 对于1 MB和更大的文件，文件系统更有效
  • 在两者之间是一个折腾

自该论文发表以来，SQL Server 2008还添加了FileStream属性，该属性使存储在文件系统中，但在交易控制下，现实。强烈建议您检查一下！

这个问题经常出现 - 看到 这个 因此搜索结果。

没有一个正确的答案 - 这取决于情况。

亲自 - 将文件路径保留在DB和文件系统上的文件中。每个人都有自己的优势。您可以备份文件以及数据库。这也是 这家伙, ，谁管理数据。

静态文件的复制，尤其是在多个服务器上，很难管理。这确实取决于管理，监视和调试复制问题与数据库大小和负载之间的权衡。

我想我可能会选择数据库方法，如果加载成为问题，请考虑在图像调用周围提出某种缓存层。

在DB中存储路径的建议缺少真正的问题，该问题正在跨多个计算机复制。

您的担忧分为两个营地。以下问题偏爱数据库中的存储文档：

  • 数据的完整性
  • 数据复制
  • 多个决议
  • 数据管理和备份

这些问题（可能）有利于在文件系统上存储文档：

  • 数据库与文件系统的速度
  • 数据库与文件系统的高架负载

因此，确定最重要的事情并相应地选择。

好吧，如果您的前两个需求是完整性和复制，那么答案肯定是DB。

但是，您的其他要点：

  • 完整性-DB，这就是为什么数据库存在与平面文件系统的原因。

  • 复制 - 不确定您是否是指图像复制，但是如果是的，则显然是DB，因为您肯定不会负载平衡。

  • 可以从数据库图像执行多种决议，但是这增加了处理成本。同样，分辨率越高，大小越大，网络等待的时间就越长。多个分辨率将速度交易。

  • 速度 - 根据访问图像的访问，可能可以忽略不计。如果您在文件共享中拍摄图像，则在任何情况下都必须在网络上等待，并且网络几乎总是瓶颈。

  • 开销 - 坦率地说，这取决于您对开销的定义以及如何访问图像。

  • 管理，DB，放下手。单数存储=一个少的担心，无论如何，您应该始终在数据库上运行备份。在多种方面，多个服务器上的文件系统备份成本高昂。

辩论的两边都有有效的问题，因此请始终提供您的要求。多少数据，多少图像，有多少数据？

内联 /斑点存储

上升: ：简化体系结构和实现，简化系统的备份，恢复或迁移；只需做一个转储，备份，导出（无论您的DB风味如何），然后将其移至新数据库。版本控制 /一致性由DB处理，因此允许时间恢复。安全 /访问控制也更加干净，因为访问图像BLOB是访问整个行的固有的。将图像在数据库外移动，并让HTTP服务器获取它，而更好地提高了并发性和可扩展性，可以在确保人们无法破解URL和请求他们不拥有的图像方面存在问题。如果您确实在数据库外容纳它们，请确保您的安全策略涵盖了用户之间图像的访问控制。您的HTTP服务器身份验证必须与整体系统的身份验证集成，或者您的HTTP服务器程序使用图像的HTTP服务器程序使用某种会话机制来确保HTTP请求有效。在多租户数据库中，这是一个非常重要的关注点。在单一目的的单租户系统中，没有简单的身份验证。

缺点: ：对于非常大的数据库，备份和恢复会变得令人沮丧，甚至有问题和成本高昂，因为在您可能拥有一个小的核心数据集的地方，否则您可能会有许多GB或TB的图像数据。从完整性的角度来看，将其视为一个一致的数据库都很好，但是除非您使用具有企业质量的DBMS，否则备份不利，数据仓库调谐备份和恢复（示例是Oracle RMAN和Rolling Backups）。

始终考虑在任何系统中恢复的时间。如果您的存储要求是<几GB，例如50-100GB，并且计划了大量的备份空间，则在线存储更加干净。首先，关注点的分离并让文件系统完成工作成为关键优势。为了造成小数据错误，试图恢复，恢复和打开一个巨大的数据库更糟糕的是。恢复时间将是我最大的担忧。

通常，就CMS而言，数据库中的持续图像数据可能不如文件系统那样有效。一次，您可能只想静态地显示图像，而其他时候您希望该图像可用于图形设计人员以获取更新等。

考虑每次要使用它时，请考虑与检索图像相关的处理开销。

几点为什么您应该考虑文件系统

  1. 浏览器可以完成所有工作，而您从图像的代理缓存等中受益
  2. 作为上述分支，您可以轻松地使用内容交付网络（CDN）
  3. 使用rsync等工具，复制图像数据很容易
  4. 处理（IE CPU）时间已大大优化

假设您在Windows环境中，没有很好的理由使用文件系统。您可能需要小心地将图像存储在表中以避免不需要的页面拆分，但这是性能调整，不是一个大问题。

文件系统的缺点

- 不自动复制

- 可能通过在每个实例中拥有不同的物理位置来使复制复杂化

-slow拥有大量文件

文件系统的好处

- 如果您存储一些非常大的文件，则可以更好地执行。

我会;

1）将唯一标识符（GUID）分配给每个图像2）标签/使用该GUID 3）在OS（文件系统）中存储GUID 4）在数据库中存储完全合格的文件名（FQN）指针。

在存储和维护方面，将图像存储在数据库中太昂贵。仅存储FQN指针将提供更好的解决方案。您还可以通过触发器和一些存储过程来构建后端完整性检查。

我不会出于一个原因将图像存储在数据库中（我的答案来自SQL Server）：

我不希望该网站的简单图像填充的SQL服务器数据缓存。我希望数据缓存实际上有数据。另外，如果您拥有多层体系结构，则与二进制数据相比，将URL用于图像更容易。但是，如果您只希望某些人查看图像（安全性），那么您确实会遇到问题。

许可以下： CC-BY-SA 和 归因
不隶属于 StackOverflow
scroll top