查看原文
其他

【156期】面试官问:Redis 存储结构体信息,选 hash 还是 string?

Java精选 2022-08-09

点击上方“Java精选”,选择“设为星标”

别问别人为什么,多问自己凭什么!

下方留言必回,有问必答!

每天 08:35 更新文章,每天进步一点点...

在讲到使用hash还是string存储的选择前,先了解Redis的hash和string结构。

以下资料引自老钱的Redis深度历险。

string

string和hash都是Redis的一种数据结构。string结构常用来缓存用户信息,通常将用户信息结构体使用JSON序列化成字符串,然后将序列化后的字符串存入Redis进行缓存。

String数据结构

Redis的字符串是动态字符串,可以修改,内部结构类似于Java的ArrayList,采用预分配冗余空间的方式来减少内存的频繁分配。如上图锁实,内部为当前字符串实际分配的空间capacity,一般高于实际字符串长度len。使用的指令有set, get, mset, mget等

hash

Redis的hash相当于Java的HashMap,内部结构实现与HashMap一致,即数组+链表结构

hash数据结构

不过Redis的hash的值只能是字符串,rehash方式不一样,为了提高性能,Redis保留新旧两个hash结构,采用渐进式rehash策略,查询时会同事查询两个hash结构,在后续的定时任务中以及hash操作指令中,循序渐进将旧hash的内容迁移到xinhash中,直至完全取代旧hash。hash移除最后一个元素后会自动被删除,内存被回收。

前面说到string适合存储用户信息,而hash结构也可以存储用户信息,不过是对每个字段单独存储,因此可以在查询时获取部分字段的信息,节省网络流量。

因此就引出了这篇文章,存储结构体信息是用hash还是string?

以下信息出自StackOverflow  Redis strings vs Redis hashes to represent JSON: efficiency?

I want to store a JSON payload into redis. There's really 2 ways I can do this:

  1. One using a simple string keys and values.

key:user, value:payload (the entire JSON blob which can be 100-200 KB)

SET user:1 payload

  1. Using hashes

HSET user:1 username "someone"

HSET user:1 location "NY"

HSET user:1 bio "STRING WITH OVER 100 lines"

Keep in mind that if I use a hash, the value length isn't predictable. They're not all short such as the bio example above.

Which is more memory efficient? Using string keys and values, or using a hash?

该用户也是同样的疑问,因为值的长度是不确定的,所以不知道采用string还是hash存储更有效率。

这个问题底下有个开发者回答的非常好,这里翻译出来供大家一起学习讨论,如果有更好的方案,欢迎提出来 首先,答者建议参考redis官方的内存优化的文章:https://redis.io/topics/memory-optimization,用来理解官方的开发者是内存优化方面基于什么考虑。

之后,答者列出了四个方案并给出了各个方案的利弊

1. 存储整个对象,其中JSON序列化过的字符串作为key

INCR id:users
SET user:{id} '{"name":"Fred","age":25}'
SADD users {id}
  • 优势:可以认为是“最佳实践”,因为每个对象都是全特性的key,JSON解析特别块,尤其是一次性查询很多个字段的时候

  • 劣势:如果只查询一个字段,速度就显得比较慢了

2. 在hash中存储每个对象的属性

INCR id:users
HMSET user:{id} name "Fred" age 25
SADD users {id}
  • 优势:这也可以认为是最佳时间。每个对象都是一个全特性的key。不需要解析JSON字符串
  • 劣势:如果要查询对象的全部字段会比较慢。嵌套类型的对象(即对象里面还包着对象)无法轻易存储

3. 将对象转化为JSON字符串,用hash结构存储

INCR id:users
HMSET users {id} '{"name":"Fred","age":25}'

这个方案可以仅用两个key,不需要很多key。但是没法对每个用户对象设置TTL(Time to Live,剩余生存时间),因为对象仅仅是hash中的一个字段,而不是全特性的key

  • 优势:JSON解析很快,尤其是一次查询多个字段时,对主key的命名空间污染更少

  • 劣势:如果要存储很多对象,那么内存使用和方案1相当。当只需要查询一个字段时,会比方案2速度慢。答者不认为这是一个“最佳实践”

4. 存储对象的每个属性作为单独的key

INCR id:users
SET user:{id}:name "Fred"
SET user:{id}:age 25
SADD users {id}

根据上面的文章,即redis内存优化,这个方案不推荐(除非对象的属性需要专门设置TTL或者别的设置)

  • 优势:对象的属性是全特征key,对于应用来说比较好处理

  • 劣势:慢,内存消耗更大,不是一个“最佳实践”。对主key的命名空间有很大污染

  • 更多面试题,公众号Java精选,回复java面试,获取面试资料。

总的来说,方案4是最不推荐的,方案1和方案2非常相似,也很常见。答者更推荐方案1,因为这个方案允许存储更复杂的对象(也就是说对象可以有很多层嵌套)。方案3通常用在对命名空间比较有要求的场景下,比如说不想要太多key,不关心TTL等参数

参考资料

  • Redis深度历险:核心原理与应用实践

  • Redis strings vs Redis hashes to represent JSON: efficiency?

作者:布鲁斯1990

https://blog.csdn.net/u010145219/article/details/99427693

版权声明:本文为CSDN博主「布鲁斯1990」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。

公众号“Java精选”所发表内容注明来源的,版权归原出处所有(无法查证版权的或者未注明出处的均来自网络,系转载,转载的目的在于传递更多信息,版权属于原作者。如有侵权,请联系,笔者会第一时间删除处理!
------ THE END -------

精品资料,超赞福利!


3000+ 道面试题在线刷,最新、最全 Java 面试题!

期往精选  点击标题可跳转

【148期】面试官问:select......for update 会锁表还是锁行?

【149期】还在用 Elasticsearch ?事实证明 ClickHouse 更强大!

【150期】面试官:Spring Boot 静态获取 bean 的三种方式,你知道哪些?

【151期】面试官:熟悉设计模式吗?谈谈简单工厂模式和策略模式的区别?

【152期】美团一面:为什么选用 Hbase,Hbase 和 MySQL有啥区别?

【153期】面试官问:如何中断一个线程,谈谈具体实现?

【154期】面试官问:请你说说 B 树、B+ 树的原理及区别?

【155期】面试官问:为什么 Spring Boot 的 jar 可以直接运行?

文章有帮助的话,在看,转发吧!

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存