40

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

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

我们的担忧是：

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

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

4

10 回答 10

59

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

他们最终的发现：

  • 最大 256 KB，blob 存储在数据库中的效率高于文件系统
  • 对于 1 MB 或更大，文件系统更高效
  • 在这两者之间是一个折腾

自那篇论文发表以来，SQL Server 2008 还添加了 FILESTREAM 属性，这使得将内容存储在文件系统中，但在事务控制下成为现实。强烈建议您检查一下！

于 2010-03-25T17:17:36.787 回答
6

这个问题经常出现 - 查看这个SO 搜索结果。

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

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

于 2010-03-25T17:17:09.050 回答
5

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

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

将路径存储在数据库中的建议缺少真正的问题，即在多台机器上复制它。

于 2010-03-25T17:23:59.990 回答
3

辩论的任何一方都有合理的担忧，因此请始终提出您的要求。多少数据，多少图像，多大？

内联/BLOB 存储

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

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

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

于 2010-03-25T17:30:42.037 回答
3

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

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

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

  • 数据库与文件系统的速度
  • 数据库与文件系统的开销

所以，决定什么是最重要的，并做出相应的选择。

于 2010-03-25T17:19:03.617 回答
2

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

你的其他观点：

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

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

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

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

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

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

于 2010-03-25T17:15:25.493 回答
2

一般来说，就 CMS 而言，将图像数据保存在数据库中的效率可能不如文件系统。有时您可能只想静态显示图像，有时您希望图形设计师可以使用该图像进行更新等。

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

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

  1. 浏览器完成所有工作，您可以从图像的代理缓存等中受益
  2. 作为上述的一个分支，您可以轻松使用内容交付网络 (CDN)
  3. 使用 rsync 等工具可以轻松复制图像数据
  4. 处理（即 CPU）时间被大幅优化
于 2010-03-25T18:03:53.093 回答
1

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

我不希望由网站的简单图像填充 SQL Server 数据缓存。我希望数据缓存中实际包含数据。此外，如果您有多层架构，则传递图像的 URL 比传递二进制数据块要容易得多。如果您只希望某些人看到图像（安全性），那么您确实会遇到问题。

于 2010-03-25T17:28:51.400 回答
1

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

文件系统的缺点

- 不会自动复制

- 通过为每个实例设置不同的物理位置，可能会使您的复制复杂化

- 文件数量非常多时速度慢

文件系统的优势

- 如果您要存储一些非常大的文件，它的性能会更好一些。

于 2010-03-25T17:16:36.273 回答
1

我会;

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

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

于 2010-03-25T17:18:00.650 回答