5

巨大なファイルストアのフォルダに名前を付けるためにGUID（uuid）を使用したいと思います。各ストレージアイテムは、独自のフォルダーとGUIDを取得します。最も簡単な方法は、「x：\ items \ uuid \ {uuid} ...」の例です。
例：「x：\ items \ uuid \F3B16318-4236-4E45-92B3-3C2C3F31D44F...」

ここに1つの問題があります。少なくとも10.000のアイテム、おそらく数の100.000以上のアイテムを100万以上取得すると予想される場合はどうなりますか。1つのフォルダにそれほど多くのアイテム（サブフォルダ）を入れたくありません。

GUIDを分割してこれを解決しようと思いました。最初の2文字を取得して、最初のレベルでサブフォルダーを作成し、次の2文字を取得して、サブフォルダーも作成します。上記の例は、-> "x：\ items \ uuid \ F3 \ B1 \6318-4236-4E45-92B3-3C2C3F31D44F..."になります。

guidの最初の4文字が実際に予想どおりにランダムである場合、しばらくすると256フォルダー内に256フォルダーが作成され、これらの各フォルダー内に常に妥当な量のアイテムが含まれるようになります。たとえば、100万個のアイテムがある場合はget-> 1 000000/256/256=フォルダあたり15.25アイテム

過去に、私はすでに最初の文字のランダム性をテストしました。（vb.netアプリ経由）。結果：スプレッドがフォルダー全体で均等に終了するアイテム。また、他の誰かが同じ結論に達しました。.NETで作成されたGUIDの最初の4バイトがどの程度均等に分散されているかを参照してください。

私が考えた可能な分割（例として100万アイテム）C1 = GUIDの文字1、C2=文字2など

  • C1 \ C2\残りのGUID->16 * 16 * 3906（ほぼ4000はまだ多くのフォルダーです）
  • C1 \ C2 \ C3 \ C4 \ Rest of Guid-> 16 * 16 * 16 * 16 * 15（フォルダーの不要な分割）
  • C1C2 \ C3C4 \ Rest of Guid-> 256 * 256 * 15（私にとって最良のオプション？）
  • C1C2C3 \ Rest of Guid-> 4096 * 244（最初のレベルの多くのフォルダーに??）
  • C1C2C3C4 \ Rest of Guid-> 65536 * 15（最初のレベルの多くのフォルダーに！）

私の質問は次のとおりです。

  • 誰かがこの種の実装の欠点を見ていますか？（スキーム：* C1C2 \ C3C4 \ Rest of Guid）
  • GUIDを分割するための標準、またはこれを行う一般的な方法はありますか。
  • 1つのフォルダーに数十万のサブフォルダーを配置するとどうなりますか（可能な場合は分割を使用しないことをお勧めします）

ありがとう、Mumblic

4

1 に答える 1

3

これは、オブジェクトデータベースをシャーディングするために使用するメソッドとかなり似ていgitます（ただし、GUIDの代わりにSHA1ハッシュを使用します...）。他のアルゴリズムと同様に、長所と短所がありますが、この場合、明確な長所を上回る重要な短所はないと思います。ディレクトリ構造を計算するために少し余分なCPUオーバーヘッドがありますが、長期的には、そのオーバーヘッドは、100万ファイルの単一ディレクトリを繰り返し検索するために必要なオーバーヘッドよりもおそらく大幅に少なくなります。

それを行う方法に関しては、GUIDを生成するために使用しているライブラリに少し依存します-struct表示するために文字表現に変換する必要があるバイト配列（または）形式でそれらを取得しますか？それとも、すでにフォーマットされたASCII配列でそれらを取得しますか？前者の場合、適切なバイトを抽出して自分でフォーマットする必要があり、後者の場合は、部分文字列を抽出するだけです。

極端な数のサブフォルダー（またはファイル）を1つのフォルダーに配置する限り、正確なパフォーマンス特性は、使用している実際のファイルシステムに大きく依存します。一部のディレクトリは他のディレクトリよりもパフォーマンスが優れていますが、ほとんどすべてのディレクトリで、各ディレクトリのエントリが多いほどパフォーマンスが大幅に低下します。

于 2012-12-12T15:55:43.050 に答える