许多的nosql都使用leveldb或者类似leveldb的系统作为存储引擎，例如tair，hbase，canssandra，因此理解并调优存储引擎可以大大的提高系统的性能。
前一篇大致介绍了原理，这一篇接下来讲解调优相关的内容。
leveldb中的写放大
一条记录写到leveldb，则会写一次到log，写一次到level 0，随着后面更多数据的写入，level n里面的记录会与level n+1的记录合并排序，按照level n+1的数据量是level n的10倍，预计每提升一级，需要11个写，因此如果是7级的话，大约为68个写，即写放大为68。leveldb存放在内存中的数据大小write_buffer_size默认为4M，level 1的大小默认为10M。因此一个1TB的数据库会有7层。通过加大内存中的数据以及level 1的大小，例如设置write_buffer_size=1G，level1大小为4G，那么总共的层级只有5级，写放大大约为46，性能可以提升大约30%
leveldb中的读放大
前一篇提到一次记录的读取需要多次文件读取，通过bloomfilter可以讲实际读取数据降到到接近1。我们来看看bloomfilter降低读取的原理。假设filter的bits为10，一个文件有1000个key，那么filter一共有1w个bit，对每个key计算hash值，把hash值模1w后对应的bit置为1，多计算几种hash值，都设置相应的bit为1。获取一个指定的key1时，按照前面的算法计算hash值检查bit值，如果这些bit值不是全1，那么可以肯定这个key1不在文件中。这样就可以通过不读取文件就判断key1是否在文件中。当然可能会出现全1但是key1又不在文件中，这样的情况就相当于是hash冲突了。通过查阅bloomfilter的资料，可以看到hash冲突的概率的情况为：
10 bits 0.0081
15 bits 0.0007
19 bits 0.0001
假设每次读取需要查找10个文件，那么10bits的hash冲突导致的多余读取为10 * 0.0081 = 0.081大约是8%
我在实际使用tair中，当写入较多时，导致level0的数据可能达到32，这种情况下10bits的多余夺取为35 * 0.0081 = 0.2835大约是28%，此时应当增加bits，例如15bits则额外读为2.45%
这两点是是实际使用中碰到的，可以提升实际的应用性能
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
