database - すべきことまたはすべきでないこと：画像をデータベースに保存する

Question

Webアプリケーションのコンテキストでは、私の古い上司は常に、画像自体ではなく、データベースに画像への参照を置くと言っていました。URLと画像自体をDBに保存するのは良い考えだと私は同意する傾向がありますが、私が今働いているところでは、データベースに多くの画像を保存しています。

私が考えることができる唯一の理由は、おそらくそれがより安全であるということですか？あなたは誰かがURLへの直接リンクを持っていることを望まないのですか？ただし、その場合は、asp.netのハンドラーのように、いつでもWebサイト/サーバーに画像を処理させることができるため、ユーザーは画像を表示するために認証する必要があります。また、データベースから画像を引き出すことでパフォーマンスが低下すると思います。データベースに画像を保存するのが良い/悪い考えであるかもしれない他の理由はありますか？

正確な複製： ユーザーイメージ：データベースまたはファイルシステムストレージ？
正確な複製： データベースへの画像の保存：そうですか、そうでないですか？
正確に複製： 画像をデータベースまたはフォルダーに保存する必要がありますか？
正確な複製： バイナリデータをデータベースまたはフォルダーに保存しますか？
正確な複製： 写真をファイルまたはWebアプリのデータベースとして保存しますか？
正確な複製： 少数の画像を保存する：blobまたはfs？
正確な複製： 画像をファイルシステムまたはデータベースに保存しますか？

score 53 · Accepted Answer

画像をデータベースに入れることの長所。

トランザクション。BLOB を保存すると、他の DB データと同じようにコミットできます。つまり、関連するメタデータのいずれかと一緒に BLOB をコミットでき、2 つが同期していることを確認できます。ディスク容量が不足したら？コミットなし。ファイルが完全にアップロードされませんでしたか? コミットなし。愚かなアプリケーションエラー？コミットなし。画像とそれに関連するメタデータの一貫性を維持することがアプリケーションにとって重要である場合、DB が提供できるトランザクションは恩恵となる可能性があります。
1 つのシステムで管理できます。メタデータと BLOB をバックアップする必要がありますか? データベースをバックアップします。それらを複製する必要がありますか? データベースを複製します。部分的なシステム障害から回復する必要がありますか? DB をリロードし、ログをロールフォワードします。DB が一般的にデータにもたらすすべての利点 (ボリュームマッピング、ストレージ制御、バックアップ、レプリケーション、復旧など) は、BLOB にも当てはまります。一貫性が向上し、管理が容易になります。
安全。データベースには、活用できる非常にきめ細かいセキュリティ機能があります。スキーマ、ユーザーロール、さらにはデータのサブセットへの安全なアクセスを提供するための "読み取り専用ビュー" など。これらの機能はすべて、ブロブを保持するテーブルでも機能します。
集中管理。＃2に関連していますが、基本的にDBAは（十分な力がないかのように）データベースという1つのことを管理します。最新のデータベース (特に大規模なもの) は、複数のマシンにまたがる大規模なインストールで非常にうまく機能します。単一の管理ソースにより、手順が簡素化され、知識の伝達が簡素化されます。
最新のデータベースのほとんどは、ブロブを問題なく処理します。データ層での BLOB のファーストクラスサポートにより、DB からクライアントに BLOB を簡単にストリーミングできます。ブロブ全体を一度に「吸い込む」ことができる操作がありますが、その機能が必要ない場合は使用しないでください。DB の SQL インターフェイスを調べて、その機能を活用してください。それらをモノリシックに処理される「大きな文字列」のように扱い、BLOB をメモリを大量に消費し、キャッシュを破壊する爆弾に変える理由はありません。
画像専用のファイルサーバーをセットアップできるように、データベースに専用の BLOB サーバーをセットアップできます。専用のディスクボリューム、専用のスキーマ、専用のキャッシュなどを提供します。DB 内のすべてのデータは同じではないか、同じように動作します。すべて同じように構成する理由はありません。優れたデータベースには、細かいレベルの制御があります。

DB から BLOB を提供する際の主な問題は、HTTP レイヤーが実際にすべての HTTP プロトコルを活用してサービスを実行することです。

