database - DBに画像を保存する-そうですか、それともそうですか？

Question

そのため、画像をDBに大量に保存するアプリを使用しています。これについてのあなたの見通しはどうですか？私は、DBに直接保存するのではなく、ファイルシステムに場所を保存するタイプです。

長所/短所は何だと思いますか？

score 350 · Accepted Answer

私は、多数のTBの画像を管理するいくつかのアプリケーションを担当しています。データベースにファイルパスを保存するのが最適であることがわかりました。

いくつかの問題があります：

データベースストレージは通常、ファイルシステムストレージよりも高価です
標準の既製の製品を使用して、ファイルシステムへのアクセスを大幅に高速化できます
- たとえば、多くのWebサーバーは、オペレーティングシステムのsendfile（）システムコールを使用して、ファイルシステムからネットワークインターフェイスに直接ファイルを非同期で送信します。データベースに保存されている画像は、この最適化の恩恵を受けません。
Webサーバーなどは、ファイルシステム内の画像にアクセスするために特別なコーディングや処理を必要としません。
データベースは、画像とメタデータ間のトランザクションの整合性が重要な場合に勝ちます。
- dbメタデータとファイルシステムデータ間の整合性を管理する方が複雑です
- データがファイルシステム上のディスクにフラッシュされたことを保証することは（Webアプリケーションのコンテキスト内で）困難です。

score 140 · Accepted Answer

As with most issues, it's not as simple as it sounds. There are cases where it would make sense to store the images in the database.

You are storing images that are changing dynamically, say invoices and you wanted to get an invoice as it was on 1 Jan 2007?
The government wants you to maintain 6 years of history
Images stored in the database do not require a different backup strategy. Images stored on filesystem do
It is easier to control access to the images if they are in a database. Idle admins can access any folder on disk. It takes a really determined admin to go snooping in a database to extract the images

On the other hand there are problems associated

Require additional code to extract and stream the images
Latency may be slower than direct file access
Heavier load on the database server

score 99 · Accepted Answer

ファイルストア。Facebookのエンジニアはそれについて素晴らしい話をしました。1つのポイントは、ディレクトリ内のファイルの実際的な制限を知ることでした。

干し草の山の中の針：何十億もの写真の効率的な保管

score 56 · Accepted Answer

これは少し遠回りかもしれませんが、SQL Server 2008 を使用している (または使用を計画している) 場合は、新しいFileStreamデータ型を確認することをお勧めします。

FileStream は、DB へのファイルの保存に関する問題のほとんどを解決します。

Blob は、実際にはファイルとしてフォルダーに格納されます。
ブロブには、データベース接続またはファイルシステムを介してアクセスできます。
バックアップが統合されています。
移行は「うまくいく」。

ただし、SQL の「Transparent Data Encryption」は FileStream オブジェクトを暗号化しないため、それを考慮する場合は、それらを varbinary として保存する方がよい場合があります。

MSDN の記事から:

Transact-SQL ステートメントは、FILESTREAM データを挿入、更新、クエリ、検索、およびバックアップできます。Win32 ファイルシステムインターフェイスは、データへのストリーミングアクセスを提供します。
FILESTREAM は、NT システムキャッシュを使用してファイルデータをキャッシュします。これにより、FILESTREAM データがデータベースエンジンのパフォーマンスに与える影響を軽減できます。SQL Server バッファープールは使用されません。したがって、このメモリはクエリ処理に使用できます。

score 39 · Accepted Answer

DB内のファイルパスは間違いなく進むべき道です-大量の画像をDBに保存しようとすると悪夢になったという、TBの画像を使用している顧客からの話を次々と聞いていますが、パフォーマンスへの影響だけでは大きすぎます。

score 35 · Accepted Answer

私の経験では、最も簡単な解決策は、主キーに従って画像に名前を付けることです。したがって、特定のレコードに属する画像を簡単に見つけることができ、その逆も可能です。しかし同時に、画像についてはデータベースに何も保存していません。

score 31 · Accepted Answer

ここでの秘訣は、熱狂的にならないことです。

ここで注意すべきことの 1 つは、プロファイルシステムキャンプの誰も特定のファイルシステムを挙げていないということです。これは、FAT16 から ZFS までのすべてが、あらゆるデータベースを簡単に打ち負かすことを意味するのでしょうか?

