> Shardable(可以引入更多服务器并在它们之间展开键空间)
> Namespaced(应该有一些机制可以逻辑地“组合”键,例如通过域或相关概念)
>高效(尝试在数据库中使用尽可能少的空间来存储密钥,以便尽可能多地使用数据)
>尽可能避免碰撞(避免两个不同对象的键相等)
我考虑过的两个选择是这些：
>使用名称空间的前缀,由某些字符分隔(例如human_resources：person：< some_id>).这样做的好处是它具有很高的可扩展性和易于理解性.缺点是可能的冲突取决于分隔符(如果id具有字符：在其中？),并且可能的大小效率(太多嵌套命名空间可能会创建非常长的键).
>使用一些数据结构(如Ordered Set或Hash)来存储名称空间.这样做的主要缺点是“可破坏性”的丢失,因为存储命名空间的结构需要在单个数据库中.
问题：在分片设置中管理键空间的好方法是什么？我们应该使用这些替代方案,还是有其他一些我们没有考虑过的更好的模式？
非常感谢！
解决方法
这如何与您设定的4条指南一起使用？
Shardable – 这种方法是可以破坏的.每个键可以进入不同的分片或相同的分片,具体取决于您的设置方式.
命名空间命名空间作为避免冲突的方法适用于此方法.但是,名称空间作为组密钥的方法无法解决.通常,使用密钥作为分组数据的方式是一个坏主意.例如,如果一个人从一个部门移动到另一个部门怎么办？如果更改密钥,则必须更新所有引用 – 这会变得棘手.
最好确保密钥永远不会改变对象.然后可以通过创建单独的索引在外部处理分组.
例如,假设您希望按部门,按工资范围和按位置对人员进行分组.这是你如何做到的 –
>个人与关键人物分开：12321
>为每个组创建一个集合 – 例如：persons_by：department – 并且仅存储此集合中每个人的数字标识符.例如[12321,43432].这样,您就可以获得Redis整数集的优势
高效上面解释的方法非常有效.为了节省更多内存,您可以在应用程序端进一步压缩密钥.例如,您可以存储p：12321而不是人：12321.只有在通过分析确定需要节省内存时才应该这样做.一般来说,这是不值得的.
无碰撞这取决于您的应用程序.每个用户或个人都应该拥有一个永不改变的主键.在Redis密钥中使用它,您将不会发生冲突.
如果id有冒号怎么办？
这当然是可能的,但是您的应用程序的设计应该可以防止它.最好不要在标识符中使用特殊字符 – 因为它们将在多个系统中使用.例如,标识符很可能是URL的一部分,冒号即使对于URL也是保留字符.
如果您确实必须在标识符中包含特殊字符,则必须在代码中编写一个包装特殊字符的小包装器. URL编码完全能够处理这个问题.
尺寸效率
长按键有成本,但不是太多.通常,您应该担心值的数据大小而不是密钥.如果您认为密钥占用的内存过多,请使用redis-rdb-tools等工具对数据库进行配置.
如果确定密钥大小有问题并且想要保存内存,则可以编写一个使用别名重写密钥的小包装器.
