一.需求:
我们希望找到一个key-value型数据库,具有以下特点
1.稳定高效
2.基于memcache或其它方便调用的包,以便在PHP中分布调用
3.如果有热备能力更佳,但至少有主从结构。
可选择的有:memcachedb和Tokyo Tyrant。它们的官方报告数据都不错。
我们曾经对Tokyo Tyrant-Tokyo Cabinet寄予厚望,因为它可以做双主。但结果是,在插入200万100字节的数据之后,Tokyo Tyrant就像蜗牛一样,而且不断报错。
二.测试数据:
软硬件环境:
CPU: 64位4核Intel(R) Xeon(R) CPU E5310 @ 1.60GHz
内存:8G
操作系统:centos
硬盘:120G
客户端:PHP PECL扩展
启动方式:memcachedb -p11211 -d -r -u root -H /opt/mdb/ -m 6144 -N -t 4
或memcachedb -p11222 -d -r -u root -H /opt/mdb/ -m 7000 -N -t 8 -E -X -v
网络环境:未明确标注的均为localhost
(1)400字节数据单主机新增数据测试(10万数据)
内网:ping值:time=0.151 ms 千兆带宽
400字节:2.8秒/万
100字节:2.0秒/万
本机: ping值:time=0.010 ms
400字节:0.7秒/万
结论:
在小数据量的情况下,localhost和内网差别为4:1左右。
数据的大小对写效率有一定的影响,400字节和100字节的数据在写入数据时,速度差别为3:2左右,读数据效率差别较小。
(2)100字节数据单主机测试结果:(2千万数据)
新增:7280条/秒 (客户端8进程,其余未标明的测试均为单进程)
更改:200万以前1860条/s,200万稳定在以后>10000条/秒(这个现象原因还未找到,更改数据测试有待重测)
读取:>10000万条/秒
结论:
客户端程序多进程与单进程对效率影响差别很小。甚至过多客户端进程写入时,反而影响效率。
(2)将数组转成字符串存取能提高效率么?压缩选项是否能较大地提高效率?
某数组(如下),序列化后长度为700字节,用分隔符将数组的值转成字符串为350字节左右。下面测试中,已经包含把数组序列化和转字符串的时间。
array ( 0 => 10735, 1 => 10720, 2 => 10705, 3 => 10690, 4 => 10675, 5 => 10660, 6 => 10645, 7 => 10630, 8 => 10615, 9 => 10600, 10 => 10585, 11 => 10570, 12 => 10555, 13 => 10540, 14 => 10525, 15 => 10510, 16 => 10495, 17 => 10480, 18 => 10465, 19 => 10450, 20 => 10435, 21 => 10420, 22 => 10405, 23 => 10390, 24 => 10375, 25 => 10360, 26 => 10345, 27 => 10330, 28 => 10315, 29 => 10300, 30 => 10285, 31 => 10270, 32 => 10255, 33 => 10240, 34 => 10225, 35 => 10210, 36 => 10195, 37 => 10180, 38 => 10165, 39 => 10150, 40 => 10135, 41 => 10120, 42 => 10105, 43 => 10090, 44 => 10075, 45 => 10060, 46 => 10045, 47 => 10030, 48 => 10015, 49 => 10000);
在内网环境:
数组直接存取:
无压缩 写3.5秒/万,读3.2秒/万
带压缩 写3.3秒/万,读2.6秒/万
字符串存取:
无压缩 写3.0秒/万,读2.3秒/万。
带压缩 写3.1秒/万,读2.4秒/万
把数组的值都改成一样时(可压缩性高,压缩后只占了10字节以内),带压缩地写2.6秒/万,读1.9秒/万。
在本机:
数组直接存取:带压缩地写1.9秒/万,读1.1秒/万
字符串存取: 带压缩地写1.1秒/万,读0.9秒/万
结论:
数组对象转成字符串存入能可以节约一半左右的空间,但在效率方面的提高非常有限,仅在本机上写数据上有所提高。
在数据可压缩性较好时,可以大量节省空间和时间。但可压缩性不太好时,几乎没有差别。
(4)主从测试结果:(100万数据以下)
100字节数据
新增:1000条/秒
400字节
更改:100条/秒(客户端单进程)
读取:3570条/秒 (客户端单进程)
结论:
在使用主从结构时,写效率很大影响,效率差别在100:1左右,所以不建议使用主从。
(5)使用SVN最新版本的测试情况(新增350字节数据)
方案1:32位4核CPU,内存8G,-m2048启动:
表现优秀:0-443万 4000条/秒,非常稳定
表现较差:在443-800万 2100条/秒,忽快忽慢 data.db在2.5G左右。
表现很差:在800-1千万 1400条/秒,忽快忽慢 data.db在4G左右 负载load average在5左右,服务器基本不响应。
出错情况:17次/1千万
在本服务器上启动两个mdb时,负载比一个高,性能较快地达到瓶颈。三个mdb时,负载很高,启动5个mdb进程时,写数据在1000多条/秒了,基本就没有性能可言。
方案2:64位4核CPU,内存8G,-m6144启动:
0-1200万 5000条/秒,非常稳定
1300万后 2000条/秒,忽快忽慢 data.db在6G左右
1800万后 1400条/秒,忽快忽慢 data.db在8G左右 此时读数据性能也不太稳定,但大部分保持在3000-4000条/秒以上。负载load average在3左右,服务器仍然响应。
出错情况: 20次/1千万
在本服务器上,起2个mdb进程的效率比一个稍好一些,写数据在5599条/秒左右,读数据在10000条/秒左右。在32位CPU的服务器上则相反,性能更快地达到瓶颈。
在重新启动mcdb后,读和写的速度都又恢复到了最好的状态,测试到单个文件大小达到14G时,仍然能和刚开始的速度一样。另外,当负载下降后,再插入数据也能有很高的性能。
mdb停止时不能删除日志,否则不能在原数据基础上再重启。
结论:
mcdb根据硬件的情况,对应着相应的性能瓶颈。强烈建议使用CPU4核64位,8G内存的服务器,测试大数量时,表现很稳定和高效。而32位的服务器因为不能管理大内存,差别很大,很容易达到瓶颈,进入不稳定状态,如果负载重需要人工重启干预。
重新启动mcdb,可以达到释放内存,提高性能的效果。隔一断时间插入数据,也可以降低负载。
应该使用SVN的版本。SVN的最新版本整体数据也比发布版在开始时更为稳定。
一台服务器上最好不要超过两个以上mdb服务。
mcdb出错的概率比较低,在20次/1千万左右,如果出错率更高,可能是服务器负载很大造成。有些写错误实际上已经写入,报错的原因仅仅是返回的数据未读到。
(6)并发测试(内网环境)
10并发读和写 每线程50000次 每线程错误量15次左右 错误率0.03%
500并发读和写 每线程100次 每线程错误量5次左右 错误率5%,允许失败重连,最高连接数达到2300个。
300并发写 每线程100次 每线程错误量2次左右 错误率2%,
100并发读 每线程50次 错误率5%以上,允许失败重连,最高连接数达到2650以上。
50并发读 每线程5000次 错误率1%,速度很快,正常。
结论:
mdb不是一个可靠db,不能独立作为db使用,可作为大缓存。我理解,mdb虽说是持久层,但它继承自缓存的性质,决定了它不可能是可靠的。
mdb对高并发的支持并不好,读写分离解决不了问题,客户端如使用并发的长连接不断地读写,长连接数保持在50左右时效率是可靠的。
三.总结:在并发较高的环境下,将memcachedb定义为大缓存更合适,而不适用为单独的db.
1.memcachedb 必须使用多线程启动,需要在编译时加上--enable-threads,否则在100万左右数以后据时,写入数据将不断报错,并效率极低,且读写并行能力极差。另外,如果要使用-m参数,需要从SVN拿,发布版不行。
2.使用8G内存与2G内存对比,速度差别在2:1左右。(2G的数据就不提供了)
3.使用localhost和千兆内网速度比为4:1。
4.在使用主从结构时,写效率很大影响,效率差别在100:1左右,所以不建议使用主从。
5.数据的大小对写效率有一定的影响,400字节和100字节的数据在写入数据时,速度差别为3:2左右,读数据效率差别较小。
6.客户端程序多进程与单进程对效率影响差别很小。甚至过多客户端进程写入时,反而影响效率。
7.数组对象转成字符串存入能可以节约一半左右的空间,但在效率方面的提高非常有限,仅在本机上写数据上有所提高。
8.在数据可压缩性较好时,可以大量节省空间和时间。但可压缩性不太好时,几乎没有差别。
9.mcdb根据硬件的情况,对应着相应的性能瓶颈。在方案1中,存放3G以下数据量能得到最佳性能,方案2则在6G以下。可以启动多个进程来解决单个文件太大的问题。
10.单线程连接时,mcdb出错的概率比较低,在20次/1千万左右
11.如果将log全都删除,重启数据库会失败。可以在启动时用-E选项,由mdb自动管理日志。
12.并发时,mdb不是一个可靠db,有一定的出错率,不能独立作为db使用,可作为大缓存。
13.mdb对高并发的支持并不好,读写分离解决不了问题,客户端如使用并发的长连接不断地读写,长连接数保持在50左右时效率是可靠的。
四.参考:
1.memcachedb官方测试结果: http://memcachedb.org/benchmark.html
2.Tokyo Cabinet的测试结果和介绍:http://blog.s135.com/read.php?362&guid=9
3.某网友的Tokyo Cabinet测试:http://blog.zol.com.cn/861/article_860439.html 结果比我在基于Tokyo Tyrant的测试好看多了,但也明确表示在200万数据以后变慢很多。
官网:http://memcachedb.org/
作者的讨论组:http://groups.google.com/group/memcachedb
安装和启动指南:http://blog.csdn.net/simonlsy/archive/2008/01/07/2027940.aspx
转载于:https://blog.51cto.com/crazyming/545467