database - ドキュメントの保存に推奨される場所-データベースまたはその他の場所？

Question

バックグラウンド：

ずっと前に実装された社内のドキュメントストレージシステムがあります。何らかの理由で、ドキュメントの保存メカニズムとしてデータベースを使用することが選択されました。

私の質問はこれです：

ドキュメントを保存するためのベストプラクティスは何ですか？選択肢は何ですか？長所と短所は何ですか？ 回答はテクノロジーやプラットフォーム固有である必要はありません。より一般的なベストプラクティスの質問です。

私の考え：

データベースはドキュメントの保存を目的としたものではありません。ファイルシステムまたはサードパーティのドキュメント管理システムの方が便利な場合があります。データベースのドキュメントストレージは高価です。操作が遅い。これらの論理的な仮定はありますか？おそらくこれが最善ですが、私の考えでは、より良い選択肢があります。oracle BFILE（NASまたはSAN上のドキュメントへのリンク）はBLOB / CLOBよりも優れているでしょうか？

詳細：

ドキュメントにはさまざまな種類があります（pdf、word、xml）
中間層コードは.net2.0/ c＃で記述されています
ドキュメントは、圧縮されたBLOBのOracle 10gデータベースに保存されます（NASストレージ）
ファイルサイズが激怒
ドキュメントの数は大幅に増加しており、減速の兆候はありません
インサートは通常、ピーク時に1時間あたり数百になります
取得は通常、ピーク時に1時間あたり数千になります
NASストレージとSANストレージが利用可能です

更新（以下の質問から）：

私のバックグラウンドは開発です
データベース内のファイルの横に保存されているファイルに関するメタデータが関連付けられています

score 14 · Accepted Answer

私の経験に基づいて、それらをデータベースに保持すると思います。これを行うために、2 つのシステムを移動しました。

データベースに入れるということは、次のことを意味します。

複数のサーバーからでも簡単にアクセスできます
自動的にバックアップされます（それを行うために別のジョブを用意する必要はありません）
スペースについて心配する必要はありません (人々は DB がディスクをいっぱいにしないようにしていますが、ドキュメントがどこに保存されているかを監視するのを忘れるかもしれません)
複雑なディレクトリスキームを用意する必要はありません

データベースからドキュメントがありました。書類が多いと困ります。Linux の通常のディレクトリは 1 ブロックで、通常は 4K です。非常に多くのファイルが含まれていたため、58MBのディレクトリがありました (階層のないフラットなディレクトリでした)。それは多くの間接ブロックを持っていました。削除に1時間以上かかりました。ディレクトリ内のファイル数をカウントするのに数分かかりました。それはひどいものでした。これはext3にあります。

必要なファイルシステムでは:

個別のバックアップメカニズム (DB バックアップから)
物事を同期させるため（ファイルが存在しないとDBにレコードが存在しないようにするため）
ストレージの階層 (上記の問題を回避するため、ディレクトリに何万ものファイルが存在しないようにするため)
クラスターが必要な場合に他のサーバーからそれらを表示する方法 (おそらく NFS など)

それは本当に苦痛です。自明ではない数のドキュメントについては、私が見たものに基づいて、ファイルシステムに反対することをお勧めします。

score 11 · Accepted Answer

ドキュメントをファイルシステムに保存してから、ファイルへのリンクと関連するファイルメタデータをデータベースに保存することを好みます。

これは、他の方法よりも便利で、保守が容易で、安価であることが証明されています。

score 8 · Accepted Answer

ほとんどのエンタープライズクラスのドキュメント管理システムは、オブジェクトファイルをデータベースに保存しません。できないからといって、そうすべきだという意味ではありません。スケーラビリティとパフォーマンスが重要であり、大きなドキュメントセットがある場合は、オブジェクトをデータベースに保存する際に非常に注意する必要があります。次のことを考慮してください。

ドキュメントイメージングの場合、2億のTIFFファイルは比較的大きなシステムと見なすことができますが、大規模ではありません。大規模なシステムでは、10億を超えるオブジェクトファイルを使用できます。たとえば、ビットンTIFFあたり20KBの場合、4TBのオブジェクトファイルストレージを使用できます。DBバックアップにはどのくらい時間がかかりますか？クエリにはどのくらい時間がかかりますか？これらのオブジェクトへのアクセス頻度はどれくらいですか？これらのオブジェクトのアクセス頻度が高い場合、ハイエンドDBサーバーがファイルの提供にすべての時間を費やすようにしますか？何百万ものオブジェクトがある場合は、オブジェクトがデータベースに格納されるソリューションをどのように設計するかについて、かなり注意する必要があります。

これらの200MTIFFファイルをPDFファイルに変換するタスクが発生したとします。データベースサーバーがすべてのオブジェクトファイルを変換プロセスに提供し、結果を再保存するために時間を浪費するため、ソリューションを屈服させる準備をしてください。

一例として、Sharepointはオブジェクトをデータベースに保存することで有名です。Sharepointは、スケーラビリティの問題でも有名です。

私の答え：
小さなシステム（100万未満のファイル）の場合、DBにファイルを保存することを検討できます。大規模なシステム（> 1Mファイル）の場合、DBにファイルを保存するのは間違いです。

score 6 · Accepted Answer

ファイルをデータベース自体に保存することに関する私の最大の懸念は、バックアップのサイズと複雑さ、およびその他のデータベース保守操作を管理することです。

