キャッシュディレクトリ構造

Question

私は自分のプロジェクトにキャッシュを実装しているところです。キャッシュのディレクトリ構造を調べてみると、次のような例がたくさんありました。

cache
cache/a
cache/a/a/
cache/a/...
cache/a/z
cache/...
cache/z
...

わかりますね。ファイルを保存する別の例です。ファイルの名前が次のとおりであるとします。 IMG_PARTY.JPG, 、一般的な方法は、次の名前のディレクトリに置くことです。

files/i/m/IMG_PARTY.JPG

いくつかの考えが頭に浮かびますが、その本当の理由が知りたいです。

• 線形検索を行うファイルシステムは、ディレクトリ内のファイルの数が少ないほど、より速くファイルを見つけます。このような構造により、ファイルは薄く分散されます。

• *nix ユーティリティを台無しにしないようにするには、 rm, 、引数の数が有限であり、一度に大量のファイルを削除するのはハッキングになる傾向があります（ただし、引数を渡す必要があります） find 等。）

本当の理由は何ですか？「適切な」キャッシュ ディレクトリ構造とは何ですか?またその理由は何ですか?

Answer 1

それをやるたびに、ファイルシステムでの遅い線形検索を避けるようになりました。幸いなことに、少なくともLinuxでは、これは過去のものになりつつあります。

ただし、今日でも、bツリーベースのディレクトリでは、非常に大きなディレクトリを扱うのは困難です。すべてのファイルのリストを取得するだけで永遠に1日かかるため、適切なファイルを見つけることを気にしないでください。

Answer 2

日付のみを使用します。日付で削除しますので。 ：）

Answer 3

もし、するなら ls -l, 、すべてのファイルが stat()詳細を取得するために必要なため、リストにかかる時間が大幅に増加します。これは、FS がハッシュ構造を使用しているか、線形構造を使用しているかに関係なく発生します。

したがって、たとえ FS が信じられないほど大きなディレクトリ サイズに対処する能力を備えていたとしても、大規模なフラット構造を持たないには十分な理由があります (それらはバックアップするのにも大変です)。

ディレクトリ内またはツリー構造に配置された 32,000 個のファイルを使用して GFS2 (クラスター化) のベンチマークを実行しました。再帰的なリストは、すべてがフラット構造にある場合にリストを取得するよりも約 300 倍高速でした (リストを取得するのに最大 10 分かかる場合があります)ディレクトリリスト)

EXT4 も同様の比率を示しましたが、エンドポイントがわずか数秒だったので、ほとんどの人は気付かないでしょう。