2003年 3月 1日 | indexing (B ツリー 構造) | >> 目次 (作成日順) |
B ツリー 構造の基本的な説明は、以下の文献を参照されたい。
基本算法 2/情報構造、米田信夫・筧 捷彦 共訳、サイエンス 社
B ツリー 構造は 「ツリー 構造」 であるから階層構造となる。
市販されている RDB のほとんどすべては、インデックス 構造として B ツリー 構造を導入している。
キー の値と データ・アドレス (相対 アドレス) を 「leaf」 のなかに収める形式としては以下の 2つがある。 この点に関しては、後日、解説する。 B ツリー 構造では、2階層目までの階層を 「high-level index」 といい──「root」 は 0階層とされる──、3階層目から 「leaf」 までの階層を 「low-level index」 という。
B ツリー 構造の特徴は、ランダム・アクセス の効率を実現する ツリー 構造である。
B ツリー 構造を シーケンシャル 用にも使うなら、「leaf」 (最下位層だけ) を GetNext するようにすればよい。
「leaf」 を GetNext するやりかたは、プロダクト ごとに違うので、それぞれの プロダクト を調べてほしい。
「leaf」 のなかには、インデックス を生成したときに、スラック (slack、ゆとり、たるみ) 領域が用意される。 ちなみに、データ を削除しても、キー は 「物理的には」 削除されないで、「使用対象ではない」 という FLAG が立てられる。そして、インデックス を再編成したときに、FLAG が立てられている キー を 「物理的に」 削除する。
既存の キー の削除と新たな キー の追加が多ければ、用意されている スラック 領域が費消され、新たな キー を収める領域が涸渇することも起こる。そうなれば、ブロック (low-level index) を スプリット (split、分割) して、新たな領域を用意することになる。「low-level index」 が スプリット されたら、ときには、それに呼応して、「high-level index」 が再編成 (スプリット) されることがある。 データ の更新 (削除および追加) が多い トランザクション に対しては、インデックス の スプリット 状態を監視したほうがいい。逆に言えば、インデックス が スプリット しないような対応策を考えなければならないということである。
さて、上述したように、B ツリー 構造の弱点は、以下の 2点として、まとめることができる。
(1) 手繰 (たぐ) る
レコード・アット・ア・タイム 法を使うなら、インデックス をたぐらないようして、インデックス が揺らがないようにすれば良い、ということである |
<< もどる | HOME | すすむ >> | |
ベーシックス |