MongoDB性能最佳实践（Performance Best Practices for MongoDB）

本文译自："Performance Best Practices for MongoDB"，该E文原文已上传至CSDB（https://download.csdn.net/download/LHDZ_BJ/12761367），以方便各位同学对照学习研究。

一.引言
MongoDB是一款为各种现代应用设计的高性能、可扩展的数据库。各种规模的机构用它来支撑低延迟、高吞吐、连续高可用的在线、可操作、关键的应用系统。
该指导概述了涉及硬件、应用模式、模式设计、索引、磁盘I/O，亚马逊EC2和基准设计等多个关键维度的MongDB系统中，大幅提升性能所应考量的因素，但并非十分详尽。
按照该指导的建议，将会减少遭遇常见性能问题的可能性，但其并不保证应用具备良好的性能。
该指导目标在于指导用户自己管理一切。为作为MongoDB服务的数据库用户提供了专门的指南——MongoDB Atlas最佳实践。MongDB与用户紧密合作以帮助优化他们的系统。用户应该监视系统以鉴别瓶颈和限制。
有各种可用的工具，其中，应用最广泛的是MongoDB Ops Manager和Cloud Manager，将在后面对其进行讨论。
有关MongoDB架构和基本假设的讨论，请看MongoDB Architecture Guide。有关MongoDB系统操作的讨论，请看MongoDB Operations Best Practices。

二.MongoDB插件式存储引擎
MongoDB 3.0公开了一个全新的存储引擎API，这使MongoDB可以扩展具备新功能的插件式存储引擎，并使其能最优利用特定硬件架构。MongoDB提供了多个支持的存储引擎：
1.默认WireTiger存储引擎（WiredTiger storage engine）。对大多数应用，WireTiger的粒度并发控制和内部压缩将为广泛应用提供最全面的性能和存储效率。
2.加密存储引擎（Encrypted storage engine）。保护高度敏感的数据，但不会产生单独文件系统加密导致的性能和管理开销。加密存储引擎基于WireTiger并贯穿该文档，有关WireTiger的语句也适用于加密存储引擎。该引擎为MongoDB Enterprise Advanced的一部分。
3.内存存储引擎（In-Memory storage engine）。为最苛刻的应用程序提供可预测的延迟以及实时分析。该引擎为MongoDB Enterprise Advanced的一部分。
4.MMAPv1存储引擎（MMAPv1 storage engine）。MongoDB3.x之前版本所用存储引擎的改善版本。MMAPv1为MongoDB3.0及更早版本的默认引擎。
这些引擎能够在单个MongoDB复制集中共存，使其易于在复制集内评估和迁移。将已有复制集升级到WireTiger存储引擎并不会造成混乱，应用将100%兼容，通过复制集的滚动升级可使迁移工作的执行达到0宕机时间。
WireTiger为新版MongoDB的默认存储引擎；如果喜欢用另外一个存储引擎，则可以使用--storageEngine选项启动mongod。如果启动3.2（或更高版本）mongod进程，且已存在一个或多个数据库，那么，MongoDB将使用数据库创建时的存储引擎。检查迁移过程相关的检查列表和完全指导。
当针对不同工作负载对每个存储引擎进行优化时，用户将独立于他们使用的引擎对同样的MongoDB查询语言、数据模型、扩展性，安全性和操作工具进行权衡。结果，该指导中最佳实践适用于支持的所有存储引擎。但请注意不同存储引擎间的不同建议。

