CS 277: Database System Implementation Notes 4: Indexing

1
CS 277 Database System ImplementationNotes 4
Indexing

• Arthur Keller

2
Chapter 4

• Indexing Hashing
• value

record
?
value
3
Topics

• Conventional indexes
• B-trees
• Hashing schemes

4
Sequential File
5
Sequential File
Dense Index
6
Sequential File
Sparse Index
7
Sequential File
Sparse 2nd level
8

• Comment
• FILE,INDEX may be contiguous
• or not (blocks chained)

9
Question

• Can we build a dense, 2nd level index for a dense
  index?

10
Notes on pointers

• (1) Block pointer (sparse index) can be smaller
  than record pointer
• BP
• RP

11
Notes on pointers

• (2) If file is contiguous, then we can omit
• pointers (i.e., compute them)

12
K1
K2
K3
K4
13
Sparse vs. Dense Tradeoff

• Sparse Less index space per record can
  keep more of index in memory
• Dense Can tell if any record exists
  without accessing file
• (Later
• sparse better for insertions
• dense needed for secondary indexes)

14
Terms

• Index sequential file
• Search key ( ? primary key)
• Primary index (on Sequencing field)
• Secondary index
• Dense index (all Search Key values in)
• Sparse index
• Multi-level index

15
Next

• Duplicate keys
• Deletion/Insertion
• Secondary indexes

16
Duplicate keys
17
Dense index, one way to implement?
Duplicate keys
10
10
10
10
10
10
20
20
20
20
30
30
30
30
30
30
18
Duplicate keys
Dense index, better way?
10
20
30
40
19
Duplicate keys
Sparse index, one way?
10
10
20
30
20
Duplicate keys
Sparse index, another way?

• place first new key from block

10
20
30
30
21
Duplicate values, primary index
Summary

• Index may point to first instance of each value
  only
• File
• Index

a
a
a
. .
b
22
Deletion from sparse index
10
30
50
70
90

110
130
150
23
Deletion from sparse index

• delete record 40

10
30
50
70
90

110
130
150
24
Deletion from sparse index

• delete record 30

10
30
50
70
90

110
130
150
25
Deletion from sparse index

• delete records 30 40

10
30
50
70
90

110
130
150
26
Deletion from dense index
10
20
30
40
50

60
70
80
27
Deletion from dense index

• delete record 30

10
20
30
30
40
40
50

60
70
80
28
Insertion, sparse index case

10
30
40
60
29
Insertion, sparse index case

• insert record 34

10
30
40
60
30
Insertion, sparse index case

• insert record 15

10
30
40
60

• Illustrated Immediate reorganization
• Variation
• insert new block (chained file)
• update index

31
Insertion, sparse index case

• insert record 25

10
30
40
60
32
Insertion, dense index case

• Similar
• Often more expensive . . .

33
Secondary indexes
Sequence field
34
Secondary indexes
Sequence field

• Sparse index

35
Secondary indexes
Sequence field

• Dense index

36
With secondary indexes

• Lowest level is dense
• Other levels are sparse

37
Duplicate values secondary indexes
38
Duplicate values secondary indexes
one option...

• Problem
• excess overhead!
• disk space
• search time

39
Duplicate values secondary indexes
another option...
10
Problem variable size records in index!
40
Duplicate values secondary indexes
?
?
Another idea (suggested in class)Chain records
with same key?
?
?

• Problems
• Need to add fields to records
• Need to follow chain to know records

41
Duplicate values secondary indexes
buckets
42
Why bucket idea is useful

• Indexes Records
• Name primary EMP (name,dept,floor,...)
• Dept secondary
• Floor secondary

43
Query Get employees in (Toy Dept) (2nd
floor)
? Intersect toy bucket and 2nd Floor
bucket to get set of matching EMPs
44
This idea used in text information retrieval

• Documents

...the cat is fat ...
...was raining cats and dogs...
...Fido the dog ...
45
IR QUERIES

• Find articles with cat and dog
• Find articles with cat or dog
• Find articles with cat and not dog

• Find articles with cat in title
• Find articles with cat and dog within 5
  words

46
Common technique more info in inverted
list
position
location
type
d1

• cat

Title
5
Author
10
Abstract
57
d2
d3
dog
Title
100
Title
12
47
Posting an entry in inverted list. Represents
occurrence of term in article

