Redis - 非常大的单条记录（哈希表）答案

【问题标题】：Redis - very large single record (hash table)Redis - 非常大的单条记录（哈希表）
【发布时间】：2018-05-27 07:01:56
【问题描述】：

我们在这里有一个巨大的争议：

我们在服务器上安装了 Redis，我们想在其中保存几种类型的数据：

一些零星变量（针对每个用户 - 所以不仅仅是几条记录）
一个非常大的表会随着时间的推移而增长

争议在于如何保存提到的表格

我们都知道 Redis 的 GET 时间复杂度是 O(1) - 所以我们可以将表的每条记录存储为 Redis 中的一条记录（加上一些前缀来知道它是那个表行）

或

我们可以将表作为单个记录存储在 Redis 中作为散列 - 然后在散列中访问我们想要的行 - 这是两个 O(1) 步骤。

我认为 Redis 中不断增长的巨大 SINGLE 记录是灾难性的，但我需要的不仅仅是我对此的看法 - 我需要一个 Redis 专家的回复来指出该方法中的错误或证明我错了。

【问题讨论】：

标签： hash redis time-complexity hashtable

【解决方案1】：

首先，让我们澄清一下 - GET 和 HGET 都是 O(1) 操作。两者在时间复杂度上没有区别。

接下来要考虑的是如何在以后对密钥空间进行分区。假设您的增长呈爆炸式增长，您需要以某种方式进行集群（企业、OSS 或其他）。在所有这些实现中，您不能拆分密钥。因此，如果您只有一个名为 users 的散列，那么代表用户 ID 的字段，如您所提到的，该散列将变得非常大，并且不容易扩展。

更好的做法是将您的用户划分为子哈希。假设您的用户 ID 看起来像这样：1234，那么您要做的是有一个哈希 user:12 和一个 34 字段，您可以在其中存储用户 1234 (HGET user:12 34) 的数据。这样，您可以节省键空间开销，并且仍然可以对键空间进行分区。 Redis Memory Optimization 文档中概述了这种策略。

就您的数据而言，您可以进行某种序列化并将所有内容存储在一个字段中（JSON、CSV 等），也可以为每个用户的每条数据使用哈希值并仍然分区（例如键 @987654330 @/字段34和user:age:12/字段34)。

【讨论】：

我认为您以某种方式误解了我的意思-重点是表（与用户属性无关-我只提到用户属性以表明 Redis 将保存其他不相关的属性到桌子上）。问题是关于表格 - 将整个表格放在一个 Redis 记录中是否合乎逻辑 - 表格随着时间的推移而增长，这听起来像是一种不好的做法......
要访问表中的某个所需行 - 它不会检索整个表然后访问它（是的，它是 o(1) 但在使用大量内存之后......？）
@Eking Redis 没有“表”的概念。它是 Redis 数据模型的重要概念部分。如上所述，出于分区和集群的目的，拥有一个巨大的密钥是一种不好的做法，但除此之外，大小实际上是无关紧要的。就时间复杂度而言，散列的大小无关紧要。内部都是指针，所以如果你只请求一个字段，Redis 实际上不会对其余的哈希做任何事情。 O(1) 是 O(1)。哈希中的多个键而不是多个字段是可以的，但是键空间会产生存储开销 - 但它仍然是 O(1)。
正如我所提到的，很好理解的是，在 Redis 中检索（和设置）值的操作是 O(1)。
@Eking 我已经阅读了您的 cmets 几次，很难理解您要做什么。也许你正在尝试做的一些例子？您引用“表”/“行”/“搜索”/“记录”，这对您的要求似乎很重要，但它们不是 Redis 中的概念，因此很难理解您的意思。也许你正在尝试做的一些例子？