4.4 内存考虑
- 只要有可能的话,就尽量使用散列键而不是字符串键来储存键值对数据,因为散列键管理方便、能够避免键名冲突、并且还能够节约内存。
具体实例: 节约内存:Instagram的Redis实践 blog.nosqlfan.com/html/3379.html
- 如果将redis作为cache进行频繁读写和超时删除等,此时应该避免设置较大的k-v,因为这样会导致redis的 内存碎片增加,导致rss占用较大,最后被操作系统OOM killer干掉。一个很具体的issue例子请见:https://github.com/antirez/redis/issues/2136
- 如果采用序列化考虑通用性,请采用json相关的库进行处理,如果对内存大小和速度都很关注的,推荐使用messagepack进行序列化和反序列化
- 如果需要计数器,请将计数器的key通过天或者小时分割,比如下边的设计:
需要修改为:
更好的一个设计是采用hash: - 各种数据结构及其占用内存的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 |
Redis开发运维实践指南本文为《Redis开发运维实践指南》内容,该书作者为黄鹏程,已授权转载。
时间: 2024-10-27 05:41:41