• Size of a list 1 Rare words or
• (in postings) miss-spellings
• 106 Common words

Size of a posting 10-15 bits (compressed)
48
IR DISCUSSION

• Stop words
• Truncation
• Thesaurus
• Full text vs. Abstracts
• Vector model

49
Vector space model

• w1 w2 w3 w4 w5 w6 w7
• DOC lt1 0 0 1 1 0 0 gt
• Query lt0 0 1 1 0 0 0 gt

50

• Tricks to weigh scores normalize
• e.g. Match on common word not as useful as
  match on rare words...

51

• How to process VS. Queries?
• w1 w2 w3 w4 w5 w6
• Q lt 0 0 0 1 1 0 gt

52

• Try Altavista, Excite, Infoseek, Lycos...

53
Summary so far

• Conventional index
• Basic Ideas sparse, dense, multi-level
• Duplicate Keys
• Deletion/Insertion
• Secondary indexes
• Buckets of Postings List

54
Conventional indexes

• Advantage
• - Simple
• - Index is sequential file
• good for scans

Disadvantage - Inserts expensive, and/or -
Lose sequentiality balance
55

• Example Index (sequential)
• continuous
• free space

10
20
30
40
50
60
70
80
90
56
Outline

• Conventional indexes
• B-Trees ? NEXT
• Hashing schemes

57

• NEXT Another type of index
• Give up on sequentiality of index
• Try to get balance

58
BTree Example n3

• Root

100
120 150 180
30
3 5 11
120 130
180 200
100 101 110
150 156 179
30 35
59
Sample non-leaf
57 81 95

• to keys to keys to keys to keys
• lt 57 57? klt81 81?klt95 ?95

60
Sample leaf node

• From non-leaf node
• to next leaf
• in sequence

57 81 95
To record with key 57 To record with key
81 To record with key 85
61
In textbooks notation n3

• Leaf
• Non-leaf

30 35
30
35
30
30
62

• Size of nodes n1 pointers
• n keys

(fixed)
63
Dont want nodes to be too empty

• Use at least
• Non-leaf ?(n1)/2? pointers
• Leaf ?(n1)/2? pointers to data

64
n3

• Full node min. node
• Non-leaf
• Leaf

120 150 180
30
3 5 11
30 35
counts even if null
65
Btree rules tree of order n

• (1) All leaves at same lowest level (balanced
  tree)
• (2) Pointers in leaves point to records except
  for sequence pointer

66

• (3) Number of pointers/keys for Btree

Max Max Min Min ptrs keys
ptrs?data keys
Non-leaf (non-root)
n1
n
?(n1)/2?
?(n1)/2?- 1
Leaf (non-root)
n1
n
?(n1)/2?
?(n1)/2?
Root
n1
n
1
1
67
Insert into Btree

• (a) simple case
• space available in leaf
• (b) leaf overflow
• (c) non-leaf overflow
• (d) new root

68

• (a) Insert key 32

n3
100
30
3 5 11
30 31
69

• (a) Insert key 7

n3
100
30
3 5 11
30 31
70

• (c) Insert key 160

n3
100
120 150 180
180 200
150 156 179
71

• (d) New root, insert 45

n3
10 20 30
1 2 3
10 12
20 25
30 32 40
72
Deletion from Btree

• (a) Simple case - no example
• (b) Coalesce with neighbor (sibling)
• (c) Re-distribute keys
• (d) Cases (b) or (c) at non-leaf

73

• (b) Coalesce with sibling
• Delete 50

n4
10 40 100
10 20 30
40 50
74

• (c) Redistribute keys
• Delete 50

n4
10 40 100
10 20 30 35
40 50
75

• (d) Non-leaf coalese
• Delete 37

n4
25
10 20
30 40
25 26
30 37
40 45
20 22
10 14
1 3
76
Btree deletions in practice

• Often, coalescing is not implemented
• Too hard and not worth it!

77
Comparison B-trees vs. static indexed
sequential file

• Ref 1 Held Stonebraker
• B-Trees Re-examined
• CACM, Feb. 1978

78

• Ref 1 claims
• - Concurrency control harder in B-Trees
• - B-tree consumes more space
• For their comparison
• block 512 bytes
• key pointer 4 bytes
• 4 data records per block

79
Example 1 block static index
1 data block

• 127 keys
• (1271)4 512 Bytes
• -gt pointers in index implicit! up to 127
• blocks

k1
k2
k3
80
Example 1 block B-tree
k1
1 data block
63 keys 63x(44)8 512 Bytes -gt
pointers needed in B-tree up to 63 blocks
because index is blocks not contiguous
k2
...
k63
-
next
81
Size comparison Ref. 1

• Static Index B-tree
• data data
• blocks height blocks height
• 2 -gt 127 2 2 -gt 63 2
• 128 -gt 16,129 3 64 -gt 3968 3
• 16,130 -gt 2,048,383 4 3969 -gt 250,047
  4
• 250,048 -gt 15,752,961 5

82
Ref. 1 analysis claims

• For an 8,000 block file, after 32,000 inserts
• after 16,000 lookups
• ? Static index saves enough accesses to allow
  for reorganization

83
Ref 2 M. Stonebraker, Retrospective on a
database system, TODS, June 1980
84

• DBA does not know when to reorganize
• DBA does not know how full to load pages of new
  index

85

• Buffering
• B-tree has fixed buffer requirements
• Static index must read several
  overflow blocks to be efficient (large
  variable size buffers needed for this)

86

• Speaking of buffering
• Is LRU a good policy for Btree buffers?

? Of course not! ? Should try to keep root in
memory at all times (and perhaps some nodes
from second level)
87
Interesting problem

• For Btree, how large should n be?

n is number of keys / node
88
Sample assumptions

• (1) Time to read node from disk is (700.05n)
  msec.

(2) Once block in memory, use binary search to
locate key (a b LOG2 n) msec. For some
constants a,b Assume a ltlt 70
(3) Assume Btree is full, i.e., nodes to
examine is LOGn N where N records
89
?Can get f(n) time to find a record

• f(n)
• nopt n

90
? FIND nopt by f(n) 0

• Answer is nopt few hundred
• (see homework for details)

91
Variation on Btree B-tree (no )

• Idea
• Avoid duplicate keys
• Have record pointers in non-leaf nodes

92

• to record to record to record
• with K1 with K2 with K3
• to keys to keys to keys to
  keys
• lt K1 K1ltxltK2 K2ltxltk3 gtk3

93
B-tree example n2
65 125

145 165
85 105
25 45
10 20
30 40
110 120
90 100
70 80
170 180
50 60
130 140
150 160
94
Note on inserts

• Say we insert record with key 25

10 20 30
n3
leaf
95
So, for B-trees

• MAX MIN
• Tree Rec Keys Tree Rec Keys
• Ptrs Ptrs Ptrs Ptrs
• Non-leaf
• non-root n1 n n ?(n1)/2? ?(n1)/2?-1
  ?(n1)/2?-1
• Leaf
• non-root 1 n n 1 ?(n1)/2? ?(n1)/2?
• Root
• non-leaf n1 n n 2 1 1
• Root
• Leaf 1 n n 1 1 1

96
Tradeoffs

• ? B-trees have faster lookup than Btrees
• ? in B-tree, non-leaf leaf different sizes
• ? in B-tree, deletion more complicated

? Btrees preferred!
97
But note

• If blocks are fixed size (due to disk and
  buffering restrictions)
• Then lookup for Btree is actually better!!

98

• Example
• - Pointers 4 bytes
• - Keys 4 bytes
• - Blocks 100 bytes (just example)
• - Look at full 2 level tree

99
B-tree

• Root has 8 keys 8 record pointers 9 son
  pointers
• 8x4 8x4 9x4 100 bytes

Each of 9 sons 12 rec. pointers (12 keys)
12x(44) 4 100 bytes
2-level B-tree, Max records 12x9 8 116
100
Btree

• Root has 12 keys 13 son pointers
• 12x4 13x4 100 bytes

Each of 13 sons 12 rec. ptrs (12 keys)
12x(4 4) 4 100 bytes
2-level Btree, Max records 13x12 156
101
So...
8 records

• ooooooooooooo ooooooooo
• 156 records 108 records
• Total 116

B
B

• Conclusion
• For fixed block size,
• B tree is better because it is bushier

102
Outline/summary

• Conventional Indexes
• Sparse vs. dense
• Primary vs. secondary
• B trees
• Btrees vs. B-trees
• Btrees vs. indexed sequential
• Hashing schemes --gt Next