2017-07-17 121 views
1

我使用的是Azure DocumentDB,我在NoSql中的所有经验都在MongoDb中。我查看了定价模型,成本是每个集合。在MongoDb中,我将为我正在使用的用户,公司和电子邮件创建3个集合。我注意到这种方法每月会花费24美元。同档vs异构documentdb

我跟我一起工作的人告诉我,我做错了。我应该将所有这些事情都存储在一个集合中,并用一个字段来描述数据类型是什么。每个馆藏应该按照日期或地理区域相关,因此世界的一部分有一小部分要搜索。 和:

“合并不同类型的文件合并为一个集合,并添加 现场所有他们在寻找像一个类型字段或 东西分开”

我永远不会有梦想在Mongo中这样做,因为它会使索引,分片键和其他事情难以理顺。

有可能不是这些对象之间的重叠可能字段:

我可以做这种方式(例如电子邮件和坚定的对象),但我似乎无法找到任何人做一个例子这样 - 这表明,也许这是不对的。现在,我不需要一个例子,但是有人能够指向某个位置来描述哪种方法是“正确”的方式吗?或者,如果您确实为所有数据创建了单个集合(除了Azure的定价模型),那么这样做的优缺点是什么?

关于DocumentDb模式设计的任何好的文章?

+0

没有“正确”或“错误”的方式(尽管你的同事告诉你)。话虽如此:人们总是将内容组合成单个集合,包括MongoDB(不知道为什么你不会想到这一点,或者为什么这会使索引变得更加困难;索引是基于每个属性的)。借助CosmosDB,它可以让您进行成本优化,并允许您在单个事务中访问异构数据。 –

+0

我不会梦想将入站电子邮件和用户或公司放在一个集合中。我会把这个集合称为什么? “熔炉”?我的意思是,数据甚至与什么方式有关?这些电子邮件确实有电子邮件地址,并可能映射到用户,但它似乎不是一个好技术。另外,你会如何碎片?而且你会在两个对象的每个字段上都有一个索引。 –

+0

此外,这个问题还有更多关于如何设计DocumentDB模式的好消息 - 显示每个模式的优缺点,而不是专门寻找'X是正确的答案' –

回答

3

是的。为了充分利用CosmosDb,它完全有必要考虑一个Collection是一个完整的数据库系统,而不是一个只能容纳一种类型对象的“表”。

在宇宙中分片是非常简单。您只需指定一个可以填充所有文档的字段,并将其选为分区键。如果您只选择一个通用值,如keypartitionKey,则可以通过选择适当的值,轻松地将入站电子邮件的存储从用户分离出来。

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树的每个路径都有索引。您必须特别选择此自动索引功能的

+0

说一些“非常简单”时请小心。尤其对于分区(分区)键,这不*非常简单(甚至不简单*),因为这可能会对性能产生重大影响。 –

+0

我并不是指您选择分区键值的过程。这当然是困难的,需要对应用程序的查询模式进行实践和深入理解。我正在谈论分片在CosmosDb中的工作原理。你选一把钥匙。整个分片过程然后被抽离你。作为一名开发人员,您完全不必做任何事情,因为它完全是PaaS,它与Mongo非常不同。 –

+0

@DavidMakogon如果您通过为分区键挑选不合适的“值”来削弱您进行高效查询的能力,这与Cosmos中的分片方式无关,也不会影响Cosmos继续高效分片的能力。 –