Chapter 12: Indexing and Hashing

Database System Concepts, 5th Ed.

©Silberschatz, Korth and Sudarshan
See www.db-book.com for conditions on re-use
 Chapter 12: Indexing and Hashing

„ Basic Concepts
„ Ordered Indices
„ B+-Tree Index Files
„ B-Tree Index Files
„ Static Hashing
„ Dynamic Hashing
„ Comparison of Ordered Indexing and Hashing
„ Index Definition in SQL
„ Multiple-Key Access

Database System Concepts - 5th Edition, Oct 4, 2006 12.2 ©Silberschatz, Korth and Sudarshan
 Basic Concepts

„ Indexing mechanisms used to speed up access to desired data.

z E.g., author catalog in library
„ Search Key - attribute to set of attributes used to look up records in a
file.
„ An index file consists of records (called index entries) of the form

search-key pointer
„ Index files are typically much smaller than the original file
„ Two basic kinds of indices:
z Ordered indices: search keys are stored in sorted order
z Hash indices: search keys are distributed uniformly across
“buckets” using a “hash function”.

Database System Concepts - 5th Edition, Oct 4, 2006 12.3 ©Silberschatz, Korth and Sudarshan
 Index Evaluation Metrics

„ Access types supported efficiently. E.g.,

z records with a specified value in the attribute
z or records with an attribute value falling in a specified range of
values.
„ Access time
„ Insertion time
„ Deletion time
„ Space overhead

Database System Concepts - 5th Edition, Oct 4, 2006 12.4 ©Silberschatz, Korth and Sudarshan
 Ordered Indices

„ In an ordered index, index entries are stored sorted on the search key
value. E.g., author catalog in library.
„ Primary index: in a sequentially ordered file, the index whose search
key specifies the sequential order of the file.
z Also called clustering index
z The search key of a primary index is usually but not necessarily the
primary key.
„ Secondary index: an index whose search key specifies an order
different from the sequential order of the file. Also called
non-clustering index.
„ Index-sequential file: ordered sequential file with a primary index.

Database System Concepts - 5th Edition, Oct 4, 2006 12.5 ©Silberschatz, Korth and Sudarshan
 Dense Index Files

„ Dense index — Index record appears for every search-key value in

the file.

Database System Concepts - 5th Edition, Oct 4, 2006 12.6 ©Silberschatz, Korth and Sudarshan
 Sparse Index Files

„ Sparse Index: contains index records for only some search-key

values.
z Applicable when records are sequentially ordered on search-key
„ To locate a record with search-key value K we:
z Find index record with largest search-key value < K
z Search file sequentially starting at the record to which the index
record points

Database System Concepts - 5th Edition, Oct 4, 2006 12.7 ©Silberschatz, Korth and Sudarshan
 Sparse Index Files (Cont.)

„ Compared to dense indices:

z Less space and less maintenance overhead for insertions and
deletions.
z Generally slower than dense index for locating records.
„ Good tradeoff: sparse index with an index entry for every block in file,
corresponding to least search-key value in the block.

Database System Concepts - 5th Edition, Oct 4, 2006 12.8 ©Silberschatz, Korth and Sudarshan
 Multilevel Index
„ If primary index does not fit in memory, access becomes
expensive.
„ Solution: treat primary index kept on disk as a sequential file
and construct a sparse index on it.
z outer index – a sparse index of primary index
z inner index – the primary index file
„ If even outer index is too large to fit in main memory, yet
another level of index can be created, and so on.
„ Indices at all levels must be updated on insertion or deletion
from the file.

Database System Concepts - 5th Edition, Oct 4, 2006 12.9 ©Silberschatz, Korth and Sudarshan
 Multilevel Index (Cont.)

Database System Concepts - 5th Edition, Oct 4, 2006 12.10 ©Silberschatz, Korth and Sudarshan
 Index Update: Deletion
„ If deleted record was the only record in the file with its particular search-
key value, the search-key is deleted from the index also.
„ Single-level index deletion:
z Dense indices – deletion of search-key:similar to file record deletion.
z Sparse indices –
 if an entry for the search key exists in the index, it is deleted by
