BDB中索引算法的选择：Hash vs BTree

Hash 和 Btree方法应该被用于当逻辑记录号不是用来做主键对数据访问的情况。（如果逻辑记录号是一个secondary key，用来对数据进行访问，Btree方法是一个可能的选择，因为它支持通过一个键和一个记录号来同时的访问。）

Btrees中的键是按一定的秩序来存放的。Btrees应该被用于那些keys存在某种关系的时候。例如用时间做keys，当现在访问8AM时间戳的时候，可能下一个就访问9AM时间戳。也就是在排列顺序中附近的（near）。再比如，用names做keys，我们也许要访问那些有相同last name的，Btrees仍然是一个不错的选择。

在小的数据设置上，Hash 和 Btree在性能表现上没什么差别。在那儿，所有的，或大部分数据设置被放在了cache里面。

尽管如此，当一个一数据设置足够大的时候，会有一些重要的数据页再也装不进cache里了。这种情况下，我们上面讨论的btree在性能表现上就很重要了。
例如，因为在hash中没有排列顺序中附近的机制。所以，cache在Btree中通常比Hash中更有效。Btree方法将产生更少的I/O调用。

尽管如此，当一个数据设置更大的时候，hash访问方法能赢过btree方法。原因是btree比hash数据库包含了更多的元数据页。
数据设置可以变的非常大，以至于元数据开始支配整个cache。如果这种事情发生，Btree将不得不对每次请求都进行一次I/O操作。Cache中几乎没有地方再放置那些真正的数据页了，失去了cache的意义。而因为hash有很少的元数据，可以它的cache照样可以用来放置那些数据页，起到cahche的作用。

当一个数据更更大的时候，以至于每个随机请求，hash和btree几乎都要进行一次I/O操作的时候。在这中情况下，实际上hash只要遍历少树几个内部页（internal pages）就差不多能找到，所以这也是hash在性能上的一个优势。

应用程序对数据的访问式样也极大的影响这些行为。例如，延着光标往下遍历的话，每次I/O操作到cache中的数据，将满足接下来的很多数据请求。

如果数据设置只是比cache大一点，我们还是条件使用Btree，如果你实在有太大的数据设置，hash也许会更好一些。db_stat公用程序是一个有用的工具，用来监视，你的cache表现的怎么样。

总结：

其实到这你应该能看出来，btree是在数据不是很大的时候是很优秀的，在更大的时候，由于元数据占用太多cache的原因，导致性能下降，落后与hash了，而不是说hash能超过它。所以能在元数据占用cache不是太多以前，也就是你的cache足够大，使用btree只最好的选择。当然，如果每次访问的数据都是随机的没有什么次序，也不是near的，那用btree也没什么优势了。