数据库如何抵抗随机IO的问题、方法与现实

1996年，P O'Neil等提出的 LSM-Tree 是一个重大 突 破。LSM-Tree主要有两种变形，最简单的LSM-Tree，是一个内存中的小索引加上外存中的大索引，更新先缓存在小索引中，再批量更新到大索引， 这样就有望合并对属性同一页面的多次更新的IO。复杂的LSM-Tree，是划分为多个level的很多的小索引，每个level的大小，近似的是前一个 level大小的r倍，如果一个level有r个小索引，则合并形成一个下一level的较大的索引，这样随机插入或删除的平均IO开销可以降低到 log（N）/B次，是一个很大的提升。但带来的问题是，搜索的时候，就要搜索这么多个小索引，而这样的索引会有O（log（N/B））个，那是可能有几 十个，搜索的性能就可能下降几十倍，这往往也带来问题。LSM-Tree已经有不少的现实应用，BigTable、Cassandra、Lucene等这 些用的是复杂的那种LSM-Tree，InnoDB的change buffer可以说是那种一大一小的简单LSM-Tree。NTSE想在做多版本事务的时候顺便实现change buffer。

　　2000年，MA Bender等提出的Cache Oblivious B-Tree 是第二个重大突破。这个跟LSM-Tree有些类似，也是索引从小到大分成相邻大小翻倍的多个索引，因此随机插入或删除的平均IO开销也是log（N）/B次，但它用了Fractional Cascading 的技术，使得搜索的性能较传统B+树相关不多。虽然论文发表了10年了，这种索引似乎现在只有TokuDB 一家实现，它是称之为Fractal Tree。我们拿来试了试，效果果然出奇的好。


　　有没有可能将来搞出一个比Fractal Tree更好的东西呢，遗憾的是如果硬件不发生根本改变，已经证明Fractal Tree已经是最理想的了。


　　但LSM-Tree或Fractal Tree，其实只是消除索引的随机插入和删除带来的随机IO，对随机搜索没什么帮助。这个剩下的索引的随机搜索问题比较复杂，要分解来看。一种是真正的来自于应用需求的搜索，另一种是检查唯一性带来的搜索。这两种处理方法是不同的。


　　对于真正的来自于应用需求的搜索，处理还得借助于记录级缓存类似的技术，但这时变成索引项的缓存了。InnoDB中的Adaptive Hash Index就是这个东西。但对检查唯一性带来的搜索，Bloomfilter是个好方法，经常可以消除98%以上不必要的检查。所以BigTable里就 用。但对传统B+树由于索引是实时更新的，Bloomfilter不好用，对Fractal Tree，索引是在merge的时候再批量更新的，可以用Bloomfilter。我们试了TokuDB，根据性能表明看，它对索引性索引的随机插入，也 能轻松对付，估计也是用了Bloomfilter类似的技术。


　　因此，我们可以看到，随机IO这个老大难的问题，其实还是有不少的技术可以 解决的。然而，现实是悲摧的，我们经常在用的主流数据库，无论是商业的Oracle、DB2、SQL Server，还是开源的MySQL、PostgreSQL，都基本上还在用最老土的技术，InnoDB里搞了一点change buffer，就能让人津津乐道半天。NoSQL系统走在前面，用上了LSM-Tree，但也并不是最先进的，搜索的性能经常令人担忧。在索引这方 面，TokuDB走在前面，但还没为大众接受。记录方面，不清楚为什么大家不作记录级缓存，这不是很难的事，莫非认为用Memcached就可以了，“因 为善小而不为”？