Ab-treeでは、キーとデータの両方を内部ノードとリーフノードに格納できますが、 ab +ツリーでは、データをリーフノードのみに保存する必要があります。
B +ツリーで上記を行うことの利点はありますか?
直感的にははるかに高速に見えるので、どこでもb +ツリーの代わりにbツリーを使用しないでください。
つまり、b +ツリー内のキー(データ)を複製する必要があるのはなぜですか?
下の画像は、B +ツリーとBツリーの違いを示しています。
B +ツリーの利点:
Bの木の利点:
Bツリーに比べてB +ツリーの主な利点は、データへのポインタを削除することで他のノードへのポインタをより多くまとめることができるため、ファンアウトが増加し、ツリーの深さが減少する可能性があることです。
不利な点は、内部ノードで一致が見つかった可能性があるときに早期アウトがないことです。しかし、どちらのデータ構造も膨大なファンアウトを持っているので、あなたのマッチの大多数はとにかくリーフノードにあるでしょう、平均してB +ツリーをより効率的にします。
B +ツリーは、ターミナルノードがリンクリストを形成するので、ツリーがインデックス付けするすべてのデータを見ると、フルスキャンを実行するのがはるかに簡単で高性能です。 Bツリーでフルスキャンを実行するには、すべてのデータを見つけるためにフルツリートラバーサルを実行する必要があります。
一方、Bツリーは、特にツリーがRAMまたはその他の非ブロックストレージにあるときに、シーク(キーで特定のデータを探す)をすると速くなります。ツリー内で一般的に使用されているノードを昇格させることができるので、データを取得するのに必要な比較が少なくなります。
- Bツリーでは、内部ノードまたはリーフノードに格納されている検索キーとデータ。しかし、B +ツリーのデータストアではリーフノードのみです。
- すべてのデータがリーフノードにあるため、B +ツリーのフルスキャンは非常に簡単です。 Bツリーをフルスキャンするには、フルトラバーサルが必要です。
- Bツリーでは、データはリーフノードまたは内部ノードにあります。内部ノードの削除は非常に複雑です。 B +ツリーでは、データはリーフノードにのみあります。葉ノードの削除は簡単です。
- Bツリーへの挿入はB +ツリーよりも複雑です。
- B +ツリーは冗長な検索キーを格納しますが、Bツリーは冗長な値を持ちません。
- B +ツリーでは、リーフノードのデータは順次リンクリストとして順序付けられますが、Bツリーでは、リンクリストを使用してリーフノードを格納することはできません。多くのデータベースシステムの実装は、B +ツリーの構造上の単純さを好みます。
データベースシステムの概念からの例5
B +ツリー
対応するBツリー
Adegoke A、Amit
このセクションで説明したように、欠けている重要な点の1つは、データとポインターの違いです。
ポインタ:他のノードへのポインタ。
データ: - データベースインデックスのコンテキストでは、データは他の場所にある実データ(行)への別のポインタです。
したがって、Bツリーの場合、各ノードには3つの情報キー、キーに関連付けられているデータへのポインタ、および子ノードへのポインタがあります。
B +ツリーでは、内部ノードはキーと子ノードへのポインタを保持し、リーフノードは関連データへのキーとポインタを保持します。これは与えられたサイズのノードに対してより多くの数のキーを許容します。ノードのサイズは主にブロックサイズによって決まります。
ノードごとにより多くのキーを持つことの利点は上で十分に説明されているので、私はタイピングの手間を省きます。
B +ツリーはブロックベースのストレージ(例:ハードディスク)に特に適しています。これを念頭に置いて、あなたは例えば、(私の頭の上から)いくつかの利点があります:
高ファンアウト/低深度:データを取得するために必要なブロックが少なくて済みます。データがポインタと混在していると、各読み取りのポインタ数が少なくなるため、データを取得するためのシークがさらに必要になります。
単純で一貫性のあるブロックストレージ:内部ノードにはN個のポインタがあり、それ以外には何もなく、葉ノードにはデータがあり、それ以外には何もありません。それは解析、デバッグそして再構築さえも容易にします。
キー密度が高いということは、最上位ノードがほぼ確実にキャッシュ上にあることを意味します。多くの場合、すべての内部ノードが素早くキャッシュされるため、データアクセスのみがディスクに送信されます。
B +ツリーでは、ポインタだけが内部ノードに格納されるため、それらのサイズはBツリーの内部ノード(データ+キーの両方を格納する)よりもかなり小さくなります。したがって、B +ツリーのインデックスは1回のディスク読み取りで外部ストレージから取得でき、ターゲットの場所を見つけるために処理されます。 Bツリーの場合は、意思決定プロセスごとにディスクの読み取りが必要です。私が自分の主張を明確にしたことを願っています! :)
**
Bツリーの主な欠点は、キーを順番にトラバースするのが難しいことです。 B +ツリーは、Bツリーの高速ランダムアクセス特性を保持しながら、高速順次アクセスも可能にします。
**参照:Cを使用したデータ構造// // Author:Aaro M Tenenbaum
BツリーとB +ツリーの主な違いは、Bツリーは検索キー値の冗長な格納を排除することです。検索キーはBツリー内で繰り返されないため、より少ないツリーノードを使用してインデックスを格納できない場合があります。しかし、非リーフノードに現れる検索キーは他のどこにもBツリーには現れないので、非リーフノードの各検索キーに追加のポインタフィールドを含めることを余儀なくされています。繰り返しが発生せず、大きなインデックスに使用できるため、それらはBツリーにとってスペース的に有利です。
B +ツリーはバランスの取れたツリーで、ツリーのルートからリーフまでのパスはすべて同じ長さで、ツリーの各非リーフノードは[n/2]から[n]個の子を持ちます。特定の木を修正しました。インデックスページとデータページが含まれています。二分木は一つの親ノードにつき二つの子しか持たない、B +木はそれぞれの親ノードに対して可変数の子を持つことができる
B +ツリーの使用法の1つは、ツリーが大きくなりすぎて使用可能なメモリに収まりきらない状況に適していることです。したがって、一般的には複数のI/Oを行うことになるでしょう。
実際には、B +ツリーが実際にメモリに収まる場合でも使用されることがよくあります。その場合、キャッシュマネージャによって永続的に保持される可能性があります。しかし、これは一般的なケースではなく特別なケースであり、キャッシングポリシーはB +ツリーのメンテナンスとは別のものです。
また、B +ツリーでは、リーフページはリンクリスト(または二重リンクリスト)で互いにリンクされているため、(範囲検索、並べ替えなどの)検索が最適化されます。したがって、ポインタの数は使用される特定のアルゴリズムの関数です。
一例を挙げると、行ごとに巨大なデータを持つテーブルがあります。つまり、オブジェクトのすべてのインスタンスはBigです。
ここでBツリーを使用すると、ほとんどの場合、データでページをスキャンするのに費やされます - これは役に立ちません。データベースでは、オブジェクトデータのスキャンを回避するためにB +ツリーを使用する理由です。
B +木はデータからキーを分離します。
しかし、あなたのデータサイズがそれより小さければ、Bツリーがすることであるキーでそれらを保存することができます。