B -trees

1
B-trees

• In practice, B-trees are not used much as defined
  earlier.
• The B-tree variation is the one most commonly
  implemented.
• In a B-tree, pointers to records are located at
  internal nodes and at leaves.
• In a B-tree, pointers to records are located in
  the leaves only.
• Leaves contain (pointers to) all records and are
  linked sequentially to form a singly-linked
  sorted list.
• Internal nodes contain values that guide the
  search towards the leaves.
• The part of the tree consisting of the internal
  nodes is called the "index set".

2
B-trees

• B-trees make it easy to support "range search"
  operations.
• E.g. Find all records whose key is between x and
  y.
• This is because we can access all records in a
  (sorted) linear order.
• Locate x and then follow simple links all the way
  to y.
• We usually try to limit the number of levels to
  3.
• If we can also manage to store the root in main
  memory, we'll only need to do 2 I/O operations to
  access a record.

3
B-trees
33
48
60
11
21
2
6
9
11
14
19
21
30
32
33
35
46
48
51
57
60
80
33 is the smallest value stored in the subtree to
its right 60 is the smallest value stored in the
subtree to its right.
4
B-trees

• Insert and delete operations are similar to those
  in the standard B-tree.
• How inefficient is a split?

In theory, a sequence of splits can slow down the
insert operation significantly. In practice, it
is very rare to split all the way to the root
(why?) We may also modify leaf insertions to
avoid splitting by allowing adoptions from
siblings.
5
B-trees

• Insert and delete operations are similar to those
  in the standard B-tree.
• Do we really need to merge after deleting a
  record?

We may decide to not bother with a merge and
instead accept the existence of an
underflow. Reasons Delete operations are
typically few. It's highly likely there will be
an insert operation soon and the underflow
reversed.
6
B-trees

• Insert and delete operations are similar to those
  in the standard B-tree.
• Do we really need to modify the index after a
  delete?

We may decide to not remove the copy of the
deleted key from the index. Reason The key
still separates the entries correctly. However,
if, later on, we end up merging, then keys must
be adjusted.