Chapter 8. Multilevel Indexing and...

Chapter 8. Multilevel Indexing and B-trees

Kim Joung-Joon

Database Lab.

[email protected]

File Processing (9) Konkuk University (DB Lab.) 2

Chapter Outline

9.1 The invention of the B-tree

9.2 Statement of the Problem

9.3 Indexing with Binary Search

Trees

9.4 Multilevel Indexing: A Better

Approach to Tree Indexes

9.5 B-trees: Working up from

the Bottom

9.6 Example of Creating a B-

tree

9.7 An Object-Oriented

Representation of B-Trees

9.8 B-Tree Methods Search,

Insert, and Others

9.9 B-tree Nomenclature

9.10 Formal Definition of B-tree

Properties

9.11 Worst-Case Search Depth

9.12 Deletion, Merging, and

Redistribution

9.13 Redistribution During

Insertion: A Way to Improve

Storage Utilization

9.14 B*-trees

9.15 Buffering of Pages: Virtual

B-trees

9.16 Variable-Length Records

and Keys


9.1 The invention of the B-tree

B-tree

de facto, the standard organization for indexes in a

database system

to solve how to access and efficiently maintain an index

that is too large to hold in memory

the notion of a paged index with retrieval time proportional

to logkI (I : index size, k : page size)

e.g., 64 bytes of a page size with 1,000,000 records

B-tree : no more than 3 seeks

Binary tree : as many as 24 seeks

B : balanced, broad, bushy, Bayer, Boeing


9.2 Statement of the Problem

Two problems !!!

searching the index must be faster than binary

searching

searching for a key on a disk involves seeking to

different disk tracks

need to find a way to home in on a key using fewer

seeks

insertion and deletion must be as fast as search

Inserting a key into an index involves moving a large #

of other keys in the index

=> index maintenance is very impractical on disk

need to find a way to make insertions and deletions that

have only local effects in the index


9.3 Indexing with Binary Search Trees (1/4)

Binary search tree

Binary search is not fast enough for disk resident indexing lack of an effective strategy of balancing the tree





Balanced tree (Fig. 9.5) => complete balance

the height of the shortest path to a leaf does not differ from

the height of the longest path by more than one level

AVL tress and paged binary trees

Nonbalanced tree(Fig. 9.6)

require 7, 8, or 9 seeks for retrieval

Binary search on a sorted list of 24 keys

=> 5 seeks in the worst case



LV NP, MB, TM, LA, UF, ND, TS, NK


9.3.1 AVL Trees (1/5)

Undesirable tree organizations

alphabetical order produces a degenerate tree

=> need to reorganize the nodes of the tree


9.3.1 AVL Trees (2/5)

AVL trees

defined by Russian mathematicians, G. M. Adel'son-Vel'skii

and E.M. Landis

a near optimal tree structure

height-balanced 1-tree (HB(1) tree)

height-balanced trees with the maximum difference is 1

no two subtrees of any root differ by more than one level

not directly applicable to file structure problems

AVL trees have too many levels

guarantees that search performance approximates that of a

completely balanced tree


9.3.1 AVL Trees (3/5)


9.3.1 AVL Trees (4/5)

Completely balanced tree from B, C, G, E, F, D, A AVL tree from the input B, C, G, E, F, D, A


9.3.1 AVL Trees (5/5)

(1)

Complexity comparison (e.g., 1,000,000 keys) completely balanced tree

the worst-case search to find a key: log2(N + 1)

require seeking 20 levels

(2) AVL trees

the worst-case search to find a key: 1.44 log2(N + 2)

require seeking 29 levels

unacceptable for finding a key in secondary storage

Two problems

Binary searching requires too many seeks

keeping an index in sorted order is expensive


9.3.2 Paged Binary Trees (1/3)

Paged binary trees

divide a binary tree(multiple binary nodes) into pages and

then store each page in a block of contiguous locations

on disk

can locate any one of the 63 nodes with no more than 2

disk accesses

e.g., 4096 nodes

Paged Binary Tree : 4 seeks

Binary Search : 12 seeks



