さらに詳しく
最初に、キー名の最初の2バイトと2番目の値の構造を含む2BIdx構造の配列で検索が実行されます：ディレクトリ配列のインデックス（Dir）。 図では、これが一番左の表です。 未定
実際には、2BIdxテーブルは必要ありませんが、その使用により、Dir配列からの選択が高速化されます。
Dirキー配列はリスト構造であり、およそ次のフィールドがあります。
-キー名
-次のリスト項目へのポインタ（またはインデックス）
-Node要素へのポインター（オプションインデックスとして）
-ネストのレベル。
Dirキー配列の次元は2 ^ 16（65536）要素です-言語が許容される場合:(。各配列はメモリプールから動的に割り当てられます。配列のすべての要素の要素番号はパススルーであり、次のように計算されます。
-上位2バイト-配列番号Dir、
-下位2バイト-配列内のインデックス。
配列内のすべてのキーがソートされているため、（mallocを最小化するために）疑似リスト構造が使用されます。
次に、Dir構造からNode構造に入ります。 すべてのノード-2 ^ 16（65536）要素の構造体の配列にあります。 構造要素の番号付けはエンドツーエンドであり、インデックス（＃Node / index）によってノードの位置を計算するアルゴリズムは、Dir配列のアルゴリズムと似ています。
ノード構造 ：
-Dir配列のインデックス（後方リンク）
-ネストレベル
-次に、次のノード（兄弟）のインデックス
-最初-ネストされた構造の最初の要素のインデックス
-データおよびデータ長へのポインター。
データ抽出はアドレスで行われます。 すべてのデータはセパレータなしで積み上げられます。 ダインとデータの最初のバイトのアドレスがわかれば、それを簡単に「抽出」して処理に転送できます。
データブロックが十分でない場合、要求は次のブロックに送信されます。
そのようなスキームを実装しようとします。 誰か他にアイデアはありますか？
スケーリングのアイデア（ああ、私は彼よりはるかに先です）：単一のDir構造を持ちます。私の計算によると、メモリ内で約2Mを占有するはずです。ノードアドレス+サーバー番号を示す必要があります