1. Database Systems (資料庫系統)
November 19/21, 2007
Lecture #8

2. Announcement
Assignment #4 on the course webpage, due 11/28.

3. Tree-Structured Indexing
Chapter 10 1

4. Outline Motivation for tree-structured indexes ISAM index
B+ tree index
Key compression
B+ tree bulk-loading
Clustered index

5. Review: Indexing Example
Search key value: find employees with age = 25
Index File
(Small for
efficient
search)
Index Data Structure:
Index entries +
Indexing method
(B+ Tree)
(Hash)
Data entries
(k=25, Paul’s rid)
Index file is much smaller than data file.
The index structure (B+ tree of hash function) allows for efficient search on data entries.
Data File
(Large)
Data records
Mary
Paul

6. Review: Three Alternatives for Data Entries
As for any index, 3 alternatives for data entries k*:
(1) Clustered Index: data entry is data record (sorted by k)
(2) Unclustered Index: data entry separated from data record: <k, rid of data record with search key value k>
(3) Unclustered Index: data entry separated from data record: <k, list of rids of data records with search key k>, useful when search key is not unique (not a candidate key).
What is the performance (cost of retrieving records) difference between clustered and un-clustered index? 2

7. Review: Clustered vs. Unclustered Index
Examples: retrieve all the employees of ages 30~39.
What is the worst-case cost (# disk page I/Os) of clustered index?
What is the worst-case cost of unclustered index?
Cost = number of pages retrieved
mr = # matched records; mp = # pages containing matched records
CLUSTERED
UNCLUSTERED
Index entries
Ages = 30~39
Ages = 30~39
Data entries
Data entries
(Index File)
(Data file)
Data Records
Data Records 12

8. Review: Two General indexing techniques
Hash-structured indexing or tree-structured indexing
Briefly describe them and ask you to compare them on cost of
Equality search: find all employees of age 30.
Range search: find all the employees of ages 30~39. 2

9. Hash-Based Indexes Data entries (key, rid) are grouped into buckets.
Bucket = primary page plus zero or more overflow pages.
Hashing function h: h(r) = bucket in which record r belongs. h looks at the search key fields of r.
If Alternative (1) is used, the buckets contain the data records. H
Smith, 44, 3000
5004 -
3000
Jones, 40, 6003
Tracy, 44, 5004
Primary page
Overflow page
Bucket A
Salary
Ashby, 25, 3000
Basu, 33, 4003
Bristow, 29, 2007
data records
H(salary)=A
data entries
H(age)=00 H
Age
H(age)=01 2

10. Hash-based Indexes (Cont)
Search on key value:
Apply key value to the hash function → bucket number
Retrieve the primary page of the bucket. Search records in the primary page. If not found, search the overflow pages.
Cost of locating rids: # pages in bucket (small)
Insert a record:
If all (primary & overflow) pages in that bucket are full, allocate a new overflow page.
Cost: similar to search.
Delete a record

11. B+ Tree Indexes
Non-leaf
Pages
Leaf
Pages
Leaf pages contain data entries, and are chained (prev & next)
Non-leaf pages contain index entries and direct searches:
index entry P K P K 1 2 P K P 1 2 m m 4

12. Example B+ Tree Entries <= 17 Entries > 17
Root 17
Entries <= 17
Entries > 17 5 13 27 30 2* 3*
14*
16*
33*
34*
38*
39* 7* 5* 8*
22*
24*
27*
29*
Find 7*, 29*? 15* < age < 30*
Insert/delete: Find data entry in leaf, then change it. Need to adjust parent sometimes.
And change sometimes bubbles up the tree (keep the tree balance)
More details about tree-based index in Chapter 10. 15

13. Tree vs. Hash-Structured Indexing
Tree index supports both range searches and equality searches efficiently.
Why efficient range searches?
Data entries (on the leaf nodes of the tree) are sorted.
Perform equality search on the first qualifying data entry + scan to find the rests.
Data records also need to be sorted by search key in case that the range searches access record fields other than the search key.
Hash index supports equality search efficiently, but not range search.
Why inefficient range searches?
Data entries are hashed (using a hash function), not sorted.

14. The Origin of [Tree] index
Range search: Find all students with gpa > 3.0
Sorted data file: binary search to find first such student, then scan to find others.
Cost?
Simple solution: create a smaller index file.
Cost of binary search over index file is reduced.
Index File k1 k2 kN
Motivate the need for tree-structure index.
Why high cost for binary search over the large data file? The cost of binary search is proportional to the number of pages fetched -> O(logN).
Say one-level index file is 1/10 size of data file (0.1N). The cost of binary search is O(log(0.1N))
Data File
Page 1
Page 2
Page 3
Page N
Can do binary search on (smaller) index file! 3

15. Why tree index? But, the index file can still be large.
The cost of binary search over the index file can still be large.
Can we further reduce search cost?
Apply the simple solution again: create multiple levels of indexes.
Each index level is much smaller than the lower index level. This index structure is a tree.
Say if a tree node is an index page holding, e.g.,100 indexes.
A tree with a depth of 4 (from the root index page to the leaf index page) can hold over 100,000,000 records.
The cost of search is 3~4 page access.
Binary search can be slow.

16. ISAM and B+ Tree Two tree-structured indexings:
ISAM (Indexed Sequential Access Method): static structure.
Assuming that the file does not grow or shrink too much.
B+ tree: dynamic structure
Tree structure adjusts gracefully under inserts and deletes.
Analyze cost of the following operations:
Search
Insertion of data entries
Deletion of data entries
Concurrent access.

17. what if inserting to a full page?
ISAM
index entry P K P K P K P 1 1 2 2 m m
Index Pages
Non-leaf
Pages
Index pages contain index entries.
Leaf pages contain data entries. In the case of alternative 1, the data entries are data records. In the case of alternatives 2/3, the data entries contain <key, rid> pairs.
The leaf primary pages are sorted based on keys.
In case of clustered index, the data record pages are sorted based on keys.
Leaf
Pages
what if inserting to a full page?
Overflow
page
Primary pages
Leaf pages contain data entries. 4

18. Example
100
120
150
180 30 3 5 11
120
130
180
200 30 35
100
101
110
150
156
179

19. Non-leaf node 57 81 95 to keys to keys to keys to keys
< £ k<81 81£k<95 k>=95

20. Leaf node 57 81 95
To record
with key 57
with key 81
with key 85

21. Comments on ISAM File creation:
Assume that data records are present and will not change much in the future.
Sort data records. Allocate data pages for the sorted data records.
Sort data entries based on the search keys. Allocate leaf index pages for sorted data entries sequentially.
File creation, we assume that data is available. 5

22. ISAM Operations
Search: Start at root; use key comparisons to go to leaf.
Cost = log F N, where F = # entries/index page, N = # leaf pages
Insert: Find the leaf page and put it there. If the leaf page is full, put it in the overflow page.
Cost = search cost + constant (assuming little or no overflow pages)
Delete: Find and remove from the leaf page; if empty overflow page, de-allocate.

23. Example ISAM Tree
Each node can hold 2 entries; no need for `next-leaf-page’ pointers in primary pages. Why not?
Primary pages are allocated sequentially at file creation time.
Root 40 20 33 51 63
10*
15*
20*
27*
33*
37*
40*
46*
51*
55*
63*
97* 6

24. After Inserting 23*, 48*, 41*, 42* ... Root Index Pages Primary Leaf40
Pages 20 33 51 63
Primary
Leaf
10*
15*
20*
27*
33*
37*
40*
46*
51*
55*
63*
97*
Pages
Overflow
23*
48*
41*
Pages
42* 7

25. ... Now Deleting 42*, 51*, 97* Root Index Pages Primary Leaf Pages40
Pages 20 33 51 63
Primary
Leaf
10*
15*
20*
27*
33*
37*
40*
46*
51*
55*
63*
97*
Pages
Overflow
23*
48*
41*
Pages
42* 7

26. Note that 51* appears in index levels, but not in leaf!
Root 40 20 33 51 63
10*
15*
20*
27*
33*
37*
40*
46*
55*
63*
23*
48*
41*
Note that 51* appears in index levels, but not in leaf! 8

27. Properties of ISAM Tree
Insertions and deletions affect only the leaf pages, not the non-leaf pages
index in the tree is static.
Static index tree has both advantages & disadvantages.
Advantage: No locking and waiting on index pages for concurrent access.
Disadvantage: when a file grows, it creates large overflow chains, leading to poor performance.
ISAM tree is good when data does not change much.
To accommodate some insertions, can leave the primarily pages 20% empty.
How to solve the disadvantage in ISAM tree?
B+ tree can support file growth & shrink efficiently, but at the cost of locking overhead.

28. B+ Tree It is similar to ISAM tree-structure, except:
It has no overflow chains (this is the cause of poor performance in ISAM).
When an insertion goes to a leaf page becomes full, a new leaf page is created.
Leaf pages are not allocated sequentially. Leaf pages are sorted and organized into doubly-linked list.
Index pages can grow and shrink with size of data file.
Index Entries
(Direct search)
Data Entries
("Sequence set")

29. Properties of B+ Tree Keep tree height-balanced.
Balance means that distance from root to all leaf nodes are the same .
Minimum 50% occupancy (except for root)
Each index page node must contain d <= m <= 2d entries.
The parameter m is the number of occupied entries.
The parameter d is called the order of the tree (or ½ node capacity) 9

30. More Properties of B+ Tree
Cost of search, insert, and delete (disk page I/Os):
Θ(height of the tree) = Θ(log m+1 N), where N = # leaf pages
Supports equality and range-searches efficiently.
B+ tree is the most widely used index.

31. Example B+ Tree
Search begins at root, and key comparisons direct it to a leaf (same as in ISAM).
Search for 5*, 15*, all data entries >= 24* ...
Root 13 17 24 30 2* 3* 5* 7*
14*
16*
19*
20*
22*
24*
27*
29*
33*
34*
38*
39* 10

32. B+ Trees in Practice Typical order: 100. Typical fill-factor: 66%.
average fanout = 133
Typical capacities:
Height 4: 1334 = 312,900,700 records
Height 3: 1333 = 2,352,637 records
Can often hold top levels in buffer pool:
Level 1 = page = Kbytes
Level 2 = pages = Mbyte
Level 3 = 17,689 pages = 133 Mbytes

33. Inserting a Data Entry into a B+ Tree
Find correct leaf L.
Put data entry onto L.
If L has enough space, done!
Else, must split L (into L and a new node L2)
Redistribute entries evenly, copy up middle key.
Insert index entry pointing to L2 into parent of L.
This can happen recursively
To split index node, redistribute entries evenly, but push up middle key. (Contrast with leaf splits.)
Splits “grow” tree; root split increases height.
Tree growth: gets wider or one level taller at top. 6

34. Inserting 8*
Root 13 17 24 30 2* 3* 5* 7*
14*
16*
19*
20*
22*
24*
27*
29*
33*
34*
38*
39*
Why is minimum occupancy always guaranteed in both leaf and index pg splits?
What is the difference between copy-up and push-up?
How to avoid splitting? 2* 3* 5* 7* 8* 5
Entry to be inserted in parent node. (Note that 5 is copied up and continues to appear in the leaf.) 5 24 30 17 13
Entry to be inserted in parent node. (Note that 17 is pushed up and only appears once in the index. Contrast this with a leaf split. 12

35. Example B+ Tree After Inserting 8*
Root 17 5 13 24 30 2* 3* 5* 7* 8*
14*
16*
19*
20*
22*
24*
27*
29*
33*
34*
38*
39*
Root was split, leading to increase in height.
Avoid split by re-distributing entries. 13

36. Redistribution after Inserting 8*
Root 13 17 24 30 2* 3* 5* 7*
14*
16*
19*
20*
22*
24*
27*
29*
33*
34*
38*
39*
Root
Check sibling leaf node to see if it has space.
Copy up 8 (new low key value on the 2nd leaf node) 8 17 24 30
Redistribute can increase occupancy rate, but not much affect when the file size is increasing.
You can apply redistribution on leaf node or non-leaf node.
In general, redistribute at non-leaf node does not benefit much – since the not-adjusted non-leaf node is still full.
Redistributing leaf nodes makes more sense, given that adjusting pointers between previous and next neighbors are costly. 2* 3* 5* 7* 8*
14*
19*
20*
22*
24*
27*
16*
29*
33*
34*
38*
39*

37. Deleting a Data Entry from a B+ Tree
Start at root, find leaf L where entry belongs.
Remove the entry.
If L is at least half-full, done!
What if L is less than half-full?
Try to re-distribute, borrowing from sibling (adjacent node with same parent as L).
What if re-distribution fails?
merge L and sibling.
If merge occurred, must delete index entry (pointing to L or sibling) from parent of L.
Merge could propagate to root, decreasing height. 14

38. Tree After Deleting 19* and 20* ...
Root 17 5 13 24 30 2* 3* 5* 7* 8*
14*
16*
19*
20*
22*
24*
27*
29*
33*
34*
38*
39*
39* 2* 3* 17 30
14*
16*
33*
34*
38* 13 5 7* 5* 8*
22*
24* 27
27*
29*
We need to do redistribution when the number of entries after deletion falls below ½ of its capacity (=d).
Redistribution is like asking its next sibling node for an additional key.
Deleting 19* is easy.
Deleting 20* is done with re-distribution. Notice how middle key is copied up. 15

39. Observe toss of index entry (27), and pull down of index entry (17).5 13 27 30 2* 3* 5* 7* 8*
14*
16*
22*
24*
27*
29*
33*
34*
38*
39*
And then deleting 24*
Must merge.
Observe toss of index entry (27), and pull down of index entry (17). 30
22*
27*
29*
33*
34*
38*
39* 2* 3* 7*
14*
16*
22*
27*
29*
33*
34*
38*
39* 5* 8*
Root 30 13 5 17
Pull down
Redistribution does not work in this case. Why? Its next sibling has exactly d keys. So we must do merge the current node with its sibling node.
Can do pull down when previous sibling node has d keys.
What if the previous sibling node has > d keys (see next slide) 16

40. Example of Non-leaf Re-distribution
Tree is shown below during deletion of 24*. (What could be a possible initial tree?)
May re-distribute entry from left child of root to right child.
Root 22 17 20 30 5 13 2* 3* 5* 7* 8*
14*
16*
17*
18*
20*
21*
22*
27*
29*
33*
34*
38*
39* 17

41. After Re-distribution
Intuitively, entries are re-distributed by pushing through the splitting entry in the parent node.
It suffices to re-distribute index entry with key 20; we’ve re-distributed 17 as well for illustration.
Root 17 5 13 20 22 30 2* 3* 5* 7* 8*
14*
16*
17*
18*
20*
21*
22*
27*
29*
33*
34*
38*
39* 18

42. Prefix Key Compression
Important to increase fan-out. (Why?)
Key values in index entries only `direct traffic’; can often compress them.
Compress “David Smith” to “Dav”? How about “Davi”?
In general, while compressing, must leave each index entry greater than every key value (in any subtree) to its left.
Daniel Lee
David Smith
Devarakonda …
Dante Wu
Darius Rex …
Davey Jones

43. Bulk Loading of a B+ Tree
Given a large collection of records
We want to create a B+ tree on some field
How to do it slowly?
Insert each record repeatedly. What is the cost of building index?
# entries * logF(N), where F = fan-out, N = # index pages
How to do it quickly?
Insert at the unit of a page. 20

44. Bulk Loading of a B+ Tree
Bulk Loading can be done much more efficiently.
Step 1: Sort data entries. Insert pointer to first (leaf) page in a new (root) page. 3* 4* 6* 9*
10*
11*
12*
13*
20*
22*
23*
31*
35*
36*
38*
41*
44*
Sorted pages of data entries; not yet in B+ tree
Root 20

45. Bulk Loading(Conti) Sorted pages of data entries; not yet in B+ tree3* 4* 6* 9*
10*
11*
12*
13*
20*
22*
23*
31*
35*
36*
38*
41*
44*
Sorted pages of data entries; not yet in B+ tree
Root
Root 10
Data entry pages 6 12
not yet in B+ tree 3* 4* 6* 9*
10*
11*
12*
13*
20*
22*
23*
31*
35*
36*
38*
41*
44* 20

46. Bulk Loading (Contd.) Step 2: Build Index entries for leaf pages.3* 4* 6* 9*
10*
11*
12*
13*
20*
22*
23*
31*
35*
36*
38*
41*
44*
Root
Data entry pages
not yet in B+ tree 35 23 12 6 10 20
Step 2: Build Index entries for leaf pages.
Always entered into right-most index page just above leaf level. When this fills up, it splits. (Split may go up right-most path to the root.)
Cost = # index pages, which is much faster than repeated inserts.
Root 20 10 35
not yet in B+ tree
Data entry pages
Split when the right-most index page (23,35) are full -> push up 35 -> (10,20) index page is pull -> push up 20 -> create a new root.
Only change the right-most index pages! 6 12 23 38 3* 4* 6* 9*
10*
11*
12*
13*
20*
22*
23*
31*
35*
36*
38*
41*
44* 21

47. Summary of Bulk Loading
Option 1: multiple inserts.
More I/Os during build.
Does not give sequential storage of leaves.
Option 2: Bulk Loading
Fewer I/Os during build.
Leaves will be stored sequentially (and linked, of course).
Can control “fill factor” on pages. 10

48. A Note on `Order’
Order (the parameter d) concept denote minimum occupancy on the number of entries per index page.
But it is not practical in real implementation. Why?
Index pages can typically hold many more entries than leaf pages.
Variable sized records and search keys mean different nodes will contain different numbers of entries.
Order is replaced by physical space criterion (`at least half-full’). 22