Redis 2.6 新功能预告：aof性能提升
openkk 13年前
<p><span class="hilite1"><a href="/misc/goto?guid=4958185538616997143" target="_blank"><strong>Redis</strong> </a>是</span>一个高性能的key-value数据库。 <span class="hilite1">redis</span>的出现，很大程度补偿了memcached这类keyvalue存储的不足，在部 分场合可以对关系数据库起到很好的补充作用。它提供了Python，Ruby，Erlang，PHP客户端，使用很方便。</p> <p><a href="/misc/goto?guid=4958185538616997143"><img alt="Redis 2.6 新功能预告：aof性能提升" src="https://simg.open-open.com/show/3c88605e89bd5c29c2bd09b022a193ed.png" width="93" height="30" /> </a><span style="font-weight:bold;"><br /> <br /> 在2.4版</span>本中，<span class="wp_keywordlink_affiliate">Redis</span>对很多命令引入了批量参数的功能，这可以让我们一次连接一个操作就操作多个值。这些功能可能你已经用上了，但今天我们要讲一个在2.6版本中会推出的一个优化，aof文件rewrite和load的性能提升。</p> <p>我们知道aof文件是纯文本形式的，里面存储的是Redis的文本协议内容。而在有了批量参数功能后。我们可以把批量参数的命令组合成一个命令，这 样就能够减小aof文件的大小。其优点是显而易见的。比如我们在rewrite的时候，我们可以通过一条命令就把set，list，zset，hash的 数据写完。load的时候也只需要一条命令就能执行完。</p> <p>下面是Redis作者做的性能测试结果：</p> <p>数据集如下：</p> <pre>TYPES ===== string: 95480 (95.48%) zset: 4469 (4.47%) list: 48 (0.05%) set: 3 (0.00%)</pre> <p>可以看到，纯key-value的string类型占了绝大多数（95.48%），实际上能够被组织成一条批量命令的数据占比非常小。在这种不利于aof优化的情况下，测试结果如何呢？</p> <p>对于aof rewrite操作：</p> <ul> <li>使用旧的aof rewrite方法：耗时 12 秒，aof文件大小 569 MB</li> <li>使用新的aof rewrite方法：耗时 9 秒，aof文件大小 479 MB</li> <li>而BGSAVE写rdb文件的：耗时 9 秒，rdb文件大小 344 MB</li> </ul> <p>对于加载aof操作</p> <ul> <li>加载 RDB 文件时间：7.156 秒</li> <li>加载旧的<span class="wp_keywordlink_affiliate">AOF</span>文件时间：15.232 秒</li> <li>加载新的AOF文件时间：12.589 秒</li> </ul> <p>我们可以看到，相对来说性能提升在20%-30%之间，效果还是相当明显的。</p> <p>下面再试一个好一些的情况，当数据全部是hash结构的时候，结果会怎么样呢。首先用下面的lua脚本向Redis写入100w个hash数据，每个hash数据包含16个属性</p> <pre>local i, j for i=1,1000000 do for j=1,16 do redis.call('hmset','key'..i,'field:'..j,'value:'..j) end end return {ok="DONE"}</pre> <p>对这100w数据进行上面的实验，得到如下的结果。</p> <p>对于aof rewrite操作：</p> <ul> <li>使用老的aof rewrite方法：耗时 17 秒，aof文件大小 851 MB</li> <li>使用新的aof rewrite方法：耗时 10 秒，aof文件大小 440 MB</li> <li>而BGSAVE写rdb文件的：耗时 4 秒，rdb文件大小 158 MB</li> </ul> <p>对于加载aof操作</p> <ul> <li>加载 RDB 文件时间：1.888 秒</li> <li>加载旧的AOF文件时间：31.946 秒</li> <li>加载新的AOF文件时间：17.512 秒</li> </ul> <p>我们能够看到，相对于旧的AOF文件，新的方法在性能上接近50%的提升。而RDB文件的性能更是惊人。这是因为在2.4版本中，BGSAVE方法 会将通过zipmap，ziplist等压缩结果直接作为value写入到dump文件，并不解析其结构，而我们上面的例子，100w hash数据，每个属性只有16个，所以全部都会采用zipmap进行压缩存储。这是RDB文件在性能上更高的原因。</p> <p>无论如何，还是让我们期待2.6版本的新版AOF吧。</p> <p>来源：<a href="/misc/goto?guid=4958318593434002877" target="_blank">antirez.com</a><br /> <br /> 本文转载自: <a href="/misc/goto?guid=4958318594225538185" rel="nofollow" target="_blank">http://blog.nosqlfan.com/html/3562.html</a> </p>