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

我的文件管理系统的要求是:

必须通过简单复制目录,文件等来防止被盗.

必须安全抵御传统病毒感染(物理文件的感染)

必须快速检索

访问者(目录)浏览用户等不得看到存储库.

我决定将所有文档(和扫描图像)作为blob存储在数据库中,到目前为止,我的经验非常棒,文档检索也非常快 - 它符合上述所有标准,甚至还有一些额外的优点,例如,将文档与其相关的实体一起自动存储,轻松快速地搜索内容,删除各种用户活动,包括打开和命名文档等.

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

编辑注意:DB是PostgreSQL,非常好地处理BLOBS并且非常好地扩展.环境是多用户.

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

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

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

我经常听到使用blob的主要缺点是,在一定大小以上,文件系统在存储和检索大文件方面效率更高.听起来你已经把这个考虑在你的要求列表中了.

这里有一个很好的参考(PDF),涵盖blob的优缺点.

根据我的经验,一些问题是:

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

缓存.IMO Web服务器可以更好地缓存静态内容.数据库也会做得很好,但如果数据库也在处理各种其他查询,那么不要指望这些大型文档会长时间保持缓存状态.你基本上必须传输两次文件.一旦从DB到Web服务器,然后从Web服务器到客户端.

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

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