いいえ。

真実は、多くのデータベースが多くのファイルシステムよりも優れているということです。実際の速度についてのみ話している場合でも同様です。

正しい行動方針は、正確なシナリオに対して正しい決定を下すことです。そのためには、いくつかの数値といくつかのユースケースの見積もりが必要になります。

score 30 · Accepted Answer

参照整合性と ACID 準拠を保証しなければならない場所では、データベースに画像を保存する必要があります。

データベースに保存されている画像とその画像に関するメタデータが同じファイルを参照していることをトランザクション的に保証することはできません。つまり、ファイルシステム上のファイルが、メタデータと同時に、同じトランザクションでのみ変更されることを保証することは不可能です。

score 28 · Accepted Answer

他の人が言っているように、SQL 2008にはファイルストリームタイプが付属しており、ファイル名または識別子をポインタとしてデータベースに格納し、画像をファイルシステムに自動的に格納できます。これは素晴らしいシナリオです。

古いデータベースを使用している場合、それをBLOBデータとして保存している場合は、機能の検索方法でデータベースから何も取得されないため、おそらく最適です。ファイルシステムにアドレスを保存し、その方法で画像を保存します。

そうすれば、ファイルシステムのスペースも節約できます。これは、ファイルシステムの正確な量のスペース、または圧縮されたスペースのみを節約するためです。

また、dbヒットなしでファイルシステム内の生の画像を閲覧できる構造や要素を使用して保存したり、ファイルを別のシステム、ハードドライブ、S3、または別のシナリオにまとめて転送したりすることもできます。プログラムを維持しますが、ストレージを増やそうとするときにデータベースからイメージを取り出そうとしても、ほとんどヒットすることなく、構造を維持します。

おそらく、一般的にヒットする画像のURLに基づいてキャッシュ要素をWebエンジン/プログラムにスローできるので、そこにも自分自身を保存できます。

score 27 · Accepted Answer

頻繁に編集されない小さな静止画像 (数メガ以内) は、データベースに保存する必要があります。この方法には、容易な移植性 (イメージがデータベースと共に転送される)、容易なバックアップ/復元 (イメージがデータベースと共にバックアップされる)、優れたスケーラビリティ (何千もの小さなサムネイルファイルを含むファイルシステムフォルダーは、スケーラビリティの悪夢のように聞こえる) など、いくつかの利点があります。自分）。

データベースから画像を提供するのは簡単です。DB サーバーから返されたバイト配列をバイナリストリームとして提供する http ハンドラーを実装するだけです。

score 26 · Accepted Answer

このトピックに関する興味深いホワイトペーパーを次に示します。

BLOB にするか BLOB にしないか: データベースまたはファイルシステムのラージオブジェクトストレージ

答えは「場合による」です。確かに、それはデータベースサーバーとそのブロブストレージへのアプローチに依存します。また、BLOB に格納されているデータの種類と、そのデータへのアクセス方法によっても異なります。

小さいサイズのファイルは、データベースをストレージメカニズムとして使用して効率的に保存および配信できます。大きなファイルは、特に頻繁に変更/更新される場合は、おそらくファイルシステムを使用して保存するのが最適です。(ブロブの断片化は、パフォーマンスに関して問題になります。)

ここで、覚えておくべき追加のポイントがあります。データベースを使用して BLOB を保存することを支持する理由の 1 つは、ACID コンプライアンスです。ただし、テスト担当者がホワイトペーパーで使用したアプローチ (SQL Server の Bulk Logged オプション) は、SQL Server のスループットを 2 倍にし、ACID の「D」を効果的に「d」に変更しました。トランザクションの最初の書き込み。したがって、完全な ACID 準拠がシステムの重要な要件である場合は、ファイル I/O とデータベース BLOB I/O を比較するときに、データベース書き込みの SQL Server スループットの数値を半分にします。

score 25 · Accepted Answer

まだ誰も言及していないことの1つですが、間違いなく注目に値するのは、ほとんどのファイルシステムにも大量の画像を保存することに関連する問題があるということです。たとえば、上記のアプローチを採用し、主キーにちなんで各画像ファイルに名前を付ける場合、ほとんどのファイルシステムでは、非常に多くの画像に到達したときにすべての画像を1つの大きなディレクトリに配置しようとすると、問題が発生します（たとえば、数十万または数百万）。

