数据模型简介

进入MongoDB中文手册（4.2版本）目录

数据建模中的关键挑战是平衡应用程序的需求，数据库引擎的性能特征以及数据检索模式。在设计数据模型时，请始终考虑数据的应用程序使用情况（即查询，更新和数据处理）以及数据本身的固有结构。

1 灵活的架构(Schema)

与SQL数据库不同，在SQL数据库中必须在插入数据之前确定并声明表的架构(Schema)，默认情况下，MongoDB的集合不需要其文档具有相同的架构(Schema)。那是：

• 单个集合中的文档不需要具有相同的字段集，并且字段的数据类型可以在集合中的不同文档之间有所不同。
• 要更改集合中文档的结构，例如添加新字段，删除现有字段或将字段值更改为新类型，请将文档更新为新结构。

这种灵活性有助于将文档映射到实体或对象。每个文档都可以匹配所表示实体的数据字段，即使该文档与集合中的其他文档有很大的不同也是如此。
但是，实际上，集合中的文档具有相似的结构，并且您可以在更新和插入操作期间对集合强制执行文档验证规则。有关详细信息，请参见架构验证。

2 文档结构(Structure)

为MongoDB应用程序设计数据模型的关键决定取决于文档的结构以及应用程序如何表示数据之间的关系。MongoDB允许将相关数据嵌入单个文档中。

2.1 嵌入数据

嵌入式文档通过将相关数据存储在单个文档结构中来表示数据之间的关系。MongoDB文档可以将文档结构嵌入文档中的字段或数组中。这些非规范化的数据模型(denormalized data models)允许应用程序在单个数据库操作中检索和操纵相关数据。

对于MongoDB中的许多用例，非规范化数据模型是最佳的。
有关嵌入文档的优缺点，请参见嵌入式数据模型。

2.2 引用

引用是通过包含从一个文档到另一个文档的链接或引用来存储数据之间的关系。应用程序可以解析这些引用并访问相关数据。广义上讲，这些是规范化的数据模型(normalized data models)。

有关使用引用的优缺点，请参见规范化数据模型。

3 写操作的原子性

3.1 单文档原子性

在MongoDB中，写操作对单个文档是原子操作，即使修改单个文档内的多个嵌入式文档也一样。
具有嵌入数据的非规范化数据模型将所有相关数据组合在一个文档中，而不是在多个文档和集合中进行规范化。该数据模型有助于原子操作。
当单个写入操作（例如 db.collection.updateMany()）修改多个文档时，每个文档的修改都是原子的，但整个操作不是原子的。
当执行多文档写操作时，无论是通过单个写操作还是通过多个写操作，其他操作都可能会交错。
对于需要对多个文档（在单个或多个集合中）进行读写原子性的情况，MongoDB支持多文档事务：

• 在版本4.0中，MongoDB支持副本集上的多文档事务。
• 在4.2版中，MongoDB引入了分布式事务，它增加了对分片群集上多文档事务的支持，并合并了对已有的副本集上多文档事务的支持。

3.2 多文档事务

对于需要对多个文档（在单个或多个集合中）进行读写原子性的情况，MongoDB支持多文档事务：

• 在版本4.0中，MongoDB支持副本集上的多文档事务。
• 在4.2版中，MongoDB引入了分布式事务，它增加了对分片群集上多文档事务的支持，并合并了对已有的副本集上多文档事务的支持。

有关MongoDB中事务的详细信息，请参阅事务页面。

重要
在大多数情况下，与单文档写入相比，多文档事务产生的性能成本更高，并且多文档事务的可用性不应代替有效的架构设计。在许多情况下， 非规范化数据模型（嵌入式文档和数组）对于您的数据和用例将继续是最佳的。也就是说，在许多情况下，对数据进行适当的建模将最大程度地减少对多文档交易的需求。
有关其他事务使用方面的注意事项（例如运行时限制和oplog大小限制），另请参见生产注意事项。

也可以看看：

• 原子性注意事项

4 数据的使用和性能

在设计数据模型时，请考虑应用程序将如何使用您的数据库。例如，如果您的应用程序仅使用最近插入的文档，请考虑使用固定集合。或者，如果您的应用程序需求主要是对集合的读取操作，则添加索引以支持常见查询，从而可以提高性能。
有关影响数据模型设计的这些和其他操作注意事项的更多信息，请参见操作因素和数据模型。

5 进一步阅读

有关使用MongoDB进行数据建模的更多信息，请下载《 MongoDB应用程序现代化指南》。
下载内容包括以下资源：

• 演示使用MongoDB进行数据建模的方法
• 白皮书涵盖了从RDBMS数据模型迁移到MongoDB的最佳实践和注意事项
• 参考MongoDB架构及其等效的RDBMS
• 应用程序现代化记分卡

进入MongoDB中文手册（4.2版本）目录