開発チェックリスト

データ耐久性

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

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

スキーマ設計

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

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

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

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

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

複製

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

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

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

シャーディング

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

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

• 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.

• 大規模なデータセットを新しいハッシュされていないシャーディングされたコレクションに挿入するときに、チャンクを事前分割し、手動でバランスをとります。 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を使用します。