阅读(798) (9)

Redis 内存考虑

2017-07-04 10:59:59 更新
  1. 只要有可能的话,就尽量使用散列键而不是字符串键来储存键值对数据,因为散列键管理方便、能够避免键名冲突、并且还能够节约内存。具体实例: 节约内存:Instagram的Redis实践 blog.nosqlfan.com/html/3379.html
  2. 如果将redis作为cache进行频繁读写和超时删除等,此时应该避免设置较大的k-v,因为这样会导致redis的 内存碎片增加,导致rss占用较大,最后被操作系统OOM killer干掉。一个很具体的issue例子请见:https://github.com/antirez/redis/issues/2136
  3. 如果采用序列化考虑通用性,请采用json相关的库进行处理,如果对内存大小和速度都很关注的,推荐使用messagepack进行序列化和反序列化
  4. 如果需要计数器,请将计数器的key通过天或者小时分割,比如下边的设计:

 6.需要修改为:


 7.更好的一个设计是采用hash:

 8.各种数据结构及其占用内存的benchmark测试
set个数每个set的元素总数内存占用Key大小Value大小
1001001.88M736
100100010.75M736
10010000111.12M736
100010011.59M836
10001000100.35M836
1000100001.08G836
10000100108.71M936
100001000996.23M936
zset个数每个zset的元素总数内存占用Key大小Value大小
1001001.62M849
100100015.91M849
10010000162.06M849
10001008.71M949
10001000151.87M949
1000100001.58G949
1000010079.83M1049
1000010001.48G1049
hash个数每个hash的元素总数内存占用Key大小Value大小
1001001.63M849
10010006.29M849
10010000156.91M849
10001008.71M949
1000100055.59M949
1000100001.52G949
1000010079.83M1049
100001000548.58M1049
list个数每个list的元素总数内存占用Key大小Value大小
1001001.23M836
100100010.00M836
1001000092.40M836
10001004.83M936
1000100092.52M936
100010000916.47M936
1000010040.76M1036
100001000917.69M1036
string个数内存占用Key大小Value大小
100846.79K1336
1000966.29K1336
100002.16M1336
100000130.88M1336