これに対する一般的な解決策は、それらをハッシュしてサブディレクトリのバランスの取れたツリーにすることです。

score 22 · Accepted Answer

誰も言及していないことは、DBがアトミックアクション、トランザクションの整合性を保証し、同時実行性を処理するということです。参照の整合性でさえ、ファイルシステムのウィンドウの外にあります-それで、ファイル名が本当にまだ正しいことをどうやって知るのですか？

ファイルシステムに画像があり、新しいバージョンを書いているとき、またはファイルを削除しているときに誰かがファイルを読んでいる場合、どうなりますか？

BLOBを使用するのは、管理（バックアップ、レプリケーション、転送）も簡単だからです。彼らは私たちのためにうまく機能します。

score 20 · Accepted Answer

画像へのファイルパスのみをデータベースに保存する場合の問題は、データベースの整合性を強制できなくなることです。

ファイルパスが指す実際のイメージが使用できなくなった場合、データベースに無意識のうちに整合性エラーが発生します。

画像は求められている実際のデータであり、ある種のファイルシステムとインターフェイスする必要がなく（ファイルシステムに個別にアクセスする場合）、1つの統合データベースで簡単に管理できます（画像が突然消えることはありません）。画像が突然「消える」可能性があります）、BLOBなどとして直接保存します。

score 17 · Accepted Answer

私が以前働いていた会社では、Oracle 8i (当時は 9i) データベースに 1 億 5,500 万の画像を保存していました。7.5TB相当。

score 14 · Accepted Answer

通常、私は、インフラストラクチャ（データベース）の最も高価で拡張が難しい部分を取り上げて、すべての負荷をそれにかけることに強く反対しています。一方、特に複数のWebサーバーがあり、何らかの方法でデータの同期を維持する必要がある場合は、バックアップ戦略が大幅に簡素化されます。

他のほとんどのものと同様に、それは予想されるサイズと予算に依存します。

score 13 · Accepted Answer

すべての画像を SQL2005 blob フィールドに格納するドキュメントイメージングシステムを実装しました。現時点では数百 GB ありますが、優れた応答時間とパフォーマンスの低下がほとんどまたはまったく見られません。さらに、規制遵守のために、新しく投稿されたドキュメントを標準の NTFS ファイルシステムとして公開する光ジュークボックスシステムにアーカイブするミドルウェア層があります。

特に次の点に関して、結果に非常に満足しています。

レプリケーションとバックアップの容易さ
ドキュメントのバージョン管理システムを簡単に実装する機能

score 11 · Accepted Answer

これがWebベースのアプリケーションである場合、AmazonのS3やNirvanixプラットフォームなどのサードパーティのストレージ配信ネットワークに画像を保存することには利点があります。

score 11 · Accepted Answer

前提: アプリケーションは Web 対応/Web ベース

誰もこれについて実際に言及していないことに驚いています...専門家である他の人に委任してください->サードパーティの画像/ファイルホスティングプロバイダーを使用してください。

次のような有料のオンラインサービスにファイルを保存します。

これについて話している別の StackOverflow スレッドがここにあります。

このスレッドでは、サードパーティのホスティングプロバイダーを使用する必要がある理由について説明します。

それだけの価値があります。彼らはそれを効率的に保管します。サーバーからクライアント要求などにアップロードされる帯域幅はありません。

score 10 · Accepted Answer

SQL Server 2008 を使用しておらず、データベースに特定のイメージファイルを配置する確固たる理由がある場合は、「両方」のアプローチを採用して、ファイルシステムを一時キャッシュとして使用し、データベースをマスターリポジトリとして使用できます。 .

たとえば、ビジネスロジックは、画像ファイルを提供する前にディスク上に存在するかどうかを確認し、必要に応じてデータベースから取得できます。これにより、複数の Web サーバーの機能が得られ、同期の問題が少なくなります。

score 7 · Accepted Answer

保存する画像の数とサイズによって異なります。私は過去にデータベースを使用して画像を保存しましたが、私の経験はかなり良好です。

IMO、データベースを使用して画像を保存することの長所は、

A.画像を保持するためにFS構造は必要ありません
。B。より多くのアイテムを保存する場合、データベースインデックスはFSツリーよりも優れたパフォーマンスを発揮します
。C。スマートに調整されたデータベースはクエリ結果のキャッシュに優れたパフォーマンスを発揮します
。D。バックアップは簡単です。また、レプリケーションが設定されていて、コンテンツがユーザーの近くのサーバーから配信される場合にもうまく機能します。このような場合、明示的な同期は必要ありません。

イメージが小さくなり（たとえば<64k）、データベースのストレージエンジンがインライン（レコード内）BLOBをサポートする場合、間接参照が不要になるため、パフォーマンスがさらに向上します（参照の局所性が実現されます）。

少数の巨大なサイズの画像を扱う場合、画像を保存することは悪い考えかもしれません。画像をdbに保存する際の別の問題は、作成、変更日などのメタデータをアプリケーションで処理する必要があることです。

score 7 · Accepted Answer

これがどれだけ「現実世界」の例であるかはわかりませんが、現在、カードの画像など、トレーディングカードゲームの詳細を保存するアプリケーションがあります。データベースのレコード数は現在までにわずか2851レコードですが、特定のカードが複数回リリースされ、代替のアートワークがあるという事実を考えると、アートワークの「プライマリスクエア」をスキャンしてから動的にスキャンする方が、実際にはサイズ的に効率的でした。要求に応じて、カードの境界線とその他の効果を生成します。

この画像ライブラリの元の作成者は、リクエストに基づいて画像をレンダリングするデータアクセスクラスを作成しました。これは、表示や個々のカードに対して非常に高速です。

これにより、新しいカードがリリースされたときの展開/更新も簡単になります。画像のフォルダー全体を圧縮してパイプに送信し、適切なフォルダー構造が作成されるようにする代わりに、データベースを更新して、ユーザーに再度ダウンロードしてもらうだけです。これは現在最大56MBのサイズであり、これは素晴らしいことではありませんが、将来のリリースに向けてインクリメンタルアップデート機能に取り組んでいます。さらに、アプリケーションの「画像なし」バージョンがあり、ダイヤルアップを使用している場合は、ダウンロードを遅らせることなくアプリケーションを入手できます。

このソリューションは、アプリケーション自体がデスクトップ上の単一のインスタンスとしてターゲットにされているため、これまでうまく機能してきました。このすべてのデータがオンラインアクセス用にアーカイブされているWebサイトがありますが、私はこれに同じソリューションを使用することは決してありません。画像に対して行われるリクエストの頻度と量に合わせて拡張できるため、ファイルアクセスが望ましいことに同意します。

うまくいけば、これはあまり口論ではありませんが、私はこのトピックを見て、比較的成功した中小規模のアプリケーションからの洞察を提供したいと思いました。

score 7 · Accepted Answer

SQL Server 2008 は、両方の長所を備えたソリューションを提供します: filestream データ型。

通常のテーブルのように管理し、ファイルシステムのパフォーマンスを備えています。

score 7 · Accepted Answer

最近、PDF/Word ファイルを MySQL テーブルに格納する PHP/MySQL アプリを作成しました (これまでのところ、ファイルあたり 40MB の大きさです)。

長所：

アップロードされたファイルは、他のすべてのものと一緒にバックアップサーバーに複製されます。個別のバックアップ戦略は必要ありません (安心してください)。
uploads/ フォルダーを用意して、すべてのアプリケーションにその場所を伝える必要がないため、Web サーバーのセットアップは少し簡単になります。
編集にトランザクションを使用してデータの整合性を改善できるようになりました - 孤立したファイルや欠落したファイルについて心配する必要はありません

短所：

テーブルの 1 つに 500MB のファイルデータがあるため、mysqldump には非常に長い時間がかかります。
ファイルシステムと比較すると、全体的にメモリ/CPU効率があまり良くありません

私の実装は成功と言えます。バックアップ要件を処理し、プロジェクトのレイアウトを簡素化します。アプリを使用する 20 ～ 30 人のユーザーにとって、パフォーマンスは問題ありません。

score 6 · Accepted Answer

私の経験では、データベースに保存された画像と、パスがdbに保存されたファイルシステム上の画像の両方の状況を管理する必要がありました。

最初のソリューションであるデータベース内のイメージは、データアクセスレイヤーがデータベースオブジェクトのみを処理する必要があるため、やや「クリーン」です。ただし、これは低い数値を処理する必要がある場合にのみ適しています。

