我们在这里有一个巨大的争议:
我们在服务器上安装了 Redis，我们想在其中保存几种类型的数据:
- 一些零星变量(针对每个用户 - 所以不仅仅是几条记录)
- 一个非常大的表会随着时间增长
争论的焦点是如何保存提到的表格
我们都知道 Redis 的 GET 时间复杂度是 O(1) - 所以我们可以将表的每条记录存储为 Redis 中的一条记录(通过一些前缀来知道它是该表行)
或
我们可以将表作为单个记录存储在 Redis 中作为哈希 - 然后在哈希中访问我们想要的行 - 这是两个 O(1) 的步骤。
我认为 Redis 中不断增长的巨大 SINGLE 记录是灾难性的，但我需要的不仅仅是我对此的看法 - 我需要 Redis 专家的回应，指出该方法的错误或证明我错了。
最佳答案
首先，让我们弄清楚一些事情 - GET和 HGET是 O(1) 操作。两者之间没有时间复杂度差异。
接下来要考虑的是以后如何对 key 空间进行分区。假设您的增长呈爆炸式增长，您需要以某种方式进行集群(企业、OSS 或其他)。在所有这些实现中，您不能拆分 key 。因此，如果您只有一个名为 users 的哈希，然后是一个表示用户 ID 的字段，那么正如您提到的那样，该哈希将变得非常大，并且不容易扩展。
更好的做法是将您的用户划分为子哈希。假设您的用户 ID 如下所示:1234 那么您要做的是拥有一个散列 user:12 和一个 34 字段您为用户 1234 (HGET user:12 34) 存储数据的位置。通过这种方式，您可以节省键空间开销，并且仍然能够对键空间进行分区。 Redis Memory Optimization 中概述了此策略文档。
就您的数据而言，您可以进行某种序列化并将所有内容存储在一个字段中(JSON、CSV 等)，或者为每个用户的每条数据使用散列并仍然分区(例如键 user:name:12/字段 34 和 user:age:12/字段 34).
关于hash - Redis - 非常大的单条记录(哈希表)，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/47792178/