3つのレベルのBツリーでインデックスを作成できるレコードの最大数はいくつですか？ B +ツリー？
動的なツリー構造の組織とデータベースの設計方法を学んでいます。
次の特性を持つDBMSについて考えてみます。
- サイズ2048バイトのファイルページ
- 12バイトのポインタ
- 56バイトのページヘッダー
セカンダリインデックスは、8バイトのページで定義されます。 3つのレベルのBツリーでインデックスを作成できるレコードの最大数はいくつですか？そして、3つのレベルのB + treeがありますか？
これらのツリーの2つの例を次に示します。
私の試み
B +ツリー
読んだ
B +ツリーはBツリーよりも浅い。最後のものを除く各リーフノードでkとして示される最高のキーのセットのみなので、 Bツリーとして編成された非リーフノードに格納されます。 リレーショナルDBMSの内部、第5章：動的なツリー構造の組織、p.46
したがって、違いがあります。Bツリーのノードに格納するものは、B +ツリーのリーフに格納されます。したがって、私の心にはそれは（m-1）でしたh（mが次数であり、h高さである）各ノードが別のノードへのキーを最大で（m-1）含む限りしかし、これはバイト数とは関係ありません。
それでも私は上記の本で次の表を見つけました：
したがって、203.7 レコード数？
Bツリー
それらについては、いくつかの値がノードに格納されている限り、ノードの数で除算する必要があります。そして、私はそこで立ち往生しています。
ここでの答えに影響を与えるBTreeおよびB + Treeアルゴリズムの開発者が利用できる多くの実装オプションがあります。単純なBTreeでは、すべてのノードが同じサイズであり、ノードがオーバーフローすると、2つの半分いっぱいのノードに分割され、他のキーの再配布は発生しません。ハーフフルとフルの間には平均して均一な分布ノードが存在するため、平均フィルファクターは75％になります。それから他のすべてを計算できます。
ただし、実際の実装では、キーを1つまたは2つの追加の隣接ノードに再配布する場合があり、平均フィルファクターが増加します。さらに、実装は事前にソートされたキーの一括挿入が行われていることを検出（または通知）し、分割アルゴリズムを変更して、最終ノードのみが不完全な完全ノードの痕跡を残すようにします。この動作の利点は明白です。
B + Treeでは、すべてのキー値がリーフノードに存在します。つまり、B + Treeには、同等のBTreeがノード全体と同じ数のリーフノードがあります。 B + Treeには、スプリッターとして使用されるキーを含む内部ノードもあり、値の同じ繰り返しがツリーの上方で発生します。ただし、実際の実装ではこれらのキーが切り詰められてより適合し（特にルートレベルでファンアウトが根本的に変更されます）、キーの再配布ももちろん可能です。
多くの実装は拡大されたルートノードを使用し、一部は他のノードも追加のページに拡張できるようにし、分割やキー再配布の手間を減らし、非常に大きなキー値を処理します。
最後に、多くの実装では、削除時にノードをマージするプロセスを短縮し、空になったノードのみを削除するようにしました。マージに関するB + Treeの厄介なEdgeケースがいくつかあります（リーフから小さなキーを削除し、そのキーがスプリッターとして使用されていた場合を考えてください。今度は、スプリッターを次の大きな値に置き換える必要があります。 、そして内部ノードが分割される原因になります！）、それをドロップするだけの方が簡単で、パフォーマンスへの影響はほとんど問題になりません。したがって、実際のFILL FACTORはキーだけでなく、履歴にも依存します。
結局のところ、あなたが答えようとしている質問は、学問的な興味を求められるだけです。実際の実装にはほとんど関係ありません。