バイナリラージオブジェクトを処理するときのデータベースアクセスパフォーマンスは明らかに低下しており、データベースのサイズが大きくなり、再びパフォーマンスが低下します。通常、データベーススペースはファイルシステムスペースよりもはるかに高価です。

一方、大きなバイナリオブジェクトをファイルシステムに格納すると、データベースとファイルシステムの両方を考慮する必要があるバックアッププランが必要になります。これは、一部のシステムでは問題になる可能性があります。

ファイルシステムを使用するもう 1 つの理由は、画像データ (またはサウンド、ビデオなど) をサードパーティのアクセスと共有する必要がある場合です。「私の Web ファームは、バイナリデータを取得するためのデータベースアクセスが単純に不可能な方法で行われました。そのため、選択を迫る設計上の考慮事項が存在する場合もあります。

また、この選択を行う際に、バイナリオブジェクトにアクセスするときにアクセス許可と認証を処理する必要があるかどうかも考慮してください。通常、これらの要件は、データが db に格納されている場合に、より簡単な方法で解決できます。

score 4 · Accepted Answer

以前のプロジェクトでは、イメージをファイルシステムに保存しましたが、バックアップ、レプリケーション、およびファイルシステムがデータベースと同期しなくなるという問題が発生しました。

私の最新のプロジェクトでは、画像をデータベースに保存し、それらをファイルシステムにキャッシュしていますが、非常にうまく機能しています。これまで問題はありませんでした。

score 4 · Accepted Answer

私はかつて画像処理アプリケーションに取り組んでいました。アップロードした画像は、/images/[今日の日付]/[ID 番号] のようなディレクトリに保存しました。しかし、画像からメタデータ (exif データ) を抽出し、それをタイムスタンプなどと共にデータベースに保存しました。

score 3 · Accepted Answer

次に、ファイルパスに関する推奨事項。私は大規模なアセットコレクションを管理する必要のあるいくつかのプロジェクトに取り組んできましたが、DBに直接保存しようとすると、長期的に苦痛とフラストレーションが生じました。

それらをDBに保存することに関して私が考えることができる唯一の本当の「プロ」は、個々の画像アセットを簡単にする可能性です。使用するファイルパスがなく、すべての画像がDBから直接ストリーミングされる場合、ユーザーがアクセスしてはならないファイルを見つける危険はありません。

ただし、Webにアクセスできないファイルストアからデータをプルする中間スクリプトを使用すると、より適切に解決できるようです。したがって、DBストレージは本当に必要ではありません。

score 3 · Accepted Answer

巷では、あなたのデータベースがそれを実行できることを証明しようとしているデータベースベンダーでない限り (たとえば、Microsoft が Terraserver が SQL Server に膨大な数の画像を格納していると自慢しているとしましょう)、それはあまり良い考えではありません。別の方法として、画像をファイルサーバーに保存し、パスをデータベースに保存する方がはるかに簡単なのに、わざわざわざわざする必要はありません。ブロブフィールドは、SUV のオフロード機能のようなものです。ほとんどの人はそれらを使用しません。通常はトラブルに巻き込まれる人がいますが、楽しむために使用する人もいます。

score 3 · Accepted Answer

画像をデータベースに保存すると、画像データは最終的にファイルシステムのどこかに保存されますが、直接アクセスできないように隠されます。

+ves:

データベースの整合性
イメージが追加または削除されたときにファイルシステムの同期を維持することを心配する必要がないため、管理が簡単です

-ves:

パフォーマンスの低下 -- 通常、データベースのルックアップはファイルシステムのルックアップよりも遅くなります
画像を直接編集することはできません（トリミング、サイズ変更）

どちらの方法も一般的であり、実践されています。長所と短所をご覧ください。いずれにせよ、デメリットを克服する方法を考える必要があります。データベースに保存するということは、通常、データベースパラメータを微調整し、何らかのキャッシュを実装することを意味します。ファイルシステムを使用するには、ファイルシステムとデータベースを同期させる何らかの方法を見つける必要があります。

score 2 · Accepted Answer

私は、一部の顧客が数百ギガバイトのドキュメントを保存するエンタープライズドキュメント管理システムのリード開発者です。それほど遠くない将来のテラバイト。このページに記載されている多くの理由に加えて、アーカイブという別の理由から、ファイルシステムアプローチを使用しています。

お客様の多くは、光ディスクへのストレージや非独占的な形式でのストレージなど、業界固有のアーカイブルールに準拠する必要があります。さらに、NASデバイスにディスクを追加するだけの柔軟性があります。SQL Server 2008のファイルストリームデータ型を使用している場合でも、データベースにファイルを保存している場合は、アーカイブオプションが大幅に狭くなります。

score 1 · Accepted Answer

Webサーバー（使用していると想定しています）は、データベースではなく画像を処理するように設計されています。したがって、私は反対側に強く投票します。

パスだけ（そしておそらくファイル情報も）をデータベースに保存します。

score 1 · Accepted Answer

私は個人的に大きなデータをデータベースの外に保存します。

長所：すべてを1つに保存してください、データファイルへの簡単なアクセス、簡単なバスクアップ短所：データベースのパフォーマンスの低下、多くのページ分割、データベースの破損の可能性

score 1 · Accepted Answer

画像をテーブルに保存する唯一の理由は、各テーブル（または作業範囲ごとのテーブルのセット）が一時的であり、ワークフローの最後に削除されるためです。長期的なストレージがある場合は、ファイルパスを保存することを選択します。

また、内部でクライアント/サーバーアプリケーションを操作するため、心配する必要のあるWebインターフェイスがないことにも注意してください。

score 1 · Accepted Answer

ファイルシステムに多数の画像を保存する必要がある場合は、次の点について検討する必要があります。

バックアップと復元。どのように画像を同期させますか。
ファイルシステムのパフォーマンス。実行内容とファイルシステムによって異なりますが、ハッシュメカニズムを実装して、1 つのディレクトリに何十億ものファイルが存在しないようにすることをお勧めします。
複製。複数のサーバー間でファイルの同期を維持する必要がありますか?

score 1 · Accepted Answer

誰かがすでに述べたように、「場合による」。データベース内のストレージがファイルシステムの 1 対 1 の派手な代替品であると想定されている場合、それは最適なオプションではない可能性があります。

ただし、データベースバックエンドが BLOB のシリアル化とストレージだけでなく、追加の値を提供する場合、それは本当に理にかなっています。

PostgreSQLデータベースシステムの地理空間拡張として機能するPostGISでのラスターサポートの開発を目的としたプロジェクトであるWKT Rasterをご覧ください。WKT Raster の背後にあるアイデアは、(PostgreSQL システムを使用して) ラスターのシリアル化とストレージの形式を定義することだけではなく、ストレージよりもはるかに重要なことは、SQL からアクセスできるデータベース側の効率的な画像処理を指定することです。簡単に言うと、運用上の重みをクライアントからデータベースのバックエンドに移すことであり、可能な限りストレージ自体に近い場所で行われます。PostGIS としての WKT Raster は、特定のドメインGISのアプリケーション専用です。

より完全な概要については、システムのWeb サイトとプレゼンテーション(PDF) を確認してください。

score 0 · Accepted Answer

SQLを使用してファイルシステムを模倣しようとすることは、一般的に悪い計画です。外部ストレージ用のファイルシステムを使用する場合、最終的には、記述するコードが少なくなり、同等以上の結果が得られます。

score 0 · Accepted Answer

DBから大量のバイナリデータをネットワーク経由でプルすると、遅延の問題が発生し、拡張性が低下します。

パスをDBに保存し、Webサーバーに負荷をかけてもらいます。これが設計された目的です。

score 0 · Accepted Answer

画像をファイルシステムに保存するもう 1 つの利点は、クライアントに画像をキャッシュさせるために特別なことをする必要がないことです...

...もちろん、ドキュメントルート (認証バリアなど) 経由で画像にアクセスできない場合を除きます。その場合、コードが送信しているキャッシュ制御ヘッダーを確認する必要があります。

score 0 · Accepted Answer

覚えておく必要があることの 1 つは、データセットのサイズです。私は、Dillie-O だけが遠く離れたところからでも的を射ていたと信じています。

小規模でシングルユーザーの消費者向けアプリの場合は、DB. 私はファイルシステム (Program Files 内) を使用する DVD 管理アプリを持っています。これはバックアップする PIA です。彼らがそれらをデータベースに保存するたびに、そのファイルを保存する場所を選択できるようにしたいと思っています。

