您基本上有两种建模数据结构的方法;您可以设计一个架构,您可以在其中引用或嵌入比赛文档。
让我们考虑以下映射游泳比赛和多种族关系的示例。如果您需要在另一个上下文中查看许多数据实体,这证明了嵌入优于引用的优势。在比赛和比赛数据之间的这种一对多的关系中,比赛有多个比赛实体:
// db.competition schema
{
"_id": 1,
"name": "Utmanaren",
"location": "town",
"startdate": "20150627",
"enddate": "20150627"
"races": [
{
"gender" : "m"
"style" : "freestyle"
"length" : "100"
},
{
"gender" : "f"
"style" : "butterfly"
"length" : "50"
}
]
}
借助嵌入式数据模型,您的应用程序只需一次查询即可检索完整的游泳比赛信息。这种设计还有其他优点,其中之一是数据局部性。由于 MongoDB 将数据连续存储在磁盘上,将所需的所有数据放在一个文档中可确保旋转磁盘花费更少的时间来查找磁盘上的特定位置。嵌入文档的另一个优点是写入数据的原子性和隔离性。为了说明这一点,假设您要删除具有值为“蝴蝶”的种族“风格”属性的比赛,这可以通过一个(原子)操作来完成:
db.competition.remove({"races.style": "butterfly"});
有关 MongoDB 中数据建模的更多详细信息,请阅读文档Data Modeling Introduction,特别是Model One-to-Many Relations with Embedded Documents
另一个设计选项是引用文档遵循规范化模式,其中竞赛文档包含对竞赛文档的引用:
// db.race schema
{
"_id": 1,
"competition_id": 1,
"gender": "m",
"style": "freestyle",
"length": "100"
},
{
"_id": 2,
"competition_id": 1,
"gender": "f",
"style": "butterfly",
"length": "50"
}
上述方法增加了执行查询的灵活性。例如,要检索主父实体competition
具有 id 1 的所有子竞赛文档将很简单,只需针对集合创建一个查询race
:
db.race.find({"competiton_id": 1});
当您具有非常不可预测的数量的一对多关系时,上述使用文档引用方法的规范化模式也具有优势。如果race
每个给定的文档有数百或数千个competition
,则嵌入选项在空间限制方面有很多挫折,因为文档越大,它使用的 RAM 越多,而 MongoDB 文档的硬大小限制为 16MB。
如果您的应用程序经常使用比赛信息检索比赛数据,那么您的应用程序需要发出多个查询来解析引用。
一般的经验法则是,如果您的应用程序的查询模式是众所周知的,并且往往只能以一种方式访问数据,那么嵌入式方法就可以很好地工作。如果您的应用程序以多种方式查询数据,或者您无法预测数据查询模式,则更规范化的文档引用模型将适合这种情况。
参考:
MongoDB 应用设计模式:领先的 NoSQL 数据库的实际用例 作者:Rick Copeland