短いアクセス時間は、コストと利益の関数です。まず、どれだけ低いかを特定する必要があります。アプリ全体で 100 ミリ秒の応答時間が必要ですか? または1s？
完了したら、さまざまなコストを計画します。
Total time taken = time for request + //across internet
processing by web app + request for data +
preparing the response + response back to client.
希望するレイテンシーが 100 ミリ秒の場合、サーバーの速度に関係なく、ネットワーク トラフィックに時間がかかりすぎる可能性があるため、それを実行できない可能性が高くなります。
データセットを分析する必要があります。1000 のドキュメントをクエリすることは、10 億のドキュメントをクエリすることとは異なります。インデックスが使用しているサイズを計算する必要があり、それが RAM 内にあるかどうか。インデックスが RAM にない場合、アクセスが遅くなります。
Mongodb 構成
Mongodb はクラスター内で動作し、自動同期 (即時または遅延、構成可能) と自動フェイルオーバー (または手動、これも構成可能) を使用できます。データセットが巨大な場合はシャーディングもサポートするため、リクエストは実際にデータを含むサーバーに送信されます。
同様に、アプリケーション サーバーを調べて、保証された応答時間を得るために、コンポーネントがどの程度遅い/速いかを把握する必要があります。
あなたが提供した情報で、これは私ができる限り詳細な回答です。
プロファイリングしてから最適化する
リクエストの 80% が中東からのものである場合は、まずそれらを迅速に処理する必要があります。同じ原則を使用して、応答時間が最も遅いコンポーネントを見つけ出し、それらを改善する必要があります。そのためには、データを収集する必要があります。
クラスタリング
1 つの大陸または複数の大陸にクラスターをセットアップすると、冗長性、自動フェイルオーバー (構成されている場合)、および負荷分散 (構成方法によって異なります) を提供するのに役立ちます。大量のデータがある場合は、シャーディングを検討してください。
レプリケーションとシャーディングのドキュメントを参照することを検討してください。
サーバーのセットアップ例
レプリケーション係数が 3 の 10 個のシャードが必要だとします。つまり、データが 10 台のサーバーに分割され、各サーバーは実際には 3 台のサーバーのレプリカ セットです (可用性とフェールオーバーのため)。つまり、レプリカ セットの各サーバーには重複データが含まれます。
ここで、s1p1 という表記は、シャード 1 - プライマリ 1、s1s1 はシャード 1、セカンダリ 1 などを意味します。
s1p1 s2p1 ... s10p1
s1s1 s2s1 ... s10s1
s1s2 s2s2 ... s10s2
シャード 1 ～ 10 はデータを分割し、各シャードは合計の約 1/10 を保持します。各シャードは、プライマリと 2 つのセカンダリを含むレプリカ セットで構成されます。さらに冗長性が必要な場合は、これを増やすことができます。奇数に保つようにしてください。選挙中にはタイ ブレーカーがあります。データのコピーを 2 つだけにしたい場合は、「アービター」を導入して引き分けにすることもできます。
クエリを分析し、最も近いサーバーまたはリージョンにサービスを提供するサーバーにアクセスするようにシャード キーを選択できます。このビットを最適化するには、おそらく何らかの分析を行う必要があります。
それが役に立てば幸い。