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

Question

我们正在开展一个项目，我们将构建一个完整的后端CMS系统，该系统将通过一个软件包为整个外联网和内部网提供支持。我一直试图找到答案的问题是哪个更好：在数据库中存储图像（SQL Server 2005），以便我们可以拥有完整性，单一复制计划等，或者存储在文件系统上？

我们遇到的一个问题是我们有多台服务器负载均衡，需要始终拥有相同的数据。截至目前，我们有SQL复制处理，但文件复制似乎有点困难。我们关注的另一个问题是我们希望拥有相同图像的多个分辨率，我们不确定在文件系统上创建和存储每个版本是最好的还是可以动态地拉动并创建我们想要的分辨率图像。

我们关注的是：

• 数据完整性
• 数据复制
• 多种分辨率
• 数据库与文件系统的速度
• 数据库与文件系统的间接负载
• 数据管理和备份

是否有人有类似的情况或对推荐的内容有任何意见？在此先感谢您的帮助！

Answer 1

微软研究院发表了一篇名为To Blob or not to Blob的好的研究论文，他们研究了各种变量和影响。

他们最终的发现：

• 最大256 KB，blob比文件系统中的存储更有效率
• 对于1 MB或更大，文件系统更高效
• 介于它之间是一个折腾

自该论文发布以来，SQL Server 2008还添加了FILESTREAM属性，该属性使得在文件系统中存储东西，但在事务控制下，这是一个现实。强烈建议你检查一下！

Answer 2

此问题经常出现 - 请参阅this搜索结果。

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

个人 - 保留数据库中的文件路径和文件系统上的文件。每个人都有自己的优势。您可以备份文件和数据库。这也是管理数据TB的this guy的结论。

Answer 3

静态文件的复制可能难以管理，特别是在许多服务器上。它实际上归结为管理，监视和调试复制问题与数据库大小和负载之间的权衡。

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

在数据库中存储路径的建议缺少真正的问题，即在多台计算机上复制这个问题。

Answer 4

你的担忧分解为两个阵营。以下问题有利于在数据库中存储文档：

• 数据完整性
• 数据复制
• 多种分辨率
• 数据管理和备份

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

• 数据库与文件系统的速度
• 数据库与文件系统的间接负载

因此，决定最重要的事情，并做出相应的选择。

Answer 5

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

你还有其他观点：

• Integrity - DB，这就是存在数据库与平面文件系统的原因。

• 复制 - 不确定您是否意味着图像复制，但如果是这样，那么显然是DB，因为您肯定不会对此进行负载平衡。

• 可以从DB映像执行多种分辨率，但这会增加处理成本。此外，分辨率越高，大小越大，网络等待的时间越长。多种分辨率以空间换取速度。

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

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

• 管理层，DB，请放下。奇异存储=不用担心，在任何情况下都应始终在数据库上运行备份。多个服务器上的文件系统备份在很多方面都很昂贵。

Answer 6

辩论的任何一方都有有效的担忧，所以总是提出你的要求。有多少数据，有多少图像，多大？

内联/ BLOB存储

上行：简化架构和实施，简化系统的备份和恢复或迁移;只需执行转储，备份，导出（无论您的DB风格如何），并将其移动到新数据库。版本控制/一致性由DB处理，因此允许进行时间点恢复。安全/访问控制也更清晰，因为访问图像BLOB是访问整个行所固有的。将图像移出数据库并让HTTP服务器获取它，同时更好地实现并发性和可伸缩性，可能会遇到问题，确保人们无法破解URL并请求他们不拥有的图像。如果您将它们放在数据库之外，请确保您的安全策略涵盖用户之间图像的访问控制。您的HTTP服务器身份验证必须与整个系统的身份验证集成，或者提供映像的HTTP服务器程序使用某种会话机制来确保HTTP请求有效。这是多租户数据库中非常重要的问题。单一用途，单租户系统中的问题较少，只需简单的身份验证。

下行：对于真正非常大的数据库，备份和恢复变得令人沮丧，甚至成问题和代价高昂，因为如果你可能有一个小的核心数据集，你可能有很多GB或TB图像数据。从完整性的角度来看，将它作为一个一致的数据库处理是好的，但对于备份是不利的，除非您使用具有企业质量的DBMS，数据仓库调优的备份和恢复（例如Oracle RMAN和滚动备份）。

始终考虑在任何系统中恢复的时间。如果您的存储要求是＆lt;几千兆字节，甚至50-100GB甚至，你有足够的备份空间计划，内联存储更清洁。除此之外，关注点的分离和让文件系统完成其工作成为关键优势。没有什么比尝试恢复，恢复和打开一个巨大的数据库更糟糕的是为了小数据错误。恢复时间将是我最关心的问题。

Answer 7

通常，就CMS而言，在DB中持久保存图像数据可能不如FileSystem有效。有时您可能只想静态显示图像，有时您希望图像设计师可以使用该图像进行更新等。

考虑每次使用它时检索图像时的处理开销。

为什么你应该考虑FileSystem

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

Answer 8

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

下载到文件系统

- 不会自动复制

- 通过为每个实例提供不同的物理位置，可能会使复制变得复杂

- 减少了大量文件

文件系统的优势

- 如果你要存储一些非常大的文件，它会表现得更好。

Answer 9

我愿意;

1）为每个图像分配唯一标识符（GUID） 2）使用该GUID标记/命名图像 3）在操作系统（文件系统）中存储GUID 4）在数据库中存储完全限定文件名（FQN）指针。

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

Answer 10

我不会出于某种原因将图像存储在数据库中（我的答案来自sql server）：

我不希望SQL Server数据缓存由网站的简单图像填充。我希望数据缓存实际上有数据。此外，如果你有一个多层架构，它传递一个图像的URL要比一团二进制数据更容易。如果您只想让某些人看到图像（安全性），那么您遇到问题的地方。