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

Question

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

1. 必须通过简单复制目录，文件等来防止盗窃。

2. 必须安全防范传统病毒感染（物理文件感染）

3. 必须快速取回

4. 临时（目录）浏览用户等不能看到该存储库。

我决定将所有文档（和扫描的图像）以blob的形式存储在数据库中，到目前为止，我的经验非常好，文档检索速度也非常快-符合上述所有条件，甚至还有一些其他优点，例如将文档及其相关实体一起自动存储，轻松快速地进行内容缓存，删除文档打开和命名周围的各种用户活动等。

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

编辑说明：DB是PostgreSQL，可以很好地处理BLOBS，并且伸缩性非常好。环境是多用户。

Answer 1

当您的数据库越来越大时，备份将变得越来越困难。还原具有超过100 GB数据的表的备份并不能使您满意。得到的另一件事是，所有表管理功能随着数据集的增长而越来越慢。但这可以通过使数据表仅包含2个字段来解决：ID和BLOB。（通过主键）检索数据很可能只会在您备份数据集遇到困难之后很长时间才成为问题。

Answer 2

我经常听到使用blob的主要缺点是，超过一定大小后，文件系统在存储和检索大文件方面效率更高。听起来您已经按照需求列表考虑了这一点。这里有一个很好的参考（PDF），涵盖了Blob的优缺点。

Answer 3

根据我的经验，一些问题是：速度与在文件系统上拥有文件的速度。缓存。IMO Web服务器将更好地缓存静态内容。DB也会做得很好，但是如果DB还处理其他各种查询，请不要期望那些大型文档会长时间保持缓存。实际上，您必须两次传输文件。一次是从DB到Web服务器，然后是Web服务器到客户端。内存限制。在我的上一份工作中，数据库中有40MB的PDF，并在日志文件中不断获取Java OutOfMemoryErrors。最终，我们认识到整个80MB PDF不仅被读入了堆，而且由于休眠ORM中的设置而被读入了TWICE（如果一个对象是可变的，它会在内存中进行编辑）。将PDF流式传输回用户后，便清理了堆，但一次仅从流中提取80MB只是用于流式传输文档，这是一个很大的打击。了解您的代码以及如何使用内存！您的Web服务器应该能够处理您的大多数安全问题，但是如果文档很小并且DB尚未承受很大的负载，那么将它们放入DB中并没有太大的问题。