多くのナイーブな実装は、単純に blob を取得し、それらをソケットに大量にダンプします。ただし、HTTP には、画像のストリーミングなどに適した重要な機能がいくつかあります。特に、キャッシュヘッダー、ETag、およびクライアントが BLOB の「断片」を要求できるようにするためのチャンク転送があります。

HTTP サービスがこれらすべての要求を適切に受け入れていることを確認してください。そうすれば、DB は非常に優れた Web 市民になることができます。HTTP サーバーによるサービスのためにファイルシステムにファイルをキャッシュすることにより、これらの利点のいくつかを「無料で」得ることができます (良いサーバーはとにかく「静的」リソースに対してそれを行うため)。画像の変更日などを尊重します。

たとえば、2009 年 1 月 1 日に作成された画像である spaceshuttle.jpg をリクエストしたとします。この画像は、2009 年 2 月 1 日のようなリクエスト日にファイルシステムにキャッシュされます。その後、画像はキャッシュから消去されます (FIFO ポリシー)。、または何でも)、その後、2009 年 3 月 1 日に誰かが再度要求します。さて、作成日が実際には 1 月 1 日だったにもかかわらず、現在は 2009 年 3 月 1 日の「作成日」になっています。実際には変更されていないのに、サーバーはリソースが変更されたと見なすため、変更されたヘッダーは実際に必要な量よりも多くのデータを取得している可能性があります。

キャッシュの作成日を実際の作成日と同期させておくと、これはあまり問題になりません。

しかし重要なのは、「良き Web 市民」になるためには、問題全体について熟考し、あなたとあなたのクライアントの帯域幅などを節約できる可能性があるということです。

DB からビデオを提供する Java プロジェクトについて、これをすべて実行しましたが、すべてうまくいきます。

score 21 · Accepted Answer

場合によっては画像を取得する必要があり、複数の異なる Web サーバーで使用できるようにする必要がある場合。でもそれくらいだと思います。

複数のサーバーで使用可能にする必要がない場合は、それらをファイルシステムに配置することをお勧めします。
複数のサーバーで使用可能にする必要があり、実際にシステムに何らかの負荷がかかる場合は、何らかの分散ストレージが必要になります。

ここでは、データベースを活用することで、システムにさらに複雑なレベルを追加することを回避できるエッジケースについて説明します。

それ以外はしないでください。

score 14 · Accepted Answer

データベースに画像を保存する（または言及する）と、データベースの専門家の大多数があなたに指を交差させてしまうことを理解しています。はい、あらゆる種類のバイナリデータの大きなブロックのリポジトリとしてデータベースを使用する場合、パフォーマンスとストレージに間違いなく影響があります（画像は、正規化できない最も一般的なデータビットである傾向があります）。ただし、画像のデータベース保存が許可されるだけでなく、推奨される状況が最も確実にあります。

たとえば、私の以前の仕事では、ユーザーが作成しているレポートのいくつかの異なるポイントに画像を添付するアプリケーションがあり、それらの画像は作成時に印刷する必要がありました。これらのレポートはSQLServerレプリケーションを介して移動され、複数のシステムやサーバー間でこれらのイメージとファイルパスをあらゆる種類の信頼性で管理しようとすると大きな頭痛の種になります。それらをデータベースに保存すると、そのすべてが「無料」で提供され、レポートツールは画像を取得するためにファイルシステムにアクセスする必要がありませんでした。

score 8 · Accepted Answer

私の一般的なアドバイスは、どちらか一方のアプローチに限定するのではなく、状況に合ったテクニックを使用することです。ファイルシステムはファイルの保存に非常に優れており、データベースは要求に応じて一口サイズのデータのチャンクを提供するのに非常に優れています。一方、私の会社の製品の1つには、アプリケーションの状態全体をデータベースに保存する必要があります。つまり、添付ファイルもデータベースに保存されます。私たちのDBサーバー（SQL Server 2005）では、大規模な顧客やデータベースでも、まだ観察可能なパフォーマンスの問題に遭遇していません。

MicrosoftのSQL2008は、FileStream機能を備えた両方の長所を提供します。チェックする価値があるかもしれません。 http://technet.microsoft.com/en-us/library/bb933993.aspx

score 7 · Accepted Answer

イメージをデータベースに保存する利点の 1 つは、システム間で移植可能であり、ファイルシステムのレイアウトに依存しないことです。

score 6 · Accepted Answer

