Couchbase:使用文档 ID 对我有什么好处？

Question

我是 NoSQL 世界的新手，因为我从事 RDBMS 编程已有一段时间了。在 RDBMS 中，每个表都有一个 PRIMARY KEY 的概念。您使用 FOREIGN KEY 引用其他表，通常，如果非规范化良好，您还有另一个表，该表基本上只包含来自 TABLE A 和 TABLE B 的映射，因此您可以连接它们。

在 Couchbase 中，有文档 ID 的概念，其中文档在文档本身之外拥有自己的唯一键。这个文档 ID 有什么用？我看到的唯一用途是查询对象本身(使用 USE KEYS 子句)。

我可以在我的 JSON 文档中指定一个“id”和“type”，然后为文档 key 分配随机 UUID。

使用它有什么好处？如果可能，ELI5。

另外，为什么有些开发人员要在文档 ID 中添加“前缀”(例如 客户::客户名称"。

Answer 1

这是一个很好的问题，答案既有历史意义又有技术意义。

历史:Couchbase 起源于 CouchOne/CouchDB 和 Membase，后者是 memcached 键值存储的持久分布式版本。 Couchbase 仍然作为键值存储运行，检索文档的最快方法是通过键查找。您可以使用基于其中一个文档字段的索引来检索文档，但那样会更慢。

从技术上讲，根据 ID 快速检索文档的能力是 Couchbase 对许多用户/应用程序具有吸引力的一个优势(以及可扩展性和可靠性)。

为什么有些开发者要给文档ID加上“前缀”，比如“customer::{customer name}”。对于与快速检索和数据建模相关的问题。假设您有一个包含客户基本资料的小文档，并且您使用客户的电子邮件地址作为文档 ID。客户登录后，您的应用程序可以使用电子邮件作为 ID，使用非常快速的 k-v 查找来检索此配置文件。您希望将此文档保持较小，以便可以更快地检索它。

也许客户有时想查看他们的整个购买历史记录。您的应用程序可能希望将该购买历史记录保存在一个单独的文档中，因为它太大而无法检索，除非您确实需要它。所以你会用文档 ID {email}::purchase_history 存储它，这样你就可以再次使用 k-v 查找来检索它。此外，您不需要在任何地方存储购买历史记录的 key ——这是隐含的。同样，客户的邮寄地址可能存储在文档 ID {email}::addresses 下。等等

Couchbase 中的数据建模与传统 RDBMS 中的数据建模一样重要，但您的处理方式有所不同。免费在线培训中对此进行了很好的讨论:https://training.couchbase.com/online?utm_source=sem&utm_medium=textad&utm_campaign=adwords&utm_term=couchbase%20online%20training&utm_content=&gclid=CMrM66Sgw9MCFYGHfgodSncCGA#

为什么 Couchbase 仍然使用外部键而不是 JSON 内部的主键字段？因为 Couchbase 仍然允许非 JSON 数据(例如，二进制数据)。此外，虽然关系数据库可以允许多个字段或字段组合作为候选键，但 Couchbase 将文档 ID 用于其分片版本，因此文档 ID 不能像其他字段一样对待。