4.4 内存考虑

  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通过天或者小时分割，比如下边的设计:

    需要修改为：

    更好的一个设计是采用hash：

  5. 各种数据结构及其占用内存的benchmark测试

set个数 每个set的元素总数 内存占用 Key大小 Value大小
100 100 1.88M 7 36
100 1000 10.75M 7 36
100 10000 111.12M 7 36
1000 100 11.59M 8 36
1000 1000 100.35M 8 36
1000 10000 1.08G 8 36
10000 100 108.71M 9 36
10000 1000 996.23M 9 36
zset个数 每个zset的元素总数 内存占用 Key大小 Value大小
100 100 1.62M 8 49
100 1000 15.91M 8 49
100 10000 162.06M 8 49
1000 100 8.71M 9 49
1000 1000 151.87M 9 49
1000 10000 1.58G 9 49
10000 100 79.83M 10 49
10000 1000 1.48G 10 49
hash个数 每个hash的元素总数 内存占用 Key大小 Value大小
100 100 1.63M 8 49
100 1000 6.29M 8 49
100 10000 156.91M 8 49
1000 100 8.71M 9 49
1000 1000 55.59M 9 49
1000 10000 1.52G 9 49
10000 100 79.83M 10 49
10000 1000 548.58M 10 49
list个数 每个list的元素总数 内存占用 Key大小 Value大小
100 100 1.23M 8 36
100 1000 10.00M 8 36
100 10000 92.40M 8 36
1000 100 4.83M 9 36
1000 1000 92.52M 9 36
1000 10000 916.47M 9 36
10000 100 40.76M 10 36
10000 1000 917.69M 10 36
string个数 内存占用 Key大小 Value大小
100 846.79K 13 36
1000 966.29K 13 36
10000 2.16M 13 36
100000 130.88M 13 36

results matching ""

    No results matching ""