解決策 1:
この種のディレクトリ構造を作成する理由は、ファイルシステムがディレクトリ内のファイルを見つける必要があり、ディレクトリが大きくなるほど、その操作が遅くなるためです。
どれだけ遅くなるかは、ファイルシステムの設計によって異なります。
ext4 ファイルシステムは、B ツリーを使用してディレクトリ エントリを格納します。このテーブルの検索には O(log n) かかると予想されます これはほとんどの場合、ext3 や以前のファイルシステムで使用されていた素朴な線形テーブルよりも短い時間です (そうでない場合は、ディレクトリが小さすぎて問題になりません)。
XFS ファイルシステムは代わりに B+tree を使用します。ハッシュ テーブルや B ツリーに対するこの利点は、ノードが複数の子を持つ可能性があることです b 、XFS では b 変動し、最大で 254 (またはルート ノードの場合は 19。これらの数値は古くなっている可能性があります) になる場合があります。これにより、時間計算量は O(logb n) 、大幅な改善。
これらのファイルシステムはどちらも、1 つのディレクトリで数万のファイルを処理できます。XFS は、同じ数の inode を持つディレクトリで ext4 よりも大幅に高速です。しかし、3M の inode を持つ単一のディレクトリはおそらく必要ありません。B+ ツリーを使用した場合でも、ルックアップに時間がかかる可能性があるためです。これが、そもそもこの方法でディレクトリを作成することにつながった理由です。
提案された構造に関しては、最初に指定したオプションは、nginx の例に示されているものとまったく同じです。どちらのファイルシステムでもうまく機能しますが、XFS にはまだ少し利点があります。 2 番目のオプションはパフォーマンスがわずかに優れているか、やや劣っている可能性がありますが、ベンチマークでもかなり近いでしょう。
解決策 2:
私の経験では、スケーリング ファクターの 1 つは、ハッシュ名のパーティション分割戦略が与えられた場合の inode のサイズです。
提案された両方のオプションは、作成されたファイルごとに最大 3 つの inode エントリを作成します。また、732 個のファイルで、通常の 16KB よりもさらに少ない i ノードが作成されます。私にとって、これはどちらのオプションも同じように機能することを意味します。
あなたの短いハッシュに拍手を送ります。私が取り組んだ以前のシステムでは、指定されたファイルの sha1sum を取得し、その文字列に基づいてディレクトリを接合していましたが、これははるかに難しい問題でした.
解決策 3:
確かに、どちらのオプションも、ディレクトリ内のファイル数を、xfs や ext4 などのファイル システムで妥当と思われる数に減らすのに役立ちます。どちらが優れているかは明らかではありません。テストして判断する必要があります。
実際のワークロードのようなものをシミュレートするアプリケーションのベンチマークが理想的です。それ以外の場合は、多くの小さなファイルを具体的にシミュレートするものを考え出してください。そういえば、これは smallfile と呼ばれるオープンソースのものです。そのドキュメントは他のいくつかのツールを参照しています。
hdparm 持続的な I/O を行うことはあまり役に立ちません。非常に多くのファイルに関連する多くの小さな I/O や巨大なディレクトリ エントリは表示されません。