三.硬件
可以在任何地方运行MongoDB-从ARM（64位）处理器到商用X86 CPU，一直到IBM Power和zSeries平台。多数用户用多个商用服务器形成一个簇来扩展他们的系统。MongoDB提供原生复制来确保可用性；提供自动分片来将数据均匀的分布到多个服务器上；提供内存计算来支持高性能而不必通过单独的缓冲层实现。下列注意事项将有助于用户优化MongoDB系统的硬件。
1.确认RAM能容纳工作集。象大多数数据库一样，当MongoDB工作集（索引和最频繁访问的数据）全部在RAM中时，其运行状态最佳。RAM时最重要的硬件因素；如果没有足够的内存，其他优化措施也许不能大幅的改善系统性能。如果工作集大小超出了单个服务器的RAM大小，考虑将系统分片到多个服务器上去。用db.serverStatus()命令查看当前工作集大评估大小。
2.对写负载重的应用采用SSD。MongoDB中大部分磁盘存取模式是随机的，所以，用户可能通过使用SSD使性能得以大幅提升。通过使用SATA、PCIe和NVMe SSD,获得了良好的性能和性价比。由于MongoDB的随机存取模式，商用SATA机械盘可与昂贵的机械盘媲美：与其将钱花在昂贵的机械盘上，还不如用钱购买更多的RAM或SSD。用SSD的另一个好处是如果内存不能容纳工作集，闪盘相对机械盘的具备良好的性能优势。
当数据文件得益于SSD时，MongoDB的日志文件因为其高速顺序写特性而成为了快速常规磁盘的合适候选。
大多数MongoDB部署使用RAID10。RAID5和RAID6存在限制而也许不能提供足够的性能。RAID0提供好的读写性能，但容错能力不足。MongoDB的复制集允许部署提供较强的数据可用性，应该与RAID和其他因素一起考虑以达到希望的可用SLA。
3.为存储和I/O敏感的工作负载配置压缩。当用WireTiger存储引擎时，MongoDB内部支持压缩。压缩最多可以减少80%的存储占用，支持较高的IOPscas以从磁盘读取较少的字节。使用任何压缩算法时，管理员将在存储效率和CPU开销间权衡，因此，测试具体环境中压缩的影响至关重要。MongoDB为管理员提供了文档和索引相关压缩选项。默认的Snappy压缩算法提供了高的文档和日志压缩率（典型70%左右，依赖数据类型）与低CPU开销间的平衡，虽然可选的zlib库获得较高的压缩率，但当数据从或向磁盘读写时将消耗额外的CPU。索引默认使用前缀压缩，这将减少索引存储的内存占用，为频繁访问的文档释放更多的RAM。测试显示用前缀压缩算法典型达到50%的压缩率，虽然建议用户用自己的测试集进行测试。管理员能修改所有集合和索引的默认压缩设置。集合和索引创建其间，也可以为每个集合和索引配置压缩设置。
4.结合多种存储和压缩类型。MongoDB提供管理数据生命周期的功能，包括活动索引时间（Time to Live indexes）和上限集合（capped collections）。另外，通过使用MongoDB域（Zones），管理员能建立高效、多层的存储模型来支持数据生命周期。通过将分片分配给域，管理员能在查询延迟与存储密度和基于类似时间戳的一个值将数据集分配至特定存储设备的成本间进行权衡：
1）最近的、频繁被访问的数据能被分配至高性能SSD，且开启Snappy压缩。
2）旧的、较少被访问的数据被标记到低吞吐的硬盘，且采用zlib压缩以较低的每位成本获得最大存储密度。
3）当数据变旧时，MongoDB自动在存储层迁移数据，无需管理员建立工具或ETL过程来管理数据移动。
5.为较快的CPU分配CPU硬件预算。MongoDB在较快的CPU上将交付较好的性能。MongoDB WireTiger存储引擎比MMAPv1存储引擎能较好的利用多核心处理资源。
6.为每个服务器分配单一系统角色。为了最佳性能，用户应该每个主机上运行一个mongod进程。使用虚拟或容器技术时通过合理的规模和资源分配，多个MongoDB进程可以在单个服务器上运行而不会发生资源冲突。
如果使用WireTiger存储引擎，管理员将需要对每个进程应该使用多少缓存合适进行评估，并为它们将默认缓存进行拆分，以便为每个实例计算合适的缓存大小。WireTiger缓存的大小可以通过设置storage.wireTiger.engineConfig.cacheSizeGB进行调整，且应该足以容纳整个工作集。如果缓存没有足够空间来加载另外的数据，WireTiger将从缓存中驱逐数据页来释放空间。默认地，storage.wireTiger.engineConfig.cacheSizeGB设置为可用RAM的60%-1GB；应该注意的是，当增大该值时由于其从OS获取资源，因为文件系统缓冲变的低效而导致WireTiger性能实际会下降。
为了可用性，同一复制集的多个成员不应该共享同一物理硬件或类似电源的任何单一失败点。
7.用多个查询路由器。将多个mongos进程分布到多个服务器上。一个常见的部署方式是将mongos进程部署在应用服务器上，其允许应用和mongos进程间进行本地通信。mongos的合理进程数依赖于应用和部署的特征。
8.利用多个核心。WireTiger存储引擎为多线程，能充分利用多CPU核心的优势。特别是，与CPU数相关的活动线程（例如：并发操作）总数能影响性能：
1）当并发活动操作数达到或超过CPU数时，吞吐量将增加。
2）当并发活动操作数超过CPU数的某个阀值后，吞吐量将降低。该阀值依赖于应用。通过实验和测量吞吐量和延迟，您可以决定应用相关的最优并发活动操作数。由于并发模型的因素，MMAPv1存储引擎并不需要太多CPU核心。同样，增加核心数能有所帮助，但并不会带来太大性能提升。
9.禁用NUMA。在NUMA系统上运行MongoDB能引起一系列操作问题，包括阶段性降低性能和过高使用系统进程。当在NUMA硬件上运行MongoDB和客户端时，应该配置内存交错策略，以便主机表现的象非NUMA硬件那样。
10.簇内网络压缩。作为分布式数据库，MongoDB查询路由和节点间复制期间依赖高效的网络传输。MongoDB3.4引进了一个新选项，其将会对簇内通信的线路协议进行压缩。基于Snappy压缩算法，网络交通能被最大压缩到70%，为带宽有限的环境提供重大的性能收益，并减少网络开销。压缩默认是关闭的，但能通过将networkMessageCompressors设置为snappy将其开启。压缩和解压缩网络交通需要CPU资源——典型的，会降低单个位的百分比开销。压缩对带宽导致性能瓶颈而CPU资源充足的环境会比较理想。

四.应用模式
因为其动态模式和丰富的查询模型，MongoDB为一款非常灵活的数据库。系统支持大量的第二索引功能以优化查询性能。为了正确权衡他们的应用，用户应该考虑系统的灵活性和复杂性。下列考量将有助于优化用户应用模式。
1.只对已变化的域发布变更。应用中不是获取整个文档，变更域，接着将文档保存回数据库，而是对特定域发变更。这会较少使用网络和减少数据库开销。
2.查询中避免非运算。象大多数数据库系统一样，MongoDB并不会对缺失的值进行索引，非运算条件也许会需要扫描所有文档。如果非运算是唯一条件且没有很好的选择性（例如：查询一张订单表中未完成的订单，该表中99%的订单已完成），将需要扫描所有的记录。
3.尽可能的使用覆盖查询。覆盖查询直接从索引返回结果而无需访问文档，因此会非常高效。为了使一个查询被覆盖，查询包含的所有域必须存在一个索引中，且查询返回的所有域也必须存在于该索引中。为了决定一个查询是否是一个覆盖查询，使用explain()方法。如果explain()输出显示indexonly域为true，则该查询被一个索引覆盖，MongoDB则只查询该索引以匹配
该查询和返回其结果。
4.用explain()测试应用中的每个查询。MongoDB支持执行计划功能，其显示一个查询被解析的相关信息，包括：
1）被返回的文档数。
2）被读取的文档数。
3）使用哪些索引。
4）该查询是否为覆盖查询，其意味着为了返回结果无需读取文档。
5）是否执行一个内存排序，其指示使用一个索引将是有好处的。
6）扫描的索引项数。
7）解析该查询需要多少毫秒（当使用executionStats模式时）。
8）拒绝了哪些可选的执行计划（当使用allPlansExecution模式时）。
如果解析查询耗时不到1毫秒，执行计划将显示0毫秒，这将典型出现于调整很好的系统中。当执行计划被调用时，先前被缓冲的查询计划被废弃，重复测试多个索引以确保使用最好可能的执行计划。查询计划能被计算和返回而无需首先运行该查询。这是DBA们无需等该查询运行完成，就能审查执行该查询时将使用哪个执行计划。
MongoDB Compass支持将执行计划可视化的共鞥，提供一个查询如何执行的关键信息——例如：返回的文档数，执行时间，索引使用等更多信息。执行管道的每个阶段用树中的一个节点表示，这将使得分布于多个节点（服务器）的查询的执行计划浏览起来变得简单。
5.避免分散-聚集（scatter-gather）查询。分片系统中，不能路由到单个分片的查询必须被广播到多个分片进行评估。因为这些查询每个请求涉及到多个分片，他们并不会因为增加更多的分片而进行很好的扩展。
6.选择合理的写保证（write guarantees）。当对数据库发布些操作时，MongoDB允许管理员确定持久保证的级别，这被称为写关系（write concern）。下列选项能对每个连接、每个数据库、每个文档，或者甚至每个操作进行配置。这些选项如下所示：
1）Write Acknowledged：这是默认写关系。mongod将会确认写操作的执行，允许客户端捕获网络、重复键、文档校验和其他例外。
2）Journal Acknowledged：mongod仅在已将写操作刷出到主库日志中时才会确认写操作。这将确认mongod崩溃时写操作能幸存，并将保证写操作永久写入磁盘。
3）Replica Acknowledged：mongod也可能等待其他复制集成员对写操作的确认。MongoDB支持对特定数目的副本进行写操作。这也确保对日志的写操作成功写入其他服务器。因为副本能被部署到数据中心的不同机架和数据中心，确保写到另外的副本能提供非常健壮的持久性。
4）Majority：该写关系等待写操作被应用于大部分复制集成员。这也确保写操作被这些副本的日志记录——包括主库。
5）Data Center Awareness：通过标签集，能创建高级策略来确保成功确认前数据写入确定的副本组合。例如：您可以创建一个策略，要求数据至少写入两个洲的三个数据中心，或确定数据中心的不同机架的两个服务器。
更多内容参考有关Data Center Awareness的MongoDB文档。
7.除非您能容忍最终一致性，否则只从主库读取。更新操作通常会很快复制到其副本，这主要由网络延迟决定。然而，副本上读取的数据可能与主库上读取的不一致。注意，由于副本必须处理来自主库的所有写操作，因此，它们并非空闲。为了增加系统的读取能力，可以考虑分片技术。因为读取副本能把读取和更新操作隔离开，因此，其对分析和ETL应用来说非常有用。
8.选择正确的读关系（read-concern）。为了确保隔离和一致性，readConcern能被设置为majority来指示，只有数据被复制到复制集的大多数节点后才能被返回到应用，并在失败事件中不能被回滚。MongoDB3.4增加了一个"线性化（Linearizable）"读关系级别。该线性化读关系确保当数据读取时一个节点还是主库，如果随后另一个节点被选举为新的主库，则前者返回的数据不能被回滚。配置该读关系级别对延迟会有重大影响，所以，为了使长期运行的操作超时，应该提供一个maxTimeMS值。
9.用来自MongoDB的最新驱动。MongoDB支持十几种语言的驱动。这些驱动由维护数据库核心的同一团队提供。驱动比数据库更新更频繁，一般每两个月更新一次。总是尽可能的用最新的驱动。如果您所用语言的驱动可用，请安装本地扩展（native extension）。加入MongoDB社区邮件列表以跟踪更新。
10.确认分片键的统一分布。当读写操作的分片键不被统一分布时，单个分片的能力也许会限制该操作。当分片键统一分布时，则没有单个分片会限制系统能力。
11.合理利用基于哈希的分片。对发布基于范围查询的应用，基于范围的分片是最佳的，因为操作能被路由到必须的、最少的分片上，通常是一个分片上。但是，基于范围的分片需要对数据和查询有很好的理解，有些场景中，这也许是不太现实的。基于哈希的分片确保读写操作的统一分布，但其并不支持高效的基于范围的操作。

五.模式设计&索引
MongoDB使用基于称作BSON的二进制文档数据模型，而BSON基于JSON标准。不像关系库中的扁平表，MongoDB文档数据模型与现代编程语言中的对象紧密一致，因为实体或对象的相关数据被包含在一个文档内，所以，多数场景中它移去了复杂事务和连接的必要，而非将这些相关数据扩散至多张表。有将数据模型建为文档的最佳实践，其正确方法取决于应用目标。下面的考量将帮助您为应用设计模式和索引时做出正确的选择。
1）将一条记录的所有数据存储到一个文档中。MongoDB在文档级别支持ACID兼容性。当一条记录的数据被存储在已个文档中时，整条记录通过一次寻址操作就能获取，这会非常高效。有些场景中，把所有数据存储到一个文档中可能不太现实，或者这将对其他操作造成影响。权衡对您的应用最有利的方案。
2）避免很大的文档。MongoDB中文档的最大大小为16MB。实际上，大多数文档几KB或更小。考虑文档更像表中的数据行而非表本身。与其在单个文档中维护数条记录，不如每个文档存储一条记录。对大型媒体项目，象视频或图像，考虑用GridFS，多数驱动实施的自动通过诸多小文档存储二进制数据的常规方法。
3）避免无限的文档增长——MMAPv1。当文档在MongoDB MMAPv1存储引擎中被修改时，如果有足够的空间，则数据在原地被修改。如果文档比已分配的空间大，则文档也许需要写在一个新的位置。移动文档和更改其相关索引的过程可能是I/O密集的，并可能会对性能造成不必要的影响。为了预测未来的增长，每个集合的usePowerOf2Sizes属性默认被开启。该设置自动配置MongoDB将分配大小四舍五入为2次幂。该设置以另外空间减小了增加磁盘I/O的机会。
一个另外的策略是手工填充文档，以为文档增长提供足够的空间。如果应用以可预测的方式向文档中增加数据，可以在知道数据值前在文档中创建域，以便在文档创建期间为文档分配合适的空间。填充文档将文档重定位最小化，所以，也最小化了过度分配。通过审查文档中的记录分配策略可以了解更多。
避免无限文档增长是任何数据库的一个最佳实践模式设计，但上述考虑与默认WireTiger存储引擎无关，因为每次更改其将会重写文档。
4）避免大型索引数组。与其将大量数据项存在一个索引域中，不如将一组数据值存入多个域中。这样，更改将是更高效的。
5）避免不必要的长域名。域名在文档中重复存储并消耗空间。通过用小的域名，您的数据将消耗较少的空间，这样，RAM就可以容纳大量的文档。注意，通过WireTiger的本地压缩，长域名对磁盘空间消耗会有较少影响，但同样会对RAM造成影响。
6）谨慎在低基数域上建索引。低基数域上的查询会返回巨大结果集。尽可能的避免返回巨大结果集。复合索引也许包括低基数值，但组合域的值应该有高基数。
7）消除不必要的索引。索引是资源密集的：即使对索引开启了压缩，它们依然会消耗内存，当修改域值时，其相关的索引也必须被维护，从而引起另外的磁盘I/O开销。
8）移除为其他索引前缀的索引。复合索引能用于索引先导域上的索引。例如：(last name,first name)上创建的复合索引也能用于过滤仅用last name过滤的查询。该例子中，没必要只在(last name)另外再创建一个索引，使用复合索引而非索引交集。为了通过多个谓词查询达到最佳性能，复合索引通常为较好的选项。
9）用部分索引。通过只包含要通过索引访问的部分文档来降低索引大小和提升性能。例如：在orderID域上创建一个只包含orderStatus为“In progress”订单文档部分索引，或者，只索引emailAddress域值存在的文档。
10）避免未左锚定或无根的正则表达式。先导通配符是低效的，而且可能会导致全索引扫描。如果表达式有足够的大小写敏感的先导字符，则尾部通配符是高效的。
11）使用WireTiger存储引擎中可用的索引优化。象之前讨论的，WireTiger存储引擎默认会压缩索引。另外，管理员也可以将索引放至单独的卷，这将允许较快的磁盘换页和较低的冲突。
12）理解任何存在的文档模式——MongoDB Compass。如果已有需要理解和优化的MongoDB，那么MongoDB Compass就是珍贵的工具。MongoDB Compass GUI允许用户理解数据库中已有数据的结构并对其进行特别查询——可以对MongoDB查询语言一无所知。通过理解现在有什么种类的数据，您可以较好决定什么索引是合理的。如果没有Compass，用户希望理解他们的数据模型，则必须连接到MongoDB shell并写查询来对文档结构、域名和数据类型进行逆向工程。MongoDB Compass包含在MongoDB Professional和MongoDB Enterprise Advanced中。
13）识别和移除废弃的索引。为了理解正被使用的现存正用索引的效率，一个$indexStats聚合阶段能被用于决定每个索引的使用频率。MongoDB Compass可视化索引覆盖，使您能决定索引包含哪些特定域，它们的类型，大小，以及如何使用它们。

六.磁盘I/O
当MongoDB通过内存中数据结构进行读写操作时，数据被持久化都磁盘，对不在RAM中数据的读取会触发磁盘读取操作。结果，存储子系统的性能是任何系统的一个关键方面。当性能是系统的一个主要目标时，用户应该谨慎使用高性能存储并避免使用网络存储。下面考量将帮助您使用最佳存储配置，包括OS和文件系统设置。
1.WiredTiger的预读大小应该设置为0。当用WiredTiger存储引擎时，用blockdev --setra <value>命令将预读块大小设置为0。当用MMAPv1存储引擎时，32（16KB）的预读值通常会运行良好。
如果预读大小比请求的数据大很多，则将从磁盘上读取一个很大的块——因为MongoDB中大部分磁盘I/O是随机的，因此，这将是个浪费。这将会有两个性能方面不希望出现的负面影响：
1）读取数据的大小将消耗不必要的消耗RAM。
2）读数据消耗了不必要的时间。
2.用EXT4或XFS文件系统；避免使用EXT3。EXT3很旧且对大多数数据库负载并非最优。例如：MMAPv1预分配数据空间。EXT3中，预分配将实际向磁盘写0来分配空间，这会很耗时。EXT4和XFS中，预分配被作为一个逻辑操作执行，其更加高效。
对WiredTiger存储引擎来说，强烈推荐使用XFS来避免以往WiredTiger上用EXT4出现的性能问题。
3.禁用访问时间设置。大多数文件系统将维护文件最后访问的元数据。这也许对有些应用会有用，数据库中，这意味着每次数据库访问一个数据页，文件系统将发布一个写操作，这将会给系统性能和吞吐带来负面影响。
4.不要用大页（Huge Pages）。不要用大页虚拟内存页，MongoDB在常规虚拟内存页上运行的较好。
5.使用RAID10。大多数MongoDB部署应该使用RAID10。RAID5和RAID6有限制且也许不会提供足够的性能。RAID0提供好的读写性能，但不能提供足够的容错。MongoDB的复制集允许部署提供较强的数据可用性，应该与RAID和其他因素一起考虑以满足渴望的可用性SLA。
通过为日志和数据文件提供单独的设备，您可以增加磁盘子系统的整体吞吐。因为日志文件的磁盘I/O倾向于顺序的，SSD也许并不能提供大的性能提升，而标准机械盘也许有更好的性价比。
Use RAID10. Most MongoDB deployments should use
6.为不同的数据库使用多个设备-WiredTiger。设置directoryForIndexes以便索引存储于不同于集合的单独目录，设置directoryPerDB以便每个数据库使用不同的目录。然后，各种目录可以映射到不同的存储设备，这样，增加了整体吞吐。
注意，使用不同的存储设备将会影响您为数据创建快照类备份的能力，因为文件在不同的设备和卷上。
7.用MongoDB Zones实施多温度存储和数据位置。MongoDB Zones（较早的MongoDB版本中描述为标签识别的分片）允许对数据物理存储位置进行精确控制，以适应某些部署场景——例如：通过地理，通过硬件配置，或通过应用。管理员通过修改分片键范围来连续调优数据存放规则，MongoDB将自动迁移数据到它的新域（Zone）。MongoDB3.4在Ops Manager和Cloud Manager中新加了帮助功能和另外的选项，以对域（Zones）进行配置，这对管理大型部署是有必要的。

