azure - documentdb 中的同构与异构

Question

我正在使用 Azure DocumentDB，并且我在 NoSql 中的所有经验都是在 MongoDb 中。我查看了定价模型，成本是按每个系列计算的。在 MongoDb 中，我会为我正在使用的内容创建 3 个集合:用户、公司和电子邮件。我注意到这种方法每月每个集合的费用为 24 美元。

与我一起工作的人告诉我，我做错了。我应该将所有这三个内容存储在一个集合中，并用一个字段来描述数据类型。每个馆藏都应按日期或地理区域相关，以便世界的某一部分需要搜索的部分较少。并致:

"Combine different types of documents into a single collection and add a field across all to separate them in searching like a type field or something"

我从来没有梦想过在 Mongo 中这样做，因为这会让索引、分片键和其他事情变得很难正确。

对象之间可能没有重叠的字段(例如:电子邮件和公司对象)

我可以这样做，但我似乎找不到任何其他人这样做的例子 - 这向我表明也许这是不对的。现在，我不需要示例，但是有人可以指出我到某个位置来描述哪种方法是“正确”的吗？或者，如果您确实为所有数据创建单个集合 - 除了 Azure 的定价模型之外，这样做的优点/缺点是什么？

有什么关于 DocumentDb 架构设计的好文章吗？

Answer 1

是的。为了充分利用 CosmosDb 的潜力，需要将集合视为整个数据库系统，而不是设计用于仅保存一种类型的对象的“表”。

Cosmos 中的分片非常简单。您只需指定一个所有文档都将填充的字段，然后选择它作为分区键。如果您只选择一个通用值，例如 key 或 partitionKey，您可以通过选择适当的值轻松地将入站电子邮件的存储与用户或其他任何内容分开。

class InboundEmail
{
   public string Key {get; set;} = "EmailsPartition";
   // other properties
}

class User
{
   public string Key {get; set;} = "UsersPartition";
   // other properties
}

我所展示的仍然只是一个例子。实际上，您的分区键值应该更加动态。重要的是要了解针对已知分区的查询非常快。一旦您需要扫描多个分区，您就会看到速度更慢且成本更高的结果。

因此，在一个摄取大量用户数据的应用程序中。将单个用户的事件保存在一个分区中可能对于该特定实体有意义。

如果您想要证据证明这是使用 CosmosDb 的适当方式，请考虑添加新的 Gremlin Graph API。图本质上是异构的，因为它们包含许多不同的实体和实体类型以及它们之间的关系。 Cosmos 的查询边界位于集合级别，因此如果您尝试将实体全部放入不同的集合中，则任何 Graph API 或查询都不起作用。

编辑:我注意到在评论中您做了这样的声明并且您将在两个对象中的每个字段上都有一个索引。 CosmosDb 确实自动为每个文档的每个字段建立索引。它们使用基于特殊专有路径的索引机制，确保 JSON 树的每个路径都有索引。您必须明确退出此自动索引功能。