より大きな商用アプリケーションの場合、私は考えを変え始めます。私は以前、郡書記情報管理アプリケーションを開発した会社で働いていました。画像は、郡が割り当てた機器番号に基づいて [多数のファイルを使用した FS の問題に対処するため] エンコードされた形式でディスクに保存します。これは、DB レコードの前にイメージが存在する可能性があるため (ワークフローにより)、別の面で役立ちました。

ほとんどのものと同様に、「あなたが何をしているかによります」

score 0 · Accepted Answer

私は両方のソリューションに行きます。つまり、画像をDBに保存する小さなコンポーネント（EJB）と、この画像のサーバーへのパスを開発します。この DB は、新しいイメージまたは元のイメージが更新された場合にのみ更新されます。次に、そのパスもビジネス DB に格納します。

アプリケーションの観点から、私は常にファイルシステムを使用し (ビジネス DB からパスを取得します)、これによりバックアップの問題を修正し、パフォーマンスの問題を回避します。

唯一の弱点は、同じ画像を 2 回保存することです...良い点は、メモリが安価であることです。

score 0 · Accepted Answer

私はファイルシステムのアプローチを採用します。画像を含む DB を作成または維持する必要はありません。長い目で見れば、いくつかの大きな頭痛の種から解放されます。

score 0 · Accepted Answer

確かにファイルシステム。その後、OS のすべての機能を使用してこれらのイメージを処理できます。バックアップ、Web サーバー、さらには imagemagic などのツールを使用してバッチ変更をスクリプト化することもできます。それらを DB に保存する場合は、これらの問題を解決するために独自のコードを作成する必要があります。

score 0 · Accepted Answer

イメージパスを DB に格納し、イメージをファイルシステムに格納することを好みます (サーバー間の rsync を使用して、すべてを適切に最新に保ちます)。

ただし、私が行っているコンテンツ管理システムの一部には、いくつかの理由で CMS の画像が必要です。たとえば、可視性の制御 (プレスリリースが公開されるまで資産が保持されるため)、バージョン管理、再フォーマット (一部の CMS は動的にサイズ変更されるため) です。サムネイル) と、画像を WYSIWYG ページにリンクするための使いやすさ。

したがって、私にとっての経験則は、CMS 駆動でない限り、常にアプリケーションのものをファイルシステムに隠しておくことです。

score 0 · Accepted Answer

主に柔軟性が優れているため、ファイルシステムアプローチを使用します。画像の数が膨大になると、1 つのデータベースでは処理しきれない場合があることを考慮してください。ファイルシステムを使用すると、NFS などを使用していると仮定して、ファイルサーバーを簡単に追加できます。

ファイルシステムアプローチのもう 1 つの利点は、Amazon S3 をプライマリストレージとして使用できる (ファイルパスの代わりにデータベースに URL を保存する) など、いくつかの凝った機能を実行できることです。S3 で障害が発生した場合は、ファイルサーバーにフォールバックします (ファイルパスを含む別のデータベースエントリである可能性があります)。Apache や使用している Web サーバーに適用するためのいくつかのブードゥー教。

score 0 · Accepted Answer

小さな画像が多数ある場合は、データベースの方が適している場合があります。

多くの小さなサムネイル (それぞれ 2Kb) を持つアプリケーションがありました。それらをファイルシステムに配置すると、ファイルシステムのブロックサイズが原因で、それぞれが 8kb を消費しました。スペースが400%増加！

ブロックサイズの詳細については、次の投稿を参照してください: iPhone ファイルシステムのブロックサイズとは何ですか?

score 0 · Accepted Answer

Teradata を使用している場合は、Teradata Developer Exchange に、LOB と BLOB の読み込みと取得に関する詳細な記事があります。

http://developer.teradata.com/applications/articles/large-objects-part-1-loading

score 0 · Accepted Answer

