开发检查清单

数据持久性

• 确保副本集至少包含三个承载数据的有投票权成员，并且写入操作使用 w: majority写关注（write concern）。要实现副本集范围内的数据持久性，需要三个承载数据的有投票权成员。

• 确保所有实例均使用日志。

模式设计

MongoDB 中的数据具有动态模式。集合不强制执行文档结构。这有利于迭代开发和多态性。然而，集合通常包含具有高度同质结构的文档。有关详细信息，请参阅数据建模。

• 确定所需的集合集以及支持查询所需的索引。除 _id 索引外，您必须明确创建所有索引：MongoDB 不会自动创建除 _id 以外的任何索引。

• 确保您的模式设计支持部署类型：如果您计划使用分片集群进行水平扩展，请将模式设计为包含强分片键。虽然您可在后续更改分片键，但请务必仔细考虑分片键的选择，以免出现可扩展性与性能问题。

• 确保您的模式设计不依赖于长度无限制增长的索引数组。通常情况下，当此类索引数组的元素少于 1000 时，性能最佳。

• 在设计模式时，请考虑文档大小限制。BSON 文档大小限制为每个文档 16 MB。如果您需要更大的文档，请使用 GridFS。

复制

• 使用奇数个投票节点，以确保选举成功进行。您最多可以有 7 个投票节点。如果您有偶数个投票节点，并且约束（如成本）禁止添加另一个从节点作为投票节点，则可以添加仲裁节点以确保投票数为奇数。有关对 3 节点副本集 (P-S-A) 使用仲裁节点时的其他注意事项，请参阅副本集仲裁节点。

• 使用监控工具并指定适当的写关注，确保从节点保持最新状态。

• 请勿使用从节点读取来扩展总体读取吞吐量。 请参阅： 我是否可以使用更多副本节点来扩展 了解读取扩展的概述。有关从节点读取的信息，请参阅：读取偏好。

分片

• 确保您的分片键将负载均匀地分布在分片上。有关更多信息，请参阅：分片键。

• 对需要随分片数量扩展的工作负载使用定向操作。

• Secondaries no longer return orphaned data unless using read concern "available" (which is the default read concern for reads against secondaries when not associated with causally consistent sessions).
  All members of the shard replica set maintain chunk metadata, allowing them to filter out orphans when not using "available". As such, non-targeted or broadcast queries that are not using "available" can be safely run on any member and will not return orphaned data.
  The "available" read concern can return orphaned documents from secondary members since it does not check for updated chunk metadata. However, if the return of orphaned documents is immaterial to an application, the "available" read concern provides the lowest latency reads possible among the various read concerns.

• 在将大型数据集插入新的非散列分片集合时，预拆分并手动平衡数据块。预拆分和手动平衡使插入负载能够在分片之间分布，从而提高初始负载的性能。

驱动程序

• 利用连接池化。大多数 MongoDB 驱动程序都支持连接池化。调整连接池大小以适合您的使用案例，从典型并发数据库请求数的 110-115% 开始。

• 确保您的应用程序可以在副本集选举期间处理瞬时写入和读取错误。

• 确保您的应用程序处理失败的请求，并在适用的情况下重试。驱动程序不会自动重试失败的请求。

• 使用指数退避逻辑进行数据库请求重试。

• 如果需要限制数据库操作的执行时间，读取时使用 cursor.maxTimeMS()，写入时使用 wtimeout。