# 随机算法 (Fall 2011)/Perfect hashing

# Collision number

Consider a 2-universal family of hash functions from to . Let be a hash function chosen uniformly from . For a fixed set of distinct elements from , say , the elements are mapped to the hash values . This can be seen as throwing balls to bins, with pairwise independent choices of bins.

As in the balls-into-bins with full independence, we are curious about the questions such as the birthday problem or the maximum load. These questions are interesting not only because they are natural to ask in a balls-into-bins setting, but in the context of hashing, they are closely related to the performance of hash functions.

The old techniques for analyzing balls-into-bins rely too much on the independence of the choice of the bin for each ball, therefore can hardly be extended to the setting of 2-universal hash families. However, it turns out several balls-into-bins questions can somehow be answered by analyzing a very natural quantity: the number of **collision pairs**.

A collision pair for hashing is a pair of elements which are mapped to the same hash value, i.e. . Formally, for a fixed set of elements , for any , let the random variable

The total number of collision pairs among the items is

Since is 2-universal, for any ,

The expected number of collision pairs is

In particular, for , i.e. items are mapped to hash values by a pairwise independent hash function, the expected collision number is .

# Perfect hashing

Perfect hashing is a data structure for storing a *static dictionary*. In a static dictionary, a set of items from the universe are preprocessed and stored in a table. Once the table is constructed, it will nit be changed any more, but will only be used for search operations: a search for an item gives the location of the item in the table or returns that the item is not in the table. You may think of an application that we store an encyclopedia in a DVD, so that searches are very efficient but there will be no updates to the data.

This problem can be solved by binary search on a sorted table or balanced search trees in time for a set of elements. We show how to solve this problem with time by perfect hashing.

The idea of perfect hashing is that we use a hash function to map the items to distinct entries of the table; store every item in the entry ; and also store the hash function in a fixed location in the table (usually the beginning of the table). The algorithm for searching for an item is as follows:

- search for in table :

- retrieve from a fixed location in the table;
- if return ; else return NOT_FOUND;

This scheme works as long as that the hash function satisfies the following two conditions:

- The description of is sufficiently short, so that can be stored in one entry (or in constant many entries) of the table.
- has no collisions on , i.e. there is no pair of items that are mapped to the same value by .

The first condition is easy to guarantee for 2-universal hash families. As shown by Carter-Wegman construction, a 2-universal hash function can be uniquely represented by two integers and , which can be stored in two entries (or just one, if the word length is sufficiently large) of the table.

Our discussion is now focused on the second condition. We find that it relies on the *perfectness* of the hash function for a data set .

A hash function is **perfect** for a set of items if maps all items in to different values, i.e. there is no collision.

We have shown by the birthday problem for 2-universal hashing that when items are mapped to values, for an chosen uniformly from a 2-universal family of hash functions, the probability that a collision occurs is at most 1/2. Thus

for a table of entries.

The construction of perfect hashing is straightforward then:

- For a set of elements:

- uniformly choose an from a 2-universal family ; (for Carter-Wegman's construction, it means uniformly choose two integer and for a sufficiently large prime .)
- check whether is perfect for ;
- if is NOT perfect for , start over again; otherwise, construct the table;

This is a Las Vegas randomized algorithm, which construct a perfect hashing for a fixed set with expectedly at most two trials (due to geometric distribution). The resulting data structure is a -size static dictionary of elements which answers every search in deterministic time.

# FKS perfect hashing

In the last section we see how to use space and constant time for answering search in a set. Now we see how to do it with linear space and constant time. This solves the problem of searching asymptotically optimal for both time and space.

This was once seemingly impossible, until Yao's seminal paper:

- Yao. Should tables be sorted?
*Journal of the ACM (JACM)*, 1981.

Yao's paper shows a possibility of achieving linear space and constant time at the same time by exploiting the power of hashing, but assumes an unrealistically large universe.

Inspired by Yao's work, Fredman, Komlós, and Szemerédi discover the first linear-space and constant-time static dictionary in a realistic setting:

- Fredman, Komlós, and Szemerédi. Storing a sparse table with O(1) worst case access time.
*Journal of the ACM (JACM)*, 1984.

The idea of FKS hashing is to arrange hash table in two levels:

- In the first level, items are hashed to
*buckets*by a 2-universal hash function .

- Let be the set of items hashed to the th bucket.

- In the second level, construct a -size perfect hashing for each bucket .

The data structure can be stored in a table. The first few entries are reserved to store the primary hash function . To help the searching algorithm locate a bucket, we use the next entries of the table as the "pointers" to the bucket: each entry stores the address of the first entry of the space to store a bucket. In the rest of table, the buckets are stored in order, each using a space as required by perfect hashing.

It is easy to see that the search time is constant. To search for an item , the algorithm does the followings:

- Retrieve .
- Retrieve the address for bucket .
- Search by perfect hashing within bucket .

Each line takes constant time. So the worst-case search time is constant.

We then need to guarantee that the space is linear to . At the first glance, this seems impossible because each instance of perfect hashing for a bucket costs a square-size of space. We will prove that although the individual buckets use square-sized spaces, the sum of the them is still linear.

For a fixed set of items, for a hash function chosen uniformly from a 2-universe family which maps the items to , called *buckets*, let be the number of items in mapped to the th bucket.
We are going to bound the following quantity:

Since each bucket use a space of for perfect hashing. gives the size of the space for storing the buckets.

We will show that is related to the total number of collision pairs. (Indeed, the number of collision pairs can be computed by a degree-2 polynomial, just like .)

Note that a bucket of items contributes collision pairs. Let be the total number of collision pairs. can be computed by summing over the collision pairs in every bucket:

Therefore, the sum of squares of the sizes of buckets is related to collision number by:

By our analysis of the collision number, we know that for items mapped to buckets, the expected number of collision pairs is: . Thus,

Due to Markov's inequality, with a constant probability. For any set , we can find a suitable after expected constant number of trials, and FKS can be constructed with guaranteed (instead of expected) linear-size which answers each search in constant time.