Question

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

与我合作的人告诉我，我做错了。我应该将所有这三个东西存储在一个集合中，并带有一个字段来描述数据类型。每个集合应该按日期或地理区域相关联，因此世界上有一部分要搜索的部分较小。并致：

＆＃34;将不同类型的文档合并到一个集合中并添加跨越所有的字段，以便像搜索类型字段一样将它们分开东西＆＃34;

我绝不会梦想在Mongo中这样做，因为它会使索引，分片键和其他东西难以正确。

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

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

关于DocumentDb架构设计的任何好文章？

Answer 1

是。为了充分利用CosmosDb，需要考虑一个集合是一个完整的数据库系统而不是一个表格＃34;旨在只容纳一种类型的物体。

宇宙中的碎片非常简单。您只需指定一个字段即填充所有文档，并选择该字段作为分区键。如果您只选择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或查询都不起作用。

修改我在评论中注意到你发表了这句话And you would have an index on every field in both objects。 CosmosDb 确实自动索引每个文档的每个字段。它们使用特殊的专有路径索引机制，确保JSON树的每个路径都有索引。您必须明确选择 out 此自动编制索引功能。

documentdb中的齐次与异构

1 个答案: