Development Checklist
在本页面
以下清单以及Operations Checklist提供了一些建议，以帮助您避免生产 MongoDB 部署中的问题。
Data Durability
-
确保您的副本集至少包含三个带有
w:majoritywrite concern的数据承载节点。为了使副本集具有更广泛的数据持久性，需要三个数据承载节点。 -
确保所有实例都使用journaling。
Schema Design
MongoDB 中的数据具有动态模式。 Collections不强制执行document结构。这有利于迭代开发和多态性。但是，collections 通常持有结构高度统一的文件。有关更多信息，请参见数据建模概念。
-
确定您将需要的集合集以及支持查询所需的索引。除
_id索引外，您必须显式创建所有索引：MongoDB 不会自动创建_id以外的任何索引。 -
确保您的架构设计支持您的部署类型：如果计划使用sharded clusters进行水平扩展，请设计架构以包含强碎片键。分片键通过确定 MongoDB 如何分区数据来影响读写性能。有关分片密钥应具有的质量的信息，请参见：分片键对集群操作的影响。一旦设置了分片键，便无法更改。
-
确保您的架构设计不依赖于长度不受限制地增长的索引数组。通常，当此类索引数组的元素数少于 1000 个时，可以获得最佳性能。
Replication
- 使用奇数个投票成员以确保选举成功进行。您最多可以有 7 个投票成员。如果您有*偶数个投票成员，并且诸如费用之类的限制禁止添加另一个辅助成员作为投票成员，则可以添加arbiter以确保投票的奇数。有关将仲裁器用于 3 成员副本集(P-S-A)的其他注意事项，请参阅复制集仲裁器。
Note
-
通过使用monitoring tools并指定适当的write concern来确保您的辅助服务器保持最新。
-
不要使用辅助读取来缩放整体读取吞吐量。有关读取缩放的概述，请参见：我可以使用更多副本节点进行扩展。有关辅助读取的信息，请参见：Read Preference。
Sharding
-
确保分片密钥在分片上平均分配负载。有关更多信息，请参见：Shard Keys。
-
对于需要随分片数量进行扩展的工作负载，请使用targeted operations。
-
对于 MongoDB 3.4 及更早版本 ，请从主节点读取非目标或 Broadcast查询，因为这些查询可能对陈旧或孤立的数据敏感。
-
对于 MongoDB 3.6 及更高版本 ，除非使用读取关注点"available"(这是与因果一致的会话不关联时针对辅助对象的读取的默认读取关注点)，否则辅助节点不再返回孤立的数据。
从 MongoDB 3.6 开始，分片副本集的所有成员都维护块元数据，从而允许他们在不使用"available"时过滤掉孤立的孤儿。因此，不使用"available"的非目标或 Broadcast查询可以在任何成员上安全运行，并且不会返回孤立数据。
"available"读取关注点可以从辅助成员返回orphaned documents，因为它不检查更新的块元数据。但是，如果孤立文档的返回对应用程序而言并不重要，则"available"读取关注点将在各种读取关注点中提供尽可能低的延迟读取。
Drivers
-
利用连接池。大多数 MongoDB 驱动程序都支持连接池。调整连接池的大小以适合您的用例，从并发数据库请求的典型数量的 110-115％开始。
-
确保您的应用程序在副本集选择期间处理瞬时写入和读取错误。
-
确保您的应用程序处理失败的请求，然后在适用时重试。驱动程序 不 自动重试失败的请求。
-
对数据库请求重试使用指数退避逻辑。
-
如果您需要限制数据库操作的执行时间，请使用cursor.maxTimeMS()进行读取，使用wtimeout进行写入。