Mongo 数据模型介绍

短命女 2022-08-09 00:55 198阅读 0赞

### 数据模型介绍 ###

数据在MongoDB中有很灵活的模式，不像在SQL数据库中，在你插入数据之前你必须确定和声明表结构，然而，MongDB数据库的集合并不会强制文档的结构。这种灵活性有助于将文档映射到一个实体或者一个对象中去。每一个文档可以匹配当前实体的数据域，即使数据有很大的变化。但是实际上，集合中的文档共享相似的结构。

数据建模的关键挑战是平衡应用的需求，数据库引擎的性能和数据检索的模式等。在设计数据模型的时候，总是要考虑数据的应用（例如：查询、更新、数据处理）以及数据本身固有的结构。

### 文档结构 ###

设计MongoDB应用的数据模型的关键围绕着文档的结构和应用程序如何表示如何表示数据间的关系。有两种方式允许程序表示这种关系：引用和嵌入式文档。

#### 引用 ####

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

![Center][]

看 [标准化的数据][Link 1]模型了解使用引用的优点和缺点。

#### 嵌入式数据 ####

嵌入式文档通过在单一的文档结构中存储相关的数据来捕获数据之间的关系。MongoDB文档集可以使在文档中的域或数组中存储文档，这些非规范化的数据模型允许程序在单一的数据库中检索和操作相关的数据。

![Center 1][]

看 [嵌入式数据模型][Link 2]的优点和缺点。

#### 原子写操作 ####

在MongoDB中，写操作在文档级别上是原执行的，没有一个单一的写操作可以会原子的影响多于一个的文档或者是集合。一个包含嵌入式数据非标准化的数据模型和相关的数据代表了一个单一的文档。这些有利于原子写操作，因为对一个实体一个单一的写操作可以插入或者更新数据，标准化数据将把数据分散在多个集合中，这样就会要求多个写操作，也就是说不是集体原子执行。

但是，有利于原子写的模式或许会限制应用程序可以使用的数据或者限制修改应用的方法，原子性的考虑文档描述了设计模式平衡灵活性和原子性的挑战。

#### 文档增长 ####

一些更新，例如一些增加域或者在数组中增加元素，都会加大文档的大小。

对于MMAPv1存储引擎，如果文档的大小超过为文档分配的空间的大小，MongoDB将会在文档上迁移文档，当我们使用MMAPv1存储引擎的时候，增长的考虑可以影响标准化与非标准化数据的决策。看 [文档的增长考虑][Link 3]获取更多的关于MMAPv1处理计划和管理增长文档的情况。

#### 数据使用和性能 ####

当设计一个数据模型的时候，要考虑应用是如何使用数据库的，例如：如果你的应用只是使用最近插入的文档，考虑使用 [加盖的集合][Link 4]。或者你的应用主要对一个集合进行读操作，增加索引可以使普通的查询的性能得到显著的提高。

看 [操作的因素和数据模型][Link 5]获取影响数据模型设计的其他操作考虑。

[Center]: /images/20220731/16bedcf8bff04bd4ab4be135102e9d72.png
[Link 1]: http://docs.mongodb.org/manual/core/data-model-design/#data-modeling-referencing
[Center 1]: /images/20220731/49e49579242f4b4d837701869c99a455.png
[Link 2]: http://docs.mongodb.org/manual/core/data-model-design/#data-modeling-embedding
[Link 3]: http://docs.mongodb.org/manual/core/data-model-operations/#data-model-document-growth
[Link 4]: http://docs.mongodb.org/manual/core/capped-collections/
[Link 5]: http://docs.mongodb.org/manual/core/data-model-operations/