データベースにドキュメントをBLOBとして保存する-欠点はありますか？
私の文書管理システムの要件は次のとおりです。
- ディレクトリ、ファイルなどの単純なコピーにより、盗難から安全でなければなりません。
- 従来のウイルス感染（物理ファイルの感染）に対して安全でなければなりません
- 取得は高速でなければなりません
- リポジトリは、カジュアルな（ディレクトリ）ブラウジングユーザーなどに表示されてはなりません。
すべてのドキュメント（およびスキャンされた画像）をデータベースにblobとして保存することにしましたが、これまでのところ私の経験は素晴らしく、ドキュメントの検索も途方もなく高速です-上記のすべての基準を満たし、さらにいくつかの利点があります。関連するエンティティと一緒にドキュメントを自動保存する、コンテンツを簡単かつ迅速に検索する、ドキュメントを開いたり命名するなどのあらゆる種類のユーザーアクティビティを削除するなど。
私の質問は-この設計と実装で見落とした重大なリスクやものはありますか？
編集注：DBはPostgreSQLであり、BLOBを非常によく処理し、非常に適切にスケーリングします。環境はマルチユーザーです。
DBが大きくなると、バックアップが難しくなります。 100 GBを超えるデータを含むテーブルのバックアップを復元することは、あなたを満足させるものではありません。
取得するもう1つのことは、すべてのテーブル管理機能が、データセットが大きくなるにつれてますます遅くなることです。
しかし、データテーブルにIDとBLOBの2つのフィールドのみを含めることで、これを克服できます。
（主キーによる）データの取得が問題になるのは、データセットのバックアップで壁にぶつかった後だけです。
ブロブを使用することでよく耳にする主な欠点は、特定のサイズを超えると、ファイルシステムが大きなファイルを格納および取得するのにはるかに効率的であることです。要件のリストでこれを考慮に入れているようです。
良いリファレンス（PDF）はこちら ブロブの長所と短所をカバーしています。
私の経験から、いくつかの問題がありました：
速度とファイルシステム上のファイルの関係。
キャッシング。 IMOは、Webサーバーが静的コンテンツをキャッシュするより良い仕事をします。 DBも良い仕事をしますが、DBが他のあらゆる種類のクエリも処理している場合、それらの大きなドキュメントが長い間キャッシュされたままになることを期待しないでください。基本的に、ファイルを2回転送する必要があります。 DBからWebサーバーへ、そしてWebサーバーからクライアントへ一度。
メモリの制約。私の最後の仕事で、データベースに40MB PDFがあり、ログファイルでJava OutOfMemoryErrorsを取得し続けました。最終的に、80MB PDF全体が一度だけヒープに読み込まれることに気づきましたが、Hibernate ORMの設定のおかげで2倍になりました（オブジェクトが変更可能な場合、メモリ内で編集用のコピーを作成します）。 PDFがユーザーにストリームバックされると、ヒープはクリーンアップされましたが、ドキュメントをストリーミングするためだけにヒープから80MBを一度に消費するのは大ヒットでした。コードとメモリの使用方法を把握してください！
Webサーバーはセキュリティに関する懸念のほとんどを処理できるはずですが、ドキュメントが小さく、DBに大きな負荷がかかっていない場合、DBにドキュメントを置くことに関して大きな問題はありません。
SQL Server 2008のBLOB用のFILESTREAMingの調査を始めたばかりで、統合されたセキュリティでのみ機能する巨大な制限（IMO）に遭遇しました。 Windows認証を使用してDBサーバーに接続しないと、BLOBの読み取り/書き込みができません。多くのアプリケーション環境では、Windows認証を使用できません。確かに異種環境ではありません。
BLOBを格納するためのより良いソリューションが存在する必要があります。ベストプラクティスは何ですか？
データベースの種類によって異なります。 OracleまたはSQLServer？ 1つの欠点に注意してください-単一のドキュメントの復元。
申し訳ありませんが、私が提供した回答はSQL Serverに基づいていたため、メンテナンス部分は適切ではありません。ただし、ファイルI/Oはハードウェアレベルで実行され、データベースによって処理ステップが追加されます。
データベースは、ドキュメントを取得するときに追加のオーバーヘッドを課します。ファイルがディスク上にある場合、サーバー上のI/Oと同じくらい遅いか速いだけです。確かにデータベースでメタを管理する必要がありますが、最終的にはファイルのUNCが必要で、ユーザーにソースを指定して邪魔にならないようにします。
メンテナンスと管理の観点から、MS SQL Serverを扱うときはSANに制限します。Documentumなどのソリューションは、ディスク上の単純なストレージで異なるアプローチを取り、ストレージソリューションを実装できます。あなたが合うと思うように。
[〜＃〜] edit [〜＃〜]
私の声明を明確にしましょう-SQL Serverでは、ボックスの物理的なストレージ容量を超えた場合、選択肢が制限されます。実際、これはSharepointの大きな弱点の1つであり、ネットワークストレージを単に接続することはできません。
SQL ServerとOracleの両方でコンテンツファイルをBLOBとして保存した経験から、小さなデータベースと少数のログインユーザーで問題なく動作します。 ECMシステムはそれらを分離し、コンテンツのストリーミングに別個のサービスを使用します。ファイルのサイズに応じて、大きなファイルを同時に取得すると、サーバーリソースに影響を与える可能性があります。大量のファイルを含むデータベースのアーカイブは、復元に時間がかかり、アーカイブからドキュメントを取得できないために問題になります。
これらのファイルが企業レコードであり、これがレコードの信頼できるコピーである場合、特にファイルをアーカイブする場合、コンプライアンスおよび保持管理の問題が発生する可能性があります。また、検索とバージョン管理は今後大きな問題になる可能性があります。
車輪を再発明するのではなく、何らかのAPIを使用してECMシステムを調査することもできます。