開発チェックリスト

データ耐久性

• レプリカセットには少なくとも 3 つのデータを保持する投票ノードが含まれていること、および書込み (write) 操作がw: majority書込み保証 ( write concern ) を使用していることを確認します。 レプリカセット全体のデータ耐久性には 3 つのデータを保持する投票ノードが必要です。

• インスタンスがすべてジャーナリングを使用しているようにします。

スキーマ設計

MongoDBのデータには動的スキーマがあります。コレクションはドキュメント構造を強制しません。これにより、反復的な開発と多形データが容易になります。それにもかかわらず、コレクションには多くの場合、高度に同種の構造を持つドキュメントを保持します。詳細については、MongoDBのデータモデリングを参照してください。

• クエリをサポートするために必要なコレクションのセットと必要なインデックスを決定します。 _idインデックスを除くすべてのインデックスを明示的に作成する必要があります。MongoDB は_id以外のインデックスを自動的に作成しません。

• スキーマ設計が配置タイプをサポートしていることを確認します。水平スケーリングにシャーディングされたクラスターを使用する場合は、強力なシャードキーを含めるようにスキーマを設計します。 シャードキーは後でも変更できますが、スケーラビリティやパフォーマンスの問題を回避するために、シャードキーの選択を慎重にすることが重要になります。

• スキーマ設計が、長さが無制限に増加するインデックス付き配列に依存していないことを確認してください。 通常、このようなインデックス付き配列の要素が1000未満の場合に最高のパフォーマンスを得ることができます。

• スキーマを設計する際には、ドキュメント サイズの制限を考慮してください。 BSON ドキュメント サイズの制限は 1 ドキュメントあたり16 MB です。 より大きなドキュメントが必要な場合は、 GridFS を使用します。

複製

• 選挙が正常に機能するようにするには、奇数の投票メンバーを使用します。 最大7の投票メンバーを含めることができます。 投票メンバーの数が偶数で、コストなどの制約により投票メンバーになる別のセカンダリの追加が禁止される場合は、アービタを追加して奇数の投票数を確保できます。 3メンバーのレプリカセット（PSA）にアービタを使用する際の追加の考慮事項については、「レプリカセット アービタ 」を参照してください。

• 監視ツールを使用し、適切な書込み保証 ( write concern) を指定して、セカンダリが最新の状態に保たれるようにします。

• 全体的な読み取りスループットを増やすには、 セカンダリ読み取り を使用しないでください。読み取りスケーリングの概要については、「 より多くのレプリカノードを使用して増やすできますか 」を参照してください。セカンダリ読み取りの詳細については、読み込み設定 (read preference) を参照してください。

シャーディング

• シャードキーがシャードに負荷を均等に分散していることを確認します。 詳細については、「シャードキー」を参照してください。

• シャードの数に応じてスケーリングする必要があるワークロードには、ターゲット操作を使用します。

• 読み取り保証 (read concern) )"available" を使用しない限り、セカンダリで 孤立したデータ が返されなくなりました（これは 因果整合性のあるセッション に関連付けられていない場合の、セカンダリに対する読み取りに関するデフォルトの読み取り保証 (read concern)）。

  シャードレプリカセットのすべてのノードは チャンクメタデータを保持し、 を使用していない場合に 孤立した状態"available" をフィルタリングで除外できるようにします。そのため、 を使用していない、非ターゲット "available"クエリまたはブロードキャスト クエリはどのノードでも安全に実行でき、孤立したデータが返されることはありません。

  "available"読み取り保証 (read concern) は、アップデートされたチャンク メタデータをチェックしないため、セカンダリ メンバーから孤立したドキュメントを返す可能性があります。 ただし、孤立したドキュメントが返されるかどうかがアプリケーションにとって重要でない場合は、さまざまな読み取り保証の中で"available"読み取り保証で読み取りのレイテンシが最低となります。

• 大規模なデータセットを新しいハッシュされていないシャーディングされたコレクションに挿入するときに、チャンクを事前分割し、手動でバランスをとります。 Pre-splitting and manually balancing enables the insert load to be distributed among the shards, increasing performance for the initial load.

ドライバー

• 接続プーリング を使用する。 ほとんどの MongoDB ドライバーは接続プーリングをサポートしています。 接続プールのサイズをユースケースに合わせて調整し、データベースの同時リクエストの通常数の110 - 115 % から開始します。

• レプリカセットの選挙中に、アプリケーションが一時的な書込みエラーと読み取りエラーを処理していることを確認します。

• アプリケーションが失敗したリクエストを処理していることを確認し、該当する場合は再試行します。 ドライバーは失敗したリクエストを自動的に再試行しません。

• データベース リクエストの再試行には 指数バックオフ ロジック を使用します。

• データベース操作の実行時間を制限する必要がある場合は、読み取りにはcursor.maxTimeMS()を使用し、書込みにはwtimeoutを使用します。