数据建模中的关键挑战是平衡应用程序的需求,数据库引擎的性能特征以及数据检索模式。在设计数据模型时,请始终考虑数据的应用程序使用情况(即查询,更新和数据处理)以及数据本身的固有结构。
与SQL数据库不同,在SQL数据库中必须在插入数据之前确定并声明表的架构,默认情况下,MongoDB的collection不需要其文档具有相同的架构。那是:
这种灵活性有助于将文档映射到实体或对象。每个文档都可以匹配所表示实体的数据字段,即使该文档与集合中的其他文档有很大的不同也是如此。
但是,实际上,集合中的文档具有相似的结构,并且您可以在更新和插入操作期间对集合强制执行文档验证规则。有关详细信息,请参见架构验证。
为MongoDB应用程序设计数据模型的关键决定取决于文档的结构以及应用程序如何表示数据之间的关系。MongoDB允许将相关数据嵌入单个文档中。
在MongoDB中,写操作是对单个文件的能级,即使操作修改多个嵌入式文档 内的单个文件。
具有嵌入数据的非规范化数据模型将所有相关数据组合在一个文档中,而不是在多个文档和集合中进行规范化。该数据模型有助于原子操作。
当单个写入操作(例如
db.collection.updateMany()
)修改多个文档时,每个文档的修改都是原子的,但整个操作不是原子的。
当执行多文档写操作时,无论是通过单个写操作还是通过多个写操作,其他操作都可能会交错。
对于需要对多个文档(在单个或多个集合中)进行读写原子性的情况,MongoDB支持多文档事务:
有关MongoDB中事务的详细信息,请参阅 事务页面。
对于需要对多个文档(在单个或多个集合中)进行读写原子性的情况,MongoDB支持多文档事务:
有关MongoDB中事务的详细信息,请参阅 事务页面。
重要
在大多数情况下,与单文档写入相比,多文档事务产生的性能成本更高,并且多文档事务的可用性不应代替有效的架构设计。在许多情况下, 非规范化数据模型(嵌入式文档和数组)对于您的数据和用例将继续是最佳的。也就是说,在许多情况下,对数据进行适当的建模将最大程度地减少对多文档交易的需求。
有关其他事务使用方面的注意事项(例如运行时限制和oplog大小限制),另请参见 生产注意事项。
也可以看看
在设计数据模型时,请考虑应用程序将如何使用您的数据库。例如,如果您的应用程序仅使用最近插入的文档,请考虑使用Capped Collections。或者,如果您的应用程序需求主要是对集合的读取操作,则添加索引以支持常见查询可以提高性能。
有关影响数据模型设计的这些和其他操作注意事项的更多信息,请参见操作因素和数据模型。
有关使用MongoDB进行数据建模的更多信息,请下载《 MongoDB应用程序现代化指南》。
下载内容包括以下资源: