Large Trees 1 Trees can be used to store entire records from a database, serving as an in-memory representation of the collection of records in a file. Trees can also be used to store indices of the collection of records in a file. In either case, if the collection of records is quite large, the tree may be so large that it is unacceptable to store it all in memory at once. or example, if we have a database file holding 2 30 records, and each index entry requires 8 bytes of storage, a BST holding the index would require 2 30 nodes, each taking 16 bytes of memory (assuming 32-bit pointers), or 16 B of memory. An alternative would be to store the entire tree in a file on disk, and only load the immediately relevant portions of it into memory isk Representation 2 It is a relatively simple matter to write any binary tree to a disk file, by representing each tree node by a data record that holds the data element and two file offsets specifying the locations of the children, if any of that node. B C The nodes don't need to be stored in any particular order. NULL pointers may be represented by a negative offset. 0 24 48 72 96 120 144 168 ata B C lchild 24 96 120 rchild 72 48 168 144
isk Representation 3 The problem is that this disk representation will require too many individual disk accesses when processing a typical tree operation, such as a search or a traversal. Why? These tree operations typically require transiting from a node to one or both of its children. But there's no reason that the child nodes will be stored anywhere near the parent node (although we could at least guarantee that siblings are adjacent). Since each node stores only one data value, and the nodes we might well perform one disk access for every node that is accessed during the tree operation. iven the extremely slow nature of disk access, this is unacceptable. 0 24 48 72 96 120 144 168 ata B C lchild 24 96 120 rchild 72 48 168 144 2-3 Trees 4 These difficulties can be moderated by allowing tree nodes to have more than two children to store more than a single value. In a 2-3 tree: - each node contains either one or two key values - every internal node either holds one key value and has two children, or holds two key values and has three children - every leaf is at the same level in the tree - there is a BST-like arrangement of values for efficient searching Compared to a BST: - 2-3 trees have lower update cost on average - a 2-3 tree storing N keys will be shallower than the corresponding BST, but - search in a 2-3 tree has essentially the same cost as in a BST
2-3 Tree Properties A 2-3 tree: 18 33 5 12 23 30 48 10 15 20 21 24 31 45 47 50 52 ach node can store up to two key values and up to three pointers. The left child holds values less than the first key. The middle child holds values greater than the first key and less than the second key. The right child holds values greater than the second key. 2-3 Tree Insertion Insertion into a 2-3 tree is similar to a BST. irst find the appropriate leaf 6 18 33 12 23 30 48 10 14 15 20 21 24 31 45 47 50 52 Inserting 14 leaf is not full, so just insert new key, shifting old key if necesssary. Inserting 55 leaf is full, but parent is not, so create a new right child, promoting median key from the children to the parent. 48 52 45 47 50 55
2-3 Tree Splitting If a subtree is sufficiently full, insertion may cause the parent to split: 7 Inserting 19 leaf is full, and so is the parent Median value is passed up to the parent node which has now acquired another child 23 23 30 20 30 20 21 24 31 19 21 24 31 2-3 Tree Splitting the Root In the worst case, the tree root splits, increasing the height of the tree: 8 Inserting 19 caused an internal node to split and a displaced value to be passed up. ere, the parent is the tree root and is already full so it splits also 23 18 33 20 30 19 21 24 31
2-3 Tree eletion 9 eletion from a 2-3 tree is, of course, essentially just the inverse of insertion. As with the BST, there are cases: eletion of a value that lies in an internal node: - replace the value with its closest successor (which must lie in a leaf) - delete the successor from the leaf eletion of a value that lies in a leaf: - if the leaf is still non-empty, nothing else needs to be done - if the leaf is now empty, the parent has an empty child, which is not allowed, and merely deleting the leaf would leave the parent with too many values - if the left or right sibling has two values, we can borrow and rearrange values - if not, we merge the leaf and its sibling (if any), demoting a value from the parent etails are interesting some are addressed on the following slides. eletion from a Leaf I Consider deletion of the value 24: 23 30 10 20 21 24 31 This would leave the middle leaf empty, which is not allowed. owever, the left sibling contains an extra value. We may manage the deletion by demoting and borrowing : 23 30 20 21 31 We move the separator value between the siblings to the leaf, and move the appropriate value from the sibling to the parent 21 30 20 23 31
eletion from a Leaf II Consider deletion of the value 24: 23 30 11 20 24 31 This would also leave the middle leaf empty, but neither sibling has any values to spare. So, again we demote and borrow, but we also delete an empty leaf. 23 30 20 31 We pick a sibling, move the separating value between the empty leaf and the sibling, and the sibling s value both into the empty leaf, and delete the sibling... 23 20 30 31 eletion from a Leaf III 12 Consider deletion of the value 24: 23 20 24 This would also leave the middle leaf empty, but neither sibling has any values to spare, nor can we delete either child without leaving the parent with a single child, which is unacceptable we can still demote a value from the parent But, now the parent has too few values (underflow), and we must handle that recursively by considering the siblings and parent of that node 20 23
13 2-3 trees illustrate the basic concepts for the B-tree family. In a B-tree of order m: - the root has at least two subtrees, unless it is a leaf - each nonroot and nonleaf node holds k 1 data values, and k pointers to subtrees, where m / 2 k m - each leaf node holds k 1 data values, where m / 2 k m - all leaves are on the same level - the data values in each node are in ascending order - for all i, the data values in the first i children are less than the i-th data value - for all i, the data values in the last m i children are larger than the i-th data value So, a B-tree is always at least half full, has a relatively small number of levels, and is perfectly balanced. Typically, m will be fairly large. B Tree xample 14 A B-tree of order 5: L O S W A B C I J K M N P Q R T U V X Y Z Since a binary search may be applied to the data values in each node, searching is highly efficient.
B Tree Insertion 15 Insertion follows the same logic as in the 2-3 tree, with the complication that we must make nodes obey the more complex restriction where k is the number of children the node has. m / 2 k m The basic idea is the same: search for the appropriate leaf, add the new value, then split and promote as necessary. or instance, inserting the values W and then X into the B tree at right would cause the right-most leaf to split and the value V to be promoted to the root. Then, inserting the value Z would cause the root to split, and the value Q to be promoted to a new root node. A K Q M O P S T V Insertion xample I 16 K Q Inserting W just fills the leaf. A M O P S T V W Inserting X causes the leaf to overflow. So, we split the leaf and promote the median value, which is V, up one level. K Q V The node there had room for the new value, so no further splitting occurs. A M O P S T W X
Insertion xample II 17 K Q V A M O P S T Inserting I just fills the second leaf. Then, inserting J causes the leaf to overflow. So, we split the leaf and promote the median value, which is, up one level. Now, the parent is full, and so splitting proceeds W X K Q V A I M O P S T W X Insertion xample III Splitting the root sends K up: 18 K Q V A I J M O P S T W X So, the B-tree grows by pushing up a new root, which keeps all leaves at the same level. As you can see here, the root must be an exception to the requirement that each node contains a minimum number of data values, since root-splitting will naturally lead to a new root node holding only one value.
B Tree Insertion Algorithm 19 Insert(K) find a leaf, node, to accept K while ( true ) find the proper position for K within node if node is not full insert K into node return else split node into node1 and node2 distribute values evenly between node1 and node2 let K = middle value if node was the root create a new root as parent of node1 and node2 return else let node = parent of node rozdek, p 307 Search Cost 20 If we let q = m / 2 then we can derive an upper bound on the height of the B-tree with n nodes: n + 1 h log q + 1 2 This is very small. or example, if m = 200 and n = 2,000,000 then h <= 4. But don t get too excited by this. The cost of doing a binary search of the data values in a node would be at least log 2 (q), and if we do that at each level in the tree, the total cost would be n + 1 n + 1 Θ log( q) logq = Θ log 2 2 Keep in mind that the motivation is to find a tree structure that can be efficiently stored to disk, and matching the search cost of a perfectly balanced binary tree is a plus.
Cost of Splitting 21 It would seem that the primary concern about the cost of insertion would be the number of splits that must be performed (everything else is essentially analogous to BST insertion). It is possible to show that as n increases, the average probability of a split is approximated by 1 m / 2 1 So, for example, if m = 100 then the probability of a split is about 2%. That shouldn t be surprising. Splitting a node is fairly expensive since about half the data values in the node must be moved to a new location, but for typical B-trees it won t be required all that often. B Tree eletion 22 As with the 2-3 tree, deletion involves locating the value, replacing it if it s in an internal node, and deleting a value from a leaf. eleting a value from a leaf will require, in some cases, merging the leaf with a sibling and demoting a value from the parent node. etails are interesting
B Tree eletion Algorithm 23 elete(k) find the node, node, containing K if node is not a leaf find a leaf with the closest successor, S, of K copy S to replace K in node let node = leaf containing S delete S from node else delete K from node while ( true ) if node did not underflow return if node has a sibling with enough values redistribute values between node and the sibling return... rozdek, p 312 B Tree eletion Algorithm... else if node s parent is the root if the parent has only one key merge node, its sibling, and the root else merge node and its sibling return else merge node and its sibling let node = its parent 24 rozdek, p 312
B Tree Storage fficiency 25 In a B tree: - nodes are guaranteed to be (essentially) at least 50% full - node could also be only 50% full, wasting half the data space in the nodes - analysis and simulation indicates that in typical use a B tree will be about 70% full This expectation of wasted space is a motivation for some variants of the basic B tree. B* Trees 26 In B* trees: - all nodes except the root are required to be at least 2/3 full rather than 1/2 full - splitting transforms 2 nodes into 3, rather than 1 node into 2 - analysis indicates the average utilization of a B* tree will be about 81% - can be generalized to specify a fill factor of (n+1)/(n+2); a B n tree Knuth
B+ Trees 27 In B+ trees: - Internal nodes store only key values and pointers*. - All records, or pointers to records, are stored in leaves. - Commonly, the leaves are simply the logical blocks of a database file index, storing key values and offsets. In this case, many key values will occur twice in the tree, once at an internal node to guide searching, and again in a leaf. - If the leaves are simply an index, it is common to implement the leaf level as a linked list of B tree nodes why? The B+ tree is the most commonly implemented variant of the B-tree family, and the structure of choice for large databases. * In small databases, it is fairly common to use a B-tree as a direct data structure, with nodes storing records. B Tree Implementation A sample B tree template interface is shown below: 28 template <typename T> class BTreeT { public: BTreeT(unsigned int Order = 3); ~BTreeT(); // some public fns not shown bool Insert(const T& Val); bool elete(const T& Val); void isplay(ostream& Out) const; T* const ind(const T& Target); const T* const ind(const T& Target) const; private: unsigned int Order; BNodeT<T>* Root; // some helper fns not shown }; The order could be supplied as a non-type template parameter, rather than via the constructor, but you could not then use a local variable when declaring a B tree, so the approach shown here is more flexible from the client perspective.
B Tree Node Implementation 29 The design of the B tree node type raises some interesting issues: - the node must provide a way to store Order - 1 data values - the node must provide a way to store Order pointers - the node must support binary search of the data values, so dynamically-allocated arrays are appropriate - the node should, perhaps, provide the necessary search function, and functions to remove and add data values (and adjust the pointer array as needed) - the node destructor must destroy the arrays - the node should provide an isull() function, and perhaps other tests such as underflow, or whether the node has extra values that could be borrowed - the split and merge operations needed for the B tree implementation could be made the responsibility of the node Since leaf nodes do not need pointers, there is a case for having two distinct node types. While that would save memory (or disk space), the idea will not be pursued here. B Tree Node Implementation 30 The most common approach seems to be to use one array, of dimension Order 1, to store the data values, and another, of dimension Order, to store the pointers. It is possible to simplify the shifting needed when inserting and removing data values by coalescing the two arrays into one, storing data/pointer pairs. or example: template <typename T> class Pair { public: T ata; BNodeT<T>* Right; // some members perhaps not shown }; The node could then store an array of Pair objects, of dimension Order, using the 0-th cell to store only a pointer (to the left-most child). This approach also simplifies some communication issues when splitting a node. On the other hand, this approach also adds some syntactic complexity. The discussion of the implementation of B tree insertion that follows uses the approach shown here, but is easily adapted to a separate-arrays approach.
B Tree Insert 31 Insertion follows the usual public/private pattern. The public stub function might look something like this: template <typename T> bool BTreeT<T>::Insert(const T& Val) { if ( Root == NULL ) { Root = new BNodeT<T>(Order); } Pair<T> Comm(Val, NULL); bool splitoccurred = false; if (!insertelper(val, Root, Comm, splitoccurred) ) return false; } if ( splitoccurred ) { // need to grow new root here... } return true; When a child splits, the parent must be notified of that fact, and supplied with the data value that is passed upwards, and the address of the new child node that has been created. In the implementation here, this communication is supported by adding parameters to the interface of the helper function. B Tree Insert elper The private helper function might look something like this: 32 template <typename T> bool BTreeT<T>::insertelper(const T& Val, BNodeT<T>* sroot, Pair<T>& Comm, bool& splitoccurred) { if ( sroot == NULL ) return false; if ( sroot->isleaf() ) { // OK, we're at a leaf, so do it! if (!(sroot->isull()) ) { // don't need to split // add data value to node splitoccurred = false; return true; } else { // need to split leaf // split leaf, identifying value to pass up, and address of // new child node (of parent of current node) splitoccurred = true; return true; } } //... continues...
B Tree Insert elper The private helper function might look something like this: 33 } //... continued... else { // need to continue downward // Look for index, Successor, of first element > Val // check for pre-existence of data, return false if found // OK, the new value would go before Content[currata] // recurse to child preceding index currata // On return, determine if child split // If yes, need to accept the value that was passed up. // If the current node splits in response to that, // need to pass correct value and pointer upwards. } The basic process is straightforward. Note that since you determine the index via which you descend, you already know where to place the passed value when the recursive call returns, and no further searching is required.