千万级海量测试数据运算下,Redis VS Couchbase性能大揭秘!

杨挺
原创 13672       2017-07-11  

上一篇中我们介绍了Redis Couchbase的不同之处和展现各自的优势所在(请戳蓝色加粗字体:Couchbase vs Redis,究竟哪个更胜一筹?)。本文会为开发者提供最真实有力的数据支撑,让技术选型更加客观,让集群扩容不再盲目,在可预估的业务规模下,让每一台机器物尽其材。

▲测试人员:杨挺,宋佳阳

▲测试时间:2017.5.8-2017.5.192017.6.28---2017.6.30

▲测试环境

▲测试工具

▲系统部署

1.集群部署:
由于redis采用单线程模型,即一个实例只能使用一个核,所以这里为了充分发挥机器性能,在3台4核的集群机器上一共部署了24个redis实例,其中12个主实例12个备份实例,对所有数据启用一份备份,即每台服务器部署八个redis实例,四主四从。而Couchbase可以充分利用多核CPU,因此每个机器只部署一个实例,数据备份启用一份。


2.压测客户端部署:
OPS压测客户端部署多线程OPS测试程序,用于测试并统计OPS;ResponseTime压测客户端部署单线程ResponseTime测试程序,用于测试并统计不同压力下集群服务的响应时间。


测试方案
每台OPS客户端使用500/1000/2000(同步的读写操作会阻塞线程,直至提升线程数OPS无明显变化)个并发线程向集群发送读/写请求,以确保Redis/Couchbase集群发挥最大输出能力,与此同时RsponseTime压测客户端采用单线程(OPS和RsponseTime测试分客户端执行是为了避免客户端网络,客户端CPU调度等对测试结果的干扰;RsponseTime压测客户端端采用单线程是为了减少CPU时间分片对响应时间的影响)发送读/写请求并记录每个请求的响应时间,以纳秒级别的统计精度准确反映出集群在最大OPS的压力下,仍能表现出的处理速度。(OPS和响应时间统计工作,由测试代码完成)


测试案例
以下测试中,采用HashMap作为测试数据类型,在Redis中直接以HashMap格式存取,在Couchbase中需要将Hashmap转换为Json格式进行存取。


【 小块数据小数据量写入测试】
四台OPS客户端分别向集群发送100W个100字节大小的数据写入请求,并统计OPS;RsponseTime压测客户端向集群发送1W个100字节大小的数据写入请求,并统计响应时间。


一、 Couchbase写入测试
四台OPS压力客户端分别启动500个并发线程和4个bucket连接数(升高和降低该数值性能表现都略有降低)分别向Couchbase集群插入100W条数据,即2000个并发线程发起400W个100字节大小的Document的插入请求,一台RsponseTime压测客户端分别在OPS压测前和OPS压测过程中,测试和统计Couchbase集群的服务处理速度。

压测前Couchbase集群的RsponseTime统计:

10.20.135.66

压测前,RsponseTime压测客户端使用单线程向集群发起一万笔写入请求,平均响应时间为0.35ms。


Couchbase控台监控情况如下:


Couchbase集群的资源消耗情况如下:
10.20.135.71

(memcached负责内存和硬盘的数据操作;beam.smp负责Couchbase其他潜在进程的监控和管理,比如跨集群备份,索引和集群操作)
10.20.135.72

10.20.135.73


OPS压测客户端的资源消耗如下:

10.20.135.67

10.20.135.68

10.20.135.69

10.20.135.70


OPS压测客户端统计如下:

10.20.135.67

10.20.135.68

10.20.135.69

10.20.135.70


RsponseTime压测客户端统计如下:
10.20.135.66

测试结果分析:
Couchbase集群资源消耗几乎达到瓶颈,且再增大压力OPS没有提升,RsponseTime倒是明显升高。因此,三台4核8G的Couchbase集群,正常情况下能提供0.35ms(有一个重要原因是Couchbase插入操作返回完整Document)的平均响应时间,在2000个并发线程发起400W个100字节大小Document的写入压力下,能够稳定提供15W的OPS,且平均响应时间只有1.95ms(多次测试后选取的一个稳定时间)。

