40

1 つのパッケージでエクストラネットとイントラネット全体を強化するバックエンド CMS システム全体を構築するプロジェクトが進行中です。私が答えを見つけようとしてきた質問は、データベース (SQL Server 2005) にイメージを保存して、整合性、単一のレプリケーション プランなどを確保することと、ファイル システムに保存することのどちらが優れているかということです。

私たちが抱えている問題の 1 つは、常に同じデータを保持する必要がある複数のサーバーが負荷分散されていることです。今のところ、SQL レプリケーションがそれを処理していますが、ファイル レプリケーションは少し難しいようです。私たちが抱えているもう 1 つの懸念は、同じ画像の複数の解像度を持ちたいということです。ファイル システムに各バージョンを作成して保存するのが最善なのか、それとも要求に応じて必要な解像度の画像を動的にプルして作成するのがよいのかわかりません。

私たちの懸念は次のとおりです。

  • データの整合性
  • データ複製
  • 複数の解像度
  • データベースとファイル システムの速度
  • データベースとファイル システムのオーバーヘッド ロード
  • データ管理とバックアップ

誰かが同様の状況を持っているか、推奨されるものについて意見を持っていますか? 助けてくれてありがとう！

4

10 に答える 10

59

Microsoft Research が発行した、 To Blob or not to Blobという優れた研究論文があり、あらゆる種類の変数と影響を調べました。

最終的に彼らの発見：

  • 最大 256 KB のサイズで、BLOB はファイル システムよりも効率的にデータベースに格納されます。
  • 1 MB 以上の場合、ファイル システムはより効率的です。
  • 間にそれはトスアップです

その論文が公開されて以来、SQL Server 2008 には FILESTREAM 属性も追加されました。これにより、ファイル システムにデータを格納することができますが、トランザクション制御下で実現されます。それをチェックすることを強くお勧めします！

于 2010-03-25T17:17:36.787 に答える
6

この質問はよく出てきます。このSO 検索結果を参照してください。

正解はありません。状況によって異なります。

個人的に-DBにファイルパスを保持し、ファイルシステムにファイルを保持します。それぞれに独自の強みがあります。データベースだけでなく、ファイルもバックアップできます。これは、TB のデータを管理するこの男の結論でもあります。

于 2010-03-25T17:17:09.050 に答える
5

特に多数のサーバー間での静的ファイルの複製は、管理が難しい場合があります。これは、レプリケーションの問題の管理、監視、およびデバッグと、データベースのサイズと負荷との間のトレードオフに帰着します。

私はおそらくデータベース アプローチを選択すると思います。負荷が問題になった場合は、画像呼び出しの周りにある種のキャッシュ レイヤーを配置することを検討してください。

データベースにパスを保存するという提案には、これを複数のマシンに複製するという実際の問題がありません。

于 2010-03-25T17:23:59.990 に答える
3

議論のどちらの側にも正当な懸念があるため、常に要件を提示してください。データ量、画像数、サイズはどれくらいですか?

インライン/BLOB ストレージ

アップサイド: アーキテクチャと実装を簡素化し、システムのバックアップとリカバリまたは移行を簡素化します。ダンプ、バックアップ、エクスポート (DB のフレーバーの用語が何であれ) を実行し、それを新しいデータベースに移動するだけです。バージョン管理/整合性は DB によって処理されるため、ポイントインタイム リカバリが可能になります。画像 BLOB へのアクセスは行全体へのアクセスに固有であるため、セキュリティ/アクセス制御もより明確になります。画像を DB の外に移動し、HTTP サーバーにフェッチさせると、同時実行性とスケーラビリティは向上しますが、ユーザーが URL をハッキングして所有していない画像を要求できないようにするという問題が生じる可能性があります。それらをDBの外に置く場合は、セキュリティポリシーがユーザー間の画像のアクセス制御をカバーしていることを確認してください。HTTP サーバー認証は、システム全体の認証と統合する必要があります。または、画像を提供する HTTP サーバー プログラムが何らかのセッション メカニズムを使用して、HTTP 要求が有効であることを確認します。これは、マルチテナント データベースでは非常に大きな懸念事項です。単純な認証を使用する単一目的のシングルテナント システムでは、問題はあまりありません。

欠点: 非常に大規模なデータベースの場合、バックアップとリカバリはイライラするか、問題が発生し、コストがかかることさえあります。それ以外の場合はコア データセットが小さい場合に、GB または TB のイメージ データが大量にある可能性があるためです。すべてを 1 つの一貫したデータベースとして扱うことは、整合性の観点からは良いことですが、エンタープライズ品質のデータ ウェアハウスで調整されたバックアップとリカバリ (たとえば、Oracle RMAN とローリング バックアップ) を備えた DBMS を使用しない限り、バックアップには適していません。

