多数の画像 (および場合によってはビデオ) ファイルを保存するアプリを作成しています。それらがアップロードされると、それらはすぐにクラウド サービス CDN にプッシュされ、実際に公開されます。アイデアは、信頼できるバックアップ可能なストアにイメージを保存することです。それぞれ最大 10KB の 200,000 個のオブジェクトと、場合によっては数 MB の少数のビデオ ファイルを想定しています。
デフォルトでは、ドキュメントが示唆するPostgres に移動します。
Oracle と MySQL で、この方法でデータベースに画像を保存した経験があります。パフォーマンスと信頼性は問題ではありません。バックアップは。バックアップは非常に大きくなります。バックアップには時間と費用がかかるため、容量を節約することをお勧めします。データベースから画像を削除するだけでデータベースを 80% 縮小できる場合は、画像を別の場所に保存することをお勧めします。新しいイメージと変更されたイメージのみを含む増分バックアップを簡単に作成できるため、個別のファイルをバックアップする方が効率的です。
私は PostgreSQL でイメージを ByteA (BLOB のようなデータ型) として格納した経験があり、良い経験であり、イメージを「デュアル ソリューション」(ファイル システムにイメージ、MySQL や PostgreSQL などのデータベースにメタデータ) に格納しましたが、これはお勧めしません。
決定に役立つ 3 つの側面 (アーキテクチャに関する考慮事項) があります。
私はお勧め：
テーブルにblob (間接ストアを使用した Binary Large OBject) として保存する: 元のイメージ ストア用ですが、バックアップは分離されています。Ivan の回答、PostgreSQL の追加提供モジュール、ハウツーなどを参照してください。
bytea (またはblob )として別のデータベース ( DBlinkを使用) に保存する: 元のイメージ ストアの場合は、別の (統合された) データベースに保存します。この場合、私はbyteaを好みますが、blob はほぼ同じです。データベースを分離することは、「統合されたイメージ Web サービス」にとって最良の方法です。
テーブルにbytea (ダイレクト ストア付きの BYTE 配列)として保存: 処理された画像 (通常はサムネイル) をキャッシュします。小さな画像をキャッシュして Web ブラウザーに高速で送信し (レンダリングの問題を回避)、サーバーの処理を減らします。幅や高さなどの重要なメタデータもキャッシュします。データベース キャッシングが最も簡単な方法ですが、ニーズとサーバー構成 (Apache モジュールなど) を確認してください。ファイル システムにサムネイルを保存する方が良い場合があります。パフォーマンスを比較してください。これは (統合された) Web サービスであり、バックアップなしで別のデータベースに格納して、多くのテーブルを提供できることを思い出してください。PostgreSQL binary data types manual、tests with bytea columnなども参照してください。
私の経験は SQL サーバーに限られていますが、データベースには 10 KB を超える数百万の PDF ファイルがあり、それでも非常にうまく機能しています。もちろん索引は必要です。このような量のデータでは、データベースの完全バックアップに予想以上の時間がかかりません。繰り返しますが、これは MS-SQL サーバー用です!