我们在缓存 JSON 数据到 Redis 时经常会面临是选择 string 类型还是选择 hash 类型去存储. 接下来我从占用空间和 IO 两方面来分析这两种类型的优势.
1, 占用空间
根据数据结构的共识我们知道 hashtable 类型是要比 string 类型更占用空间, 而 ziplist 类型与 string 类型占用的空间基本相差不大.
如下图就是 ziplist 的存储的格式
那我们接下来分别分析 Redis 的 string 和 hash 类型占用空间方面的知识
string 类型: string 类型当然如其名, 如果 JSON 数据以 string 类型去存储, 那么它的空间占用方面肯定是相当的.
hash 类型: Redis 对 hash 类型是有两种编码方式, 分别是 ziplist 和 hashtable.
当如下情况时 Redis 的 hash 类型, 底层是用 ziplist 编码的:
哈希对象保存的所有键值对的键和值的字符串长度都小于 64 字节;
哈希对象保存的键值对数量小于 512 个;
不满足上述情况时, Redis 的 hash 类型, 底层编码格式为 hashtable.
2,IO
从 IO 的角度来分析 string 和 hash 类型, 我们得有一个共识, 我们知道 Redis 是有服务端的, 也就是部署 Redis 的所在机器他们会运算能力的.
string 类型:
取数据: 根据 Redis 键取对应的整个 value 值.
存数据: 根据 Redis 键存这个 value 值
更新数据: 根据 Redis 键更新整个 value 值
hash 类型:
取数据: 根据 Redis 键, 然后遍历整个 hash 键值对(相对 string 的取数据更加耗时).
存数据: 根据 Redis 键, 在 value 出存键值对
更新数据: 根据 Redis 键和 hash key 更新对应的数据
3, 总结
综上所述, 那具体怎么选择是用 string 类型还是 hash 类型存储 JSON 数据呢? 给出以下结论
如果你的业务类型中对于缓存的读取缓存的场景更多, 并且更新缓存不频繁(或者每次更新都更新 JSON 数据中的大多数 key), 那么选择 string 类型作为存储方式会比较好.
如果你的业务类型中对于缓存的更新比较频繁 (特别是每次只更新少数几个键) 时, 或者我们每次只想取 JSON 数据中的少数几个键值时, 我们选择 hash 类型作为我们的存储方式会比较好.
来源: http://www.cnblogs.com/lifei01/p/14285224.html