azure – documentdb中的同构与异构
|
我正在使用Azure DocumentDB,我在NoSql中的所有经验都在MongoDb中.我查看了定价模型,每个集合的成本.在MongoDb中,我会为我使用的东西创建3个集合：用户,公司和电子邮件.我注意到这种方法每月收费24美元.
我和我一起工作的人告诉我,我做错了.我应该将所有这三个东西存储在一个集合中,并带有一个字段来描述数据类型.每个集合应该按日期或地理区域相关联,因此世界上有一部分要搜索的部分较小.
我永远不会梦想在Mongo中这样做,因为它会使索引,分片键和其他难以理解的东西. 可能没有可能在对象之间重叠的字段(例如：电子邮件和公司对象) 我可以这样做,但我似乎找不到任何其他人这样做的例子 – 这向我表明可能是不对的.现在,我不需要一个例子,但是有人可以指向某个位置来描述哪个是“正确”的方法吗？或者,如果您为所有数据创建单个集合 – 除了Azure的定价模型之外,这样做的优点/缺点是什么？ 关于DocumentDb架构设计的任何好文章？ 解决方法
是.为了充分利用CosmosDb,需要考虑Collection是一个完整的数据库系统,而不是一个只用于保存一种类型对象的“表”.
宇宙中的碎片非常简单.您只需指定一个字段即填充所有文档,并选择该字段作为分区键.如果您只选择一个通用值(例如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树的每个路径都有索引.您必须明确选择退出此自动索引功能. （编辑：李大同） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |