同じレプリカセット上のコレクションは、リソースをめぐって競合するときにパフォーマンスのボトルネックが発生する可能性があります。データが使用可能なメモリを超えると、ディスク I/O が増加するとレイテンシが発生し、システム リソースに負担がかかり、アプリケーション全体のパフォーマンスが低下します。クラスター内の専用シャードでコレクションを分離すると、これらのリソース制約が軽減され、アプリケーションの単一の接続点が維持されます。
コレクション分離のメリット：
ワークロードの分離 - コレクションを特定のシャードに割り当てることで、リソースの競合を防ぎます。
ハードウェアの最適化 - 特定のコレクション要件に合わせてカスタマイズされたハードウェアを使用して、の非対称シャードを構成します。
独立したスケーリング -ワークロードの増加に基づいてコレクションを個別にスケーリングします。
回復力の向上 - 潜在的な障害を分離することで、リカバリ時間を短縮します。
使用ケース moveCollection
コレクションの要件が次のように異なる場合に、専用シャードでコレクションを移動することは特に役立ちます。
要件 | 説明 |
|---|---|
アクセス パターン | コレクションの中には、読み取りが多いコレクションもあれば、書込みが多いコレクションもあります。 |
パフォーマンス | 特定のコレクションは、他のコレクションよりも多くのRAM、CPU、またはディスクスループットを必要とします。 |
スケーラビリティの要求 | 急増パターンまたは予測できない増加パターンを持つコレクションには専用のハードウェアが必要です。 |
特定の要件を満たすために必要なハードウェアを備えたシャードにコレクションを割り当てることで、操作を簡素化しながらパフォーマンスが最適化します。
シャーディングされていないコレクションの移動タイミング
MongoDB 8.0 以降、 の移動可能なコレクションを使用すると、シャーディングされていないコレクションをクラスター内の任意のシャードに戦略的に配置できます。以前は、シャーディングされていないコレクションはデータベースのプライマリシャードに制限されていたため、リソースのボトルネックが生じていました。コレクションを移動すると、ワークロードを中断することなくシャーディングされていないコレクションを再配置できるため、水平スケーリングが簡素化されます。
すべてのコレクションをシャーディングする必要はありませんが、シャーディングされたクラスターを配置すると、シャーディングされていないコレクションでも水平スケーリングの利点が得られます。このアプローチにより、すべてのデータアクセスに対して単一の接続点が維持され、アプリケーションアーキテクチャが簡素化されます。
次のシナリオでは、シャーディングされていないコレクションをシャード間で移動することでメリットが得られます。
ワークロードの分離
複数のコレクションが同じクラスター内で異なるワークロードを提供する場合、シャーディングされていないコレクションを異なるシャードに移動すると、リソースの競合を防ぐのに役立ちます。これにより、あるワークロードのパフォーマンスが他のワークロードに悪影響を与える問題が排除されます。
マルチテナント アーキテクチャ
異なるテナントのコレクションをホストする環境では、MongoDB の moveCollection コマンドにより、ダウンタイムなしでシャード間でのコレクションのシームレスな分散が可能になります。この柔軟性により、各テナントの特定のニーズに基づいてリソース割り当てが最適化されます。
地理データ分散
組織は、データ所有権規則に準拠するために、ユーザー データを特定の地理的リージョンに保存する必要がある場合があります。moveCollection を使用すると、シャーディングされていないコレクションを異なるリージョンのシャードに配置し、規制要件の進化に合わせて再ロケーションできます。
コスト最適化
MongoDB 8.0 より前は、データベース内のすべてのシャーディングされていないコレクションはプライマリシャードに制限されていました。この制限により、多くの場合、より大きくコストの高いインスタンス階層へのアップグレードが強制されます。MongoDB 8.0 ではこの制約が取り除かれ、シャーディングされていないコレクションをクラスター内の利用可能なすべてのシャード間で移動できるようになります。
シャーディングされていないコレクションを非対称シャードハードウェアに移動すると、リソースの最適化に大きなメリットが得られ、特定のコレクションを要件に合わせてカスタマイズされハードウェアに配置できます。コレクションを適切なハードウェアリソースに一致させることで、実際の需要に基づいてさまざまなワークロードを個別に増やすできます。この ターゲット アプローチ により、パフォーマンスが向上し、クラスター全体でリソースが過剰にプロビジョニングされるコストを回避できます。
コレクション密度の削減
MongoDBでは、インスタンスごとのコレクション数にハード制限はありませんが、ノードが管理するコレクションとインデックスが多すぎるとパフォーマンスが低下します。これらの制限の詳細については、 MongoDB Atlas のコレクションとインデックスの制限 を参照してください。
シャーディングされていないコレクションを異なるシャードに分散することで、アプリケーションの統合アクセス点を維持しつつ、任意の単一ノードでコレクション密度を削減できます。
戦略的なコロケーション
クロスコレクショントランザクションや結合操作などの分散操作を最小限に抑えるために、シャーディングされていないコレクションを同じシャードに共存させることを検討してください（$lookup）。関連する操作を 1 つのシャードに限定して使用すると、ネットワークのオーバーヘッドが排除され、レイテンシが排除され、全体的なパフォーマンスが向上します。このアプローチは、同じトランザクション内で頻繁に結合されたりアクセスされたりするコレクションに特に効果的です。
コマンド構文
sh.moveCollection("database.collection", "shardName")
次の例では、4 つのシャーディングされていないコレクションを2 つのシャード間で移動し、コレクションを等しく分散しています。
db.adminCommand({moveCollection:"E", toShard: "shard1"})
の使用を避ける場合 moveCollection
moveCollection は大幅な柔軟性を提供しますが、最適なソリューションではない可能性がある特定のシナリオがいくつかあります。
大規模なコレクション
コレクションが単一のシャードでは大きすぎる場合は、moveCollection を使用しないでください。コレクションのサイズが 3 TB に達した場合は、コレクションのシャーディングを検討してください。
Atlas Search インデックスを持つコレクション
特定のコレクションが Atlas Search を使用する場合は、 がmoveCollection 再シャーディング を使用して別のシャードにコレクションを書き換えることに注意してください。コレクションを 移動した後、その Atlas Searchインデックスを手動で再構築する必要があります。インデックスが完全に再構築されるまで、Atlas Search 機能はこの特定のコレクションで使用できなくなりますが、アプリケーションの残りの部分は正常に機能します。
moveCollection を使用する前に、アプリケーションの要件に対してこれらの制限を評価して、適切なソリューションであるかどうかを判断してください。