ASP.Net MVCサイトを作成しています。このサイトには、サイズが約2k〜5kの100万枚以上の写真を保存する必要があります。以前の調査から、ファイルサーバーはおそらくデータベースよりも優れているようです（そうでない場合はコメントしてください）。
これだけ多くのファイルを保存するときに考慮すべき特別なことはありますか？1つのフォルダに非常に多くのファイルがある場合、Windowsが写真をすばやく見つけることができるという問題はありますか？セグメント化されたディレクトリ構造を作成する必要がありますか？たとえば、ファイル名で分割しますか？将来の拡張ニーズに備えて、ソリューションを少なくとも1,000万枚の画像に拡張できると便利です。
4Kbは、NTFSのデフォルトのクラスタサイズです。通常の画像サイズに応じて、この設定を調整できます。 http://support.microsoft.com/kb/314878
あるFSから別のFSに移動できるように、サブディレクトリを使用してツリーを構築します。ディレクトリにいくつのファイルを配置できますか？ いくつかの問題を回避します：http：//www.frank4dd.com/howto/various/maxfiles-per-dir.htm
関連する画像を含むアーカイブを作成して、1つのファイルだけを開いた状態で画像をロードすることもできます。これらのアーカイブは圧縮されている可能性があります。ボトルネックはI/Oであり、CPUの場合は非圧縮です。
DBは保守が簡単ですが、時間がかかります...だから、それはあなた次第です！
ディレクトリ構造に関する説明については、このサーバー障害の質問も参照してください。
問題は、ファイルシステムがディレクトリにそれほど多くのファイルを保存できないことではなく、Windowsエクスプローラを使用してそのディレクトリにアクセスする場合は永久に時間がかかるため、そのフォルダに手動でアクセスする必要がある場合は、セグメント化する必要がありますたとえば、名前の最初の2〜3文字/数字ごとにディレクトリがあり、さらに深い構造になっています。
それを1k個のファイルで1k個のフォルダーに分割できれば、それぞれで十分であり、それを行うためのコードは非常に単純です。
私はコンテンツ配信ネットワークを使用することを除外しません。これらはこの問題のために設計されています。私はAmazonS3で多くの成功を収めてきました。Microsoftベースのソリューションを使用しているので、おそらくAzureが適している可能性があります。
サードパーティのソリューションを使用できないようにする何らかの要件はありますか？
NTFSを想定すると、ボリュームあたり40億ファイルの制限があります（2 ^ 32-1）。これは、ボリューム上のすべてのフォルダー（オペレーティングシステムファイルなどを含む）の合計制限です。
1つのフォルダに多数のファイルがある場合は問題ありません。NTFSは、高速検索のためにB+ツリーを使用します。ショートファイル名の生成（mypictureofyou.htmlをmypic〜1.htmとして取得できる機能）を無効にすることをお勧めします。
それらを複数のディレクトリにセグメント化することにパフォーマンス上の利点があるかどうかはわかりません。NTFSは大規模なディレクトリでのパフォーマンスを目的として設計されているため、利点はないと思います。
それらを複数のディレクトリに分割する場合は、ファイル名のハッシュ関数を使用してディレクトリ名を取得し（たとえば、ディレクトリ名がファイル名の最初の文字になるのではなく）、各サブディレクトリの番号がほぼ同じになるようにします。ファイルの。