Paged binary trees (Cont’d)



Page size : 8 KB for 512 key/reference field pairs

# of keys : 134,217,727

① Completely full, balanced binary tree

Log2(N+1) = 27 seeks

② Paged version of a completely full, balanced binary tree

Logk+1(N+1) = 3 seeks

( k : # of keys held in a single page)

=> can reduce disk seeks


9.3.3 Problems with Paged Trees (1/3)

Two problems

Inefficient disk usage

14 reference fields for 8 subtrees

How to build it ?

Keys : sorted order or random order

Construction of the paged binary trees

from the following sequence of keys:

CSDTAMPIBWNGURKEHOLJYQZFXV

contain a maximum of three keys per pages

rotate keys within a page to keep each page as balanced

as possible



Construction of the paged binary trees (Cont’d)

C

D wrong keys are placed in the root of the tree

D

C S

rotate

S



Three unsolved questions

(1) the keys in the root turn out to be good separator keys ?

How do we ensure that ?

divide up the set of other keys more or less evenly

(2) how do we avoid grouping keys that should not share a page ?

C, D, S should not share the same page

(3) each of the pages contains at least some minimum number of keys?

maintain a lower bound

=> B-trees : build trees upward from bottom instead of downward from the top


9.4 Multilevel Indexing: A Better Approach to Tree Indexes (1/2)

800 MB file of 8,000,000 records

100 bytes each, with 10 byte keys

Index has 8,000,000 key-reference pairs

Each index record has 100 key-reference pairs

(1) first level index

80,000 index records for 8,000,000 keys

index to the data file (i.e., its reference fields are data

record addresses in the data file ) (2) second level index

800 index records for 80,000 keys

choose one of the keys (the largest) in each index record

use reference fields for index record addresses


9.4 Multilevel Indexing: A Better Approach to Tree Indexes (2/2)

800 MB file of 8,000,000 records (Cont’d)

(3) third level index

8 index records for 800 keys

(4) fourth level index

1 index records for 8 keys

=> ① total 80,809 index records

② average, min., max. # of disk access = 4 (∵ 4 levels)

Problems

How can we insert keys into the index?

Suppose that the new smallest key is added to the index

every record in the first level index must be changed

this requires 80,000 reads and writes


9.5 B-trees: Working Up from the Bottom (1/2)

B-trees

multilevel indexes defined by Bayer and McCreight

built upward from the bottom(i.e., leaves) instead of

downward from the top

do not require that the index records be full

do not shift the overflow keys to the next record

split an overfull record into two records, each half full

deletion takes a similar strategy of merging two records into a single record when necessary

the order of the B-tree : n

the maximum number of key-reference pairs that can be stored in a node

Node : n/2 ~ n

Root : can have a minimum of 2 keys


9.5 B-trees: Working Up from the Bottom (2/2)

B-trees (Cont’d)

Insertion of a new key into an index record

(1) An index record that is not full

Simply update the index record

(2) New key is the new largest key

It will be the new higher level key of that record

The next higher level of the index must be updated

(3) Overfull

It is split into two records, each with half of the keys

The largest key in this new node must be inserted into

the next higher level node(=promotion)

(4) Promotion causes an overflow at that level

Node split and promotion to the next level


9.6 Example of Creating a B-tree (1/3)

Creation of a B-tree with an order 4

given the key sequence :

CSDTAMPIBWNGURKEHOLJYQZFXV

the number of nodes affected by any insertion is never

more than two nodes per level

Figure 9.14

The tree up to the point where it is about to split the root

for the second time

Figure 9.15

The tree as it grows to height three






9.7 An Object-Oriented Representation of B-Trees 9.7.1 Class BTreeNode: Representing B-tree Nodes in Memory (1/6)

B-tree

an index file associated with a data file

most of the operations on B-tree, including insertion and

deletion, are applied to the B-tree nodes in memory

a class is needed to represent the memory resident B-tree

nodes

Template class BTreeNode : btnode.h of Appendix I

B-tree file

simply stores the nodes when they are not in memory

Konkuk University (DB Lab.) 28

9.7.1 Class BTreeNode: Representing B-tree Nodes in Memory (2/6) template <class keyType>

class BTreeNode: public SimpleIndex <keyType>

// this is the in-memory version of the BTreeNode

{public:

BTreeNode(int maxKeys, int unique = 1); ~BTreeNode();

int Insert (const keyType key, int recAddr);

int Remove (const keyType key, int recAddr = -1);

int LargestKey (); // returns value of largest key

int Split (BTreeNode<keyType> * newNode); // move keys into newNode

int Merge (BTreeNode<keyType> * fromNode);// move keys from fromNode

int UpdateKey (keyType oldKey, keyType newKey, int recAddr = -1);

int Pack (IOBuffer& buffer) const;

int Unpack (IOBuffer& buffer);

static int InitBuffer (FixedFieldBuffer & buffer,

int maxKeys, int keySize = sizeof(keyType));

protected:

int NextNode; // address of next node at same level

int RecAddr; // address of this node in the BTree file

int MinKeys; // minimum number of keys in a node

int MaxBKeys; // maximum number of keys in a node

int Init ();

void Clear(){NumKeys = 0; RecAddr = -1;}

friend class BTree<keyType>;

}; File Processing (9)


9.7.1 Class BTreeNode: Representing B-tree Nodes in Memory (3/6) template <class keyType>

class SimpleIndex

{public:

SimpleIndex (int maxKeys = 100, int unique = 1); ~SimpleIndex ();

void Clear (); // remove all keys from index

int Insert (const keyType key, int recAddr);

// for Remove, Search, and Find, if recAddr == -1,

//remove the first instance of key

int Remove (const keyType key, const int recAddr = -1);

// for Search and Find, if exact == 1, return -1 if not found

//if exact == 0, find largest key in node <= argument key

int Search (const keyType key, const int recAddr = -1, const int exact = 1) const;

int numKeys () const {return NumKeys;}

protected:

int MaxKeys;

int NumKeys;

keyType * Keys;

int * RecAddrs;

int Find (const keyType key, const int recAddr = -1,

const int exact = 1) const;

int Init (const int maxKeys, const int unique);

int Unique; // if true, each key value must be unique in the index

friend class IndexBuffer<keyType>;



9.7.1 Class BTreeNode: Representing B-tree Nodes in Memory (4/6)

Class BTreeNode for B-tree node in memory(Cont’d)

Based on the SimpleIndex template class

Methods to insert and remove a key and to split and merge

nodes

Protected members that store the file address of the node

and the minimum and maximum number of keys

No search method : uses the Search method of SimpleIndex

disk representations of BTreeNode objects

managed by the pack and unpack operations



Number of keys in BTreeNode

actually one more than the order of the tree

the SimpleIndex constructor creates an index record with

maxKeys + 1 elements template <class keyType>

BTreeNode<keyType>::BTreeNode (int maxKeys, int unique)

:SimpleIndex<keyType> (maxKeys + 1, unique)

{ Init();}

allow the Insert method to create an overfull node



Method Insert

simply calls SimpleIndex::Insert and then checks for overflow

template <class keyType>

int BTreeNode<keyType>::Insert (const keyType key, int recAddr)

{

int result = SimpleIndex<keyType>::Insert (key, recAddr);

if (!result) return 0; // insert failed

if (NumKeys > MaxKeys) return –1; // node overflow

return 1;

}

Similarly, the remove method can create an underflow node


9.7.2 Class BTree: Supporting Files of B-tree Nodes (1/2)

Class Btree : btree.h of Appendix I

Use in-memory BTreeNode objects, add the file access

portion, and enforce the consistent size of the nodes

Methods to create, open, and close a B-tree

Methods to search, insert, and remove key-references pairs

Methods to transfer nodes from disk to memory(Fetch) and

back to disk(Store)

Members that hold the root node in memory and represent

the height of the tree and the file of index records

Member Nodes is used to keep a collection of tree nodes

in memory and reduce disk accesses


9.7.2 Class BTree: Supporting Files of B-tree Nodes (2/2) template <class keyType>

class Btree // this is the full version of the BTree

{public:

BTree(int order, int keySize = sizeof(keyType), int unique = 1); ~BTree();

int Open (char * name, int mode);

int Create (char * name, int mode);

int Close ();

int Insert (const keyType key, const int recAddr);

int Remove (const keyType key, const Int recAddr = -1);

int Search (const keyType key, const int recAddr = -1);

protected:

typedef BTreeNode<keyType> BTNode; // useful shorthand

BTNode * FindLeaf (const keyType key); // load a branch into memory down to the leaf with key

BTNode * NewNode ();

BTNode * Fetch(const int recaddr); // load node into memory

int Store (BTNode *); *); // store node into file

BTNode Root;

int Height; // height of tree

int Order; // order of tree

int PoolSize;

BTNode ** Nodes; // Nodes[1] : level 1, …, Nodes[Height-1] : leaf (see FindLeaf)

FixedFieldBuffer Buffer;

RecordFile<BTNode> BTreeFile;



9.8 B-Tree Methods Search, Insert, and Others 9.8.1 Searching (1/2)

Search procedure

They are iterative, and

They work in two stages, operating alternatively on entire

pages(class BTree) and then within pages (class BTreeNode) recAddr = btree.Search(‘L’); // in Figure 9.15(a) => no data file record

=> leafNode = FindLeaf(key);

=> recAddr = Nodes[level-1]->Search(key, -1, 0);

=> Nodes[level] = Fetch(recAddr);


9.8.1 Searching (2/2)

BTree::Search and BTree::FindLeaf

template <class keyType> int BTree<keyType>::Search (const keyType key, const int recAddr) { BTreeNode<keyType> * leafNode; leafNode = FindLeaf (key);

return leafNode->Search (key, recAddr); }

template <class keyType> BTreeNode<keyType> * BTree<keyType>::FindLeaf(const keyType key) // load a branch into memory down to the leaf with key { int recAddr, level; for (level = 1; level < Height; level++) { recAddr = Nodes[level-1]->Search(key, -1, 0); // inexact search

Nodes[level] = Fetch(recAddr); } return Nodes[level-1];

}


9.8.2 Insertion (1/5)

Insertion

splitting and promoting process

① Search to the leaf level, using method FindLeaf, before the

iteration

② Insertion, overflow detection, and splitting on the upward

path

③ Creation of a new root node, if the current root was split



Insert procedures

(1) Search the leaf node for key R using FindLeaf for Fig

9.14(e) thisNode = FindLeaf (key);

(2) Insert R into the leaf node Result = thisNode->Insert(key, recAddr);

(3) Detect an overflow

The node must be split into two nodes

newNode = NewNode();

thisNode->Split (newNode);

Store(thisNode);

Store(newNode);



Insert procedures (Cont’d)

(4) Update the parent node

The largest key in thisNode has changed

thisNode->LargestKey() = ‘T’

ParentNode->UpdateKey(largestkey, thisNode->LargestKey());

The value W in the root is changed to T

(5) Insert the largest value(W) in the new node into the root

ParentNode->Insert(newNode->largestKey(), newNode->recAddr);

Promote the key W

cause the root to overflow with five keys

a new root node is created and the keys P and W are

inserted : (D,M,P), (T,W)



Insert procedures (Cont’d)

(6) Create a new root node, and insert the keys P & W into it int newAddr = BTreeFile.Append(Root); //put previous root into file // insert 2 keys in new root node Root.Keys[0] = thisNode->LargestKey(); Root.RecAddrs[0] = newAddr; Root.Keys[1] = newNode->LargestKey(); Root.RecAddr[1] = newNode->RecAddr; Root.NumKeys = 2; Height++;



