数据建模简介

在本页面

• Document Structure

• 写入操作的原子性

• Document Growth

• 数据使用和性能

MongoDB 中的数据具有弹性模式。与 SQL 数据库不同，在 SQL 数据库中必须在插入数据之前确定并声明表的架构，而 MongoDB 的collections并不强制使用document结构。这种灵 Active 有助于将文档 Map 到实体或对象。每个文档都可以匹配所表示实体的数据字段，即使数据有实质性变化。但是，实际上，集合中的文档具有相似的结构。

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

Document Structure

为 MongoDB 应用程序设计数据模型的关键决定取决于文档的结构以及应用程序如何表示数据之间的关系。有两种工具可让应用程序代表这些关系：参考和嵌入式文档。

References

引用通过包含从一个文档到另一个文档的链接或“引用”来存储数据之间的关系。应用程序可以解析这些references来访问相关数据。广义上讲，这些是标准化数据模型。

有关使用参考的优缺点，请参见标准化数据模型。

Embedded Data

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

有关嵌入文档的优缺点，请参见嵌入式数据模型。

写入操作的原子性

在 MongoDB 中，写操作在document级别上是原子的，并且任何单个写操作都不能原子地影响一个以上的文档或多个集合。具有嵌入数据的非规范化数据模型将单个文档中代表实体的所有相关数据组合在一起。由于单个写入操作可以插入或更新实体的数据，因此这有助于原子写入操作。对数据进行规范化将把数据拆分为多个集合，并且将需要多个不是原子集合的写操作。

但是，促进原子写入的架构可能会限制应用程序使用数据的方式或可能会限制修改应用程序的方式。 Atomicity Considerations文档描述了设计兼顾灵 Active 和原子性的架构所面临的挑战。

Document Growth

某些更新(例如将元素推送到数组或添加新字段)会增加document's的大小。

对于 MMAPv1 存储引擎，如果文档大小超出了为该文档分配的空间，则 MongoDB 会将文档重新放置在磁盘上。使用 MMAPv1 存储引擎时，增长考虑因素可能会影响对数据进行规范化或非规范化的决策。有关计划和 ManagementMMAPv1 的文档增长的更多信息，请参见文件增长注意事项。

数据使用和性能

在设计数据模型时，请考虑应用程序将如何使用您的数据库。例如，如果您的应用程序仅使用最近插入的文档，请考虑使用Capped Collections。或者，如果您的应用程序需求主要是对集合的读取操作，则添加索引以支持常见查询可以提高性能。

有关影响数据模型设计的这些和其他操作注意事项的更多信息，请参见运营因素和数据模型。