将文档作为Blob存储在数据库中 - 有什么缺点吗？

Question

我的文档管理系统的要求是：

1. 必须通过简单复制目录，文件等来防止盗窃。
2. 必须安全抵御传统病毒感染（物理文件感染）
3. 必须快速检索
4. 访问者（目录）浏览用户等不得看到存储库。

我决定将所有文档（和扫描图像）作为blob存储在数据库中，到目前为止我的体验非常棒，文档检索也非常快 - 它符合上面的所有标准，甚至有几个其他优点，例如自动存档文档及其涉及的实体，简单快速的内容搜索，删除各种用户活动，打开和命名文档等。

我的问题是 - 这个设计和实施是否存在任何我忽略的严重风险或事情？

编辑注意：DB是PostgreSQL，非常好地处理BLOBS并且非常好地扩展。环境是多用户。

Answer 1

当您的数据库变得越来越大时，备份将变得更加困难。 恢复超过100 GB数据的表的备份并不会让您满意。

另一件事是，随着数据集的增长，所有表管理功能都变得越来越慢 但这可以通过使您的数据表只包含2个字段来克服：  ID和BLOB。

检索数据（通过主键）可能只会在您通过备份数据集进入墙后很长时间内成为问题。

Answer 2

我经常听到使用blob的主要缺点是，超过一定大小，文件系统在存储和检索大文件方面效率更高。听起来你已经把这个考虑在你的要求清单中了。

有一个good reference (PDF) here涵盖blob的优点和缺点。

Answer 3

根据我的经验，有些问题是：

1. 速度与文件系统上的文件。

2. 缓存。 IMO Web服务器 将更好地缓存 静态内容。 DB会做一个 干得好，但如果DB也是 处理各种其他查询， 不要指望那些大文件 保持缓存。您 基本上必须转移 文件两次。一旦从DB到 Web服务器，然后Web服务器 客户端。

3. 内存限制。在我上一份工作中，我们在数据库中有一个40MB的PDF，并且在日志文件中不断获得Java OutOfMemoryErrors。我们最终意识到整个80MB的PDF不仅被读入堆中，而且由于Hibernate ORM中的设置而被TWICE读取（如果一个对象是可变的，它会在内存中进行编辑）。一旦PDF被传回给用户，堆就被清理干净了，但是为了流式传输文件，一次只能从堆中吸出80MB。了解您的代码以及如何使用内存！

您的Web服务器应该能够处理您的大多数安全问题，但是如果文档很小并且数据库尚未承受很大的负担，那么我真的没有看到将它们放在数据库中的大问题

Answer 4

我刚刚开始研究SQL Server 2008的BLOB的FILESTREAMing并且遇到了巨大的限制（IMO） - 它只适用于集成安全性。如果不使用Windows身份验证连接到数据库服务器，则无法读取/写入BLOB。许多应用程序环境无法使用Windows身份验证。当然不是在异构环境中。

必须存在更好的存储BLOB的解决方案。什么是最佳实践？

Answer 5

此article涵盖了大部分问题。如果您使用的是SQL Server 2008，请查看Paul Randal here所讨论的新FILESTREAM类型的使用。

Answer 6

这取决于数据库类型。 Oracle还是SQLServer？请注意一个缺点 - 恢复单个文档。

Answer 7

抱歉 - 我提供的答案基于SQL Server，因此维护部分不合适。但文件I / O是在硬件级别完成的，任何数据库都会增加额外的处理步骤。

检索文档时，数据库会产生额外的开销。当文件在磁盘上时，您只能像服务器上的I / O一样慢或快。您当然应该在数据库中管理您的元数据，但最终您需要文件的UNC并指向用户 来源并走开。

从维护和管理角度来看，在处理MS SQL Server时，您将自己限制为SAN。像Documentum这样的解决方案采用不同的方法在磁盘上进行简单存储，并允许您根据需要实施存储解决方案。

修改

让我澄清一下我的陈述 - 使用SQL Server，当你超过盒子的物理存储容量时，你的选项有限。事实上，这是Sharepoint的一大弱点，您无法简单地连接任何类型的网络存储。

Answer 8

根据我在SQL Server和Oracle中将内容文件存储为blob的经验，可以使用小型数据库和少量登录用户。 ECM系统将它们分开并为流内容使用单独的服务。根据文件的大小，可以同时检索大文件来影响服务器资源。由于恢复时间和无法从存档中检索文档，存档包含大量文件的数据库会出现问题。

如果这些文件是公司记录，并且这是记录的权威副本，则可能存在合规性和保留管理问题，尤其是在归档文件时。此外，搜索和版本控制可能会成为一个巨大的问题。

您可能想要使用某种API调查ECM系统，而不是重新发明轮子。