Redis 键中冒号的用途是什么
我正在学习如何在我的项目中使用 Redis。我不明白的一件事是键名称中冒号的确切用途。
我见过这样的键名称：
users:bob
color:blue
item:bag
冒号是否将键分成类别并使查找键更快？如果是这样，您可以在命名键时使用多个冒号将它们分解为子类别吗？最后，它们与在 Redis 服务器中定义不同的数据库有什么关系吗？
我已经阅读了文档并就此事进行了大量谷歌搜索，但奇怪的是我找不到任何讨论此问题的内容。
I'm learning how to use Redis for a project of mine. One thing I haven't got my head around is what exactly the colons are used for in the names of keys.
I have seen names of key such as these:
users:bob
color:blue
item:bag
Does the colon separate keys into categories and make finding the keys faster? If so can you use multiple colons when naming keys to break them down into sub categories? Lastly do they have anything to do with defining different databases within the Redis server?
I have read through documentation and done numerous Google searches on the matter but oddly I can't find anything discussing this.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
冒号作为存储命名空间数据的概念出现在早期的 Redis 版本中。在早期版本中，Redis 仅支持字符串。如果您想存储电子邮件和“bob”的年龄，则必须将其全部存储为字符串，因此使用冒号：
它们在 Redis 中没有特殊处理或性能特征。唯一的目的是为数据命名空间以便再次找到它。如今，您可以使用哈希来存储大多数冒号键：
您不必将哈希命名为“user:bob”，我们可以将其命名为“bob”，但是使用用户前缀命名它，我们立即知道该信息是哪些信息哈希应该/可以有。
The colons have been in earlier Redis versions as a concept for storing namespaced data. In early versions, Redis supported only strings. If you wanted to store the email and the age of 'bob' you had to store it all as strings, so colons were used:
They had no special handling or performance characteristics in Redis. The only purpose was namespacing the data to find it again. Nowadays, you can use hashes to store most of the coloned keys:
You don't have to name the hash "user:bob" we could name it "bob", but namespacing it with the user-prefix we instantly know which information this hash should/could have.
冒号是构建键的一种方式。 Redis 不会以任何方式解释它们。您还可以使用您喜欢的任何其他分隔符或根本不使用。我个人更喜欢
/，它使我的密钥看起来像文件系统路径。它们对性能没有影响，但不应将它们设置得太长，因为 Redis 必须将所有键保留在内存中。良好的键结构对于利用排序命令的强大功能非常重要，排序命令是 Redis 对 SQL 连接的回答。
您可以看到键结构使 SORT 能够通过引用结构化键来查找用户的颜色。
Colons are a way to structure the keys. They are not interpreted by redis in any way. You can also use any other delimiter you like or none at all. I personally prefer
/, which makes my keys look like file system paths. They have no influence on performance but you should not make them excessively long since redis has to keep all keys in memory.A good key structure is important to leverage the power of the sort command, which is redis' answers to SQL's join.
You can see that the key structure enables SORT to lookup the user's colors by referencing the structured keys.