データベースにドキュメントをBLOBとして保存する-欠点はありますか？

StackOverflow https://stackoverflow.com/questions/211895

質問

ドキュメント管理システムの要件は次のとおりです。

  1. ディレクトリ、ファイルなどの単純なコピーにより、盗難から保護する必要があります
  2. 従来のウイルス感染（物理ファイルの感染）に対して安全でなければなりません
  3. 高速に取得する必要があります
  4. リポジトリは、カジュアルな（ディレクトリ）閲覧ユーザーなどに表示されてはなりません。

すべてのドキュメント（およびスキャンされた画像）をデータベースにblobとして保存することにしましたが、これまでの私の経験は素晴らしく、ドキュメントの検索も驚くほど高速です-上記のすべての基準を満たし、関連するエンティティと一緒にドキュメントを自動保存する、コンテンツを簡単かつ迅速に検索する、ドキュメントを開くおよび命名するなどのあらゆる種類のユーザーアクティビティを削除するなどの追加の利点など

私の質問は-この設計と実装で見落とした重大なリスクやものはありますか？

EDIT注：DBはPostgreSQLであり、BLOBを非常によく処理し、非常に適切にスケーリングします。環境はマルチユーザーです。

役に立ちましたか？

解決

DBが大きくなると、バックアップが難しくなります。 100 GBを超えるデータを含むテーブルのバックアップを復元することは、あなたを満足させるものではありません。

取得する別のことは、すべてのテーブル管理機能が、データセットが大きくなるにつれてますます遅くなることです。
ただし、データテーブルに2つのフィールドのみを含めることで、これを克服できます。  IDとBLOB。

（主キーによる）データの取得は、データセットのバックアップで壁にぶつかった後の長い間だけ問題になる可能性があります。

他のヒント

blobを使用することでよく耳にする主な欠点は、特定のサイズを超えると、ファイルシステムが大きなファイルを格納および取得する際にはるかに効率的であることです。要件のリストにより、これを考慮に入れているようです。

参考資料（PDF）がここにありますブロブの短所。

私の経験から、いくつかの問題がありました：

  1. 速度とファイルシステム上のファイルの関係。

  2. キャッシュ。 IMO Webサーバー キャッシュのより良い仕事をします 静的コンテンツ。 DBは 良い仕事ですが、DBも 他のあらゆる種類のクエリを処理し、 これらの大きなドキュメントを期待しないでください 長期間キャッシュを維持します。君は 本質的に転送する必要があります ファイルを2回。 DBから Webサーバー、次にWebサーバー クライアント。

  3. メモリの制約。私の最後の仕事では、データベースに40MBのPDFがあり、ログファイルでJava OutOfMemoryErrorsを取得し続けました。最終的に、80MBのPDF全体が一度だけヒープに読み込まれるのではなく、Hibernate ORMの設定のおかげで2倍になったことに気付きました（オブジェクトが可変の場合、メモリ内で編集するためにコピーを作成します）。 PDFがユーザーにストリームバックされると、ヒープはクリーンアップされましたが、ドキュメントをストリーミングするためだけにヒープから80MBを一度に消費することは大ヒットでした。コードとメモリの使用方法を知ってください！

あなたのウェブサーバーはセキュリティ上の懸念のほとんどを処理できるはずですが、ドキュメントが小さく、DBにまだ大きな負荷がかかっていない場合、DBにそれらを置くことに関して大きな問題はありません。 。

SQL Server 2008のBLOB用のFILESTREAMingの調査を開始しましたが、統合されたセキュリティでのみ機能する巨大な制限（IMO）に遭遇しました。 Windows認証を使用してDBサーバーに接続しないと、BLOBの読み取り/書き込みができません。多くのアプリケーション環境では、Windows認証を使用できません。確かに異種環境ではありません。

BLOBを格納するためのより優れたソリューションが存在する必要があります。ベストプラクティスは何ですか？

この記事ほとんどの問題。 SQL Server 2008を使用している場合は、Paul Randal こちら。

データベースの種類によって異なります。 OracleまたはSQLServer？ 1つの欠点に注意してください-単一のドキュメントの復元。

申し訳ありません-私が提供した答えはSQL Serverに基づいていたため、メンテナンスの部分は適切ではありません。ただし、ファイルI / Oはハードウェアレベルで実行され、データベースは追加の処理ステップを追加します。

データベースは、ドキュメントを取得するときに余分なオーバーヘッドを課します。ファイルがディスク上にある場合、サーバーのI / Oと同じくらい遅いか速いだけです。メタはデータベースで管理する必要がありますが、最終的にはファイルのUNCが必要で、ユーザーに ソースと邪魔にならないように。

保守および管理の観点から、MS SQL Serverを扱う場合はSANに制限されます。 Documentumのようなソリューションは、ディスク上の単純なストレージを使用して異なるアプローチを取り、適切なストレージソリューションを実装できます。

編集

私の声明を明確にしましょう-SQL Serverでは、ボックスの物理的なストレージ容量を超える場合、オプションが制限されます。実際、これはSharepointの大きな弱点の1つであり、単純にあらゆるタイプのネットワークストレージを接続することはできません。

SQL ServerとOracleの両方でコンテンツファイルをblobとして保存した経験から、小さなデータベースとログインユーザー数が少ない場合は問題なく動作します。 ECMシステムはそれらを分離し、コンテンツのストリーミングに別個のサービスを使用します。ファイルのサイズによっては、大きなファイルを同時に取得するとサーバーリソースに影響を与える可能性があります。大量のファイルを含むデータベースのアーカイブは、復元に時間がかかり、アーカイブからドキュメントを取得できないため、問題になります。

これらのファイルが企業レコードであり、これがレコードの信頼できるコピーである場合、特にファイルをアーカイブする場合、コンプライアンスおよび保持管理の問題が発生する可能性があります。また、検索とバージョン管理は今後大きな問題になる可能性があります。

車輪を再発明するのではなく、何らかのAPIを備えたECMシステムを調査することもできます。

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top