为面向文档的数据库设计记录密钥 - 最佳做法 [英] Designing record keys for document-oriented database - best practices

问题描述

我们的团队已经开始开发由Couchbase DB支持的应用程序;对于我们每个人来说，这是一个无SQL数据库的第一次体验。

我们已经开始定义我们的实体，并采用了使用类型前缀的做法， Couchbase手册建议：

 实体A：
键：a＃123 
 
实体B：
 key：b＃123 
  

但是我们意识到，与选择创建复合文档键的策略混淆。我们使用计数器很多，他们需要自己的文件。我们的钥匙变得很复杂：

 实体A的每日计数器x：
键：cntrx＃a ＃123-20140117 
  

我们已经考虑过不同的方法，但是我们还是关于这个问题的greenhorns想要一些建议。

分层键是否有什么好处？任何人都可以分享他们定义非平凡密钥的最佳做法？

解决方案

在我们的项目中，我们以下面描述的方式使用分层键：
键的第一部分是RDBMS中的表名：
用户 - 表示表

然后每个用户都有自己的id，例如：

users：1 - 一个用户

我们使用'：'，因为我认为它比其他分隔符看起来更好。您可以使用任何您喜欢的分隔符。

如果您想在上一个示例中使用 id 之类的顺序索引，我们需要从一些密钥中获取它们，所以：

用户：计数器 - 保存最后一个用户ID （它的行为就像自动增量）

如果您需要为用户帐户存储一些子，可以存储：

users：< user's id>：subsection 。

更复杂的例子

用户：1：头像：1：url - 表示通过这个键我们将获得用户1的头像url，但如果用户想存储他们将在用户之下的许多化身：1：替身：X：url ，其中X将是用户的值：1 ：替身：计数器 key。

我们对所有的文档都使用了这个策略，它只存储一个值，甚至是二进制数据。 p>

所以就你的例子，我会选择：

a：123-20140117 ：counter - 这意味着我们有（以RDBMS语言发言）表名为a，在表a中我们记录了id（或其他）123-20140117字段cntrx。

UPD：
关于键大小。其实没关系。是的键的大小有限，但有很多方法来减少它。其中一个 - 使用散列，但我认为这是坏的方式，因为键将很长，消耗更多的内存。在我们的项目中，我们使用memcached bucket的short键。我们有一个枚举（也可以存储在couchbase中），代表人类可理解的密钥名称，并缩短其价值。

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


usersByPhotosCount - k：ubpc：{0}


，30张照片的密钥将为 k：ubpc：30 / p>

但是，只有在生产时才做这些优化。在开发中，最好在应用和数据库中拥有可理解的密钥（即，您可以创建两套k-v对：正常的开发，缩短和模糊生产，并根据您的环境加载）。

Our team has started development of an application backed by Couchbase DB; for every one of us it's the first experience with a no-SQL database.

We've started to define our entities and adopted the practice of using "type" prefixes, suggested by Couchbase manual:

Entity "A":
key: a#123

Entity "B":
key: b#123

But we realized that we're getting confused with choosing the strategy for creating compound document keys. We use counters a lot, and they require their own documents. Our keys have become complicated:

Daily counter "x" for entity "A":
key: cntrx#a#123-20140117

We've considered different approaches, but we're still greenhorns on the subject and would like to ask some advice.

Are hierarchical keys any good at all? Can anyone share their best practices for defining non-trivial keys?

解决方案

In our project we used hierarchical keys in a way described below: First part of a key is something like table name from RDBMS: users - represents "table"

Then each user has it's own id in example:

users:1 - "represents one user"

We used ':', because I think it just looks nicer than other delimiters. You can use any delimiter you like.

If you want to use sequential indexes like id in previous example, you'll need get them from some key, so:

users:counter - key that holds "last user id" (it acts like autoincrement)

If you need to store some "subsection" for user account, you can store it:

users:<user's id>:subsection.

More complex example

users:1:avatars:1:url - means that by this key we will get avatar url of user 1, but if user wants to store many avatars they will go under users:1:avatars:X:url, where X is will be a value of users:1:avatars:counter key.

We used this strategy for all docs, that store only one value, JSON or even binary data.

So exactly for your example, I'll chose:

a:123-20140117:counter - that will mean that we have (speaking in RDBMS language) table named "a", in table "a" we have record with id (or something else) "123-20140117" that has field "cntrx".

UPD: About key size. Actually it doesn't matter. Yes keys are limited in size, but there are a lot of ways to reduce it. One of them - use hashes, but I think it's bad way, because keys will be long and consume more memory. In our project we used "short" keys for memcached bucket. We had a enum (that can be also stored in couchbase) that represent human understandable key name and it's shorten value.

Example: we have some set of records: list of users that have more than 30 photos. So we have a key-value pair:

usersByPhotosCount - k:ubpc:{0}

and for 30 photos key will be k:ubpc:30.

But it's better to do such optimizations only on production. In development it's better to have understandable keys in app and database (i.e. you can create two sets of k-v pairs: normal for development, shorten and obfuscated for production and load them depending on your environment).

这篇关于为面向文档的数据库设计记录密钥 - 最佳做法的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！