七.基准考量
通用基准能是技术及其针对特定应用执行情况的误导和歪曲。MongoDB反而推荐用户通过代表他们意向应用系统的数据、查询、硬件和其他方面，来为应用建模和基准测试。下列考量将帮助您开发对应用有意义的基准。
1）根据您的应用为基准建模。您在基准测试练习中测试的查询、数据、系统配置和性能目标，应该反映您的产品系统的目标。不能反映您的产品系统的测试假设可能会产生误导结果。
2）加载或用基于哈希的分片前创建块。如果范围查询是您的基准测试的一部分，那么，使用基于范围的分片并在加载前创建块。没有预拆分，数据也许加载进一个分片，然后，随着加载进行，再移到一个不同的分片。
通过预分片数据，文档将被并行加载到合适的分片。如果您的基准测试并不包括范围查询，您能用基于哈希的分片来确保写操作的统一分布。
3）批量加载禁用平衡器。批量加载期间，禁用平衡器来阻止不必的再平衡以提高性能。
4）花几分钟准备系统。生产系统中，MongoDB系统工作集应该全部放入RAM，所有的读写都将在RAM内执行。MongoDB必须首相将工作集放入RAM，因此，运行测试以得到MongoDB生产库运行状况的精确指标前，花几分钟时间用代表性的查询准备系统。
5）监控所有因素以定位性能瓶颈。理解基准测试的瓶颈很重要。根据很多因素，整个系统的任何组件都可能成为限制因素。各种流行的工具能用于MongoDB——手册中列出了很多工具。
监控MongoDB最全面的工具是Ops Manager，其作为MongoDB Enterprise Advanced的一部分。富有特色的图表、定制仪表盘和自动告警，Ops Manager跟踪100多个关键数据库和系统指标，这些指标包括操作计数、内存、CPU利用率、复制状态、打开连接、队列和节点状态。指标被安全的传给Ops Manager进行处理、汇聚、更改并在浏览器中可视化，以便管理员能容易的、实时的确定MongoDB的健康状况。Ops Manager的好处是也可用于基于Saas的Cloud Manager，用于MongoDB运行于云环境的场景。运行MongoDB Enterprise Advanced的机构能为他们的部署选择Ops Manager或Cloud Manager。
从MongoDB3.4开始，Ops Manager允许遥测数据每个10秒进行收集，之前的最小间隔为60秒。
除了监控，Ops Manager和Cloud Manager提供自动化部署、升级、在线索引创建和跨分片在线备份。
6）分析。MongoDB支持叫做数据库分析器（Profiler）的功能，其记录细粒度的数据库操作的信息。分析器能对所有事件或期间超过配置阀值（默认为100毫秒）的那些事件开启记录日志信息。分析数据存储于限定（capped）集合中，其中，可以容易的对相关事件进行查找。查询该集合也许比分析日志文件更容易些。当分辨慢查询时，MongoDB Ops Manager和Cloud Manager能被用来可视化分析器的输出信息。
Ops Manager和Cloud Manager包括一个可视化查询分析器（Visual Query Profiler），其可以为操作组和DBA们提供一种分析特定查询或查询组的快速便捷的方式。可视化查询分析器显示查询和写延迟如何随着时间而发生变化——这使得鉴别使用常见存取模式和特征的慢查询及任何延迟峰值变得简单。通过单击Ops Manager用户界面可以激活分析器，接着，其将在一屏中整合和显示每个节点的指标。
可视化分析器分析数据——推荐另外的索引并可以通过自动的、滚动索引的方式添加它们。
MongoDB Compass可视化索引覆盖，使您能确定哪些特定的域被索引，它们的类型、大小，以及这些索引被使用的频率。
7）使用mongoperf描述存储系统。
mongoperf是一款免费、开源工具，通过它用户可以模拟直接磁盘I/O和内存映射I/O、线程数目的可配置选项、文档大小及其他因素。该工具能帮助您理解针对系统上磁盘受限的I/O和内存映射的I/O，
可能发生什么类型的吞吐。
8）遵照配置最佳实践。
审查MongoDB产品有关包、硬件、网络和操作系统调整最近指导的注意。

八.MongoDB Atlas：作为MongoDB服务的数据库
MongoDB Atlas支持MongoDB所有的特性，而新应用无需哪些繁重的操作。MongoDB Atlas可以通过随用随付的模式按小时计费，从而让您专注于最擅长的事儿。
开始是容易的——用简单的GUI选择所需实例大小、区域和特性。MongoDB Atlas可以提供：
1.为访问您数据提供保护的安全特性。
2.复制always-on可用，整个数据中心失败容错。
3.备份和时间点恢复以对数据崩溃提供保护。
4.细粒度监控以便您知道扩容时间。按下按钮即可添加额外实例。
5.数据库自动打补丁和单击升级新主版本，使您利用最新最好的MongoDB特性。
6.自由选择云提供商、区域和支付选项。
MongoDB Atlas功能强大。从快速的概念验证，到测试/QA环境，再到完成生产环境集群它都非常棒。如果您决定重新控制业务，可以很容易的将数据库移到您自己的基础架构，并通过MongoDB Ops Manager或MongoDB Cloud Manager进行管理。用户对MongoDB Atlas、Cloud Manager和Ops Manager的使用经验是一致的，如果您决定迁移到您自己的基础架构，保证影响是最小的。
MongoDB Atlas是自动化的、容易的，这来自MongoDB的创造者。了解更多信息，试试吧。
本文主要面向管理他们自己MongoDB实例的人们，MongoDB Atlas有关的性能最佳实践将在单独的文档描述——MongoDB Atlas最佳实践（MongoDB Atlas Best Practice）。

