Hashing - Dynamic Methods:

Thus far we have been looking at Static Hashing Methods.  That is, even though we deal with collisions by added memory outside our "static" table, we are not really growing and shrinking memory as needed.  We first "statically" allocate so much space before we've hashed our 1st value!

Now, Dynamic Methods......

Hashing Techniques for Secondary Storage (I.e., tables/objects in blocks on disk) ---

* Important metric : How many disk accesses?  Concern about the I/O bottleneck!

Assume a page/block can hold b records -

Obvious solution:  Hash an array of m pages (each holds b records) and chain overflows

Works fine, but...

- a few elements will be at the end of long chains

- as n, the number of records/objects to be hashed grows we have problems

* Several approaches (almost) guarantee that all records can be retrieved within a couple of disk accesses.

* One such method - Dynamic Hashing:

• Number of buckets not fixed as with static hashing, but grows or shrinks as needed
• The hash function: Keys are mapped to an arbitrarily long pseudorandom bit string (often called a "signature" or "pseudokey")
  • only the first "so many" bits will be used
  • but we won't know in advance how many
  • a possible hash function: Key% (a prime), where the prime is safely above a maximum file size.
• If we add a record:
  • either it fits on the page it maps to (this should happen most often)
  • or - the page overflows and must be split
• File starts with a single bucket, once bucket is full and a new record is to be inserted, the bucket splits into 2 buckets and all values are re-inserted into the appropriate bucket
• On the first bucket split, all values whose hash value starts with a 0 are inserted into one bucket, while all values whose hash value starts with a 1 are inserted into the other bucket
• At this point, a binary tree structure, called a directory is which has 2 types of nodes:
  • Internal nodes: These guide the search - each has a left pointer corresponding to a 0 bit and a right pointer corresponding to a 1 bit
  • Leaf nodes (or bucket pointers): These hold a bucket address

  We will "fake out" the situation by declaring a record/object type that has 3 pointer fields:

  zero - which holds either null or a real pointer to another internal directory node

  bucket - which holds either null or a real pointer to a bucket

  one - which holds either null or a real pointer to another internal directory node

  Thus, a true "leaf" node will look like this:

     Where , a true "internal" node will look like this:

Where either a or b can be null, but both cannot be null at the same time! (Usually, both will be non-null, for some "badly shaped" trees, we might have one be null.)

***************************************

Algorithm for the Search Procedure for Dynamic Hashing:

• Let h be the hash value (pseudokey of 0s,1s) of a record, or h <--- hash value of record
• t <--- root of the directory
• i <--- 1

While t is an internal node of the directory do

    begin

        if the ith bit of h is a zero

            then   t <--- left son of t

            else      t <--- right son of t;

        i <--- i+1

    end;

Search the bucket whose address is in node t - continue searching chained overflow buckets if necessary;

Return null if not found, bucket pointer where found otherwise;

*****************************************

Dynamic Hashing E.g. -

*****************************************

E.g. Load the records below into expandable hash files based on dynamic hashing:

Record        Key=K         H(K)              Pseudokey or Binary H(K)

record1                     2369                     1                                 001

record2                     3760                     0                                 000

record3                     4692                     4                                 100

record4                     4871                     7                                 111

record5                     5659                     3                                 011

record6                     1821                     5                                 101

record7                     1074                     2                                 010

record8                     7115                     3                                 011

record9                     1620                     4                                 100

record10                   2428                     4                                 100

record11                   3943                     7                                 111

record12                   4750                     6                                 110

record13                   6975                     7                                 111

*************************************

The loading:

*************************************

Similar Technique : Extendible Hashing

• Every record can be retrieved within 2 disk accesses
• Cost (Overhead) - Keep an index/directory (on disk).  This is typically of size 2n/b (n total number of records being hashed, b=bucket size), but can become larger
• Like a B-tree (will cover later) - when a page fills, we split it in two
• Like an indexed sequential search structure: we keep an index to find the record matching a given key
• The hash function: Keys are mapped to an arbitrarily long pseudorandom bit string (often called a "signature" or "pseudokey")
  • only the first "so many" bits will be used
  • but we won't know in advance how many
  • a possible hash function: Key% (a prime), where the prime is safely above a maximum file size.
• If we add a record:
  • either it fits on the page it maps to (this should happen most often)
  • or - the page overflows and must be split

**************************************************************************************

The idea: 

• At any time we know how many bits of the hash sequence are needed so no more than b (= bucket size) records have the same "prefix".... call this d
• Keep, on disk, a pointer to the page where we store the records corresponding to each possible d bit prefix.  This gives 2^d pointers
• If fewer than b records share a d-1 bit prefix, they will be stored on the same page.  Hence, the 2^d pointers need not all be distinct

*******************************************************

Example: b=bucket size=2, i.e. a page/block holds 2 records

Assume we have the following keys and hash values:

Key        Hash Values

A             00001...

B             01001...

C             00110...

D             10101...

E             11010...

Go through the insertion sequence.....

Now add -

F             10010....

Note that the bucket corresponding to "10" must be split.

In general, if we add a record:

• either - it fits onto the page it maps to (almost always the case)
• or - page overflows and must be split

Suppose the page is mapped to by a g-bit prefix (i.e. g is the local prefix length).  There are 2 subcases:

• g < d : Split according to the next bit, creating a new data page.   This will also cause a number (roughly 2^d-g) of pointers to be altered in the index table.
• g = d : Split according to the next bit.  This means d+1 bits are needed to indicate the prefix.  Hence all 2^d pointers in the index file must be duplicated, then a few changed.  Note:  This happens rarely; more or less as the file doubles in size.

************************************************************

Next e.g. - Add G to the structure above, where

G        00101....

*************************************************************************************

Extendible E.g. -

**************************************************************************************

E.g. Load the records below into expandable hash files based on extendible hashing:

Record        Key=K         H(K)              Pseudokey or Binary H(K)

record1                     2369                     1                                 001

record2                     3760                     0                                 000

record3                     4692                     4                                 100

record4                     4871                     7                                 111

record5                     5659                     3                                 011

record6                     1821                     5                                 101

record7                     1074                     2                                 010

record8                     7115                     3                                 011

record9                     1620                     4                                 100

record10                   2428                     4                                 100

record11                   3943                     7                                 111

record12                   4750                     6                                 110

record13                   6975                     7                                 111

*************************************

The loading: