さて、PostgreSQL を実行する Linux バックエンドを使用して、C#.NET で記述されたフロント エンドを備えた Windows ボックスにイメージを提供するアプリケーションに取り組んでいますが、フロント エンドはほとんど重要ではありません。私の質問は：
画像はそれぞれ約 4 ～ 6 メガピクセルで、3000 以上を保存しています。これは Web アプリケーションではないことに注意してください。一度にデータベースにアクセスするフロントエンドはせいぜい 2 つです。
2012年に更新すると、すべてのアプリケーションで画像サイズと画像数がどんどん増えています...
サムネイルのように、「元の画像」と「処理された画像」を区別する必要があります。
Jcobyの答えが言うように、2つのオプションがあるので、私はお勧めします:
blob (Binary Large OBject) を使用: テーブルで元の画像を保存します。Ivan の回答 (ブロブのバックアップに問題はありません!)、PostgreSQL の追加提供モジュール、ハウツーなどを参照してください。
DBlinkで別のデータベースを使用します: 別の (統合/特殊化された) データベースで、元のイメージ ストアに使用します。この場合、私はbyteaを好みますが、blob はほぼ同じです。データベースを分離することは、「統合されたイメージ Web サービス」にとって最良の方法です。
bytea (BYTE 配列) を使用: サムネイル画像のキャッシュ用。小さな画像をキャッシュして Web ブラウザーに高速で送信し (レンダリングの問題を回避するため)、サーバーの処理を減らします。幅や高さなどの重要なメタデータもキャッシュします。データベース キャッシングが最も簡単な方法ですが、ニーズとサーバー構成 (Apache モジュールなど) を確認してください。ファイル システムにサムネイルを保存する方が良い場合があります。パフォーマンスを比較してください。これは (統合された) Web サービスであり、(バックアップなしで) 別のデータベースに保存して、多くのテーブルを提供できることを思い出してください。PostgreSQL binary data types manual、tests with bytea columnなども参照してください。
注 1: 今日、「デュアル ソリューション」(データベース + ファイルシステム)の使用は推奨されません (!)。デュアルの代わりに「データベースのみ」を使用することには多くの利点があります。PostgreSQL には、同等のパフォーマンスと、エクスポート/インポート/入力/出力用の優れたツールがあります。
注 2: PostgreSQL には bytea しかなく、デフォルトの Oracle のBLOBがないことに注意してください。
EDIT 2014 : 今日、上記の元のテキストを変更していません (私の回答は 12 年 4 月 22 日で、現在 14 票あります)。校正のために、変更の回答を開いています (「Wiki モード」を参照してください。編集できます!)。および更新用。質問は安定しています (@Ivans の '08 回答で 19 票)。このテキストの改善にご協力ください。
jcobyの答えについて：
bytea が「通常の」列であることは、フェッチ時に値が完全にメモリに読み込まれることも意味します。対照的に、ブロブは標準出力にストリーミングできます。これは、サーバーのメモリ フットプリントを削減するのに役立ちます。特に、4 ～ 6 MPix の画像を保存する場合。
BLOB のバックアップに問題はありません。pg_dump は、大きなオブジェクトをバックアップに含めるための「-b」オプションを提供します。
したがって、私は pg_lo_* を使用することを好みます。
再クリス・エリクソンの答え：
私は反対だと思います:)。保存するデータが画像だけでない場合は、どうしても必要な場合を除き、ファイル システムに保存しないでください。データの一貫性を常に確保し、データを「一体型」(DB) に保持することは、非常に大きなメリットです。ところで、PostgreSQL は一貫性を維持するのに優れています。
しかし、実際には、多くの場合、パフォーマンスが要求されすぎることが多く、ファイル システムからバイナリ ファイルを提供する必要があります。しかし、それでも私はDBをバイナリの「マスター」ストレージとして使用し、他のすべての関係を一貫してリンクし、パフォーマンスの最適化のためにファイルシステムベースのキャッシュメカニズムを提供する傾向があります。
データベースには、次の 2 つのオプションがあります。
私は bytea 列を使用して、過去に数千行の 10 GB 以上の画像を保存して大成功を収めました。PG の TOAST 機能は、blob が持つ利点をほとんど無効にします。いずれの場合も、ファイル名、コンテンツ タイプ、ディメンションなどのメタデータ列を含める必要があります。
10 年後の更新 2008 年には、データベースを実行するハード ドライブは、ファイルを保存するディスクとは特性が大きく異なり、コストもはるかに高くなります。最近では、10 年前には存在しなかったファイルを保存するためのはるかに優れたソリューションが存在するため、このアドバイスを取り消して、このスレッドの他の回答のいくつかを参照するよう読者にアドバイスします。
オリジナル
どうしても必要な場合を除き、画像をデータベースに保存しないでください。これが Web アプリケーションではないことは理解していますが、データベース内のファイルの場所を保存するために指定できる共有ファイルの場所がない場合。
//linuxserver/images/imagexxx.jpg
次に、Web サーバーをすばやくセットアップして、Web URL をデータベース (およびローカル パス) に保存することができます。データベースは LOB と 3000 の画像 (4 ～ 6 メガピクセル、画像 500K を想定) を処理できますが、1.5 ギグはそれほど多くのスペースではありません。ファイル システムは、データベースよりも大きなファイルを格納するように設計されています。
これを試してください。私はラージ オブジェクト バイナリ (LOB) 形式を使用して生成された PDF ドキュメントをデータベースに格納しましたが、その中にはサイズが 10 MB 以上のものもありましたが、うまく機能しました。