[repost ]存储引擎数据结构优化(2):io bound

original:http://www.douban.com/note/304349195/ 经常看到些引擎与别的引擎进行性能对比，测试数据只有100万，然后就得出我的引擎比别的引擎性能要高的结论（我也曾经干过）。 其实这个测试结果意义不大，只能说明在100万这个数据规模，你的引擎性能领先。 100万记录，key 16bytes, values 100bytes，共 100,0000 * (116)Bytes ~110MB。 如果用的buffered-io，测试的基本是引擎的cpu-bound，很少或基本没有触及到后端的disk io。 一个合理的测试，应该是把引擎cache开小点，然后持续压几亿甚至几十亿条数据，结合着它的io行为一起看。如果在这样的条件下，性能一直领先，那说明这个引擎确实不错。 如果引擎A干完一个活需要10次io，而引擎B干完同样的活需要250次io，可简单认为引擎A对io是友好的，本文就谈下针对io-bound的优化，如何设计数据结构，干同样的活，花更少的io。 一个“二维”的tree(索引结构)落在磁盘上的时候，就变成了个“一维”文件。 假设经过多次添加删除等操作后，一个索引tree(这里二叉树是个示例，真正的索引不是这样的结构，fanout要大)如下： /* * * (key-6) * / \ * (key-4) (key-8) * / \ / \ * (key-3) (key-5) (key-7) (key-9) * * */ 它在磁盘上的“一维”文件结构是： /* * * | … |(key-6)|(key-3)| … |(key-4)| … |(key-8)|(key-7)| … |(key-5)| * */ [...]



via WordPress http://blog.newitfarmer.com/imd/design-db/13214/repost-%e5%ad%98%e5%82%a8%e5%bc%95%e6%93%8e%e6%95%b0%e6%8d%ae%e7%bb%93%e6%9e%84%e4%bc%98%e5%8c%962io-bound#utm_source=rss&utm_medium=rss&utm_campaign=repost-%25e5%25ad%2598%25e5%2582%25a8%25e5%25bc%2595%25e6%2593%258e%25e6%2595%25b0%25e6%258d%25ae%25e7%25bb%2593%25e6%259e%2584%25e4%25bc%2598%25e5%258c%25962io-bound