存储redis密钥的最佳方式
我使用Redis存储一些信息并检测该信息随时间的变化（例如，考虑用户和位置）。 使用更长或更短的键名有什么价值？ 使用更长的密钥更清晰，但使用更长的密钥名需要大量内存或性能吗？
以下是示例：
SET L:123456 " ..." HSET U:987654321 loc 123456 time 要么
SET loc:{123456} " ..." HSET user:{U987654321} loc 123456 time
这一切都取决于你将如何使用它。 如果每个字节都很重要，例如当您必须为转移到云服务的每个kB付费时，您就可以计算成本。 数学很简单; 一个字节是’在线上’的一个字节’。 在redis中，对于更大的值，它同样简单。 对于较小的值，Redis会进行一些内存优化。
在您的HSET示例中，您将成员分开，只有在大多数时候需要将它们彼此分开时才有意义。 更好的方法 – 可能是： HSET HSET user:data 987654321 '{"loc": "123456", "time": "2014-01-01T13:00:00"}' 。 单独的键/成员成本’比更长的字符串更多，性能明智。 如果只将一个表或数据集用作一个完整的半静态实体，您甚至可以将整个表或数据集放在一个成员中。
速度和大小： 键和值之间存在显着差异。
密钥：更短通常是更高的内存效率和速度效率。 如果您使用redis Sorted Set，您甚至可以使用’numbers’作为键（排序集’成员’加’得分’）。 我说“数字”因为技术上得分是一个浮点数64，但要用作ID，它必须介于-999999999999999和999999999999999之间（包括15位数），没有任何小数部分。 这可能非常有用，因为Redis可以对排序集进行快速且可扩展的O（log（n））即时排序（使用跳过列表，简化）。
值： MsgPack格式（未压缩）占用的空间最小，尤其是在存储定义一次且值为多的情况下。 JSON的内存效率要低一些，但它是一种常见的IPC格式，不应该被忽略。 原始字符串，字符分隔，固定长度（ugh），无论您的愿望如何，都可以使用。 在将数据存储在Redis中之前，您始终可以压缩数据。 到目前为止内存效率 。 谈到速度 ，它不那么简单。 如果要使用Lua服务器端脚本（应该使用），则无法对压缩数据执行任何操作。 JSON和MsgPack可以反序列化，但只能“作为一个整体”。 这在大多数情况下都很好。 最灵活的是存储单独的值（例如作为HSET的成员），但这也是有代价的（大多数时候：价格太高）。 你也可以结合所有这些。 我们最常用的：两个或三个分隔符分隔值的前缀，后跟MsgPack有效负载。
我的一般建议是：从仅使用HSET和ZSET开始，不要拆分属于一起的数据，在10-25个字符之间使用描述性的PascalCased名称，如果你需要键中的分隔符（命名空间），请使用’：’ ，序列化为JSON（为简单起见，但代码易于切换到MsgPack），使用Lua脚本（即使你不知道Lua，你在Redis中使用的子集很小）。
我不会在项目的启动阶段过多地担心它，你可以随时更改它，并在你有一些可插入的数据后立即进行一些A / B比较。
希望这有帮助，TW
现在Redis v3.2几乎就在这里，您应该考虑切换到新的地理哈希function： http ： //redis.io/commands/geoadd