This section we will cover how Btree and Ehash fares in similar conditions. However few important points to note here as one may want to ponder when to pick which one, and performance certainly, among others play important role.
Btree arranges the keys in order, default or defined by the user. Hence when we deal with data which has some order and can store them using the same then Btree is a good option. Because Btree has to maintain the order while doing the inserts or updates, it deals with some overhead compared to hash where order is not maintained. Typical complexity for Btree is in the order of logN
Since we are interested in order of the key, hence we may want to retrieve a range of adjacent keys and their values. Btree supports the functionality to do so, whereas hash would not be able to do that. Hence to have scan on range of keys, pick Btree as access method
Btree because of it's inherent structure, has balanced read and write, though we will see read performance is better for bangdb than write
Hash stores key in such a manner which guarantees constant time for write and read. Bangdb implements extendabale hash, which maintains a directory of all the index pages which in turn stores the keys and data information. Sine directory size is very small compared to index and data files, complete directory is kept in-memory all the time. This enables very fast look up for read and write. Especially for read, ehash doesn't lock any page even in cocurrent scenario, which further boosts the read performance
Hence when read performance is desired more than write, then Ehash could be a better choice, escpecially when order of keys are not important. Note that the write of ehash is again comparable to that of Btree
Following are few graphs which compares the Ehash performance to that of Btree. The comparison has been done for both log On and Off.