我们的团队已开始开发由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对:用于开发的常规对,用于生产的缩短和混淆的对,并根据您的环境进行加载)。

10-06 05:16
查看更多