当前位置:Gxlcms > mysql > 三千万数据量下redis2.4的一统计情况

三千万数据量下redis2.4的一统计情况

时间:2021-07-01 10:21:17 帮助过:67人阅读

先说一下工作场景,要求做一个服务,满足:处理千万级别数据,单个请求响应时间在20ms以下。由于是存储的数据式为key:list[],所以很适合使用redis来存放数据,为了测试一下redis存储的效率问题,才有了这篇文章。 第一步:造数据。思路如下:(1)先产生三

先说一下工作场景,要求做一个服务,满足:处理千万级别数据,单个请求响应时间在20ms以下。由于是存储的数据格式为key:list[],所以很适合使用redis来存放数据,为了测试一下redis存储的效率问题,才有了这篇文章。

第一步:造数据。思路如下:(1)先产生三千万个key,为了解决随机函数不能很好平均分布的问题,采用两步走的方法来造3000W个key。首先,从key从1到3000万依次产生,解决数量问题。然后,再使用随机函数产生1000W数据,添加到这些key中。(2)为了提高效率,使用50个线程并发造数据,每个线程负责60万数据的入库工作。(3)对于其中的几种长度的key,插入1万条数据。【3000万数据,大约使用3G左右的内存,实体机内存为8G,分配给redis 4G】

第二步:计算访问速度。为了能比较准确地反映查询速度,产生1万个随机的key并进行访问,10000次get,大约用时15625ms,平均1.56ms一次。

查询时,对于key长度为14,且存有10000个数据的list,执行lrange(key,0, -1),时间为31ms,而key长度为10,且存有10000个相同数据的list,执行lrange(key,0, -1),时间为16ms。

插入时,list的key长度为14时插入10000个数据,用时23015ms,而key为10时,用时19875ms。

可见key长度增加4,查询时间由16ms上升到31ms,而插入一条记录的时间由1.9875ms上升到2.3015ms。

三点结论:

一:控制key的长度,尽量使用有意义且简短的词。

二:控制list的长度,尽量不要超过一万,如果可能超过一万,需要考虑过期删除机制。

三:redis占用的内存最好不要超过实际内存的50%,否则在插入时会有读取超时的情况。

测试环境 操作系统:Linux x86_64 内存8G,redis版本:2.4.18【最新为2.6.14http://redis.io】

人气教程排行