BTreeNode::Split

Distribute the keys between the original page and the new

page

Fig 9.19 : Method Split of class BTreeNode

Full implementation of BTree::Insert in Appendix I

handle the special case of the insertion of a new largest key

in the tree


9.8.3 Create, Open, and Close

Method Create

Write the empty root node into the file BTreeFile

Method Open

Open BTreeFile and load the root node into memory from

the first record in the file

Method Close

Store the root node into BTreeFile and close it


9.8.4 Testing the B-tree

tstbtree.cpp in Appendix I

Full code of program to test creation and insertion of

a B-tree

Figure 9.20

Contain most of the code tstbtree.cpp in Appendix I


9.9 B-tree Nomenclature

Order of a B-tree : m

The maximum number of descendants(keys)

m/2 ~ m

B+-tree

The data file is not entry sequenced but is organized into

a linked list of sorted blocks of records


9.10 Formal Definition of B-tree Properties

Properties of a B-tree of order m

1. Every page has a maximum of m descendents

2. Every page, except for the root and the leaves, has at

least m/2 descendents

3. The root has at least two descendents(unless it is a leaf)

4. All the leaves appear on the same level

5. The leaf level forms a complete, ordered index of the

associated data file


9.11 Worst-Case Search Depth (1/2)

Relationship between the page size of a B-tree,

the number of keys to be stored in the tree, and

the number of levels that the tree can extend the maximum number of disk accesses required to

locate a key in the tree in the worst case

the minimum number of descendents that can extend from

any level of a B-tree of some given order

the worst-case depth of the tree

a maximal height for the tree and a minimal breadth


9.11 Worst-Case Search Depth (2/2)

any level d of a B-tree of order m

the minimum number of descendents is 2 x m/2 d-1

See the page 402

the minimum height d for a tree with N keys

the depth of the tree at the leaf level

N >= 2 x m/2 d-1

d <= 1 + log m/2 (N /2)

an upper bound for the depth of a B-tree with N keys

(e.g.,) a tree of order 512 with 1,000,000 keys

d <= 3.37

has a depth of no more than three levels


9.12 Deletion, Merging, and Redistribution (1/3)

Splitting process of an order four B-tree



Rules for deleting a key k from a node n of order m

1. N(n) > m/2 and k: not the largest in n

simply delete k from n

2. N(n) > m/2 and k: the largest in n

delete k and modify the higher level indexes to reflect the new largest key in n

3. N(n) = m/2 and one of the siblings of n has few enough keys

merge n with its sibling and delete a key from the parent node

4. N(n) = m/2 and one of the siblings of n has extra keys

redistribute by moving some keys from a sibling to n, and modify the higher level indexes to reflect the new largest keys in the affected nodes



Example of order five B-tree

delete C -> merge

delete W -> redistribute

delete M -> merge with the left sibling or redistribute keys

in the right sibling


9.13 Redistribution During Insertion : A Way to Improve Storage Utilization

A way of avoiding, or at least postponing, the

creation of new pages

make a B-tree more efficient in terms of its utilization of

space

Space utilization in a B-tree using two-way splitting

after a node splits, each of the two resulting pages is about

half full

worst case : around 50%

theoretical average : 69%

Experimental results of space utilization

two-way splitting during insertion : 67%

redistribution during insertion : 86% (or 85%)


9.14 B*-trees (1/2)

Properties of a B*-tree of order m

extend the notion of redistribution during insertion to

include new rules for splitting 1. Every page has a maximum of m descendants

2. Every page except for the root has at least (2m-1)/3

descendents (v.s. m/2 )

3. The root has at least two descendents(unless it is a leaf)

4. All the leaves appear on the same level


9.14 B*-trees (2/2)

Root of a B*-tree

never has a sibling => no two-to-three split

(1) Allow the root to grow to a size larger than the other pages

Adv.

ensure that all pages below the root level adhere to B*-

tree characteristics

Disadv.

require to handle a page that are larger than all the

others

(2) Handle the splitting of the root as a conventional one-to-

two split

complicate deletion, redistribution, and other procedures


9.15 Buffering of Pages: Virtual B-trees

Virtual B-tree

B-tree that uses a memory buffer

Objective of virtual B-trees

obtain better performance from B-trees

Keep-the-root strategy

rather than just holding the root page in memory, create

page buffer to hold some number of B-tree pages(5,10, or

more)

read the root page into memory and just keep it there