二、Redis写入测试



四台OPS压力客户端分别启动500个并发线程和300个并发连接(再升高该数值性能表现略微下降),分别向Redis集群插入100W条数据,即2000个并发线程发起400W个100字节大小的数据写入请求,一台RsponseTime压测客户端分别在OPS压测前和OPS压测过程中,测试和统计Redis集群的服务处理速度,测试结果如下:
压测前Redis集群的RsponseTime统计:

压测前,RsponseTime压测客户端使用单线程向集群发起一万笔写入请求,平均响应时间为0.21ms。


Redis集群的资源消耗情况如下:
10.20.135.71

(4个Redis主节点对外暴露提供读写服务,4个从节点提供备份服务;因此查询测试中只有4个Redis进程消耗资源)
10.20.135.72

10.20.135.73


 OPS压测客户端统计如下:

10.20.135.67

10.20.135.68

10.20.135.69

10.20.135.70


RsponseTime压测客户端统计如下:

10.20.135.66


测试结果分析:
虽然OPS压测客户端和Redis集群的资源消耗都没有逼近满负荷,但再增大压力的情况下OPS不升反降,RsponseTime更是明显增长。因此,三台四核八G的Redis集群正常使用情况下能提供0.21ms的平均响应时间,在百万量级100字节大小的数据块写入请求下能够稳定提供20W的OPS,且平均响应时间只有2.09ms。

三、 测试小结
正常使用情况下,Redis和Couchbase都可以提供亚毫秒级别的处理速度,但Redis集群的响应速度(0.21ms)比Couchbase集群(0.35ms)几乎快一倍。在2000个并发线程发起400W个100字节大小数据写入压力下,Redis集群能稳定提供20W的OPS,Couchbase集群能提供稳定15W的OPS,平均响应时间方面两者相当。继续增大压力的话,Redis的RsponseTime增长速度大于Couchbase,即Redis在较大压力下的处理速度下降较快。


【小块数据大数据量写入测试】

每台OPS客户端向集群发送500W个100字节大小的数据写入请求,并统计OPS;RsponseTime压测客户端向集群发送1W个100字节大小的数据写入请求,并统计响应时间。


一、 Couchbase写入测试
四台OPS压力客户端分别启动500个并发线程和4个bucket连接数向Couchbase集群插入500W条数据,即2000个并发线程发起2000W个100字节大小的Document的写入请求,一台RsponseTime压测客户端在OPS压测过程中,测试和统计Couchbase集群的服务处理速度,测试结果如下:
Couchbase控台监控情况如下:


Couchbase集群的资源消耗情况如下:
10.20.135.71

10.20.135.72

10.20.135.73

OPS压测客户端的资源消耗如下:
10.20.135.67

10.20.135.68

10.20.135.69

10.20.135.70


OPS压测客户端统计如下:
10.20.135.67

10.20.135.68

10.20.135.69

10.20.135.70


RsponseTime压测客户端统计如下:
10.20.135.66

测试结果分析:
Couchbase集群资源消耗几乎达到瓶颈,且再增大压力OPS没有提升,RsponseTime倒是明显升高。因此,三台4核8G的Couchbase集群,正常情况下能提供0.35ms的平均响应时间,在2000个并发线程发起2000W个100字节大小Document的写入请求压力下,能够稳定提供14W的OPS,平均响应时间达到3.81ms。


二、 Redis写入测试
四台OPS压力客户端分别启动500个并发线程和300个并发连接(再升高该数值性能表现略微下降),分别向Redis集群插入500W条数据,即2000个并发线程发起2000W个100字节大小的数据插入请求,一台RsponseTime压测客户端在OPS压测过程中,测试和统计Redis集群的服务处理速度,测试结果如下:


