70,000 個の静的ファイル (jpg) を提供する最適な方法は何ですか?

Question

nginx を使用して約 70,000 個の静的ファイル (jpg) を提供する必要があります。これらをすべて 1 つのディレクトリにダンプする必要がありますか、それとももっと良い (効率的な) 方法がありますか? ファイル名は数値なので、次のようなディレクトリ構造を検討しました。

xxx/xxx/xxx

OSはCentOS5.1です

Answer 1

ベンチマーク、ベンチマーク、ベンチマーク！おそらく有意差なし2 つのオプションを比較すると、他の問題に時間を費やした方がよいことがわかります。ベンチマークを行っても実際の違いが見つからない場合は、プログラムだけがファイルにアクセスする必要がある場合にコーディングしやすいスキーム、または、頻繁にファイルを操作する必要がある場合に人間が操作しやすいスキームのどちらか、より簡単なスキームを選択します。

どちらが速いかという点については、ディレクトリの検索時間は、ディレクトリ内のファイル数の対数に比例すると思います。したがって、ネストされた構造の 3 つの検索はそれぞれ 1 つの大きな検索よりも速くなりますが、3 つの検索の合計はおそらく長くなります。

でも、私を信じないでください。私は自分が何をしているのか全く分かっていません!パフォーマンスを測定する重要なときに！

Answer 2

実際には、ファイルを保存するために使用しているファイル システムによって異なります。

一部のファイルシステム (ext2 や、程度は低いが ext3 など) では、1 つのディレクトリに何千ものファイルがある場合、速度がひどく低下するため、サブディレクトリを使用することは非常に良い考えです。

XFS や reiserfs(*) などの他のファイルシステムでは、1 つのディレクトリに何千ものファイルがあっても速度が低下しないため、1 つの大きなディレクトリがある場合でも、多数の小さなサブディレクトリがある場合でも問題はありません。

(*) reiserfs には優れた機能がいくつかありますが、これは実験的なおもちゃであり、壊滅的な失敗の歴史があります。少しでも重要な用途には使用しないでください。

Answer 3

他の人が言っているように、ディレクトリ ハッシュが最も最適である可能性が非常に高いです。

私がお勧めするのは、URIを独立したnginx の rewrite モジュールを使用して、使用するディレクトリ スキームを変更します。たとえば、example.com/123456.jpg を /path/12/34/123456.jpg にマップします。

パフォーマンス上の理由でディレクトリ構造を変更する必要がある場合は、公開された URI を変更せずに変更できます。

Answer 4

nginx サーバーの前面に squid キャッシュを配置できます。squid は、人気のある画像をメモリ内に保持するか、独自のファイル レイアウトを使用して高速検索を行うことができます。

Squid の場合、デフォルトはレベル 1 のディレクトリが 16 個、レベル 2 のディレクトリが 256 個です。これらは、私のファイル システムでは妥当なデフォルトです。

Squid のような製品を使用せず、独自のファイル構造を作成する場合は、ファイルに適したハッシュ アルゴリズムを用意する必要があります。ファイル名がランダムに生成される場合は簡単です。ファイル名自体を使用してバケットに分割できます。すべてのファイルが IMG_xxxx のような場合は、最下位桁を使用するか、ファイル名をハッシュしてそのハッシュ番号に基づいて分割する必要があります。