九.我们提供的帮助
我们是MongoDB专家。2000多个机构依赖我们的商业产品，包括创业和超过一半的财富100强机构。我们提供软件和服务让您的生活更容易:
MongoDB Enterprise Advanced是在您的数据中心运行MongoDB的最好方式。它是为您的业务设计的、精心调整的高级软件、支持、认证和其他服务的包。
MongoDB Atlas是作为MongoDB服务的数据库，其让您专注于应用而非操作（ops）。通过MongoDB Atlas，您可以通过方便的小时计费模式购买您所需要的。只需点击按钮，就可以按需扩展和缩小数据库规模，同时零宕机时间，绝对安全，且高性能。
MongoDB Cloud Manager是基于云的管理工具，其可以帮您管理自己基础架构中的MongoDB。具备自动补充配置、细粒度监控和连续备份功能，您可以获得一套完整的管理工具，当其完全控制您的数据库时可以减少操作开销。
MongoDB Professional帮助您管理部署和保持平稳运行。其包括来自MongoDB工程师的支持，以及对MongoDB Cloud Manager的访问。
Development Support帮助您快速启动和运行。其为您提供项目早期阶段的软件和服务的完整包。
MongoDB Consulting包帮您快速投产，帮您调整产品性能，帮您扩容，并把您解放出来以专注下一个版本。
MongoDB Training帮您变为一名MongoDB专家，从设计到操作大规模重大关键系统。
无论您时开发人员、DBA，还是架构师，我们都能让您更擅长MongoDB。