Reveldb 与 Kyoto Tycoon 性能对比(一)

一、概述

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 :-)