Redis集群的资源消耗情况如下:
10.20.135.71

10.20.135.72

10.20.135.73


OPS压测客户端资源消耗如下:
10.20.135.67

10.20.135.68

10.20.135.69

10.20.135.70


OPS压测客户端统计如下:
10.20.135.67

10.20.135.68

10.20.135.69

10.20.135.70

RsponseTime压测客户端统计如下:
10.20.135.66


测试结果分析:
Redis集群和OPS压测客户端的资源消耗并未达到瓶颈,但再增大压力OPS没有提升,RsponseTime倒是明显升高。因此,三台4核8G的Redis集群,正常情况下能提供0.21ms的平均响应时间,在2000个并发线程发起2000W个100字节大小Document的写入请求压力下,能够稳定提供16W的OPS,但平均响应时间达到6.43ms。


三、测试小结
在2000个并发线程发起2000W个100字节大小Document的写入请求压力下,Redis集群能稳定提供16W的OPS,Couchbase集群能提供稳定14W的OPS,而平均响应时间方面Redis集群(6.43ms)明显长于Couchbase集群(3.81ms),即此时两者所提供的OPS相当,但Couchbase集群的请求处理速度已明显反超Redis集群。


 【大块数据小数据量写入测试】
每台OPS客户端向集群发送50W个10KB大小的数据写入请求,并统计OPS;RsponseTime压测客户端向集群发送1W个100字节大小的数据写入请求,并统计响应时间。


一、 Couchbase写入测试
六台OPS压力客户端分别启动1000个并发线程和4个bucket连接数向Couchbase集群插入50W条数据,即6000个并发线程发起300W个10KB大小的Document的插入请求,一台RsponseTime压测客户端在OPS压测过程中,测试和统计Couchbase集群的服务处理速度,测试结果如下:
Couchbase控台监控情况如下:


Couchbase集群的资源消耗情况如下:
10.20.135.71

10.20.135.72

10.20.135.73

OPS压测客户端的资源消耗如下:
10.20.135.57

10.20.135.58

10.20.135.67

10.20.135.68

10.20.135.69

10.20.135.70


OPS压测客户端统计如下:
10.20.135.57

10.20.135.58

10.20.135.67

10.20.135.68

10.20.135.69

10.20.135.70


RsponseTime压测客户端统计如下:
10.20.135.66


测试结果分析:
Couchbase集群资源消耗未达到机器瓶颈,但OPS压测客户端都达到满负荷,因为没有额外机器完成极限测试,测试结果仅能表明单台8核8G OPS压测客户端只能发起一千OPS左右的10K数据块写入请求。因此,三台4核8G的Couchbase集群,正常情况下能提供0.35ms的平均响应时间,在6000个并发线程发起300W个10KB大小Document的写入请求压力下能够稳定提供6K以上的OPS,平均响应时间只有1.16ms,可见压力主要集中在客户端。


二、 Redis写入测试
六台OPS压力客户端分别启动1000个并发线程和300个并发连接数分别向Redis集群插入50W条数据,即6000个并发线程发起300W个10KB大小的数据插入请求,一台RsponseTime压测客户端在OPS压测过程中,测试和统计Redis集群的服务处理速度,测试结果如下:
Redis集群的资源消耗情况如下:
10.20.135.71

10.20.135.72

10.20.135.73


OPS压测客户端资源消耗如下:
10.20.135.57

10.20.135.58

10.20.135.67

10.20.135.68

10.20.135.69

10.20.135.70


OPS压测客户端统计如下:出现大量超时等写入异常
RsponseTime压测客户端统计如下:
10.20.135.66


测试结果分析:

在百万级别10KB大小的数据写入操作下,集群资源消耗极不稳定。Redis集群出现了混乱,首先是错误执行了主从切换,又因为OOM被操作系统杀死(可手动设置内存使用上限),且平均响应时间达到4.27ms。因此,在未经足够优化的条件下,Redis集群在大数据块的写入操作下,显得并不稳定。


