柳皓亮,王 丽,周阳辰(中国科学院电子学研究所苏州研究院存储计算组,江苏苏州215123)
Redis集群性能测试分析
柳皓亮,王丽,周阳辰
(中国科学院电子学研究所苏州研究院存储计算组,江苏苏州215123)
摘 要:Redis是一个非关系型数据库,属于内存级数据库。但是由于数据量的不断增大,单机的Redis物理内存远远无法满足大数据的需要,因此需要搭建分布式的Redis,可以动态扩展内存,弥补单机Redis物理内存不够的缺点。本次测试旨在对Redis各方面性能有深入的了解,为今后的工作打好基础。本次实验的目的主要是搭建Redis Cluster和TwemProxy Redis两种集群,分别对其进行性能测试,测试出集群性能的拐点,找出性能的瓶颈有哪些,并对两套集群进行比较,以便于在不同业务场景下择优选择。
关键词:Redis Cluster;TwemProxy Redis;性能测试
本次存储测试是用Java程序调用Jedis提供的API向集群里面灌入数据。首先研究灌入少量数据后两种集群的数据分布在哪些节点上,然后研究灌入大量数据后两种集群的落盘情况。
1.1Redis C luster
(1)少量数据储存分析
用程序向某一个节点灌入30条数据,结果发现每个节点拥有部分数据,数据存储得很分散。由此可知,数据落盘时把一份数据分成多份存储在不同的Redis节点上,进行分片存储,通过调研得知这种分配方式是通过sharding算法分配[1]的。
(2)大量数据存储分析
首先查看单节点未插入数据前的rdb大小为18 B;然后,用Java程序插入10万条数据,查看rdb大小为1 289 892 B,然后改用Java程序向Redis Cluster集群中灌入10万条数据,查看每个节点rdb文件大小分别为214 912 B、 216 586 B、215 939 B、214 145 B和213 757 B。由此可见,单机的rdb大小约等于每个Redis节点rdb大小之和,并且每个节点rdb大小相对均衡。综上所述,这种落盘方式把一份数据平均分配到每一个节点上,也就是说每一个节点的rdb文件共同组成一份完整的数据。
1.2Twem Proxy Red is
(1)少量数据存储分析
向集群中插入20条key为0~19的数据,查看数据在各个Redis节点分布情况,结果发现某个节点存储第0 ~9的数据,另一个节点存储11~19的数据,最后一个节点没有存储数据。经过多次相同参数测试,每次落盘结果相同,由此可见TwemProxy[2]根据相应算法将数据落盘到各个节点中,并且分配算法是对一段连续的数据进行落盘,而不是对每一条数据进行选择存入到哪个节点中的操作,这样可以减少路由开销。
(2)大量数据存储分析
首先查看单机Redis节点未插入数据前的rdb文件大小为84 B;然后插入10万条数据,查看rdb文件大小为1.6 MB;接着改用Java程序向TwemProxy Redis[2]集群中灌入10万条数据,查看各各节点rdb文件大小分别为0.49 MB、0.62 MB和0.51 MB。由此可见,单机的rdb大小约等于每个Redis节点rdb大小之和,并且每个节点rdb大小相对均衡。由此可见,这种落盘方式把一份数据平均分配到每一个节点上,也就是说每一个节点的rdb文件共同组成一份完整的数据。
主要从3个方面进行测试,当value类型分别是String类型、list类型和map类型时,统计吞吐率的走势,找出拐点,并分析原因[2]。
2.1Redis C luster
(1)String插入测试——吞吐率随value大小变化情况:当吞吐量一定时并且插入的是String类型数据时,如果value值在1 KB以内时,吞吐率基本保持不变;如果value值大于1 KB,吞吐率随value增大而减小。当value值达到10 KB且请求总量为1万条时,共100 MB的数据,内存远远没有被打满,即此时内存的使用率仍比较低,所以此时Redis数据存储瓶颈[3]并不是内存。同时监控了网卡和IO,发现均处于正常水平,所以也不是这两方面的原因。所以可以推出,此时吞吐率下降是由于Redis本身不能够承受过大的value值。
(2)String插入测试——吞吐率随吞吐量变化情况:当value大小一定时,吞吐量的增大对吞吐率没有影响。
(3)String获取测试——吞吐率随value大小变化关系:结果与(2)相同。
(4)List插入测试——吞吐率随List大小变化情况:当List元素大小和吞吐量一定时,吞吐率随list的size增大而减小,size从10增加大100时吞吐率下降了一半。由此可见,Redis Cluster对List的支持效果并不好,性能有待提升,不建议在以后的项目阶段用Redis Cluster存储List。
(5)List插入测试——吞吐率随List元素字节大小变化情况:List的元素字节大小变化对吞吐率没有影响。
(6)List插入测试——吞吐率随吞吐量大小的变化关系:吞吐率与吞吐量无关。
(7)Map插入测试——吞吐率随Map size大小变化关系:当吞吐量和元素字节一定时,吞吐率随Map的size增大而减小。
(8)Map插入测试——吞吐率随Map的value大小变化情况:当吞吐量和Map的size一定时,吞吐率随Map元素字节增大而减小。
2.2Twem Proxy Redis
TwemProxy Redis[2]采用单条读写和批量读写两种方式进行压力测试,测试结果如下。
(1)String单条插入测试——吞吐率随value大小变化情况:value值在1 KB以内且总请求量为1万时吞吐率基本保持不变;当value值大于1 KB时,吞吐率随value增大而减小,单条TwemProxy Redis的插入吞吐率明显比Redis Cluster低。
(2)String批量插入测试——吞吐率随value大小变化情况:当吞吐量一定时,value值小于100 B时,吞吐率随value增大而增大;当value值大于100 B时,吞吐率随value增大而减小。由此可见,批量插入存在极值点,此外批量插入的吞吐率远远高于TwemProxy Redis和Redis Cluster的单条插入。
(3)String单条获取测试——吞吐率随value大小变化关系:测试结果与(1)的结果相同。由此可见,Twem-Proxy Redis的单条读写效率一致。
(4)String批量获取测试——吞吐率随value大小变化关系:结果与(2)相同。
(5)String单条插入测试——吞吐率随吞吐量的变化关系:吞吐率与吞吐量无关,TwemProxy Redis吞吐率只有Redis Cluster的一半,明显吞吐率很低。
(6)String批量插入测试——吞吐率随吞吐量的变化关系:随着吞吐量的增加,吞吐率也在增加。但在测试时将请求量给到10万条后,程序宕掉并且集群服务停止工作,说明pipeline批量打包的数据量有限,即性能是有限的。但是可以通过打包多次解决这个问题,批量插入的吞吐率明显高于TwemProxy Cluster和Redis Cluster的单条插入吞吐率。
(7)List和Map类型的单条插入测试吞吐率变化:吞吐率变化与Redis Cluster的相同,但是吞吐率低于Redis Cluster。
(8)List和Map类型的单条插入测试吞吐率变化:吞吐率变化与Redis Cluster的相同,但是吞吐率高于Twem-Proxy Cluster和Redis Cluster的单条吞吐率。
(1)TwemProxy Redis的批量读写吞吐率远远高于Redis Cluster单条的吞吐率,Redis Cluster单条读写的吞吐率略高于TwemPrxoy Redis单条吞吐率。
(2)Redis Cluster和TwemPrxoy Redis对List和Map集合的吞吐率很低,不建议存储这两种类型的数据。
(3)当需要进行TwemProxy Redis批量操作时,需要通过程序保证一次批量读写的数据量不宜过大,否则底层服务会宕掉。
参考文献
[1]王敏,陈亚光.数据库系统辅助测试工具[J].微型机与应用,2013,32(3):13-15,18.
[2]夏文忠,邹雯奇.基于X86平台的高性能数据库集群技术的研究[J].微型机与应用,2015,34(1):36-39,46.
[3]张蕾,侯瑞春,丁香乾,等.会话保持机制在集群系统中的应用研究[J].微型机与应用,2015,34(9):32-34,50.
柳皓亮(1991 -),男,硕士研究生,主要研究方向:分布式在线实时流式计算。
王丽(1992 -),女,硕士研究生,主要研究方向:分布式数据挖掘与存储。
周阳辰(1992 -),男,硕士研究生,主要研究方向:集群监控。
引用格式:柳皓亮,王丽,周阳辰.Redis集群性能测试分析[J].微型机与应用,2016,35(10):70-71,78.
The analysis of the performance test of the Redis Cluster
Liu Haoliang, Wang Li, Zhou Yangchen
(Storage Computing Group,Suzhou Institute of Electronics,Chinese Academy of Sciences Research Institute,Suzhou 215123,China)
Abstrac t:Redis is a non-relational database,which belongs to the memory database.However,with the amount of data increasing quickly,the single Redis is unable tomeet the needs of the large data.So we need to build a distributed Redis,which can extend memory dynamicly and make up the faults that the single Redis doesn' t have enough physical memory.In order to have a good design for the Redis Cluster and p lay a Redis high throughput characteristics of Redis Cluster,we make the experiment about this.In this experiment,we build two clusters,which are Redis Cluster and TwemProxy Cluster.W e make experiment one by one to test out the clustering performance of inflection point,meanwhile,find out what are the performance bottlenecks.So we can make a good choice under different business scenarios.
Key w ords:Redis Cluster;TwemProxy Redis;performance test
作者简介:
收稿日期:(2016-01-20)
中图分类号:TP23
文献标识码:A
DOI:10.19358 /j.issn.1674-7720.2016.09.024