社区
Java EE
帖子详情
为什么说redis的ziplist节约内存
i244782405
2019-01-26 11:49:21
为什么说redis的ziplist节约内存,看了他的数据结构,没catch到他节约内存这个点啊。大神们指点一下。
...全文
640
6
打赏
收藏
为什么说redis的ziplist节约内存
为什么说redis的ziplist节约内存,看了他的数据结构,没catch到他节约内存这个点啊。大神们指点一下。
复制链接
扫一扫
分享
转发到动态
举报
AI
作业
写回复
配置赞助广告
用AI写文章
6 条
回复
切换为时间正序
请发表友善的回复…
发表回复
打赏红包
k2z
2020-04-21
打赏
举报
回复
typedef struct zlentry { unsigned int prevrawlensize, prevrawlen; unsigned int lensize, len; unsigned int headersize; unsigned char encoding; unsigned char* p; } zlentry;
// 这是zlentry的结构体 楼主的疑惑点应该是从上述结构体来看,一个zlentry占据的空间相较双向链表没有更少反而更多。 但是,从源码来看,__ziplistInsert函数进行新节点插入时,并不存储prevrawlensize/lensize,而在取节点时通过prerawlen/len去确定,再进行相应操作。 同时,在__ziplistInsert函数插入新节点时,会根据prerawlen/len的实际大小为这两个值分配存储空间。 // ziplist两方面节省内存:
- 第一,之前的内容 - 第二,分配大块内存减小内存碎片
qq_39849130
2020-04-06
打赏
举报
回复
64位系统双向链表一个节点prev和next指针就16字节了,ziplist主要省的内存就在这儿了
你家熊博士
2019-07-16
打赏
举报
回复
这个压缩链表都在一块连续的空间上创建,碎片化的空间小了,不久节约了
-星星-
2019-02-28
打赏
举报
回复
变为linkedlist是因为他的数据太紧凑了,导致增改操作需要大量内存支持吧
-星星-
2019-02-28
打赏
举报
回复
除了头和尾大部分都是数据,linkedlist是按照项最大的数据类型存的(每一个都是,为啥数据量大了变为linkedlist就不知道了) 相对于dict来说更好维护吧(只是因为数据量大了查询效率降低才变为dict)
tianfang
2019-01-29
打赏
举报
回复
数据是压缩后存储在内存的,所以节约了内存。 但是增加了压缩/解压的开销
redis
_3.2.9_
内存
分布分析
而列表类型的存储则会使用
zip
list
或者quick
list
作为存储结构,如果列表中的元素个数不多且元素体积不大,则使用
zip
list
以
节约
内存
,否则使用quick
list
。对于集合类型,
Redis
提供了对象编码(OBJ_ENCODING_HT和OBJ_...
17原理 7:开源节流 —— 小对象压缩(1).md
例如,在使用哈希命令hset添加的键值对数量较少时,
Redis
会使用
zip
list
来存储,而一旦元素数量超过一定阈值,
Redis
会自动转换为更合适的数据结构以维持性能。 5.
Redis
的intset:这是另一种压缩数据结构,用于存储...
redis
使用场景及数据结构.docx
- **Intset**:存储整数值时使用,
节约
内存
空间。 - **Dict**:非整数值或数量较多时采用字典结构。 5. **Sorted Set (有序集合)**: - 结合了set和hash的特点,存储有序的键值对。 - 内部使用跳表(skip
list
)...
36源码 4:风驰电掣 —— 探索「快速列表」内部(1).md
为了进一步
节约
空间,
Redis
还会对
zip
list
进行压缩存储,使用LZF算法压缩。LZF算法是一种无损压缩算法,适用于快速压缩和解压场景,特别适合用于
内存
数据的压缩。压缩深度可以在创建或更新quick
list
时通过配置决定,...
35源码 3:挨肩迭背 —— 探索「压缩列表」内部(1).md
- 在元素数量不多的情况下,使用压缩列表能有效
节约
内存
空间。 3. **压缩列表的组成部分**: - zlbytes:表示整个压缩列表占用的字节数。 - zltail_offset:表示最后一个元素距离列表起始位置的偏移量,用于快速...
Java EE
67,550
社区成员
225,863
社区内容
发帖
与我相关
我的任务
Java EE
J2EE只是Java企业应用。我们需要一个跨J2SE/WEB/EJB的微容器,保护我们的业务核心组件(中间件),以延续它的生命力,而不是依赖J2SE/J2EE版本。
复制链接
扫一扫
分享
社区描述
J2EE只是Java企业应用。我们需要一个跨J2SE/WEB/EJB的微容器,保护我们的业务核心组件(中间件),以延续它的生命力,而不是依赖J2SE/J2EE版本。
社区管理员
加入社区
获取链接或二维码
近7日
近30日
至今
加载中
查看更多榜单
社区公告
暂无公告
试试用AI创作助手写篇文章吧
+ 用AI写文章