三、测试小结
在6000个并发线程发起300W个10KB大小Document的写入请求压力下,Couchbase集群能够稳定提供6K以上的OPS,平均响应时间只有1.16ms,而Redis集群显得极不稳定且平均响应时间长达4.27ms。因此,在大数据块的写入操作下,Couchbase集群显得更高效更可靠。


【 小块数据大数据量读取测试】
每台OPS客户端向集群发送1000W个100字节大小的数据读取请求,并统计OPS;RsponseTime压测客户端向集群发送1W个100字节大小的数据读取请求,并统计响应时间。

一、 Couchbase读取测试
六台OPS压力客户端分别启动500个并发线程和4个bucket连接数分别从Couchbase集群读取1000W条数据,即3000个并发线程发起6000W个100字节大小的Document的读取请求,一台RsponseTime压测客户端分别在OPS压测前和OPS压测过程中,测试和统计Couchbase集群的服务处理速度,测试结果如下:


压测前Couchbase集群的RsponseTime统计:

10.20.135.66


Couchbase控台监控情况如下:


Couchbase集群的资源消耗情况如下:
10.20.135.71

10.20.135.72

10.20.135.73


OPS压测客户端的资源消耗如下:
10.20.135.57

10.20.135.58

10.20.135.67

10.20.135.68

10.20.135.69

10.20.135.70


OPS压测客户端统计如下:
10.20.135.57

10.20.135.58

10.20.135.67


10.20.135.68

10.20.135.69

10.20.135.70


RsponseTime压测客户端统计如下:
10.20.135.66


测试结果分析:
虽然Couchbase集群没有达到满负荷,但此时平均响应时间已长达7.04ms,继续追加压力会造成响应时间的快速增长,再一味追求OPS已经没有意义,且尝试追加一台OPS客户端后OPS提升并不明显。
因此在拥有2000W条100字节数据的Couchbase集群中,正常情况下读取操作的响应时间只有0.35ms,3000个线程并发进行总计6000W次的100字节的数据查询操作,Couchbase集群能稳定提供51W以上的OPS,但平均响应时间长达7.04ms。


二、 Redis读取测试
六台OPS压力客户端分别启动500个并发线程和300个并发连接数分别从Redis集群读取1000W条数据,即3000个并发线程发起6000W个100字节大小的数据读取请求,一台RsponseTime压测客户端在OPS压测过程中,测试和统计Redis集群的服务处理速度,测试结果如下:


压测前Redis集群的RsponseTime统计:
10.20.135.66


Redis集群的资源消耗情况如下:
10.20.135.71

10.20.135.72

10.20.135.73


OPS压测客户端资源消耗如下:
10.20.135.57


10.20.135.58

10.20.135.67

10.20.135.68

10.20.135.69

10.20.135.70


OPS压测客户端统计如下:
10.20.135.57

10.20.135.58

10.20.135.67

10.20.135.68

10.20.135.69

10.20.135.70


RsponseTime压测客户端统计如下:
10.20.135.66


测试结果分析:
虽然Redis集群没有达到满负荷,但此时平均响应时间已长达9.12ms,继续追加压力会造成响应时间的快速增长,再一味追求OPS已经没有意义,且尝试追加一台OPS客户端后OPS提升并不明显。
因此在拥有2000W条100字节数据的Redis集群中,正常情况下读取操作的响应时间只有0.74ms,3000个线程并发进行总计6000W次的100字节的数据查询操作压力下,Redis集群能稳定提供18W以上的OPS,但平均响应时间长达9.12ms。


三、 测试小结
在2000W条100字节数据的规模下,Redis和Couchbase仍然可以为读取请求提供亚毫秒级别的处理速度,但Couchbase集群的处理速度(0.35ms)反超Redis集群(0.74ms)一倍。在3000个线程并发进行总计6000W次的100字节的数据查询操作压力下,Redis集群能稳定提供18W的OPS,Couchbase集群能提供稳定51W的OPS,平均响应时间方面两者差异不大。继续增大压力的话,OPS无明显增长Redis的RsponseTime增长速度大于Couchbase,即Redis在较大压力下的处理速度下降较快。


