为面向文档的数据库设计记录键 - 最佳实践

我们的团队已经开始开发由 Couchbase DB 支持的应用程序；对于我们每个人来说，这都是第一次使用非 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 key.

我们对所有仅存储一个值、JSON 甚至二进制数据的文档使用了这一策略。

因此，对于您的示例，我将选择：

a:123-20140117:counter- 这意味着我们有（用 RDBMS 语言来说）名为“a”的表，在表“a”中，我们有 id（或其他）“123-20140117”的记录，其中包含字段“cntrx”。

UPD:关于钥匙尺寸。其实没关系。是的，按键的大小是有限的，但是有很多方法可以减少它。其中之一 - 使用哈希，但我认为这是不好的方法，因为密钥会很长并且消耗更多内存。在我们的项目中，我们对 memcached 存储桶使用“短”键。我们有一个枚举（也可以存储在 couchbase 中），它代表人类可以理解的键名称及其缩写值。

示例：我们有一些记录集：拥有超过 30 张照片的用户列表。 所以我们有一个键值对：

usersByPhotosCount - k:ubpc:{0}

对于 30 张照片，关键是k:ubpc:30.

但最好只在生产中进行此类优化。在开发过程中，最好在应用程序和数据库中拥有可理解的键（即，您可以创建两组 k-v 对：正常用于开发，缩短和混淆用于生产，并根据您的环境加载它们）。