MongoDB操作最佳实践(二)

MongoDB部署前的准备

 

MongoDB可拔插存储引擎

MongoDB公开了存储引擎API，支持集成可插入存储引擎，这些可插入存储引擎使用新功能扩展MongoDB，并且支持优化使用指定的硬件体系结构。MongoDB 这艘船拥有多个支持的存储引擎：

• 默认的 是WiredTiger存储引擎。对于大多数应用程序，WiredTiger的粒度并发控制和本地压缩将为最广泛的应用程序提供最佳的综合性能和存储效率。

• Encrypted存储引擎，保护高度敏感的数据，没有单独的文件系统加密的性能或管理开销。Encrypted存储引擎是基于WiredTiger的，因此在整个文档中，关于WiredTiger 也适用于加密的存储引擎。该引擎是MongoDB企业版的高级部分。

 

• In-Memory存储引擎，为最苛刻的应用程序提供可预测的延迟和实时分析。该引擎是MongoDB企业版的高级部分。

 

• MMAPv1存储引擎，是在3.x MongoDB版本之前使用的存储引擎的改进版本。MMAPV1是MongoDB 3.0和更早的默认存储引擎。

MongoDB允许用户在单个MongoDB集群中混合使用多个存储引擎。这种混合提供了一种更简单可靠的方法来满足不同应用程序对数据的需求。传统上，需要多个数据库管理技术和复杂的定制集成代码在技术之间移动数据，来满足这些需求，并确保一致的安全访问。虽然每个存储引擎都针对不同的工作负载进行了优化，但是用户仍然利用相同的MongoDB查询语言、数据模型、伸缩性、安全性和操作工具，而不依赖于他们使用的引擎。因此，本指南中的大多数最佳实践都适用于所有支持的存储引擎。存储引擎介绍中的任何差异都会被标识出来。

在单个MongoDB副本集中混合多种存储引擎还使得他们的评估和迁移变得容易。对WiredTiger存储引擎的升级对现有副本集部署没有任何破坏性；应用程序将100%兼容，并且通过滚动升级MongoDB副本集，可以在零停机时间下执行迁移。WiredTiger是MongoDB 3.2之后的版本部署的默认存储引擎；如果要使用其他引擎， 使用--storageEngine选项启动mongod。如果一个3.2+ mongod的进程已经启动，并且已经存在一个或多个数据库，那么它将使用创建这些数据库时候的存储引擎。

 

设计模式

开发人员和数据架构师应该一起工作来开发正确的数据模型，并且他们应该在项目的早期投入时间在这个练习中。应用程序的需求应该驱动MongoDB系统的数据模型、更新和查询。给定MongoDB的动态模式，开发人员和数据架构师可以在整个开发和部署过程中继续迭代数据模型，以优化性能和存储效率，以及支持添加新的应用程序特征。所有这些都可以在没有昂贵的模式迁移的情况下完成。

 

模式设计的主题是有意义的，在此充分的讨论超出了本指南的范围。网上有许多资源，包括MongoDB解决方案架构师和用户的会议介绍，以及MongoDB大学提供的基于网络的免费培训。要记住的关键设计模式概念如下。

 

文档模型

MongoDB将数据存储为称为BSON的二进制表示形式的文档。BSON编码扩展了流行的JSON表示方法，包含了一些其他类型，如int、long、decimal和date。BSON文档包含一个或多个文件，每个文件包含指定数据类型的值，包括数组、子文档和二进制数据。将文档(document)看成大致等同于关系数据库中的行，而将field看成大致等同于列，这可能是有帮助的。然而，MongoDB文档倾向于在单个文档中具有给定对象的所有相关数据，而在关系数据库中，数据通常在许多表中的行之间进行规范化。例如，属于两个RDBMS表中的父子关系的数据常常可以折叠（嵌入）到MongoDB中的单个文档中。对于操作应用，文档模型在许多情况下使得join操作显得多余。

集合(Collections)

集合是文档的组合。通常，一个集合中的所有文档都有相似或相关的用途。可以将集合看作类似于关系数据库中的表。

动态模式与文档验证

MongoDB文档可以在结构上有所不同。例如，描述用户的文档可能都包含用户id和他们登录到系统的最后日期，但是其中只有一些文档可能包含用户的发货地址，并且其中一些文档可能包含多个发货地址。MongoDB并不要求所有文档都符合相同的结构。此外，不需要向系统声明文档的结构——文档是自描述的。

文档验证允许DBA通过检查文档结构、数据类型、数据范围和强制字段的存在来加强数据治理。因此，DBA可以应用数据治理标准，而开发人员则保持了弹性文档模型的优点。这在博客文章Document Validation: Adding Just the Right Amount of Control Over Your Documents(ps：这里理论上应该有链接的，但是下载的文档中没看到链接)中有所介绍。

MongoDB指南帮助识别有用的验证规则，然后可以在GUI中创建这些规则。有关更多详细信息，请参阅Visualizing your Schema and Adding Validation Rules: MongoDB Compass(ps：此处应该有链接)。

索引

MongoDB使用B-tree索引来优化查询。索引是在集合的文档字段上定义的。MongoDB包含了对多种索引的支持，包括复合索引、地理空间索引、TTL索引、全文索引、稀疏索引、部分索引、唯一索引等等。有关更多信息，请参见下面的索引部分。

事务

更新的原子性可能会影响应用程序的架构。MongoDB保证了在文档级别的数据ACID特性。在一个原子操作中更新多个文档是不可能的，但是与JOIN一样，在许多情况下，将相关数据嵌入MongoDB文档的能力消除了这种需求。对于确实需要自动更新多个文档的用例，可以在应用程序中实现两阶段提交逻辑。

有关模式设计的更多信息，请参阅MongoDB文档中的DataModeling Considerations for MongoDB(ps：此处应该有链接)。

 

可视化架构并添加验证规则：MongoDB Compass

MongoDB Compass GUI可以使用户理解数据库中现有数据的结构，并对它执行特殊查询——即使对MongoDB的查询语言一无所知。典型的用户可能包括构建新的MongoDB项目的架构师或从工程团队继承了数据库、现在必须在生产中维护数据库的DBA。您需要理解存在哪种类型的数据，定义哪些索引可能是合适的，以及确定是否应该添加文档验证规则以强制执行一致的文档结构。

图1：视图模式和交互式构建和执行带有MongoDB Compass的数据库查询

如果没有MongoDB Compass，希望理解其数据形状的用户必须连接到MongoDB Shell，并编写查询语句来反向设计文档结构、文件名和数据类型。类似地，任何希望对数据运行定制查询的人都需要理解MongoDB的查询语言。

MongoDB Compass通过从集合中采样文档的子集为用户提供MongoDB模式的图形视图。通过使用采样，MongoDB Compass最小化了数据库开销，并且可以几乎立即向用户呈现结果。

文档验证允许DBA通过检查文档结构、数据类型、数据范围和强制字段的存在来加强数据治理。验证规则现在可以从 Compass GUI管理。规则可以直接使用简单的点和单击界面创建和修改，并且任何违反规则的文档都可以清楚地显示。然后，DBA可以使用Compass的CRUD支持来对单个文档中的数据质量问题进行修正。

文档大小

MongoDB中的最大BSON文档大小为16 MB。用户应该避免某些允许文档无限增大的应用模式。例如，在电子商务应用程序中，很难估计每个产品可能从客户那里收到多少评论。此外，通常情况下，仅向用户显示评论的子集，例如最流行的或最近的评论。与其将产品和客户评论建模为单个文档，不如参考产品文档将每个评论或评论组建模为单独的文档；同时还将关键评论存储在产品文档中以便快速访问。

GridFS

对于大于16MB的文件，MongoDB提供一个名为GridFS的约定，由所有MongoDB驱动程序实现。GridFS自动将大数据划分为多个256KB大小的片，称为块，并维护所有块的元数据。GridFS允许检索单个块以及整个文档。例如，应用程序可以在视频中快速跳转到指定的时间戳。GridFS经常被用来存储MongoDB中的大型二进制文件，如图像和视频。