53

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

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

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

私の質問は、この設計と実装で見落としていた深刻なリスクや事柄はありますか?

編集注: DB は PostgreSQL であり、BLOB を非常にうまく処理し、非常にうまくスケーリングします。環境はマルチユーザーです。

4

8 に答える 8

40

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

もう 1 つの問題は、データセットが大きくなるにつれて、すべてのテーブル管理機能がますます遅くなるということです。
しかし、これはデータ テーブルに ID と BLOB の 2 つのフィールドだけを含めることで解決できます。

(主キーによる) データの取得は、データセットのバックアップで壁にぶつかった後になって初めて問題になる可能性があります。

于 2008-10-18T15:03:59.950 に答える
30

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

ブロブの長所と短所をカバーする優れたリファレンス (PDF) がここにあります。

于 2008-10-17T12:16:01.973 に答える
13

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

  1. 速度とファイル システム上にファイルを持つこと。

  2. キャッシング。IMO Web サーバーは、静的コンテンツのキャッシュをより適切に処理します。DB も適切に機能しますが、DB が他のあらゆる種類のクエリも処理している場合、それらの大きなドキュメントが長時間キャッシュされたままになるとは思わないでください。基本的に、ファイルを 2 回転送する必要があります。DBからWebサーバーへ、次にWebサーバーからクライアントへ。

  3. メモリの制約。私の最後の仕事では、データベースに 40MB の PDF があり、ログ ファイルに Java OutOfMemoryErrors が記録され続けていました。最終的に、Hibernate ORM の設定のおかげで、80MB の PDF 全体が 1 回だけではなく 2 回ヒープに読み込まれたことに気付きました (オブジェクトがミュータブルの場合、メモリ内で編集するためのコピーが作成されます)。PDF がユーザーにストリーミングされると、ヒープはクリーンアップされましたが、ドキュメントをストリーミングするためだけにヒープから一度に 80MB を吸い出すのは大打撃でした。コードとメモリがどのように使用されているかを理解してください!

あなたの Web サーバーはセキュリティ上の問題のほとんどを処理できるはずですが、ドキュメントが小さく、DB にまだ大きな負荷がかかっていない場合、ドキュメントを DB に置いても大きな問題はないと思います。

于 2008-10-18T15:46:39.300 に答える
4

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

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

于 2009-11-18T19:57:03.590 に答える
2

この記事では、ほとんどの問題について説明します。SQL Server 2008 を使用している場合は、ここでPaul Randal が説明している新しい FILESTREAM タイプの使用を確認してください。

于 2008-10-17T12:12:44.630 に答える
2

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

于 2008-10-17T12:22:26.873 に答える
-1

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

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

メンテナンスと管理の観点から、MS SQL Server を扱う場合は SAN に制限されます。Documentum のようなソリューションは、ディスク上に単純なストレージを使用するという異なるアプローチを採用しており、必要に応じてストレージ ソリューションを実装できます。

編集

私の声明を明確にさせてください。SQL Server では、ボックスの物理ストレージ容量を超えた場合の選択肢が限られています。実際、これはどのタイプのネットワーク ストレージでも簡単に接続できないという、Sharepoint の大きな弱点の 1 つです。

于 2008-10-17T12:17:11.580 に答える