我们的团队已开始开发由Couchbase DB支持的应用程序;对于我们每个人来说,这都是使用no-SQL数据库的首次体验。
我们已经开始定义实体,并采用了Couchbase手册建议的使用“类型”前缀的做法:
Entity "A":
key: a#123
Entity "B":
key: b#123
但是我们意识到,我们对于选择创建复合文档密钥的策略感到困惑。我们使用计数器很多,它们需要自己的文件。我们的密钥变得复杂了:
Daily counter "x" for entity "A":
key: cntrx#a#123-20140117
我们考虑过不同的方法,但是我们在这个问题上仍然不切实际,并想提出一些建议。
层次密钥有什么用吗?谁能分享定义非平凡键的最佳实践?
最佳答案
在我们的项目中,我们以如下所述的方式使用了层次结构键:
密钥的第一部分类似于RDBMS中的表名:users
-代表“表格”
然后,每个用户在示例中都有自己的ID:users:1
-“代表一个用户”
我们使用':',因为我认为它看起来比其他定界符更好。您可以使用任何喜欢的定界符。
如果要使用上一个示例中的id
之类的顺序索引,则需要从某个键中获取它们,因此:users:counter
-包含“最后一个用户ID”的键(其作用类似于自动递增)
如果需要为用户帐户存储一些“小节”,则可以存储它:users:<user's id>:subsection
。
更复杂的例子users:1:avatars:1:url
-表示通过此密钥,我们将获得用户1的化身URL,但如果用户要存储许多化身,则他们将进入users:1:avatars:X:url
,其中X是users:1:avatars:counter
密钥的值。
对于所有仅存储一个值,JSON甚至二进制数据的文档,我们都采用了这种策略。
因此,就您的示例而言,我将选择:a:123-20140117:counter
-这意味着我们(用RDBMS语言讲)有一个名为“ a”的表,在表“ a”中我们有ID(或其他名称)为“ 123-20140117”的记录,该记录具有字段“ cntrx”。
UPD:
关于密钥大小。其实没关系。是的,密钥的大小受到限制,但是有很多方法可以减小密钥的大小。其中之一-使用哈希,但我认为这是不好的方法,因为密钥很长,而且会占用更多内存。在我们的项目中,我们为内存缓存存储桶使用了“短”键。我们有一个枚举(也可以存储在沙发上),该枚举表示人类可以理解的键名,并且它的缩写值。
示例:我们有一些记录:拥有30张以上照片的用户列表。
因此,我们有一个键值对:usersByPhotosCount - k:ubpc:{0}
对于30张照片,密钥将为k:ubpc:30
。
但是最好仅在生产中进行此类优化。在开发中,最好在应用程序和数据库中具有易于理解的键(即,您可以创建两组k-v对:用于开发的常规对,用于生产的缩短和混淆的对,并根据您的环境进行加载)。