replacing the entry in the index with the next search-key value in
the file (in search-key order).
 If the next search-key value already has an index entry, the entry
is deleted instead of being replaced.

Database System Concepts - 5th Edition, Oct 4, 2006 12.11 ©Silberschatz, Korth and Sudarshan
 Index Update: Insertion

„ Single-level index insertion:

z Perform a lookup using the search-key value appearing in the
record to be inserted.
z Dense indices – if the search-key value does not appear in the
index, insert it.
z Sparse indices – if index stores an entry for each block of the file,
no change needs to be made to the index unless a new block is
created.
 If a new block is created, the first search-key value appearing
in the new block is inserted into the index.
„ Multilevel insertion (as well as deletion) algorithms are simple
extensions of the single-level algorithms

Database System Concepts - 5th Edition, Oct 4, 2006 12.12 ©Silberschatz, Korth and Sudarshan
 Secondary Indices

„ Frequently, one wants to find all the records whose values in a

certain field (which is not the search-key of the primary index) satisfy
some condition.
z Example 1: In the account relation stored sequentially by
account number, we may want to find all accounts in a particular
branch
z Example 2: as above, but where we want to find all accounts
with a specified balance or range of balances
„ We can have a secondary index with an index record for each
search-key value

Database System Concepts - 5th Edition, Oct 4, 2006 12.13 ©Silberschatz, Korth and Sudarshan
 Secondary Indices Example

Secondary index on balance field of account

„ Index record points to a bucket that contains pointers to all the

actual records with that particular search-key value.
„ Secondary indices have to be dense

Database System Concepts - 5th Edition, Oct 4, 2006 12.14 ©Silberschatz, Korth and Sudarshan
 Primary and Secondary Indices

„ Indices offer substantial benefits when searching for records.

„ BUT: Updating indices imposes overhead on database modification --
when a file is modified, every index on the file must be updated,
„ Sequential scan using primary index is efficient, but a sequential scan
using a secondary index is expensive
z Each record access may fetch a new block from disk
z Block fetch requires about 5 to 10 milliseconds
 versus about 100 nanoseconds for memory access

Database System Concepts - 5th Edition, Oct 4, 2006 12.15 ©Silberschatz, Korth and Sudarshan
 B+-Tree Index Files

B+-tree indices are an alternative to indexed-sequential files.

„ Disadvantage of indexed-sequential files

z performance degrades as file grows, since many overflow blocks
get created.
z Periodic reorganization of entire file is required.
„ Advantage of B+-tree index files:
z automatically reorganizes itself with small, local, changes, in the
face of insertions and deletions.
z Reorganization of entire file is not required to maintain
performance.
„ (Minor) disadvantage of B+-trees:
z extra insertion and deletion overhead, space overhead.
„ Advantages of B+-trees outweigh disadvantages
z B+-trees are used extensively

Database System Concepts - 5th Edition, Oct 4, 2006 12.16 ©Silberschatz, Korth and Sudarshan
 B+-Tree Index Files (Cont.)

A B+-tree is a rooted tree satisfying the following properties:

„ All paths from root to leaf are of the same length

„ Each node that is not a root or a leaf has between ⎡n/2⎤ and n
children.
„ A leaf node has between ⎡(n–1)/2⎤ and n–1 values
„ Special cases:
z If the root is not a leaf, it has at least 2 children.
z If the root is a leaf (that is, there are no other nodes in the
tree), it can have between 0 and (n–1) values.

Database System Concepts - 5th Edition, Oct 4, 2006 12.17 ©Silberschatz, Korth and Sudarshan
 B+-Tree Node Structure

„ Typical node

z Ki are the search-key values

z Pi are pointers to children (for non-leaf nodes) or pointers to
records or buckets of records (for leaf nodes).
„ The search-keys in a node are ordered
K1 < K2 < K3 < . . . < Kn–1

