Explain the difference between Hash indexes and B+-tree indexes. In particular, discuss how equality and range searches work, using an example.
A Hash index is constructed by using a hashing function that quickly
maps an search key value to a specific location in an array-like list of elements called
buckets. The buckets are often constructed such that there are more bucket locations
than there are possible search key values, and the hashing function is chosen so that
it is not often that two search key values hash to the same bucket. A B+-tree index
is constructed by sorting the data on the search key and maintaining a hierarchical
search data structure that directs searches to the correct page of data entries.
For range queries, hash indexes perform terribly since they could conceivably read as many pages as there are records since the data is not sorted in any clear grouping or set. On the other hand, B+-tree indexes have a cost of 3-4 I/Os plus the number of qualifying pages or tuples, for clustered or unclustered B+-trees respectively. Assume we have the employees example again with 10,000 records and 10 records per page. Also assume that there is an index on sal and query of age ¿ 20,000, such that there are 5,000 qualifying tuples. The hash index could cost as much as 100,000 I/Os since every page could be read for every record. It is not clear with a hash index how we even go about searching for every possible number greater than 20,000 since decimals could be used. An unclustered B+-tree index would have a cost of 5,004 I/Os, while a clustered B+-tree index would have a cost of 504 I/Os. It helps to have the index clustered whenever possible.
Insertions and deletions in a hash based index are relatively simple. If two search
values hash to the same bucket, called a collision, a linked list is formed connecting
multiple records in a single bucket. In the case that too many of these collisions occur,
the number of buckets is increased. Alternatively, maintaining a B+-tree’s hierarchical
search data structure is considered more costly since it must be updated whenever there
are insertions and deletions in the data set. In general, most insertions and deletions
will not modify the data structure severely, but every once in awhile large portions of
the tree may need to be rewritten when they become over-filled or under-filled with
data entries.
Hash indexes are especially good at equality searches because they allow a record look up very quickly with an average cost of 1.2 I/Os. B+-tree indexes, on the other hand, have a cost of 3-4 I/Os per individual record lookup. Assume we have the employee relation with primary key eid and 10,000 records total. Looking up all the records individually would cost 12,000 I/Os for Hash indexes, but 30,000-40,000 I/Os for B+- tree indexes.
Hash indexes are especially good at equality searches because they allow a record look up very quickly with an average cost of 1.2 I/Os. B+-tree indexes, on the other hand, have a cost of 3-4 I/Os per individual record lookup. Assume we have the employee relation with primary key eid and 10,000 records total. Looking up all the records individually would cost 12,000 I/Os for Hash indexes, but 30,000-40,000 I/Os for B+- tree indexes.
For range queries, hash indexes perform terribly since they could conceivably read as many pages as there are records since the data is not sorted in any clear grouping or set. On the other hand, B+-tree indexes have a cost of 3-4 I/Os plus the number of qualifying pages or tuples, for clustered or unclustered B+-trees respectively. Assume we have the employees example again with 10,000 records and 10 records per page. Also assume that there is an index on sal and query of age ¿ 20,000, such that there are 5,000 qualifying tuples. The hash index could cost as much as 100,000 I/Os since every page could be read for every record. It is not clear with a hash index how we even go about searching for every possible number greater than 20,000 since decimals could be used. An unclustered B+-tree index would have a cost of 5,004 I/Os, while a clustered B+-tree index would have a cost of 504 I/Os. It helps to have the index clustered whenever possible.
0 comments:
Feel free to contact the admin for any suggestions and help.