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

Question

私のプロジェクトにキャッシュを実装中です。あなたのアイデアを得る

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

：キャッシュディレクトリ構造を見た後、私のような多くの例を見てきました。別の例として、ファイルを保存するために、一般的な方法は、名前のディレクトリに置くことで、私たちのファイルがIMG_PARTY.JPG命名されたとしましょう：

files/i/m/IMG_PARTY.JPG 

いくつかの考えが思い浮かびますが、私はのための本当の理由を知りたいのですがこの。

• リテラルルックアップを実行するファイルシステムでは、ディレクトリ内のファイルシステムの数が少ない場合、ファイルの検索が高速になります。そのような構造はファイルを薄く広げます。

• 台無し引数の有限数を取るrmのような* nixのユーティリティをしないようにして、一度に多数のファイルを削除する（findなどものの、それに合格する必要が）ハックする傾向がある

本当の理由は何ですか？ 「良い」キャッシュディレクトリ構造とは何ですか？なぜですか？

Answer 1

私がやったたびに、ファイルシステムの線形検索が遅くなるのを避けることができました。幸いにも、少なくともLinuxでは、これは過去のものになっています。

しかし、今日でさえも、bツリーベースのディレクトリでは、すべてのファイルのリストを取得するのに永遠に1日かかるので、非常に大きなディレクトリは扱いにくいでしょう。ファイル。

Answer 2

日付のみを使用してください。あなたは日付で削除するので。 :)

Answer 3

ls -lを実行すると、詳細を取得するためにすべてのファイルがstat()になる必要があります。これは、リストの作成時間にかなり追加されます。これは、FSがハッシュ構造または線形構造を使用する場合に発生します。 FSは非常に大規模なディレクトリのサイズに対処する能力を持っている場合でも

だから、（彼らはまた、バックアップする豚だ）大型フラットな構造を持っていない理由があります

私はGFS2をベンチマークしました（クラスタ化された）ディレクトリ内に32,000個のファイルがあるか、ツリー構造に整理されている - 再帰的なリストは、すべてがフラットな構造になっていたときにリスティングを取得するより約300倍高速でした（ディレクトリリストを取得するのに最大10分かかることがありました）

EXT4も同様の比率を示しましたが、エンドポイントが数秒でほとんどの人が気づかないほどでした。