Redis教程4--Redis数据存储优化机制

1.zipmap优化hash:

前面谈到将一个对象存储在hash类型中会占用更少的内存,并且可以更方便的存取整个对象。省内存的原因是新建一个hash对象时开始是用zipmap来存储的。这个zipmap其实并不是hash table,但是zipmap相比正常的hash实现可以节省不少hash本身需要的一些元数据存储开销。尽管zipmap的添加,删除,查找都是O(n),但是由于一般对象的field数量都不太多。所以使用zipmap也是很快的,也就是说添加删除平均还是O(1)。如果field或者value的大小超出一定限制后,redis会在内部自动将zipmap替换成正常的hash实现。这个限制可以在配置文件中指定(默认配置在redis根目录下的redis.conf中):


hash-max-zipmap-entries 512 #配置字段最多512个

hash-max-zipmap-value 64 #配置value最大为64字节

2.ziplist优化list:

如果redisObject的type成员值是REDIS_LIST类型的,则当该list的元素个数小于配置值list-max-ziplist-entries且元素值字符串的长度小于配置值list-max-ziplist-value则可以编码成 REDIS_ENCODING_ZIPLIST 类型存储,否则采用 Dict 来存储(Dict实际是Hash Table的一种实现),list采用ziplist数据结构存储数据,这样做一方面为了节省内存,另一方面这种结构式顺序存储的结构,能够更好利用cpu local和预取策略。

配置如下所示:


list-max-ziplist-entries 512 #配置元素个数最多512个

list-max-ziplist-value 64 #配置value最大为64字节

3.intset优化set:

当set集合中的元素为整数且元素个数小于配置set-max-intset-entries值时,使用intset数据结构存储,否则转化为Dict结构,Dict实际是Hash Table的一种实现,key为元素值,value为NULL,这样即可在O(1)时间内判断集合中是否包含某个元素。

intset中有三种类型数组:int16_t类型、int32_t 类型、 int64_t 类型。至于怎么选择是那种类型的数组,是根据其保存的值的取值范围来决定的,初始化时是 int16_t,根据 set 中的最大值在[INT16_MIN, INT16_MAX] , [INT32_MIN, INT32_MAX], [INT64_MIN, INT64_MAX]的那个取值范围来动态确定整个数组的类型。例如set一开始是 int16_t 类型,当一个取值范围在 [INT32_MIN, INT32_MAX]的值加入到
set 时,则将保存 set 的数组升级成 int32_t 的数组。

intset元素限制的配置如下所示:


set-max-intset-entries 512 #配置元素个数最多512个

4.ziplist优化sorted set:

根hash和list一样sorted set也有节约内存的方式,当sorted set的元素个数及元素大小小于一定限制时,它是用ziplist来存储。

这个限制的配置如下:


zset-max-ziplist-entries 128 #配置元素个数最多512个

zset-max-ziplist-value 64 #配置value最大为64字节

5.小结:

Redis提供了很多关于优化内存的方法,上面这些配置的值都是默认配置,实际要根据我们具体的需求场景来调节,并要做大量的测试,以达到最优的效果。同时必须对Redis这些数据结构有很好的理解。

Redis内存存储结构分析:http://www.searchtb.com/2011/05/redis-storage.html

版权声明:本文为博主原创文章,未经博主允许不得转载。

时间: 2024-08-30 00:59:17

Redis教程4--Redis数据存储优化机制的相关文章

Redis学习笔记2--Redis数据存储优化机制

1.zipmap优化hash: 前面谈到将一个对象存储在hash类型中会占用更少的内存,并且可以更方便的存取整个对象.省内存的原因是新建一个hash对象时开始是用zipmap来存储的.这个zipmap其实并不是hash table,但是zipmap相比正常的hash实现可以节省不少hash本身需要的一些元数据存储开销.尽管zipmap的添加,删除,查找都是O(n),但是由于一般对象的field数量都不太多.所以使用zipmap也是很快的,也就是说添加删除平均还是O(1).如果field或者val

Redis数据存储优化机制(转)

原文:Redis学习笔记4--Redis数据存储优化机制 1.zipmap优化hash: 前面谈到将一个对象存储在hash类型中会占用更少的内存,并且可以更方便的存取整个对象.省内存的原因是新建一个hash对象时开始是用zipmap来存储的.这个zipmap其实并不是hash table,但是zipmap相比正常的hash实现可以节省不少hash本身需要的一些元数据存储开销.尽管zipmap的添加,删除,查找都是O(n),但是由于一般对象的field数量都不太多.所以使用zipmap也是很快的,

