c - 存储redis键的最佳方式

Question

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

例子如下:

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>

Answer 1

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

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

速度和大小:键和值之间存在显着差异。

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

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

我的一般建议是:从仅使用 HSET 和 ZSET 开始，不要拆分属于一起的数据，使用 10-25 个字符之间的描述性 PascalCased 名称作为 key ，如果您需要在 key 中使用分隔符，请使用“:” (命名空间)，序列化为 JSON(为简单起见，但代码很容易切换到 MsgPack)，使用 Lua 脚本(即使你不知道 Lua，你在 Redis 中使用的子集很小)。

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

希望这有帮助，TW