この問題を (少なくとも MS SQL で) 軽減するための 1 つの戦略は、別々のデータベースパーティションを作成し、別のドライブに保存することです。

次に、ファイルに関するメタデータが 1 つのパーティションに配置され、実際の BLOB ファイルが別のパーティションに配置されるように、データスキーマを分離します。

これらのパーティションは、異なるスケジュールでバックアップすることも、個別に復元することもできます。

score 5 · Accepted Answer

ドキュメントをデータベースに保存する際の唯一の制限は、技術的なものです。

リレーションデータベースは、企業のミッションクリティカルなデータを永続的に保存することを目的としています。もちろん、その機能をどれだけうまく実行できるかは、データベースごと、システムごとに異なります。しかし、理想的には、リレーショナルデータベースのACIDプロパティは、すべてのエンタープライズデータを格納することを目的としています。ファイルシステム、リビジョンコントローラーシステム、およびその他のローカルストアストレージシステムには、特定の利点があるかもしれませんが、エンタープライズデータストレージ用には設計されていません。

保管している文書がエンタープライズ・データとして適格である場合 (それらが企業全体で永続的に使用される場合)、それらをデータベースに保持することは論理的です。データベースへの格納に問題がある場合は、DBA がより良い解決策を見つけることができます。パフォーマンス上の理由からデータベースから移動する必要があるかもしれませんが、ベストプラクティスの理由からデータベースから移動する必要はないと思います。

もちろん、ドキュメントがエンタープライズデータではない場合、たとえばドキュメントが 1 つのアプリケーションでのみ使用される場合は、ドキュメントをデータベースから移動することも理にかなっています。

score 3 · Accepted Answer

画像を BLOB としてデータベースに保存したことがありますが、最初にそれらの画像に対してバッチ操作を実行しなければならなかったことを後悔しています。ファイルシステムでそれを行う方がはるかに簡単だったでしょう。また、おっしゃったように、ドキュメントがファイルシステム上にある場合は、ドキュメントを取得する方がはるかに高速です。

私の単純な見解: ファイルシステムはファイルを格納する必要があり、リレーショナルデータベースはリレーショナルデータを格納する必要があります。

score 1 · Accepted Answer

バイナリファイルをファイルシステムに格納します。格納および取得操作用の ASP.NET アプリケーションを作成します。Web アプリ (ドキュメントのバージョン管理、多層セキュリティなど) に気を配ることができます。これはドキュメント管理業界のコンセンサスだと思います。

「文書数が急激に増えている」ということで、大規模化しているようです。サードパーティのすぐに使えるソリューション ( http://kofax.com/capture/など- 私はこれについて豊富な経験があります!) を調べて、「汚い仕事」を行うことをお勧めします。あなた。または、さらに良いことに、 http: //www.edocumentsolutionsllc.com/ などの SaaS サービスを検討することを検討してください。

:-)

score 0 · Accepted Answer

ドキュメントをSubversionまたは他のバージョン管理システムに保存することを検討してください。優れたバックアップ、古いバージョンのドキュメントを確認する機能、優れたネットワークアクセスが得られます。「転覆の私の人生」を参照してください。

score 0 · Accepted Answer

それどころか、いくつかの理由から、データベースに保存することにしました。

よりシンプルなバックアップ戦略
データベースに保存された文書は索引付けして検索できます
ファイルの移動やセキュリティの改ざんを心配する必要はありません
クラッシュが発生した場合に別のサーバーに簡単に移植できます
政府が x 年前のデータを保存する必要がある場合、データベースを使用してこれを管理する方がはるかに簡単です。

データベースはデータを保存するために作られています。ファイルは単なるデータです。

ファイルシステムにファイルを保存することには利点があると述べましたが、主なものはデータベースのパフォーマンスが向上し、サイズが抑えられることです。SQL Server 2008 では、FileStream を使用して両方の長所を活用できます。詳細については、このホワイトペーパーをお読みください

score 0 · Accepted Answer

個人的な専門知識: あなたはデータベース管理者ですか、それともプログラマーですか?

セキュリティ: データベースに 1 つの設定、データベースとファイルシステムに 2 つの設定。誰かが誤ってファイルを移動/削除する懸念はありますか? 複雑な設定では、管理者はファイルを別のサーバーに移動し、共有またはマッピングを変更することを選択する場合があります。私は知っています、これは決して起こらないでしょう。

新しいデータベースは、この分野で改善されています。

score 0 · Accepted Answer

ファイルにアクセスして編集および再保存できるようにする場合は、ドキュメントを .doc などのファイルとして保存します。

プルバックして再現できる実際の履歴コピーが必要な場合は、ドキュメントを .pdf や .tiff などのファイルとして保存します。

ファイルに関するすべての情報 (日付、作成者、場所など) をデータベースに保存します。

score 0 · Accepted Answer

私は常にドキュメントのコア情報とファイルパスをデータベースに保存しますが、ドキュメント自体は保存しません。ドキュメント全体がデータベースにある必要があることはめったにありません。

これにより、これらのドキュメントをより柔軟に使用できます。たとえば、階層化されたバックアップストレージと重複排除メカニズムを使用したいですか? Oracle BLOB で試してみてください。

score 0 · Accepted Answer

ドキュメントをデータベースに保存する唯一の利点は、それらのドキュメントを別の環境に簡単に移動できることです。それとは別に、すでに述べたすべての理由から、私はそれをしません。

database - ドキュメントの保存に推奨される場所-データベースまたはその他の場所？

13 に答える 13

Related

Reference