Bツリーデータをディスクにレイアウトする方法は？
B-Treeがメモリ内でどのように機能するかを知っています。実装は簡単です。ただし、現在完全に私を超えているのは、次のように、ディスク上で効果的に機能するデータレイアウトを見つける方法です。
- Bツリーのエントリ数は無限に増える可能性があります（または少なくとも1000GBを超えるまで）
- ディスクレベルのコピー操作が最小限に抑えられます
- 値は任意のサイズにすることができます（つまり、固定スキーマはありません）
誰かがディスクレベルでのBツリー構造のレイアウトについての洞察を提供できれば、私は非常に感謝しています。特に最後の箇条書きは私に多くの頭痛の種を与えます。本へのポインタもいただければ幸いですが、私が見たほとんどのデータベースの文献では、高レベルの構造（つまり、「これがメモリ内での実行方法」）のみを説明していますが、ディスクレイアウトの本質的な詳細はスキップしています。
UPDATE（Oracleインデックス内部のアーカイブバージョン）： http://web.archive.org/web/20161221112438/http://www.toadworld.com/platforms/Oracle/w/wiki/11001.Oracle- b-tree-index-from-the-concept-to-internals
OLD（元のリンクはもう存在しません）：Oracleインデックスの内部に関する情報： http://www.toadworld.com/platforms/Oracle/w/wiki/11001.Oracle-b-tree-index- from-the-concept-to-internals
ノート：
データベースは、Bツリーに基づいてインデックスを直接実装するのではなく、B +ツリーと呼ばれるバリアントに基づいてインデックスを実装します。ウィキペディアによると：
B +ツリーは、各ノードにキーのみが含まれ（キーと値のペアではない）、下部にリンクされたリーフで追加のレベルが追加されたBツリーと見なすことができます。
データベースは一般にブロック指向のストレージで動作し、b +ツリーはbツリーよりも適しています。
ブロックは固定サイズであり、値またはキーサイズの将来の変更に対応するためにいくらかの空きスペースが残されています。
ブロックは、リーフ（実際のデータを保持）またはブランチ（リーフノードへのポインターを保持）のいずれかになります。
ディスクへの書き込みを実装する方法をおもちゃのモデル（算術を簡略化するためのブロックサイズ10kの場合）：
- 10Gのファイルがディスク上に作成されます（1000ブロックあります）
- 最初のブロックはルートとして割り当てられ、次の空きブロックはリーフとして割り当てられ、リーフアドレスのリストがルートに配置されます
- 新しいデータが挿入されると、現在のリーフノードはしきい値に達するまで値で埋められます
- データは引き続き挿入され、次の空きデータはリーフブロックとして割り当てられ、リーフノードのリストが更新されます[.____]。
- 多くの挿入の後、現在のルートノードには子が必要なので、次の空きブロックがブランチノードとして割り当てられ、ルートからリストがコピーされ、ルートは中間ノードのリストのみを維持します。
- ノードブロックを分割する必要がある場合、次の空きブロックがブランチノードとして割り当てられ、ルートリストに追加され、リーフノードのリストが初期ブランチノードと新しいブランチノードに分割されます。
情報がビッグインデックスから読み取られる場合：次のようになります。
- ブロック900にある子を指す最初の/ルートブロック（seek（0）、read（10k））を読み取ります
- ブロック5000にある子を指すブロック900（seek（900 * 10k）、read（10K））を読み取ります。
- ブロック190にあるリーフノードを指すブロック5000（seek（5000 * 10k）、read（10K））を読み取ります。
- ブロック190（seek（190 * 10k）、read（10K））を読み取り、そこから対象の値を抽出します
非常に大きなインデックスを複数のファイルに分割できる場合、ブロックのアドレスは（filename_id、address_relative_to_this_file）のようになります。
それを読んでくださいこれは間違いなく役立ちます http://www.geeksforgeeks.org/b-tree-set-1-introduction-2/