documentdb 中的同质与异构

Question

我正在使用 Azure DocumentDB，我在 NoSql 方面的所有经验都在 MongoDb 中。我查看了定价模型，成本是每个收藏品。在 MongoDb 中，我会为我正在使用的东西创建 3 个集合：用户、公司和电子邮件。我注意到这种方法每月每次收集的费用为 24 美元。

与我一起工作的人告诉我，我做错了。我应该将所有这三个东西都存储在一个集合中，并带有一个字段来描述数据类型是什么。每个集合都应该按日期或地理区域相关联，以便世界的一个部分有更小的部分可供搜索。 并：

"将不同类型的文档组合成一个集合并添加 一个字段，用于在搜索中将它们分开，如类型字段或 东西”

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

对象之间可能没有重叠的字段（例如：电子邮件和公司对象）

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

有没有关于 DocumentDb 架构设计的好文章？

Answer 1

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

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 或查询都不会起作用。

编辑： 我在 cmets 中注意到您发表了此声明 And you would have an index on every field in both objects。 CosmosDb 确实自动索引每个文档的每个字段。他们使用一种特殊的专有的基于路径的索引机制，确保 JSON 树的每个路径都有索引。您必须明确选择退出此自动索引功能。