Database System Concepts - 5th Edition, Oct 4, 2006 12.18 ©Silberschatz, Korth and Sudarshan
 Leaf Nodes in B+-Trees

Properties of a leaf node:

„ For i = 1, 2, . . ., n–1, pointer Pi either points to a file record with search-
key value Ki, or to a bucket of pointers to file records, each record
having search-key value Ki. Only need bucket structure if search-key
does not form a primary key.
„ If Li, Lj are leaf nodes and i < j, Li’s search-key values are less than Lj’s
search-key values
„ Pn points to next leaf node in search-key order

Database System Concepts - 5th Edition, Oct 4, 2006 12.19 ©Silberschatz, Korth and Sudarshan
 Non-Leaf Nodes in B+-Trees

„ Non leaf nodes form a multi-level sparse index on the leaf nodes. For
a non-leaf node with m pointers:
z All the search-keys in the subtree to which P1 points are less than
K1
z For 2 ≤ i ≤ n – 1, all the search-keys in the subtree to which Pi
points have values greater than or equal to Ki–1 and less than Ki
z All the search-keys in the subtree to which Pn points have values
greater than or equal to Kn–1

Database System Concepts - 5th Edition, Oct 4, 2006 12.20 ©Silberschatz, Korth and Sudarshan
 Example of a B+-tree

B+-tree for account file (n = 3)

Database System Concepts - 5th Edition, Oct 4, 2006 12.21 ©Silberschatz, Korth and Sudarshan
 Example of B+-tree

B+-tree for account file (n = 5)

„ Leaf nodes must have between 2 and 4 values