【大块数据小数据量读取测试】
每台OPS客户端向集群发送200W个10KB大小的数据读取请求,并统计OPS;RsponseTime压测客户端向集群发送1W个10KB大小的数据读取请求,并统计响应时间。


一、 Couchbase读取测试
六台OPS压力客户端分别启动500个并发线程和4个bucket连接数(升高和降低该数值性能表现都略有降低)分别从Couchbase集群读取200W条数据,即3000个并发线程发起1200W个10KB大小的Document的读取请求,一台RsponseTime压测客户端分别在OPS压测前和OPS压测过程中,测试和统计Couchbase集群的服务处理速度,测试结果如下:


压测前Couchbase集群的RsponseTime统计:
10.20.135.66


Couchbase控台监控情况如下:


Couchbase集群的资源消耗情况如下:
10.20.135.71

10.20.135.72

10.20.135.73


OPS压测客户端的资源消耗如下:
10.20.135.57

10.20.135.58

10.20.135.67

10.20.135.68

10.20.135.69

10.20.135.70


OPS压测客户端统计如下:
10.20.135.57

10.20.135.58

10.20.135.67

10.20.135.68

10.20.135.69

10.20.135.70


RsponseTime压测客户端统计如下:
10.20.135.66


测试结果分析:
Couchbase集群资源消耗未达到机器瓶颈,但即使再增加压力OPS也不会有明显增加,平均响应时间倒是明显增长。因此,三台4核8G的Couchbase集群,正常情况下能为客户端读取操作提供0.68ms的平均响应时间,在300W条10KB大小数据块的规模下,3000个并发线程发起1200W个10KB大小的Document的读取请求压力下,Couchbase集群能够稳定提供9W以上的OPS,平均响应时间只有2.79ms。


【测试总结】
经过以上测试,我们可以得到以下结论:
小块数据,小数据量下

Redis以更小的资源消耗提供了更高的OPS和更快的服务速度,因其接口设计不同,相较Couchbase还减少了网络传输。因此,Redis更适合作为一个更轻更快的组件集成到整个系统中。


小数据块,大数据量下

Redis以更低的资源消耗提供了和Couchbase相当的数据写入OPS,但此时的服务速度已经明显落后于Couchbase;数据读取操作上Couchbase以更低的响应时间提供了几乎三倍于Redis的OPS(配置了View Index,4.0以后的N1QL能进一步提高查询性能)。因此对于拥有一定的数据规模,且写少查多的场景,Couchbase无疑是更加合适的选择。


大块数据,小数据量下

在同样未经优化的情况下,Redis集群不发生崩溃已经是幸事(后续我们会推出针对性的优化建议以及实测报告),如果你需要进行整页缓存,图片或文件存储,又没有足够的精力去完成集群优化管理和异常分析处理,建议选择Couchbase。


大块数据,大数据量下

二选一的情况下,直接选择Couchbase。


以上的测试案例并没有包括全部的使用场景,实际使用中肯定不会出现单一类型的数据存储,机器配置和集群部署等环境因素也会对性能表现造成巨大影响,而我们又无法穷尽每一种情况。因此我们进一步简化了测试工程,同学们可以通过https://github.com/yt485212/NoSQLTest(eclipse直接Git导入,填写该URI,填写自己的GitHub账号密码,检出后convert to maven)进行获取,修改couchbase-config.xml和redis-config.xml的相关配置,参考我们的测试方案即可快速上手进行定制化的性能测试,得到最适合自身的性能数据。如果有相关需求或者任何问题都可以通过留言联系我们。

在此特别鸣谢宋佳阳同学的大力支持。


恒生技术之眼原创文章,未经授权禁止转载。详情见转载须知

联系我们

恒 生 技 术 之 眼