部署策略

在计划部署 MongoDB 时，您需要考虑几个关键方面。 最重要的是当前和预期的数据集大小。 这两个方面是您选择各个物理节点资源需求的主要驱动因素，同时也是制定分片计划的参考依据。 此外，还需要考虑数据的重要性以及对数据丢失或滞后可能性的容忍度（特别是在复制场景中）。

内存大小

MongoDB（与许多面向数据的应用程序一样）在数据集保留在内存中的情况下工作得最好。 没有什么性能比不需要磁盘 I/O 的 MongoDB 实例更好。 尽可能选择具有比工作数据集大小更多可用 RAM 的平台。 如果数据集超过单个节点的可用 RAM，请考虑利用分片。 分片可增加集群中可用 RAM 的数量，以容纳更大的数据集， 从而最大限度地提高部署的总体性能。 缺页故障可能指示即将超过部署中的可用 RAM。 您需要考虑增加可用 RAM。

磁盘类型

如果不考虑速度，或者如果拥有的数据集大于可用内存策略可以支持的大小，那么有适合您部署的磁盘类型非常重要。 IOPS 是选择磁盘类型的关键。 IOPS 越高，MongoDB 的性能越好。 如果本地磁盘在可能的情况下需要被用作网络存储器，就会导致部署等待时间长、性能不佳。 建议将 RAID 10 用作磁盘阵列。

CPU

如果要使用 map-reduce，那么应考虑时钟速度和可用处理器数。 但是，运行 MongoDB 实例时，如果大部分数据位于内存中，时钟速度会影响性能。 如果您的系统在这种情况下运行，并希望最大限度地提高每秒运行次数，则应考虑采用包括高时钟总线速度 CPU 的部署策略。

复制

复制可以在集群中一个节点出现故障时，提供数据的高可用性。 为了获得最佳结果，请在任何 MongoDB 部署中至少使用三个节点进行复制。 复制三个节点的最常见配置是 2x1 部署，即在单个数据中心中有两个主节点，备份服务器位于辅助数据中心。

分片

[: #dbt-sharding]

如果预计会有大型数据集，建议您部署分片的 MongoDB 部署。 您可以使用分片在多个节点之间对数据集进行分区。MongoDB 可以在集群中的节点之间自动分发数据。 或者，可以定义分片键，然后为该键创建基于范围的分片。 分片有利于提高写入性能，因此就算数据集很小，但如果需要大量更新或插入操作，也可以进行分片。 部署分片集时，MongoDB 只需要三个配置服务器实例，这些实例是专用 Mongo 运行时，可跟踪当前的分片配置。 其中一个节点的丢失会导致群集进入配置的只读模式，并要求在进行任何配置更改之前恢复所有节点的联机。

写安全方式

您有多个用于编写安全方式的选项，这些安全方式用于管理 MongoDB 如何处理数据到磁盘的持久性。 重要的是考虑哪种策略最适合数据完整性和性能需求。 下面是可用的写安全方式：

• None- 提供一种非阻塞的延迟写入策略，有助于提高性能。 但是，节点故障和数据丢失是一个小问题。 写入集群中一个节点的数据也可能无法立即在该集群的所有节点上实现读取一致性。 “无”方式并未针对网络故障提供任何数据保护。 这种方式非常不可靠，仅当性能优先并且不需要考虑数据完整性时才可使用。
• 正常 - 这是 MongoDB 的缺省值。 正常模式也是一种非阻塞延迟写入策略。
• Safe- 在 MongoDB 确认收到写入请求之前阻塞，但在写入完成之前不阻塞。 在“安全”方式下，集群内的数据完整性和读一致性水平更高。
• 日志安全 - 为 MongoDB 提供恢复选项。 日志安全模式确保数据得到确认，日志更新完成后才会返回。
• Fsync - 提供最高级别的数据完整性和阻塞，直到执行数据物理写入为止。 使用 Fsync 会使性能降级，因此仅当数据完整性是应用程序的主要考虑因素时才可使用。

测试部署

10gen 有多种工具可帮助您对部署执行负载测试。 benchRun,控制台工具可在 JavaScript 测试线束中运行操作。benchRun 返回操作信息和每个操作的延迟数。 如果需要有关 MongoDB 实例的更多详细信息，请考虑在测试期间运行 mongostat 命令或 MMS 来监视部署。

安装植入

安装可帮助创建稳定且面向性能的解决方案的 MongoDB 时，您有几个注意事项。10gen 建议您尽可能使用 CentOS (64 位)。 避免部署在 32 位操作系统和 Windows 操作系统上。 这些系统提供的部署平台很差。32 位操作系统的文件大小限制会造成问题，如果操作系统使用虚拟内存来弥补部署中内存的不足，Windows 可能会导致性能问题。 缺省情况下，IBM Cloud 为所有工程服务器部署提供 CentOS 64 位操作系统。

此外，请确保对基本操作系统安装进行以下更改，以最大限度地提高性能：

• 将 SSD 预读的缺省值设置为 16 个块 - SSD 驱动器的搜寻时间非常出色，使“预读”缩小为 16 个块。 旋转磁盘可能需要略微缓冲，所以这类磁盘设置为 32 个块。
• noatime - noatime 无需系统将正在读取的文件写入文件系统。 这意味着文件访问速度更快，磁盘磨损更少。
• 在 BIOS 中关闭 NUMA Linux、NUMA 和 MongoDB通常不能一起工作。 如果要在 NUMA 硬件上运行 MongoDB，建议将 NUMA 关闭（使用 interleave 内存策略运行）。 如果不这样做，那么可能会出现速度大幅下降或系统 CPU 时间长等问题。
• 设置 ulimit - 对于打开文件数，ulimit 设置为 64000，对于用户进程数，ulimit 设置为 32000。 这些 ulimit 可防止因可用文件句柄数或用户进程数丢失而导致的故障。
• 使用 ext4 - Ext3 分配文件（或除去文件）的速度慢。 此外，ext3 的大型文件访问性能不佳。

默认情况下，这些更改会在所有 IBM Cloud 服务器上设置。

此外，建议日志卷和数据卷位于不同的物理卷。 如果日志目录和数据目录位于一个物理卷上，那么对日志执行清空会导致 MongoDB 部署中发生数据访问中断和延迟时间峰值。

操作

将 MongoDB 部署提升到生产环境后，请考虑以下建议以进行监视和性能优化。

• 确保 MMS 代理程序正在 MongoDB的所有实例上运行，这有助于监视部署的运行状况和性能。 MMS 代理程序在支持交互期间会向 10gen 提供有用的调试数据。
• mongostat 命令还提供有关 {{site.data.keyword.mongobd}} 节点性能的运行时信息。

如果这些工具中的任何一个工具发现性能问题，可以通过分片或索引来帮助更正这些性能问题。

• 如果监控工具显示基于字段的查询运行不佳，则为 MongoDB 部署创建索引。 为了帮助提高性能，请在查询基于不同字段的数据时始终使用索引。
• 当节点的整体性能因运行数据集过大而受到影响时，可使用分片。 确保在达到阈值之前分片。 仅对于插入或更新操作上的分片，系统会拆分区块。 如果等待分片的时间过长，可能会出现分布不均的问题。