私はこの点に関していくつかの投稿を読みましたが、私の場合の最善の解決策がまだわかりません。
私は新しいwebAppを書き始めており、バックエンドは約100万から1000万の画像を提供する予定です。（単一画像の平均サイズ200-500kB ）
私のサイトは、コンテンツと画像を100〜1000人のユーザーに同時に提供します。
また、プロバイダーのコストを可能な限り低く抑えたいと思います（ただし、これは二次的な要件です）。DBサイズのコストと比較すると、ファイルシステムのスペースは安価だと思います。
個人的には、すべての画像をDBに入れるというアイデアが好きですが、どんな提案でも本当にありがたいです:)
私の場合、DBアプローチが正しい選択だと思いますか？
これらの画像をすべてデータベースに入れると、非常に大きくなります。これは、DBエンジンが、代わりにホットなアプリケーションデータをキャッシュする可能性がある場合に、これらすべてのイメージ（実際には設計されていないタスク）のキャッシュでビジー状態になることを意味します。
ファイルのキャッシュはOSやリバースプロキシに任せてください。
ファイルシステムに画像を保存するその他の理由：
ほとんどの大規模なサイトはファイルシステムを使用しています。
写真をファイルとして保存するか、Webアプリのデータベースに保存するかを参照してください。
バイナリオブジェクトを処理するときは、アーキテクチャのドキュメント中心のアプローチに従い、PDFや画像などのドキュメントをデータベースに保存しないでください。データベースであらゆる種類のパフォーマンスの問題が発生し始めたら、最終的にはリファクタリングする必要があります。ファイルをファイルシステムに保存し、データベースのテーブル内にパスを設定するだけです。シリアル化してデータベースに保存するために使用するデータ型のサイズにも物理的な制限があります。ファイルシステムに保存してアクセスするだけです。
あなたの最初の文はあなたが主題に関するいくつかの投稿を読んだと言っているので、私はこれをカバーする記事へのリンクをわざわざ入れません。私の経験では、画像の数と画像のサイズに関する投稿内容に基づいて、それらをDBに保存すると、DBのパフォーマンスにかなりの費用がかかります。それらをファイルシステムに保存します。
どのデータベースを使用していますか？MS SQL Server 2008は、FILESTREAMストレージを提供します
SQL Server 2008とNTFSファイルシステムの組み合わせを使用して、BLOBデータの保存と効率的なアクセスを可能にします。BLOBストレージの選択、FILESTREAMデータを使用するためのWindowsおよびSQL Serverの構成、FILESTREAMを他の機能と組み合わせる際の考慮事項、およびパーティション分割やパフォーマンスなどの実装の詳細について説明します。
イメージング用に最適化されたサーバーであるFileNetを使用します。それは非常に高価です。より安価な解決策は、ファイルサーバーを使用することです。
データベースサーバーに大きなファイルを保存することを検討しないでください。
他の人が述べているように、大きなファイルへの参照をデータベースに保存します。