Redis hash数据存储空间优化

最近遇到一个需求,需要将hive中16亿行数据存储到redis中。数据存储采用hash结构,将16亿行数据根据key离散到32万个hash中。

由于每一行的key是16个字节,数据为1个字节,一开始在预估存储空间为:16亿*(16+1) = 26 G 左右。于是部署了16个分片,每个分片10G的集群。但是实际数据推上集群后,发现占用了140G空间,这大大超出了之前的预估。

感到很疑惑,于是查找相关资料。发现https://stackoverflow.com/questions/10004565/redis-10x-more-memory-usage-than-data , https://redis.io/topics/memory-optimizationhttps://www.peterbe.com/plog/understanding-redis-hash-max-ziplist-entries中提到hash结构在redis中有ziplist和dictionary两种实现形式。当hash中的数据不超过hash-max-ziplist-entries、hash-max-ziplist-value的配置值时,redis会将hash中的数据以ziplist的格式存储,从而最大可能的减少维持map的内部数据结构消耗。

查看我自己的集群配置,发现hash

  • 2
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
Redis在不同版本中对哈希表(hash)的数据结构进行了一些改进和优化。下面是Redis中哈希表的数据结构在不同版本中的变化: 1. Redis 2.4及之前版本: - 哈希表的底层数据结构使用链地址法(Separate Chaining)来解决哈希冲突。每个哈希表节点包含一个指向下一个节点的指针,形成链表结构。 - 每个哈希表节点包含一个键(key)和值(value),以及一个指向下一个节点的指针。 2. Redis 2.6版本: - 引入了渐进式哈希表扩容(progressive hash table expansion)的概念,用于解决哈希冲突。 - 哈希表的底层数据结构使用链地址法(Separate Chaining)来解决哈希冲突。 3. Redis 3.0版本: - 引入了ziplist(压缩列表)作为哈希表的底层数据结构,用于存储较小的哈希表。 - 当哈希表的键值对数量较小时,Redis会使用ziplist来存储,以节省内存空间。 4. Redis 3.2版本: - 哈希表的底层数据结构可以是ziplist或者hashtable。 - 当哈希表的键值对数量较小时,Redis会使用ziplist来存储,以节省内存空间。而当键值对数量超过一定阈值时,会切换为hashtable。 5. Redis 4.0及之后版本: - 哈希表的底层数据结构可以是ziplist、hashtable或者quicklist。 - quicklist是一种优化数据结构,用于存储大型哈希表。它将多个hashtable链接在一起,以减少内存碎片和提高性能。 需要注意的是,Redis的不同版本可能会引入新的功能和优化,并可能修改底层数据结构以提高性能和减少内存消耗。因此,具体的数据结构和实现方式可能会随着版本的更新而有所变化。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值