代码改变世界

Reveldb 与 Kyoto Tycoon 性能对比(一)

2013-01-03 20:36  Haippy  阅读(3839)  评论(6编辑  收藏  举报

一、概述

Reveldb 是个人在空余时间和周末完成(应该说还远远未完善)的一个基于 google leveldb 的 NoSQL 数据服务器,网络连接采用了 libevent 的 HTTP 接口,因此 reveldb 天生就适合处理 HTTP 请求。但更确切地说,reveldb 并没有直接采用 libevent 的 HTTP 接口,而是使用了另外一个基于 libevent 的网络连接库 libevhtp(https://github.com/ellzey/libevhtp),并对它做了适当的修改,使之成为 reveldb 的底层组件 evhttpx(https://github.com/forhappy/reveldb/tree/master/src/evhttpx), evhttpx 为 reveldb 提供了 HTTP 和 HTTPS 支持,因此,reveldb 除了能够处理 HTTP 请求外,也能够处理 HTTPS 请求,这一特性是 Kyoto Tycoon 没有的,如果它有,请您告诉我 :-)

Kyoto Tycoon(以下简称KT)是Tokyo Tyrant 的作者Mikio Hirabayashi 的系列作品之一,KT 是一个数据库网络层服务。Reveldb 定位与 KT 类似,也是一个数据库网络层的服务,具体一点就是 Leveldb 的网络层接口(因为 leveldb 本身只是一个程序库,并没有服务器/客户端的概念),reveldb 封装了 leveldb 的绝大部分操作,如 Snapshot, Writebatch, Iterator 等等,并且在此基础之上扩展了很多命令,比如 string 的 append, prepend, insert,Key-Value 的 mset, mget, mdel, seize, mseize,此外还有 range query, 基于编辑距离的查找,正则式 regex 匹配查找;同时还提供了一些数据库管理的命令,如compact, repair, destroy 等;另外,reveldb 支持打开多个数据库,底层使用了红黑树缓存各个客户端已经打开的 leveldb 实例。

Reveldb 同时支持 HTTP RPC 和 REST 访问方式(其中 REST 还未完成),HTTP RPC 命令现在已经基本可用,文档见:GITHUB。Reveldb 支持多线程,加上 libevent 本身在网络处理方面的高性能以及 leveldb 在存储方面的速度,所以 reveldb 在性能上也有相当很好的表现,本文将之前做的测试进行一个简单的总结。

二、测试准备

 测试工作是一台相当老(可以追溯至 2007 年 12 月份)配置比较低的笔记本上进行的,具体配置如下:

 

硬件环境 软件环境
CPU Intel Core Duo CPU T5250 1.5GHz 操作系统 Ubuntu 12.04
内存容量 2 GB 内核版本 Linux 3.2.0-35-generic-pae
硬盘容量 160 GB GCC 版本 4.6.3

另外,测试对象如下,Reveldb 版本:5124b1, Kyoto Tycoon:0.9.56,Tyoto Cabinet: 1.2.76。

三、测试步骤

  • 准备测试数据,使用 cpy-leveldb(个人写的 leveldb 的 python 绑定)生成800万条 Key-Value 对
  1. import leveldb
    
    db = leveldb.LevelDB("/tmp/reveldb/default")
    batch = leveldb.WriteBatch();
    for i in xrange(1000):
        batch.Put(str(i), "%d%d%d%d%d hello, hello, hello string %s" %(i, i, i, i, i, i))
    db.Write(batch)
  • 使用 kchashtest 也同样生成800万条测试数据。
  • 使用 ab 进行测试,测试包括了 get, set 等命令,每组参数测试 5 次,取平均结果,如。
    • Kyoto Tycoon测试: ab -n 10000 -c 30 http:127.0.0.1:1978/rpc/get?key=12345
    • Reveldb 测试: ab -n 10000 -c 30 http:127.0.0.1:8088/rpc/get?key=12345
    • 即测试参数为-c 30 (30个并发) 和 -n 10000(请求10000次),测试5次,然后取平均结果作为最终的结果。
  • 测试指标选取为“测试总时长”,“每秒的请求数目”,“每秒数据传输率”

四、测试结果

请求10000次,并发数从 50 开始,每次递增 50,直到并发达到1000,测试结果如下:

 

 

五、测试总结

可以看出,reveldb 的性能和稳定性远远好于 Kyoto Tycoon,在较小的并发请求的情况下,比如 30 个并发请求,reveldb 完成 10000 次请求用时耗时1.126秒,每秒完成的请求数为 8882个,Kyoto Tycoon 耗时2.307秒,每秒完成的请求数为4334个,此时 reveldb 的性能是 Kyoto Tycoon 的两倍;而当并发增大时,比如当并发达到 1000 时,reveldb 完成 10000 次请求用时耗时 1.296 秒,每秒完成的请求数为 7716 个,Kyoto Tycoon 耗时 6.167 秒,每秒完成的请求数才1641 个,此时 reveldb 的性能接近 Kyoto Tycoon 的五倍(4.7倍);

所以,当并发请求变大时,reveldb 依然能够很好的处理大量的并发请求并且性能下降很小,而 Kyoto Tycoon 的在大并发的情况下性能下降地比较快( 每秒完成的请求数从 4334 下降为 1641,下降了 62.14%);在测试中发现的另外一个问题是 Kyoto Tycoon 的稳定性似乎并不好,在不同的并发下测试性能抖动厉害,而 reveldb 在不同程度的并发条件下依然表现稳定,虽然性能也会下降,但是下降地幅度远远小于 Kyoto Tycoon(从并发 30 的情况下每秒完成的请求数从 8882 下降到并发 1000 的 7716,下降 13.13%)。

六、存在的问题

Reveldb 目前虽然已完成了基本功能,但还远远不够,仍然还有很大的进步空间,下一步将完善 reveldb 的 REST 接口,优化代码,提升性能,支持备份(Master-Master 和 Master-Slave),支持集群(可能会采用 Zookeeper),完善文档以及相应的工具和客户端 API。

如果你希望和我一起完善 Reveldb,就在 GitHub 上面 Fork 一下吧,欢迎提交 Patch :-)