私は多くのデジタルストレージシステムを使用してきましたが、それらはすべてデジタルオブジェクトをファイルシステムに格納しています。彼らはブランチアプローチを使用する傾向があるため、ファイルシステムにはアーカイブツリーがあり、多くの場合は 2009 年などのエントリの年から始まり、サブディレクトリは月 (8 月などは 8)、次のディレクトリは 11 日などになります。同様に、ファイルにはレコードの永続 ID を使用して名前が付けられます。BLOBS の使用には利点があり、数千または数百万の写真や図を保存するために、化学業界の IT 部門で頻繁に使用されていると聞いています。よりきめ細かなセキュリティ、単一のバックアップ方法、潜在的に優れたデータ整合性、改善されたメディア間検索を提供できます。Oracle は、以前 Intermedia と呼んでいたパッケージ内に、このための多くの機能を備えています (現在は別の名前になっていると思います)。ファイルシステムには、XACML や別の XML タイプのセキュリティオブジェクトなどのシステムを介して提供されるきめ細かなセキュリティを設定することもできます。例については、Fedora Object Store の D Space を参照してください。

score 0 · Accepted Answer

0

データのデータベース

ファイルのファイルシステム

于 2009-03-02T07:14:31.100 に答える

score -1 · Accepted Answer

一般向けの Web サイトを計画している場合は、どちらのオプションも使用しないでください。コンテンツ配信ネットワーク (CDN) を使用する必要があります。インターネット経由で大量の静的コンテンツを配信する場合、CDN には価格、スケーラビリティ、速度の利点があります。

score -1 · Accepted Answer

私はファイルシステムのアプローチを採用します。他の何人かが指摘しているように、ほとんどの Web サーバーは、ファイルパスから画像を送信するように構築されています。データベースから BLOB フィールドを書き込んだり、ストリーミングしたりする必要がなければ、パフォーマンスが大幅に向上します。画像用のファイルシステムストレージを使用すると、コンテンツが変更されていない場合や、データベースの負荷を制限したい場合に、静的ページを簡単にセットアップできます。

score -1 · Accepted Answer

私の小さなアプリケーションには、最終的に約 200 GB の重さの少なくとも 100 万個のファイルがあります。すべてのファイルは、iSCSI 経由で Linux サーバーにマウントされた XFS ファイルシステムに置かれています。パスはデータベースに保存されます。ファイルパスとファイル名には、ある種のインテリジェントな命名規則を使用してください。

私見、本来の目的であるファイルシステムを使用して、ファイルを保存します。通常、データベースは、バイナリデータの格納において、標準のファイルシステムに勝る利点はありません。

score -1 · Accepted Answer

ファイルストア上のイメージは最善の策であり、データベースにメタデータを格納することでこれを補完します。Web サーバーの観点から見ると、コンテンツを提供するための迅速な方法は、それを直接指定することです。それがデータベース内にある場合-ala Sharepoint-それを引き出したり、ストリーミングしたりするためのADO.Netのオーバーヘッドがあります。

Documentum は肥大化して複雑ではありますが、ファイルが共有上にあり、ファイルをサーバー、SAN、NAS などのディスクに保存する方法を決定できるという点で適切です。Documentum の戦略は、DB 内の主キーに従ってフォルダーとファイル名をエンコードすることにより、ファイルをツリー構造に格納することです。DBは、どのファイルが何であるかを知り、セキュリティを強化するためのリソースになります。大容量システムの場合、このタイプのアプローチは適切な方法です。

メタデータを扱うときは、これも考慮してください。メタデータコーパスの属性を更新する必要が生じた場合、SQL を使用して更新をすばやく実行できる DB が役に立ちます。他のタグ付けシステムでは、簡単なデータ操作ツールが手元にありません

score -1 · Accepted Answer

現在のアプリケーションでは、両方を行っています。ユーザーがレコードに添付する画像を特定したら、ImageMagick を使用して、画面に表示するのに適切なサイズ (私のアプリケーションでは約 300x300) にサイズを変更し、アクセスしやすいようにデータベースに保存します。元のファイルをネットワーク共有に転送して、より高い解像度を必要とするアプリケーション (印刷など) で使用できるようにします。

(他にもいくつかの要因が関係しています。Navision は BMP のみを表示するため、サイズを変更するとストレージ用に BMP にも変換されます。データベースは、画像を表示できると便利なリモートサイトに複製されます。印刷本社でのみ行うため、元のファイルを複製する必要はありません。)

score -1 · Accepted Answer

いいえ、ページ分割のためです。基本的に、1KB - n MB の行を定義しているため、データベースのページには多くの空きスペースがあり、パフォーマンスが低下します。

database - DBに画像を保存する-そうですか、それともそうですか？

56 に答える 56

Related

Reference