Redis 中的数据类型

太过爱你忘了你带给我的痛 2021-09-21 07:38 346阅读 0赞

# Redis 支持的数据类型      #

Redis 是一个 key-value 的数据结构服务器，key 是字符串。value 支持的数据类型，我们都知道有 String（字符串）、List（列表）、Hash（哈希）、Set（集合）、Sorted Set（有序集合）。除了这些之外，随着Redis 的版本迭代，还有 BitMap（位图）、HyperLogLog、Stream 三种数据类型。

# Redis 中的 key #

Redis中的 key 是二进制安全的（因为Redis中的SDS是二进制安全的），这意味着您可以使用任何二进制序列作为key，从“ foo”之类的字符串到JPEG文件的内容。 空字符串也是有效的key。

官方推荐的有关 key 的一些其他规则：

*  太长的 key 不是一个好主意。 例如，一个1024字节的 key 不仅是内存方面是个坏主意，因为在数据集中查找 key 可能需要进行一些代价高昂的 key 比较。 即使手头的任务是匹配一个大值的存在，对它进行哈希（例如使用SHA1）也是一个更好的主意，尤其是从内存和带宽的角度来看。
 *  非常短的 key 通常不是一个好主意。 如果您可以改写“ user：1000：followers”，那么将“ u1000flw”作为 key 写的毫无意义。 与 key 对象本身和值对象使用的空间相比，后者更具可读性，并且添加的空间较小。 虽然短 key 显然会消耗较少的内存，但您的工作是找到正确的平衡点。这一点主要是从可读性上考虑的。
 *  尝试坚持一个模式。 例如，“ object-type：id”是一个好主意，例如“ user：1000”。 点或破折号通常用于多字字段，例如“ comment：1234：reply.to”或“ comment：1234：reply-to”中。这一点是考虑 key 的命名风格。
 *  允许的最大 key 的大小为512 MB。这一点是受限于Redis 中 String 的最大大小为512 MB。

# Redis 中 value 支持的数据类型 #

Redis 中 value 支持的数据结构：**String、List、Hash、Set、Sorted Set、 BitMap、HyperLogLog、Stream 。**

## String ##

Redis字符串类型是您可以与Redis键关联的最简单的值类型。String可以是每种类型的字符串（包括二进制数据），例如，您可以在字符串内存储jpeg图像。字符串大小不能大于512 MB。

## List ##

列表是根据插入顺序排序的字符串元素集合。 可以认为是链表。

## Hash ##

哈希是由与值相关联的字段组成的 field-value 映射表。 字段【field】和值【value】都是字符串。

## Set ##

Redis集合是字符串的无序集合。 SADD命令将新元素添加到集合中。 还可以对集合进行许多其他操作，例如测试给定元素是否已存在，执行多个集合之间的交集，并集或差集等。

## Sorted Set ##

有序集合是一种类似于集合和哈希之间的混合数据类型。 像集合一样，排序集合由唯一的，非重复的字符串元素组成，因此从某种意义上说，有序集合也是一个集合。有序集合中的每个元素都与一个称为“分值（score）”的浮点值相关联（这就是为什么该类型也类似于哈希的原因，因为每个元素都映射到一个值）。

有序集合中的元素排序规则：

*  如果A和B是两个具有不同分值的元素，那么如果A.score是> B.score，则A>B。
 *  如果A和B的分数完全相同，那么如果A字符串在字典上大于B字符串，则A>B。 A和B字符串不能相等，因为排序集仅具有唯一元素。

## BitMap ##

Redis中的位图不是实际的数据类型，而是在String类型上定义的一组面向位的操作。 由于字符串是二进制安全的Blob，并且最大长度为512 MB，因此它们适合设置多达 **2^32** 个不同的 bit 位。

位操作分为两类：固定时间的单个位操作（例如将一个位设置为1或0或获取其值），以及对位组的操作，例如计算给定位范围内设置位的数量。

位图的最大优点之一是，它们在存储信息时通常可以节省大量空间。 例如，在以增量用户ID表示不同用户的系统中，仅使用512 MB内存就可以记住40亿用户的单个 bit 位信息（例如，知道用户是否要接收新闻通讯，是：bit 位置为1）。

位图的常见用例有：

1、各种实时分析。

2、存储与对象id相关联的节省空间但高性能的布尔信息。

## HyperLogLogs ##

Redis 在 2.8.9 版本添加了 HyperLogLog 结构。HyperLogLog 是一种概率数据结构，用于对唯一事物进行计数（从技术上讲，这是指**估计集合的基数**）。 通常，对唯一项目进行计数需要使用与要计数的项目数量成比例的内存量，因为您需要记住过去已经看到的元素，以避免多次对其进行计数。 但是，有一组算法会以内存换取精度：您最终会得到带有标准误差的估计量，在Redis实现的情况下，该误差小于1％。 该算法的神奇之处在于，您不再需要使用与所计数项目数量成比例的内存量，而可以使用恒定数量的内存！ 在最坏的情况下为12k字节，如果您的HyperLogLog（从现在开始将它们称为HLL）看到的元素很少，则少得多。

什么是基数?
    比如数据集 {1, 3, 5, 7, 5, 7, 8}， 那么这个数据集的基数集为 {1, 3, 5 ,7, 8}, 基数(不重复元素)为5。 
    基数估计就是在误差可接受的范围内，快速计算基数。

在 Redis 里面，每个 HyperLogLog 键只需要花费 12 KB 内存，就可以计算接近 2^64 个不同元素的基 数。这和计算基数时，元素越多耗费内存就越多的集合形成鲜明对比。但是，因为 HyperLogLog 只会根据输入元素来计算基数，而不会储存输入元素本身，所以 HyperLogLog 不能像集合那样，返回输入的各个元素。

Redis中的HLL（HyperLogLog）尽管在技术上是不同的数据结构，但被编码为Redis字符串，因此您可以调用GET来序列化HLL，然后调用SET来将其反序列化回服务器。

用途：用来做基数统计，比如每天计算用户在搜索表单中执行的唯一查询集合的基数。

## Stream ##

Stream是Redis 5.0引入的一种新数据类型，它以更抽象的方式对日志数据结构进行建模，但是日志的本质仍然完好无损：就像日志文件一样，通常实现为仅在追加模式下打开的文件， Redis流主要是仅追加数据结构。 至少从概念上讲，因为Redis是流式传输在内存中表示的抽象数据类型，所以它们实现了更强大的操作，以克服日志文件本身的限制。

尽管数据结构本身非常简单，Redis流却成为最复杂的Redis类型，原因是它实现了附加的、非强制性的特性：一组阻塞操作允许消费者等待生产者添加到流中的新数据，此外还有一个称为消费者组的概念。

Redis Stream 官方文档地址：[https://redis.io/topics/streams-intro][https_redis.io_topics_streams-intro]

[https_redis.io_topics_streams-intro]: https://redis.io/topics/streams-intro