私たちのサイトでは、ユーザーは多くのプライベート ファイルを持つことができます。サーバーのパフォーマンスを損なわないように最適なディストリビューションを考えています。これらのファイルは Apache を介して提供され、ユーザーがファイルを管理する必要があるたびに一覧表示する必要があります。
現在の最初のアプローチは次のとおりです。
var first_level = (int) $user_id/100;
var files_folder = /uf/$first_level/$user_id
これにより、第 1 レベルの 100 個のフォルダーと多数の第 2 レベルのフォルダーができます。すべてのユーザーがファイルを持っているわけではなく、現在約 80,000 人のユーザーがいるため、これは第 2 レベルのフォルダーあたり約 800 個のフォルダーを意味します。
このアプローチについてどう思いますか？
読みやすさを気にしない場合に人気のあるスケーラブルなフォルダー命名スキームは、squidが使用するようなものです：<4-bit>/<8-bit>/<remaining-116-bit-of-md5-of-whatever-lookup-key>または<whatever-unique-key-you-have>、したがって、ユーザーID 1の場合、フォルダーパスは/ c4 / ca42/1になります。
この場合、第1レベルは最大16ディレクトリ、第2レベルは最大256ディレクトリです。
このアプローチの大きな利点は、ユーザーID /ユーザー名に穴またはクラスターがあるかどうかに関係なく、フォルダーの分布が統計的に均一であるということです（小さいユーザーIDは、減少により未使用になる傾向があります）。
ファイルを保存するためにどのファイルシステムが使用されているかはわかりません。実際の負荷に期待される特性を備えたランダムなディレクトリツリーを簡単に作成できるはずです。次に、検討しているさまざまな戦略のパフォーマンスを示す実験を実行できます。
どのファイルシステムが大きなディレクトリのBツリーのような効率的なデータ構造を使用しているかについての情報を簡単に見つけることができませんでした。私はMacOSHFSがそうしているという主張を見つけました。XFSまたは別の高性能なジャーナリングファイルシステムを調べます。
ユーザーIDの値がかなり均一に分散されていて、その数が増え続ける場合は、ツリーのバランスをもう少し調整する必要があります。何が最善かは、数の観点からどこに行き着くかによって部分的に異なります。大きなディレクトリは小さなディレクトリよりも検索に時間がかかります。800ファイルはひどいものではありませんが、それも素晴らしいものではありません。2つの層を使い続けたい場合で、（ターゲット母集団として）N人のユーザーがいる場合は、最初の層にsqrt （N）フォルダーを配置し、各2番目の層のディレクトリにsqrt（N）フォルダーを配置する必要があります。Nの場合= 80,000、つまりレベルごとに約300個のフォルダーを意味します。3層の配置を検討する場合は、平方根を立方根に置き換えます。また、モジュロ演算を使用すると、よりスムーズな分布が得られる場合があります。つまり、最初のレベルは次のように計算する方が適切な場合があります。
var first_level = (int) ($user_id % 300);
未確認の言語がモジュロ演算子に％を使用していると仮定します。
CPANは、3つの層に基づくシステムを使用します。最初の層はユーザーのログインIDの最初の文字です。2番目の層は最初の2文字で、3番目の層は完全なログインIDです。
あるサイト（大学ベース、IIRC）が、名前の最初と最後の文字が優れたシステムを提供していることを発見したことをどこかで読みました。