我的文檔管理系統的要求是：必須通過簡單復制目錄，文件等來防止盜竊。必須安全防范傳統病毒感染（物理文件感染）必須快速取回臨時（目錄）瀏覽用戶等不能看到該存儲庫。我決定將所有文檔（和掃描的圖像）以blob的形式存儲在數據庫中，到目前為止，我的經驗非常好，文檔檢索速度也非常快-符合上述所有條件，甚至還有一些其他優點，例如將文檔及其相關實體一起自動存儲，輕松快速地進行內容緩存，刪除文檔打開和命名周圍的各種用戶活動等。我的問題是-在此設計和實現中是否存在任何嚴重的風險或我忽略的事情？編輯說明：DB是PostgreSQL，可以很好地處理BLOBS，并且伸縮性非常好。環境是多用戶。
3 回答
喵喔喔
TA貢獻1735條經驗 獲得超5個贊
當您的數據庫越來越大時，備份將變得越來越困難。還原具有超過100 GB數據的表的備份并不能使您滿意。
得到的另一件事是，所有表管理功能隨著數據集的增長而越來越慢。
但這可以通過使數據表僅包含2個字段來解決：ID和BLOB。
（通過主鍵）檢索數據很可能只會在您備份數據集遇到困難之后很長時間才成為問題。
慕森王
TA貢獻1777條經驗 獲得超3個贊
我經常聽到使用blob的主要缺點是，超過一定大小后，文件系統在存儲和檢索大文件方面效率更高。聽起來您已經按照需求列表考慮了這一點。
這里有一個很好的參考（PDF），涵蓋了Blob的優缺點。
墨色風雨
TA貢獻1853條經驗 獲得超6個贊
根據我的經驗，一些問題是：
速度與在文件系統上擁有文件的速度。
緩存。IMO Web服務器將更好地緩存靜態內容。DB也會做得很好，但是如果DB還處理其他各種查詢，請不要期望那些大型文檔會長時間保持緩存。實際上，您必須兩次傳輸文件。一次是從DB到Web服務器，然后是Web服務器到客戶端。
內存限制。在我的上一份工作中，數據庫中有40MB的PDF，并在日志文件中不斷獲取Java OutOfMemoryErrors。最終，我們認識到整個80MB PDF不僅被讀入了堆，而且由于休眠ORM中的設置而被讀入了TWICE（如果一個對象是可變的，它會在內存中進行編輯）。將PDF流式傳輸回用戶后，便清理了堆，但一次僅從流中提取80MB只是用于流式傳輸文檔，這是一個很大的打擊。了解您的代碼以及如何使用內存！
您的Web服務器應該能夠處理您的大多數安全問題，但是如果文檔很小并且DB尚未承受很大的負載，那么將它們放入DB中并沒有太大的問題。
添加回答
舉報
0/150
提交
取消