Bitmaps

简介

  1. Bitmaps本身不是一种数据类型, 实际上它就是字符串.
  2. Bitmaps单独提懂了一套命令, 所以在Redis中使用Bitmaps和使用字符串的方法不太相同, 可以把Bitmaps想象成一个以位为单位的数组, 每个单元只能存0和1, 数组的下标称为偏移量.
  3. 第一次初始化Bitmaps, 假如偏移量很大, 整个初始化过程会很慢.

命令

  • setbit KEY OFFSET VALUE: 设置某个偏移量的值
  • getbit KEY OFFSET: 取某个偏移量的值
  • bitcount KEY [START END]: 统计被设为1的bit数, START/END设为负数, -1表示最后一个字节, -2表示倒数第二字节. 注意!!!: 这里设置的是字节, 每个字节里8位, 统计的是位上的1的数量!
  • bitop and(/or/not/xor) DESTKEY [KEY ...]: and(交集), or(并集), not(非), xor(异或), 操作结果保存在DESTKEY中, 返回结果的bit为1的数量
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    #例子: 获取两天都访问过网站的用户数量
    setbit users:20201103 0 1
    setbit users:20201103 3 1
    setbit users:20201103 6 1

    setbit users:20201104 1 1
    setbit users:20201104 4 1
    setbit users:20201104 6 1

    bitop and users:20201103_04 users:20201103 users:20201104

Bitmaps 和set的比较

活跃用户很多的时候, Bitmaps可以大大节省空间.
活跃很少的时候, 那么Bitmaps占用内存较多, 因为大部分数据都是0.

HyperLogLog

简介

解决基数问题, 基数就是一个数组中去重的结果
解决基数问题的方案:
1. 数据存在mysql中, 直接用distinct count统计.
2. 使用Redis提供的hash, set, bitmaps等数据结构来处理.
以上的方案结果精确, 但是随着数据不断增加, 导致占用空间越来越大, 对于非常大的数据集是不切实际的.
能否降低精度来平衡存储空间? Redis推出了HyperLogLog.
HyperLogLog的优点是, 在输入元素的数量或者体积非常非常大的时, 计算基数所需的空间总是固定的, 并且是很小的.
它花费12KB, 就可以计算接近2^64个不同元素的基数.
它只能计算基数, 不能像set那样返回输入的各个元素, 给人的感觉是就是进去就消失了.

命令

  • pfadd KEY ELEMENT1 ...: 插入元素, 返回成功1, 不成功返回0, 有一个不重复即可成功.
  • pfcount KEY: 计算基数
  • pfmerge DESTKEY KEY1 KEY2 ...: 将一个或多个HLL合并, 结果存在DESTKEY中.

Geospatial

简介

GEO, Geographic是地理信息的缩写, 该类型就是元素的二维坐标, 在地图上就是经纬度.

命令

  • geoadd KEY LONGITUDE LATITUDE MEMBER: 添加一个元素并设置经度, 维度, 两极无法添加有效精度(-180 ~ 180), 有效维度(-85.05112878 ~ 85.05112878)
  • geopos KEY MEMBER ...: 获取指定坐标的值.
  • geodist KEY MEMBER1 MEMBER2 [m/km/ft/mi]: 获取连个位置的直线距离, m表示米(默认), km是千米, mi是英里, ft是英尺.
  • georadius KEY 经度 维度 半径 单位: 给定的经纬度为中心, 找出某一半径内的元素, 这里的单位是必填的.