程序性能优化之网络传输与数据存储优化(五)下

阿里P7移动互联网架构师进阶视频(每日更新中)免费学习请点击:https://space.bilibili.com/474380680 本篇文章将继续从7Z极限压缩和WebP使用来介绍网络传输与数据存储优化: 一.7Z极限压缩 一些文件过大或者是容量太大了,占用硬盘太多空间了.此刻可以使用压缩软件进行压缩,让它的体积变小了.其中极限压缩可以让文件夹或者是文件,压缩的最小.那么如何使用这个极限压缩功能的. ? 1.你要到网上下载这个压缩的程序,点击它,点击[install]. ? ? 2.此刻软件

redis教程(二)-----redis事务、记录日志到redis、分布式锁

redis事务 Redis 事务可以一次执行多个命令, 并且带有以下两个重要的保证: 批量操作在发送 EXEC 命令前被放入队列缓存. 收到 EXEC 命令后进入事务执行,事务中任意命令执行失败,其余的命令依然被执行. 在事务执行过程,其他客户端提交的命令请求不会插入到事务执行命令序列中. 一个事务从开始到执行会经历以下三个阶段: 开始事务. 命令入队. 执行事务. 示例: //根据multi开启事务redis 127.0.0.1:6379> MULTI OK redis 127.0.0.1:6

Redis教程03——Redis 发布/订阅(Pub/Sub)

Pub/Sub 订阅,取消订阅和发布实现了发布/订阅消息范式(引自wikipedia),发送者(发布者)不是计划发送消息给特定的接收者(订阅者).而是发布的消息分到不同的频道,不需要知道什么样的订阅者订阅.订阅者对一个或多个频道感兴趣,只需接收感兴趣的消息,不需要知道什么样的发布者发布的.这种发布者和订阅者的解耦合可以带来更大的扩展性和更加动态的网络拓扑. F为了订阅foo和bar,客户端发出一个订阅的频道名称: SUBSCRIBE foo bar 其他客户端发到这些频道的消息将会被推送到所有订

智能合约语言 Solidity 教程系列4 - 数据存储位置分析

写在前面 Solidity 是以太坊智能合约编程语言,阅读本文前,你应该对以太坊.智能合约有所了解,如果你还不了解,建议你先看以太坊是什么 这部分的内容官方英文文档讲的不是很透,因此我在参考Solidity官方文档(当前最新版本:0.4.20)的同时加入了深入分析部分. 数据位置(Data location) 在系列第一篇,我们提到 Solidity 类型分为两类:值类型(Value Type) 及 引用类型(Reference Types),前面我们已经介绍完了值类型,接下来会介绍引用类型.

redis教程(三)-----redis缓存雪崩、缓存穿透、缓存预热

缓存雪崩 概念 缓存雪崩是由于原有缓存失效(过期),新缓存未到期间.所有请求都去查询数据库,而对数据库CPU和内存造成巨大压力,严重的会造成数据库宕机.从而形成一系列连锁反应,造成整个系统崩溃. 解决方案 加锁排队 一般并发量不是特别多的时候,使用最多的解决方案是加锁排队. public object GetProductListNew() { const int cacheTime = 30; const string cacheKey = "product_list"; const

Redis教程2--Redis数据类型及相关命令

Redis支持的种数据类型包括string.list .set .sorted set 和hash. Redis相关的命令可以查看:http://redis.io/commands 这是官方的命令使用手册,也有中文翻译的:http://redis.readthedocs.org/en/2.4/index.html 1. keys:  redis本质上一个key-value store,所以首先了解它的key.首先key也是字符串类型,但是key中不能包括边界字符.由于key不是binary sa

深入理解开源数据库中间件 Vitess:核心特性以及如何进行数据存储的堆叠

概述 Vitess 是一个用于 MySql 扩展的数据库解决方案.它以能够像运行在专用硬件上那样有效地运行在云体系为目标进行架构.它集 MySql 数据库的很多重要特性和 NoSQL 数据库的可扩展性于一体.Vitess 已经成功侍服了 2011 年以来所有的 YouTube 数据库流量. Kubernetes 上的 Vitess Kubernetes 是 Google 开源的 Docker 容器集群管理系统,Vitess 是 Kubernetes 用户的逻辑存储引擎的一个可选项.Kuberne