您当前的位置: 首页 >  redis

壹小俊

暂无认证

  • 4浏览

    0关注

    885博文

    0收益

  • 0浏览

    0点赞

    0打赏

    0留言

私信
关注
热门博文

redis“万金油”的String,为什么不好用了?

壹小俊 发布时间:2021-10-21 15:26:32 ,浏览量:4

从今天开始,我们就要进入“实践篇”了。接下来,我们会用5节课的时间学习“数据结构”。我会介绍节省内存开销以及保存和统计海量数据的数据类型及其底层数据结构,还会围绕典型的应用场景(例如地址位置查询、时间序列数据库读写和消息队列存取),跟你分享使用Redis的数据类型和module扩展功能来满足需求的具体方案。

今天,我们先了解下String类型的内存空间消耗问题,以及选择节省内存开销的数据类型的解决方案。

先跟你分享一个我曾经遇到的需求。

当时,我们要开发一个图片存储系统,要求这个系统能快速地记录图片ID和图片在存储系统中保存时的ID(可以直接叫作图片存储对象ID)。同时,还要能够根据图片ID快速查找到图片存储对象ID。

因为图片数量巨大,所以我们就用10位数来表示图片ID和图片存储对象ID,例如,图片ID为1101000051,它在存储系统中对应的ID号是3301000051。

photo_id: 1101000051
photo_obj_id: 3301000051

可以看到,图片ID和图片存储对象ID正好一一对应,是典型的“键-单值”模式。所谓的“单值”,就是指键值对中的值就是一个值,而不是一个集合,这和String类型提供的“一个键对应一个值的数据”的保存形式刚好契合。

而且,String类型可以保存二进制字节流,就像“万金油”一样,只要把数据转成二进制字节数组,就可以保存了。

所以,我们的第一个方案就是用String保存数据。我们把图片ID和图片存储对象ID分别作为键值对的key和value来保存,其中,图片存储对象ID用了String类型。

刚开始,我们保存了1

关注
打赏
1664335782
查看更多评论
立即登录/注册

微信扫码登录

0.0608s