Redis特殊的三种数据类型
(为什么说他特殊呢?如果使用type 命令查看,HyperLogLog和BitMap是String类型的,Geo是zSet类型的。但是他们的语法和原本的数据类型又有所出入)
1:HyperLogLog(基数估算器)
2:BitMap(类似于java当中的map一样的数据结构,但是key仅仅可以为数字类型,value只有0,1两个值)
3:Geo(是一种基于GeoHash算法的一种zSet的数据结构。可用于附近查询,但是我个人认为该类型在技术和性能上还不建议用于生产环境)
HyperLogLog
版本支持:
Redis 在 2.8.9 版本添加了 HyperLogLog 结构。
基本概念:
Redis HyperLogLog 是用来做基数统计的算法,HyperLogLog 的优点是,在输入元素的数量或者体积非常非常大时,计算基数所需的空间总是固定 的、并且是很小的。
PFADD如果存入相同的元素,则会覆盖,而不是单纯的累加。
但是,因为 HyperLogLog 只会根据输入元素来计算基数,而不会储存输入元素本身,所以 HyperLogLog 不能像集合那样,返回输入的各个元素。
性能:
在 Redis 里面,每个 HyperLogLog 键只需要花费 12 KB 内存,就可以计算接近 2^64 个不同元素的基 数。这和计算基数时,元素越多耗费内存就越多的集合形成鲜明对比。这三个操作的时间复杂度均为O(1)。
应用:
这个结构可以非常省内存的去统计各种计数,比如注册 IP 数、每日访问 IP 数、页面实时UV)、在线用户数等。但是它也有局限性,就是只能统计数量,而没办法去知道具体的内容是什么。
基本语法:
序号 | 命令及描述 |
---|---|
1 | PFADD key element [element ...] 添加指定元素到 HyperLogLog 中。 |
2 | PFCOUNT key [key ...] 返回给定 HyperLogLog 的基数估算值。 |
3 | PFMERGE destkey sourcekey [sourcekey ...] 将多个 HyperLogLog 合并为一个 HyperLogLog |
参考:https://www.runoob.com/redis/redis-hyperloglog.html
BitMap
版本支持:
Redis 从 2.2 版本之后新增了setbit, getbit, bitcount 等几个 bitmap 相关命令。
基本概念:
BitMap 就是通过一个 bit 位来表示某个元素对应的值或者状态, 其中的 key 就是对应元素本身,实际上底层也是通过对字符串的操作来实现。
性能:
redis中bit映射被限制在512MB之内,所以最大是2^32位。建议每个key的位数都控制下,因为读取时候时间复杂度O(n),越大的串读的时间花销越多。
应用
这个数据结构可以用来,储存用户在线状态。这里只需要一个 key,然后把用户 ID 作为 key,如果在线就设置为 1,不在线就设置为 0。
基本语法:
序号 | 命令及描述 |
---|---|
1 | SETBIT key field value 添加指定元素到 BitMap 中。 |
2 | GETBIT key field 返回给定 BitMap 的field的bit值。未赋值和0值均返回0。 |
3 | BITCOUNT key 返回给定BitMap 所有field的bit值为1的,field总数。 |
Geo
版本支持:
Redis 的 GEO 特性在 Redis 3.2 版本中推出
基本概念:
这个功能可以将用户给定的地理位置信息储存起来, 并对这些信息进行操作。
主要针对于用户存储的地理位置信息进行,距离换算,附近的数据位置查询功能。
性能:
该数据不是作者亲自做的实验,所以不能保证数据的正确性。
原始数据大小 | mem | 80%cpu qps |
---|---|---|
10000 | 5.5MB | 26000 |
100000 | 14MB | 22000 |
1000000 | 102MB | 10000 |
参考:https://www.codercto.com/a/89291.html
应用
可用于LBS 的附近查询功能,但是作者不推荐使用。
1:该功能仅能支持简单的附近查询,如果需求出现了,各种状态,类型的过滤。使用该功能就形同虚设了(例如查询附近1公里内的所用女性用户)
2:该功能的数据存储结构很单一,较难满足当下,互联网应用的复杂的应用需求。
(如果各位老板有该方向的需求,可以参考作者的另一篇文章,针对LBS 附近查询功能的简单实现)
(以上文章的概念,定义等。如果出现错误请各位看官指正)