keys in the root require no disk access


9.15.1 LRU Replacement (1/2)

Two causes of page faults

1. We have never used the page

Unavoidable

2. It was once in the buffer but has been replaced with a new

page

need to read a new page into a buffer that is already full

which page do we decide to replace?

Effect of increasing the # of pages held in the buffer


9.15.1 LRU Replacement (2/2)

Least Recently Used (LRU) page replacement

during redistribution after overflow or underflow

access a page and then access its sibling

hierarchical structure of B-trees

accessing a set of sibling pages involves repeated

access to the parent page

a kind of clustering of the use of certain pages over time

=> temporal locality


9.15.2 Replacement Based on Page Height

Page replacement strategy

use the hierarchical nature of the B-tree to replace pages

in the buffers

keep-the-root strategy: always retain the pages that

occur at the highest levels of the tree

retains the higher-level pages

the root page and all the pages at the second level

give preference to pages that are higher in the tree to keep

in the buffer


9.16 Variable-Length Records and Keys

B-tree with a variable # of keys per page

a variable number of keys and records ?

require a different kind of page structure

need a different criterion for deciding when a page is full

and when it is an underflow condition

the shortest variable-length keys are promoted upward


A.0 m-원 검색 트리(m-Way Search Tree)

한 노드가 최대 m-1 개의 키와 m개의 서브트리를 갖음 (이진 검색 트리에서는 한 노드가 한 개의 키와 두 개의 서브트리를 갖음). 이진 검색 트리에 비해 분기율이 향상됨으로써 트리 높이 가 낮아져 특정 노드에 대한 검색 시간이 감소됨.

삽입 및 삭제 시 트리의 균형을 유지하기 위하여 복잡한 연산이 필요해지는 단점이 있음. m-원 검색 트리의 특성

( n: 키 값 수, Ki : 키 값 , Pi : 서브트리에 대한 포인터 , 1 ≤ n ≤ m)

각 노드안에 있는 키 값들은 오름차순으로 되어 있다. 즉, i=1,2,..,n-2에 대해 Ki < Ki+1 이다.

Pi(i=1,2,...n-1)가 가리키는 서브트리내의 모든 노드들의 키 값들 은 Ki보다 작다.

Pn이 가리키는 서브트리내의 노드들의 모든 키 값들은 Kn보다 크 다.

Pi(i=1,2,...n)가 가리키는 서브트리들은 모두 m-원 검색 트리이다.

Pn Kn-1 Pn-1 … P3 K2 P2 K1 P1 n


A.0 m-원 검색 트리(m-Way Search Tree) a

b c d

e f g h i j

3 100 140

3 30 60 3 110 120 3 170 200

10 20 40 50 70 90 150 160 180 220

<3-원 검색 트리 예>

루트(Root) 노드와 단말 노드를 제외한 모든 노드는 최소 ⌈m/2⌉개,


A.1 B-트리 (1/3)

인덱스를 구성하는 방법으로 많이 사용되는 균형된 m-원 검색 트리

키값과 레코드를 가리키는 포인터들이 트리의 노드에 오름차순에

따라 차례대로 저장됨.

순차 검색은 중위순회 방식(inorder traversal)으로 가능함.

키의 삽입과 삭제시 노드의 분열과 합병이 발생할 수 있음.

차수 m인 B-트리의 특징

모든 노드는 최대 m개의 서브트리를 가진다. 최대 m개의 서브트리를 가진다.

루트 노드는 단말 노드가 아닌 이상 적어도 두 개의 서브트리를 가진다.

리프가 아닌 노드에 있는 키 값의 수는 그 노드의 서브트리 수보다 하나 작다.

모든 단말 노드는 같은 레벨(Level)에 있다.

한 노드안에 있는 키 값들은 오름차순을 유지한다.


19 43 128 138

145 132 100 60 26 40 16

7 15 18 20 30 36 42 50 58 62 65 70 110 120 130 136 140 150

A.1 B-트리 (2/3) a 69

b c

d e f g h i

j k l m n o p q r s t u v

