Redis6新增的数据类型Bitmaps + HyperLogLog + Geospatial

最新推荐文章于 2022-04-12 15:29:54 发布

7zwang

最新推荐文章于 2022-04-12 15:29:54 发布

阅读量151

点赞数 1

分类专栏： redis 文章标签：数据库 redis 数据结构

本文链接：https://blog.csdn.net/weixin_37749732/article/details/120238429

版权

redis 专栏收录该内容

3 篇文章 0 订阅

订阅专栏

前言
Redis6新增了3种数据类型
分别是：1.Bitmaps 2.HyperLogLog 3.Geospatial

1.Bitmaps

Bitmps可以说是一种专门进行位操作的字符串

我们知道，如果能够有效的使用位运算，可以提高内存的使用率以及开发效率。
Redis 6中就提供了这么一种可以进行位运算的数据类型
但其实Bitmaps本身就是一种字符串而已，只不过它是专门进行位操作的字符串
Bitmaps内部是以0和1进行存储，我们可以把它想象成一个以位位单位的数组，数组中只能够放0和1，
Bitmaps的数组的下标叫作偏移量

在这里插入图片描述

Bitmaps的基本操作

setbit + key + 偏移量 + value
举个例子
现在统计每个用户是否访问或某个网站，如果访问过则记为1，否则为0。下面我们使用Bitmaps来进行操作，使用 “用户id” 作为偏移量（假设userid = 1、6、11、15、19 这几个用户访问了网站，其他的用户没有访问）。

setbit user 1 1
setbit user 6 1
setbit user 11 1
setbit user 15 1
setbit user 19 1

缺点:初始化时，如果偏移量很大，那么初始化时间需要很长。

getbit + key + 偏移量
说白了就是根据数组下标取值（取出0或者1）

getbit user 1
输出 1

_{操作有很多可以看文档}

Bitmaps和Set的对比

【情景】假设一个日活非常大的网站，假设有1000W的用户需要用bitmaps和set进行缓存信息。
一个Set需要用64位来存储一个用户的id，而Bitmaps只需要用1位来存储一个用户的id。
如果是1000W的用户量，那么Set需要800M，而bitMaps只需要12.5M 。这样看来bitmaps在存储一些数据量很大且能用0或者1标识状态的信息时，能够极大的节省内存空间！

但是什么时候不适合用bitmaps？
当用户量很少的时候，一个01数组上基本上都是0，没有几个1，那么就不适合了。所以bitmaps还是比较适合记录量大活跃的用户。

2.HyperLogLog

HyperLogLog主要是为了解决基数问题的
也就是对数去重取唯一性的数据

解决基数问题的方案有很多:
( 1 ) 数据存储在MySQL表中，使用distinct count计算不重复个数。
( 2）使用Redis提供的hash、 set、 bitmaps等能够去重的数据结构来处理.
以上的方案结果精确，但随着数据不断增加，导致占用空间越来越大，对于非常大的数据集是不切实际的。

那么是否能够降低一定的精度来平衡存储空间？
Redis6就提供了HyperLogLog，它其实就是一种用来基数统计的算法。
HyperLogLog的优点
在输入元素的数量或者体积非常非常大时,计算基数所需的空间总是固定的、并且是很小的。
在Redis 里面,每个HyperLogLog键只需要花费12 KB内存，就可以计算接
近2^64个不同元素的基数。这和计算基数时，元素越多耗费内存就越多的集合形成鲜明对比。
但是,因为HyperLogLog只会根据输入元素来计算基数，而不会储存输入元素本身，所以HyperLogLog不能像集合那样，返回输入的各个元素。