在所有数据库中，MongoDB是唯一允许用户在一个MongoDB集群中使用多个存储引擎的数据库系统。这种灵活性可以提供一种更简单更可靠的方法来满足数据的多样化应用需求。通常，为了满足数据多样化，需要使用不同的数据库系统，并且为了保证一致性以及安全性，需要加入很多复杂的、自定义的代码使数据在不同数据库系统间进行迁移。尽管每个存储引擎对不同的工作负载进行了优化，用户仍然可以在不同的存储引擎中使用相同的MongoDB查询语言、数据模型、扩展方式、安全性以及操作工具。因此，此文档中的***实践适用于所有支持的存储引擎。不同存储引擎的使用建议中的不同之处，文档也会做提醒。
在MongoDB复制集中使用多引擎能简化评估以及迁移数据的工作。升级到WiredTiger引擎多现有的复制集是没有影响的；应用会100%兼容系统，使用滚动升级，能在零宕机的情况下完成迁移工作。MongoDB3.2默认的存储引擎就是WiredTiger；如果要使用其他引擎，可以在启动mongod的时候使用—storageEnginge选项。如果使用的是3.2+以上的版本启动的mongod,，并且存在一个或者多个数据库系统，则可以使用任意的数据库创建是使用的存储引擎。
模式设计开发人员和数据架构师在项目初期就应该一起讨论开发合理的数据模型。数据模型、升级以及MongoDB系统的查询使用应用的需求来驱动的。考虑到MongoDB的动态模型设计特性，开发人员和数据架构师也可以在开发和部署的过程中对数据模型进行迭代以优化性能、存储高效性以及应用特性需要的其他支持。所有这些工作都不需要大规模修改模式。
模式设计的话题讨论是很有意义的，但是本文档不会做深入的讨论。网上有很多相关的资源，包括MongoDB解决方案架构师以及用户的会议演示，还有MongoDB大学的免费网上培训。MongoDB全球咨询服务中的Development Rapid Start service有关于模式设计的咨询。模式设计的几个关键概念如下。
文档模型MongoDB把数据以BSON这种二进制方式存放在文档中。BSON编码扩展了流行的JSON格式以支持int、long、decimal和date类型。BSON文档包含一个或者多个键，每个键对应一个值。值的类型包含数组、嵌入式文档和二进制数据。文档大概类似于关系型数据库中的行，而键大概类似于关系型数据库中的列。MongoDB一个文档可以包含所有相关的数据，而关系型数据库中相关联的数据通常是在多个表中的多个行里。比如，在关系型数据库中放在两张表中的父子关系这种数据在MongoDB中可以放在一个文档中。
集合很多文档组合在一起就形成了集合。一般来说，一个集合中的所有文档的作用对应用来说都是类似的或者说有相关联系的。集合可以理解为关系型数据库中的表。
动态图表以及文档验证MongoDB的文档在结构上是可以变化的。例如，一张用户表可能包含用户ID以及用户最近登录系统的时间，但是只有一部分文档可能会包含用户的购物地址，有些甚至还包含多个用户购物地址。MongoDB不会强制所有的文档保持同样的结构。因此文档的结构是不需要事先声明的——文档是自描述的。
文档验证功能可以对文档结构、数据类型、数据范围以及字段是否强制存在进行检查，从而允许DBA对数据进行强制性管理。这样一来，DBA就可以管理数据标准，而开发人员就可以享受灵活性文档模型带来多种好处。这些内容在以下博客中有所涉及：《文档验证：》
MongoDB Compass帮助识别有用的验证规则，然后可以在GUI中创建这些规则。
索引MongoDB使用B树索引来优化查询。索引是在文档级别定义的。MongoDB支持很多类型的索引，包括混合索引、地理索引、TTL、文本搜索、偏重索引、唯一所以以及其他的。详情看后文的索引章节。
事务更新操作的原子性会影响你应用的模式设计。MongoDB可以在文档级别保证更新的ACID原则。一个原子操作不可能更新多个文档，但是，和JOIN一样，把关系型数据嵌入到MongoDB文档中就可以解决这种需求。
模式设计的深入详情可以在MongoDB文档中查看Data Modeling Considerations for MongoDB
使用MongoDB Compass可视化模式并增加验证规则MongoDB Compass GUI可以让用户清楚明了的了解数据库中的数据结构，即使不掌握MongoDB的查询语言，也可以对数据进行特定的查询。这些用户通常是创建一个新的MongoDB项目的架构师，或者从开发团队接手过来的已有数据库系统，并且需要在生产环境中维护的。你需要理解数据库中存在哪些数据，怎么定义合适的索引，确认是否需要创建文档验证规则以保证文档结构的一致性。