(⎡(n–1)/2⎤ and n –1, with n = 5).
„ Non-leaf nodes other than root must have between 3 and 5
children (⎡(n/2⎤ and n with n =5).
„ Root must have at least 2 children.

Database System Concepts - 5th Edition, Oct 4, 2006 12.22 ©Silberschatz, Korth and Sudarshan
 Observations about B+-trees

„ Since the inter-node connections are done by pointers, “logically”

close blocks need not be “physically” close.
„ The non-leaf levels of the B+-tree form a hierarchy of sparse indices.
„ The B+-tree contains a relatively small number of levels
 Level below root has at least 2* ⎡n/2⎤ values
 Next level has at least 2* ⎡n/2⎤ * ⎡n/2⎤ values
 .. etc.
z If there are K search-key values in the file, the tree height is no
more than ⎡ log⎡n/2⎤(K)⎤
z thus searches can be conducted efficiently.
„ Insertions and deletions to the main file can be handled efficiently, as
the index can be restructured in logarithmic time (as we shall see).

Database System Concepts - 5th Edition, Oct 4, 2006 12.23 ©Silberschatz, Korth and Sudarshan
 Queries on B+-Trees
„ Find all records with a search-key value of k.
1. N=root
2. Repeat
1. Examine N for the smallest search-key value > k.
2. If such a value exists, assume it is Ki. Then set N = Pi
3. Otherwise k ≥ Kn–1. Set N = Pn
Until N is a leaf node
3. If for some i, key Ki = k follow pointer Pi to the desired record or bucket.
4. Else no record with search-key value k exists.

Database System Concepts - 5th Edition, Oct 4, 2006 12.24 ©Silberschatz, Korth and Sudarshan
 Queries on B+-Trees (Cont.)

„ If there are K search-key values in the file, the height of the tree is no
more than ⎡log⎡n/2⎤(K)⎤.
„ A node is generally the same size as a disk block, typically 4
kilobytes
z and n is typically around 100 (40 bytes per index entry).
„ With 1 million search key values and n = 100
z at most log50(1,000,000) = 4 nodes are accessed in a lookup.
„ Contrast this with a balanced binary tree with 1 million search key
values — around 20 nodes are accessed in a lookup
z above difference is significant since every node access may need
a disk I/O, costing around 20 milliseconds

Database System Concepts - 5th Edition, Oct 4, 2006 12.25 ©Silberschatz, Korth and Sudarshan
 Updates on B+-Trees: Insertion

1. Find the leaf node in which the search-key value would appear
2. If the search-key value is already present in the leaf node
1. Add record to the file
2. If necessary add a pointer to the bucket.
3. If the search-key value is not present, then
1. add the record to the main file (and create a bucket if
necessary)
2. If there is room in the leaf node, insert (key-value, pointer)
pair in the leaf node
3. Otherwise, split the node (along with the new (key-value,
pointer) entry) as discussed in the next slide.

Database System Concepts - 5th Edition, Oct 4, 2006 12.26 ©Silberschatz, Korth and Sudarshan
 Updates on B+-Trees: Insertion (Cont.)

„ Splitting a leaf node:

z take the n (search-key value, pointer) pairs (including the one
being inserted) in sorted order. Place the first ⎡n/2⎤ in the original
node, and the rest in a new node.
z let the new node be p, and let k be the least key value in p. Insert
(k,p) in the parent of the node being split.
z If the parent is full, split it and propagate the split further up.
„ Splitting of nodes proceeds upwards till a node that is not full is found.
z In the worst case the root node may be split increasing the height
of the tree by 1.

Result of splitting node containing Brighton and Downtown on inserting Clearview

Next step: insert entry with (Downtown,pointer-to-new-node) into parent

Database System Concepts - 5th Edition, Oct 4, 2006 12.27 ©Silberschatz, Korth and Sudarshan
 Updates on B+-Trees: Insertion (Cont.)

B+-Tree before and after insertion of “Clearview”

Database System Concepts - 5th Edition, Oct 4, 2006 12.28 ©Silberschatz, Korth and Sudarshan
 Insertion in B+-Trees (Cont.)

„ Splitting a non-leaf node: when inserting (k,p) into an already full

internal node N
z Copy N to an in-memory area M with space for n+1 pointers and n
keys
z Insert (k,p) into M
z Copy P1,K1, …, K ⎡n/2⎤-1,P ⎡n/2⎤ from M back into node N
z Copy P⎡n/2⎤+1,K ⎡n/2⎤+1,…,Kn,Pn+1 from M into newly allocated node
N’
z Insert (K ⎡n/2⎤,N’) into parent N
„ Read pseudocode in book!

Mianus

Downtown Mianus Perryridge Downtown Redwood

Database System Concepts - 5th Edition, Oct 4, 2006 12.29 ©Silberschatz, Korth and Sudarshan
 Updates on B+-Trees: Deletion

„ Find the record to be deleted, and remove it from the main file and
from the bucket (if present)
„ Remove (search-key value, pointer) from the leaf node if there is no
bucket or if the bucket has become empty
„ If the node has too few entries due to the removal, and the entries in
the node and a sibling fit into a single node, then merge siblings:
z Insert all the search-key values in the two nodes into a single node
(the one on the left), and delete the other node.
z Delete the pair (Ki–1, Pi), where Pi is the pointer to the deleted
node, from its parent, recursively using the above procedure.

Database System Concepts - 5th Edition, Oct 4, 2006 12.30 ©Silberschatz, Korth and Sudarshan
 Updates on B+-Trees: Deletion

„ Otherwise, if the node has too few entries due to the removal, but the
entries in the node and a sibling do not fit into a single node, then
redistribute pointers:
z Redistribute the pointers between the node and a sibling such that
both have more than the minimum number of entries.
z Update the corresponding search-key value in the parent of the
node.
„ The node deletions may cascade upwards till a node which has ⎡n/2⎤
or more pointers is found.
„ If the root node has only one pointer after deletion, it is deleted and
the sole child becomes the root.

Database System Concepts - 5th Edition, Oct 4, 2006 12.31 ©Silberschatz, Korth and Sudarshan
 Examples of B+-Tree Deletion

Before and after deleting “Downtown”

„ Deleting “Downtown” causes merging of under-full leaves
z leaf node can become empty only for n=3!

Database System Concepts - 5th Edition, Oct 4, 2006 12.32 ©Silberschatz, Korth and Sudarshan
 Examples of B+-Tree Deletion (Cont.)

Deletion of “Perryridge” from result of previous example

„ Leaf with “Perryridge” becomes underfull (actually empty, in this special case) and
merged with its sibling.
„ As a result “Perryridge” node’s parent became underfull, and was merged with its sibling
z Value separating two nodes (at parent) moves into merged node
z Entry deleted from parent
„ Root node then has only one child, and is deleted

Database System Concepts - 5th Edition, Oct 4, 2006 12.33 ©Silberschatz, Korth and Sudarshan
 Example of B+-tree Deletion (Cont.)

Before and after deletion of “Perryridge” from earlier example

„ Parent of leaf containing Perryridge became underfull, and borrowed a
pointer from its left sibling
„ Search-key value in the parent’s parent changes as a result
Database System Concepts - 5th Edition, Oct 4, 2006 12.34 ©Silberschatz, Korth and Sudarshan
 B+-Tree File Organization

„ Index file degradation problem is solved by using B+-Tree indices.

„ Data file degradation problem is solved by using B+-Tree File
Organization.
„ The leaf nodes in a B+-tree file organization store records, instead of
pointers.
„ Leaf nodes are still required to be half full
z Since records are larger than pointers, the maximum number of
records that can be stored in a leaf node is less than the number of
pointers in a nonleaf node.
„ Insertion and deletion are handled in the same way as insertion and
deletion of entries in a B+-tree index.

Database System Concepts - 5th Edition, Oct 4, 2006 12.35 ©Silberschatz, Korth and Sudarshan
 B+-Tree File Organization (Cont.)

Example of B+-tree File Organization

„ Good space utilization important since records use more space than
pointers.
„ To improve space utilization, involve more sibling nodes in redistribution
during splits and merges
z Involving 2 siblings in redistribution (to avoid split / merge where
possible) results in each node having at least ⎣2n / 3⎦ entries

Database System Concepts - 5th Edition, Oct 4, 2006 12.36 ©Silberschatz, Korth and Sudarshan
 Indexing Strings

„ Variable length strings as keys

z Variable fanout
z Use space utilization as criterion for splitting, not number of
pointers
„ Prefix compression
z Key values at internal nodes can be prefixes of full key
 Keep enough characters to distinguish entries in the subtrees
separated by the key value
– E.g. “Silas” and “Silberschatz” can be separated by “Silb”
z Keys in leaf node can be compressed by sharing common prefixes

Database System Concepts - 5th Edition, Oct 4, 2006 12.37 ©Silberschatz, Korth and Sudarshan
 B-Tree Index Files

„ Similar to B+-tree, but B-tree allows search-key values to

appear only once; eliminates redundant storage of search
keys.
„ Search keys in nonleaf nodes appear nowhere else in the B-
tree; an additional pointer field for each search key in a
nonleaf node must be included.
„ Generalized B-tree leaf node

„ Nonleaf node – pointers Bi are the bucket or file record

pointers.

Database System Concepts - 5th Edition, Oct 4, 2006 12.38 ©Silberschatz, Korth and Sudarshan
 B-Tree Index File Example

B-tree (above) and B+-tree (below) on same data

Database System Concepts - 5th Edition, Oct 4, 2006 12.39 ©Silberschatz, Korth and Sudarshan
 B-Tree Index Files (Cont.)

„ Advantages of B-Tree indices:

z May use less tree nodes than a corresponding B+-Tree.
z Sometimes possible to find search-key value before reaching leaf
node.
„ Disadvantages of B-Tree indices:
z Only small fraction of all search-key values are found early
z Non-leaf nodes are larger, so fan-out is reduced. Thus, B-Trees
typically have greater depth than corresponding B+-Tree
z Insertion and deletion more complicated than in B+-Trees
z Implementation is harder than B+-Trees.
„ Typically, advantages of B-Trees do not out weigh disadvantages.

Database System Concepts - 5th Edition, Oct 4, 2006 12.40 ©Silberschatz, Korth and Sudarshan