<차수가 3인 B-트리 예>


A.1 B-트리 (3/3) <차수가 3인 B-트리 예>

루트 노드를 제외한 모든 노드는 적어도 ⌈(2m-2)/3⌉개, 최대 m개의


A.2 B*-트리

B-트리의 문제점인 빈번한 노드의 분할을 줄이는 목적으로 제시된

B-트리의 변형

각 노드가 가능한 최소한 2/3가 채워지도록 한 것으로 특징임.

순차 검색은 중위순회 방식(inorder traversal)으로 가능함.

차수 m인 B*-트리의 특징 서브트리를 가진다.

루트 노드는 그 자체가 단말이 아닌 경우 적어도 2개의 서브트리를

갖는다.

리프가 아닌 노드에 있는 키 값의 수는 그 노드의 서브트리 수보다

하나 작다.

모든 단말 노드는 같은 레벨에 있다. 즉, 루트로부터 같은 거리에 있다.

한 노드안에 있는 키 값들은 오름차순을 유지한다.

루트 노드와 단말 노드를 제외한 모든 노드는 최소 ⌈m/2⌉개, 최대 m개


A.3 B+-트리 (1/6)

B-트리의 변형으로 단말 노드가 아닌 노드로 구성된 인덱스 세트 (Index Set)와 단말 노드로만 구성된 순차 세트(Sequence Set)로 구분됨. 인덱스 세트에 있는 노드들은 단말 노드에 있는 키 값을 찾아갈 수 있는 경로로만 제공되며, 순차 세트에 있는 단말 노드가 해당 데이 터 레코드를 가리키고 있음. 또한, 모든 키값은 단말 노드에 나타남. 직접접근에는 인덱스 세트가 이용되고, 순차접근에는 순차 세트가 이용됨. 차수 m인 B+-트리의 특징 의 서브트리를 가진다.

루트 노드는 0 또는 2에서 m개 사이의 서브트리를 가진다.

리프가 아닌 노드에 있는 키 값의 수는 그 노드의 서브트리 수보다 하나 작다.

모든 단말 노드는 같은 레벨에 있다. 즉 루트로부터 같은 거리에 있다.

한 노드 안에 있는 키 값들은 오름차순을 유지하고, 순차 세트내의 단 말 노드들은 모두 링크로 연결되어 있다.


A.3 B+-트리 (2/6)

Typical node of the B+-tree(1)

P2, K2 P1, K1

Data/

Node(4bytes)

…… Key Value(30bytes)

Pn, Kn

Entry

Typical node of the B+-tree(2) Ki : the search-key values (K1 < K2 < K3 < . . . < Kn–1)

Pi : pointers to children (for non-leaf nodes) or pointers

to records or buckets of records (for leaf nodes, Pn :

sibling node pointer).


A.3 B+-트리 (3/6)

S100 S16

S16 S12 S100

S100 S52 S16 S12 S10

Root

IB3

IB1 IB4

IB5

IB2 Level 0

DR4 DR5 DR1 DR3 DR2

IB6

Dri : data records/blocks

i denotes the physical location of data records/blocks

IBj : index blocks

j indicates the physical location of the index blocks in the

index file

Level 1

Level 2


A.3 B+-트리 (4/6)

Data file

Index file

Header DR2 DR3 DR4 DR5 DR1

Header IB2 IB3 IB4 IB5 IB1

Root

IB6


j

16 18

k

19 20

l

26 30

m

36 40

n

42 43

o

50 58

p

60 62

q

65 69

r s

70 100 110 120128

u

130

v

132136

w x

138140 145150

y

d

15 18

e

30 40

g

100

f

58 62

h

128 130

i

140

b

20 43

c

110 136

69

순차

세트

인덱스

세트

A.3 B+-트리 (5/6) a

t

{ 7

<차수가 3인 B+-트리 예>


A.3 B+-트리 (6/6) <차수가 3인 B+-트리 예>

Date post:	03-Nov-2019
Category:	Documents
Upload:	others
View:	4 times
Download:	0 times

Chapter 8. Multilevel Indexing and...

Documents