存储 redis 密钥的最佳方式答案

【问题标题】：Best way to store redis keys存储 redis 密钥的最佳方式
【发布时间】：2015-09-04 16:35:56
【问题描述】：

我正在使用 Redis 存储一些信息并检测该信息随时间的变化（例如，考虑用户和位置）。使用更长或更短的键名有什么价值？使用更长的键名更清晰，但是使用更长的键名是否会消耗大量内存或性能？

以下是示例：

SET L:123456 "<name> <latitude> <longitude> ..."
HSET U:987654321 loc 123456 time <epoch>

或

SET loc:{123456} "<name> <latitude> <longitude> ..."
HSET user:{U987654321} loc 123456 time <epoch>

【问题讨论】：

嗨 Chuck，这个评论有点跑题了。我注意到你没有接受我的任何回答。这当然很好，但是由于您已经发布了很多，所以如果您留下评论并说明理由，那么对于 SO 的每个人来说都是更可取的。它有助于保持一个整洁的地方。您也可以回答（并接受）您自己的答案。这样，您的问题就不会出现在“未回答”的查询中。一切顺利，TW。

标签： c ruby database redis nosql

【解决方案1】：

这完全取决于您将如何使用它。如果每个字节都很重要，例如当您必须为传输到云服务的每个 kB 付费时，您可以计算成本。数学很简单；一个字节是“在线”上的一个字节。在 redis 内部，对于较大的值，它同样简单。对于较小的值，Redis 会进行一些内存优化。

在您的 HSET 示例中，您拆分了成员，这仅在您大部分时间需要将它们彼此分开时才有意义。更好的方法-可能-是：HSET user:data 987654321 '{"loc": "123456", "time": "2014-01-01T13:00:00"}'。在性能方面，单独的键/成员比更长的字符串“花费”更多。如果仅将其用作一个完整的半静态实体，您甚至可以将整个表或数据集放在一个成员中。

速度和大小：keys 和 values 之间存在显着差异。

键：更短的内存效率和速度效率通常更高。如果您使用 redis Sorted Set，您甚至可以使用“数字”作为键（排序集“成员”加“分数”）。我说“数字”是因为分数在技术上是 float64，但要用作 ID，它必须介于 -999999999999999 和 999999999999999 之间，包括（即 15 位数字），没有任何小数部分。这真的很有帮助，因为 Redis 对排序集进行快速且可扩展的 O(log(n)) 即时排序（使用跳过列表，简化）。

价值观： MsgPack 格式（未压缩）占用的空间最少，尤其是在您存储定义一次且值很多时。 JSON 的内存效率有点低，但它当然是一种常见的 IPC 格式，不应该被遗漏。原始字符串，字符分隔，固定长度（呃），无论你想要什么，都可以使用。您始终可以在将数据存储到 Redis 之前对其进行压缩。到目前为止内存效率。谈到速度，就没有那么简单了。如果你想使用 Lua 服务器端脚本（你应该这样做），你不能对压缩数据做任何事情。 JSON 和 MsgPack 可以反序列化，但只能“作为一个整体”。这在大多数情况下都很好。最灵活的是存储单独的值（例如作为 HSET 的成员），但这也是有代价的（大多数时候：价格太高）。你也可以结合所有这些。我们最常用的是：两个或三个分隔符分隔值的前缀，后跟一个 MsgPack 负载。

我的一般建议是：从仅使用 HSET 和 ZSET 开始，不要拆分属于一起的数据，对 10 到 25 个字符之间的键使用描述性 PascalCased 名称，如果需要在键中使用分隔符，请使用 ':' （命名空间），序列化为 JSON（为简单起见，但代码便于切换到 MsgPack），使用 Lua 脚本（即使您不了解 Lua，您在 Redis 中使用的子集也很小）。

我不会在您项目的启动阶段过于担心它，您可以随时更改它，并在获得一些可插值数据后立即进行一些 A/B 比较。

希望这有帮助，TW

【讨论】：

附注：我看到你有'C'作为标签。如果您选择 MsgPack 并想从 C 中使用它，我可以推荐 Inada Naoki 的出色 Cython 实现，它主要是 C 和/或非常容易移植。见here。我们发现它比官方的 C 实现更容易使用（来自 C）。
我使用 Lua 并从我的客户端代码调用函数来调用存储在键空间 ( :func: ) 中的脚本，并进行一些简单的服务器端查找和加入。您的回答很有帮助；我正在寻找关键选择的洞察力。
好的，明白了。您的问题是：'使用更长的键名对内存或性能有很大影响吗？'，我想我已经回答了。您还追求哪些其他见解？乐于助人。

【解决方案2】：

现在 Redis v3.2 即将推出，您应该考虑切换到新的地理哈希功能：http://redis.io/commands/geoadd

【讨论】：