将文档作为 Blob 存储在数据库中 - 有什么缺点吗？
https://stackoverflow.com/questions/211895
-
03-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian题
我的文档管理系统的要求是：
- 必须通过简单的目录、文件等复制来防止被盗。
- 必须能够抵御传统病毒感染（物理文件感染）
- 必须快速检索
- 临时（目录）浏览用户等不能看到存储库。
我决定将所有文档（和扫描图像）作为 blob 存储在数据库中，到目前为止，我的体验非常好，文档检索也快得令人眼花缭乱 - 它满足上面的所有标准，甚至还有一些额外的优点，例如自动存储文档及其相关实体、轻松快速地搜索内容、删除围绕打开和命名文档的各种用户活动等。ETC。
我的问题是 - 在这种设计和实施中是否存在任何严重的风险或我忽略的事情？
编辑注意：DB 是 PostgreSQL，可以很好地处理 BLOBS 并且扩展性非常好。环境是多用户。
解决方案
当您的数据库变得越来越大时，备份将变得更加困难。 恢复超过100 GB数据的表的备份并不会让您满意。
另一件事是，随着数据集的增长，所有表管理功能都变得越来越慢 但这可以通过使您的数据表只包含2个字段来克服： ID和BLOB。
检索数据（通过主键）可能只会在您通过备份数据集进入墙后很长时间内成为问题。
其他提示
我经常听到使用blob的主要缺点是，超过一定大小，文件系统在存储和检索大文件方面效率更高。听起来你已经把这个考虑在你的要求清单中了。
这里的好参考资料（PDF）涵盖专业人士和斑点的缺点。
根据我的经验，一些问题是：
速度与文件系统上有文件的比较。
缓存。IMO Web服务器将在缓存静态内容方面做得更好。数据库也将做得很好，但是如果数据库也递给其他各种疑问，请不要期望这些大型文件会长时间持续。你 基本上必须将 文件两次。从数据库到 网络服务器，然后将网络服务器转到 客户。
内存限制。在我上一份工作中，我们的数据库中有一个 40MB 的 PDF，并且日志文件中不断出现 Java OutOfMemoryErrors。我们最终意识到，由于 Hibernate ORM 中的设置，整个 80MB PDF 不仅被读入堆一次，而且两次（如果对象是可变的，它会在内存中创建一个副本以进行编辑）。PDF 流式传输回用户后，堆就被清理了，但是为了流式传输文档而一次从堆中吸出 80MB 是一个很大的打击。了解您的代码以及内存的使用方式！
您的网络服务器应该能够处理您的大部分安全问题，但是如果文档很小并且数据库还没有承受很大的负载，那么我认为将它们放在数据库中并不是什么大问题。
我刚刚开始研究SQL Server 2008的BLOB的FILESTREAMing并且遇到了巨大的限制（IMO） - 它只适用于集成安全性。如果不使用Windows身份验证连接到数据库服务器，则无法读取/写入BLOB。许多应用程序环境无法使用Windows身份验证。当然不是在异构环境中。
必须存在更好的存储BLOB的解决方案。什么是最佳实践？
这取决于数据库类型。 Oracle还是SQLServer？请注意一个缺点 - 恢复单个文档。
抱歉 - 我提供的答案基于SQL Server，因此维护部分不合适。但文件I / O是在硬件级别完成的，任何数据库都会增加额外的处理步骤。
检索文档时，数据库会产生额外的开销。当文件在磁盘上时，您只能像服务器上的I / O一样慢或快。您当然应该在数据库中管理您的元数据，但最终您需要文件的UNC并指向用户 来源并走开。
从维护和管理角度来看，在处理MS SQL Server时，您将自己限制为SAN。像Documentum这样的解决方案采用不同的方法在磁盘上进行简单存储，并允许您根据需要实施存储解决方案。
修改
让我澄清一下我的陈述 - 使用SQL Server，当你超过盒子的物理存储容量时，你的选项有限。事实上，这是Sharepoint的一大弱点，您无法简单地连接任何类型的网络存储。
根据我在SQL Server和Oracle中将内容文件存储为blob的经验，可以使用小型数据库和少量登录用户。 ECM系统将它们分开并为流内容使用单独的服务。根据文件的大小，可以同时检索大文件来影响服务器资源。由于恢复时间和无法从存档中检索文档，存档包含大量文件的数据库会出现问题。
如果这些文件是公司记录，并且这是记录的权威副本，则可能存在合规性和保留管理问题，尤其是在归档文件时。此外，搜索和版本控制可能会成为一个巨大的问题。
您可能想要使用某种API调查ECM系统，而不是重新发明轮子。
