注意事项
模式设计，即在文档中表示数据的方式，对于数据表示来说时非常关键的。
为 MongoDB 做模式设计时，在性能、可伸缩性和简单性方面是重中之重，也需要考虑一些特别的注意事项。
限制条件
与常见的 SQL 相比而言，MongoDB 有自己的限制条件：
- 文档最大限制为 16M 大小
- 从磁盘读写完整文档
- 更新会重写整个文档
- 在文档级别进行原子更新
访问模式
设计模式时最需要关注的就是数据库的读操作，在数据库运行过程中，应尽量减少查询的数量，这就需要在设计时确保一起查询的数据存储在同一个文档中。
其实，就是考虑是否是否可以将动态（读/写）数据和静态（主要是读）数据分离开，如未经常使用的数据应该移到不同的集合中。
在进行模式设计时，提高最常见查询的优先级会获得最佳的性能。
关系类型
数据之间的关系影响着文档之间应该是内嵌还是引用。
比如说，需要弄清楚如何在不执行其他查询的情况下引用文档，以及当关系发生变化时需要更新多少文档。
关系基数对于文档之间的关系非常重要，如一对一、一对多、多对多、一对百万、多对百万等等关系基础，影响的程度差距非常大，应选取最佳格式去做建模。
在关系基数的基础上，还需关注访问的情况、重要数据更新与读取的比例，这些充分考虑之后，将有助于确定应采用内嵌文档还是引用文档。
范式化和反范式化
基本概念
通常来说，多文档之间的关系可以使用反范式化（内嵌）或范式化（引用）。
范式化是指在文档中引用外部数据的标识，同一份数据只存在一个地方。
在查询时，查询完整的数据需要做 JOIN 的操作，需要查询多次才可能获取到所需内容；但是在更改时仅需修改一处地方，不需要担心破坏数据的完整性。
反范式化是指将外部数据复制一份存储在文档中，也就是说同一份数据存在多处地方。
在查询时，只需查询一次即可得到所需内容，查询效率比较可观；而在更改时，需要更新多处地方，可能会出现数据不一致的情况，不能保证完整性。
范式化选择
决定何时采用范式化以及何时采用反范式化是比较困难的：通常，范式化的写入速度更快，而反范式化的读取速度更快。
通过判断以下因素可决策选择使用范式化还是反范式化：
| 更适合范式化 | 更适合反范式化 |
|---|---|
| 较大子文档 | 较小子文档 |
| 数据经常变更 | 数据不经常变更 |
| 数据要强一致 | 数据最终一致即可 |
| 文档数据大幅增加 | 文档数据小幅增加 |
| 数据通常不包含在结果中 | 数据通常需要执行二次查询才能获得 |
| 快速写入 | 快速读取 |
模型设计小技巧
指导原则
通常来说，具有类似模式的文档应该保存在同一个集合中。
对于集合来说，需要考虑的一个大问题是锁机制（每个文档都有一个读/写锁）和存储。
当使用 --directoryperdb 选项时，每个数据库都可以保留在自己的目录中，这允许你将不同的数据库挂载到不同的卷中。
同一个应用程序连接的数据库可以根据业务进行划分，也许可以将高价值的业务数据存储在 SSD 上，或者是使用 RAID10 进行存储，而低价值的数据可以存储在 RAID0 上。
删除旧数据
有些数据只在短时间内比较重要，过了这段时间，保存这些数据只是再浪费存储空间。
删除旧数据有 3 种常见的方式：使用固定集合、使用 TTL 索引、使用多个集合。
最简单的方式是使用固定集合：将集合大小设置成一个较大的值，并让旧数据从固定集合的末尾被“删除”。
第二种方式是使用 TTL 集合：TTL 集合可以更精确地控制删除文档的时间，但其在写入量过大的集合中操作速度不够快。
最后一种方式是使用多个集合：例如每个月的文档都单独使用一个集合。
一致性管理
MongoDB 支持多种一致性级别，从总是能够读取自己所写的数据到读取不确定的旧数据。
其内部实现是服务器端为每一个数据库连接都维护了请求队列，同一个连接发来的请求都会被添加到队列的末尾，连接中的任何后续请求都将依次得到处理。
这个管理方式涉及到多个客户端连接会出现并发问题，在一个连接中插入文档后，在另一个连接的后续查询却不一定会返回这个文档（实际上已经插入成功）。
同样的一致性问题在 MongoDB 拥有副本集时也会出现，副本节点的数据与主节点的数据总是会有时间差，高并发的请求同样存在读取到旧数据的风险。
MongoDB 提供了 readConcern 选项来控制被读取数据的一致性和隔离性。它通常与 writerConcern 组合使用，以控制为应用程序提供的一致性和可用性保证：
如果 readConcern=local，从当前实例查询并返回结果，不能保证数据已经写入大多数副本集成员。默认在主库读，如果本次读取使用了 causally consistent 则在从库读。
如果 readConcern=available，从当前实例查询并返回结果，不能保证数据已经写入大多数副本集成员。默认在从库读，并且此选项与 causally consistent 不能同时使用。
如果 readConcern=majority，查询结果返回被副本集的大多数成员确认的数据，读操作返回的文档是持久化的。前提是 MongoDB 必须是 WiredTiger 存储引擎。
如果 readConcern=linearizable，查询可能会等待并发执行的写操作传播到大多数副本集成员，然后再返回结果。
如果 readConcern=snapshot，这是适用于多文档事务中的操作，通常情况下使用较少。
模式迁移
随着应用程序的增长和需求的变化，数据库模式也可能需要随之增长和改变。理想情况下，如果可以的话，应该考虑使用文档版本控制模式。
最简单的方式是根据应用程序的需要改进数据库模式，以确保应用程序支持所有的旧版模式。但是这种方式可能会导致混乱，特别是当不同版本的模式存在冲突时。
为了以一种更结构化的方式处理不断变化的需求，可以在每个文档中包含一个 version 字段，并使用它来确定应用程序将接受的文档结构。
最后一种方式是在模式变更时迁移所有数据。但这通常不是一个好主意：会给系统带来压力，还必须确保所有文档都被更新成功。
模式管理
MongoDB 3.2 引入了模式验证，其可以在更新和插入操作期间对数据进行验证。
MongoDB 3.6 又通过 $jsonSchema 运算符添加了 JSON 模式验证，现在这是 MongoDB 中所有模式验证的推荐方法。
只有当文档被更改时，验证功能才会检查这些文档，并且此功能是每个集合都需要单独配置的。
要向现有集合添加验证功能，可以在 collMod 命令中使用 validator 选项。在使用 db.createCollection() 时，可以通过指定 validator 选项将验证添加到新集合中。
MongoDB 还提供了两个额外的选项：
validationLevel: 决定了在更新过程中验证规则对现有文档检查的严格程度validationAction: 决定了是应该在发生错误时拒绝请求，还是允许请求并发出警告
当然，更详细的相关内容可以查看 官方文档。
编写代码来处理数据完整性问题
为保证 MongoDB 数据的完整性，有可能需要在应用程序中增加必要的逻辑代码进行处理，也需要增加定时任务来保持数据的一致性。
有可能需要有以下的任务：
- 一致性修复程序：检查计算和重复数据以确保每个人都具有一致的值
- 预填充器：创建将来需要的文档
- 聚合：保持内联聚合为最新
- 架构检查器：确保当前使用的文档集都具有一组字段，可以自动更正它们
- 定时备份：定期锁定和转储数据库
到此这篇关于MongoDB 模式设计详解的文章就介绍到这了,更多相关MongoDB模式设计内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们！