最も単純で、最もパフォーマンスが高く、最もスケーラブルなソリューションは、イメージをファイルシステムに保存することです。セキュリティが懸念される場合は、Web サーバーがアクセスできない場所にファイルを置き、セキュリティを処理してファイルを提供するスクリプトを作成します。

Web/アプリサーバーと DB サーバーが異なるマシンであると仮定すると、DB にイメージを配置することで、いくつかのヒットが発生します。(1) 2 つのマシン間のネットワーク遅延、(2) DB 接続のオーバーヘッド、(3) 追加の DB の消費提供される各画像の接続。最後の点についてはもっと心配です。サイトが大量の画像を提供する場合、Web サーバーは多くの DB 接続を消費し、接続プールを使い果たす可能性があります。

score 5 · Accepted Answer

アプリケーションが複数のサーバーで実行されている場合は、画像の参照コピーをデータベースに保存し、必要に応じてファイルシステムにキャッシュします。そうすることで、ファイルシステムを横方向に同期しようとするよりも、エラーが発生しやすいお尻の痛みがはるかに少なくなります.

アプリケーションが単一のサーバー上にある場合は、ファイルシステムに固執し、データベースがデータへのパスを維持するようにします。

score 3 · Accepted Answer

もちろん、ほとんどの SQL データベースは画像を提供することを念頭に置いて設計されていませんが、データベースに画像を含めることにはある程度の利便性があります。

たとえば、すでにデータベースを実行しており、レプリケーションを構成している場合です。rsync または nfs ベースのファイルシステムレプリケーションを実行しようとするのではなく、すぐに HA イメージストアを作成できます。また、ファイルをディスクに書き込むための一連の Web プロセス (または新しいサービスの設計) があると、複雑さが少し増します。実際には、可動部分が増えるだけです。

少なくとも、イメージに関する「メタ」データ (権限、所有者など) と実際のデータを異なるテーブルに分けて保持することをお勧めします。これにより、別のデータストアに簡単に切り替えることができます。この線。これをある種の CDN やキャッシングと組み合わせると、ある程度まではかなり優れたパフォーマンスが得られるはずです。そのため、このアプリケーションに必要なスケーラビリティと、それと実装の容易さのバランスをどのように取るかにかかっていると思います。

score 2 · Accepted Answer

URL を保存する必要はありません (安全でないと思われる場合)。他の場所で画像を参照する一意の ID を保存するだけです。

データベースストレージは、ファイルシステムよりも高価で維持費がかかる傾向があるため、データベースに大量の画像を保存することはしません。

score 1 · Accepted Answer

1

データのデータベース
ファイルのファイルシステム

于 2009-05-02T21:32:00.467 に答える

score 1 · Accepted Answer

デモンストレーションアプリケーション用に画像をデータベースに保存しました。私がそれをした理由はセキュリティでした-私がすべきではなかったレコードを削除することは大きな問題ではありませんでしたが、私がすべきではなかったファイルを削除することは問題だったかもしれません！

パフォーマンスが問題になった場合、不正なファイルの削除が実際に可能かどうかを調査しました。

score 1 · Accepted Answer

定期的にデータベースから取り出される画像の場合は、常にファイルシステムを使おうと思います。

たまに引き出す必要のある画像で、データベースに保存しておくと生活が楽になりますが、全く問題ありません。

score 1 · Accepted Answer

データベースに数テラバイトの画像データが保存されている場合、ディザスタリカバリはまったく面白くありません。データの信頼性を高めるために、データを分散するためのより良い方法を見つけたほうがよいでしょう... もちろん、レプリケーションなどの際には、すべてのオーバーヘッド (上記) が乗算されます...

ただそれをしないでください！

score 1 · Accepted Answer

これは本当に KISS (keep it simple bad) の問題のようです。ファイルシステムは、画像ファイルの保存を簡単に処理できるように作られていますが、データベースでは簡単ではなく、データをめちゃくちゃにするのは簡単です。ファイルのセキュリティだけを心配できるのに、なぜパフォーマンスが低下し、SQL とレンダリングですべての問題が発生するのでしょうか? また、NFS または CIFS を使用して混合システムを処理することもできます。ファイルシステムは成熟したテクノロジーです。よりシンプルに、より堅牢に。

database - すべきことまたはすべきでないこと：画像をデータベースに保存する

14 に答える 14

Related

Reference