どのシステムでも、回復までの時間を常に考慮してください。ストレージ要件が数ギガバイト未満、たとえば 50 ～ 100 GB で、十分なバックアップ スペースが計画されている場合は、インライン ストレージの方がクリーンです。その上で、関心の分離とファイルシステムに任せることが重要な利点になります。小さなデータエラーのために巨大なデータベースを復元、回復、オープンしようとすることほど悪いことはありません。回復時間は私の最大の懸念事項です。

于 2010-03-25T17:30:42.037 に答える
3

あなたの懸念は 2 つの陣営に分かれます。次の懸念事項は、データベースへのドキュメントの保存を優先します。

  • データの整合性
  • データ複製
  • 複数の解像度
  • データ管理とバックアップ

これらの懸念は、(おそらく) ファイル システムにドキュメントを保存することを好みます。

  • データベースとファイル システムの速度
  • データベースとファイル システムのオーバーヘッド ロード

したがって、何が最も重要かを判断し、それに応じて選択してください。

于 2010-03-25T17:19:03.617 に答える
2

上位 2 つのニーズが整合性とレプリケーションである場合、答えは間違いなく DB です。

ただし、他のポイント：

  • 整合性 - DB。フラット ファイル システムに対してデータベースが存在するのはそのためです。

  • レプリケーション - イメージのレプリケーションを意味するかどうかはわかりませんが、そうであれば、これをロード バランシングしないため、明らかに DB です。

  • DB イメージから複数の解像度を実行できますが、これには処理コストがかかります。また、解像度が高いほどサイズが大きくなり、ネットワークの待ち時間が長くなります。複数の解像度は速度のためにスペースを交換します。

  • 速度 - 画像へのアクセスによっては、無視できる可能性があります。ファイル共有を介して画像を取得している場合、いずれにしてもネットワークで待機する必要があり、ほとんどの場合、ネットワークがボトルネックになります。

  • オーバーヘッド - 率直に言って、オーバーヘッドの定義と画像へのアクセス方法によって異なります。

  • 管理、DB、伝承。単一のストレージ = 心配が 1 つ減ります。どのような場合でも、常にデータベースでバックアップを実行する必要があります。複数のサーバーにまたがるファイル システムのバックアップは、多くの点でコストがかかります。

于 2010-03-25T17:15:25.493 に答える
2

一般に、CMS に関する限り、DB に画像データを永続化することは、FileSystem ほど効率的ではない可能性があります。画像を静的に表示したい場合もあれば、更新などのためにグラフィック デザイナーがその画像を利用できるようにしたい場合もあります。

画像を操作するたびに画像を取得することに伴う処理オーバーヘッドを考慮してください。

FileSystem を考慮する必要があるいくつかのポイント

  1. ブラウザがすべての作業を行い、画像などのプロキシ キャッシュを利用できます。
  2. 上記の派生物として、コンテンツ配信ネットワーク (CDN) を簡単に使用できるようになります。
  3. rsyncなどのツールを使えば画像データの複製も簡単
  4. 処理 (CPU) 時間の大幅な最適化
于 2010-03-25T18:03:53.093 に答える
1

1つの理由でデータベースに画像を保存しません（私の答えはSQLサーバーから来ています）：

Web サイト用の単純な画像で作成された SQL Servers Data Cache は必要ありません。データキャッシュに実際にデータを入れたいです。また、多層アーキテクチャを使用している場合は、バイナリ データのブロブよりも画像の URL を渡す方がはるかに簡単です。ただし、特定の人だけに画像を見せたい場合 (セキュリティ) に問題が発生する場合があります。

于 2010-03-25T17:28:51.400 に答える
1

Windows 環境にいると仮定すると、ファイル システムを使用する大きな理由はありません。不要なページ分割を避けるために、テーブルに画像を保存する方法に注意する必要があるかもしれませんが、これはパフォーマンスの調整であり、大きな問題ではありません。

ファイルシステムの欠点

-自動的に複製されない

-インスタンスごとに物理的な場所が異なるため、レプリケーションが複雑になる可能性があります

-非常に多数のファイルで遅い

ファイルシステムの利点

-非常に大きなファイルをいくつか保存している場合は、パフォーマンスが少し向上します。

于 2010-03-25T17:16:36.273 に答える
1

私は...するだろう;

1) 一意の識別子 (GUID) を各イメージに割り当てます。2) その GUID でイメージにタグ付け/名前を付けます。3) GUID を OS (ファイル システム) に保存します。4) 完全修飾ファイル名 (FQN) ポインタをデータベースに保存します。

イメージをデータベースに保存すると、ストレージとメンテナンスの点でコストがかかりすぎます。FQN ポインタだけを保存すると、より良い解決策が得られます。トリガーと一部のストアド プロシージャを使用して、バックエンドの整合性チェックを構築することもできます。

于 2010-03-25T17:18:00.650 に答える