高密度クラスター下の地理クエリは最新の 30 レコードを返しますが、20,000 レコードをスキャンする必要があります。
同じ点セットに対して、2d インデックスと 2dsphere インデックス クエリを作成してみます。実行効率はそれほど変わりません。
ステートメント1の実行環境
{
リーリー ＃＃＃}＃＃＃さよなら＃＃＃ステートメント2の実行環境
2dsphere インデックス
MongoDB シェル バージョン: 3.2.8
接続先: 10.108.93.135:7004/admin
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
2d インデックスは球状クエリ自体をサポートしていますが、パフォーマンスに大きな問題があるため、主に 2dsphere インデックスを使用して 2 番目の結果を確認します。
クエリの Explain 結果から判断すると、正常に動作しています。以下の図では、円はクエリの maxDistance で、四角はデータが読み取られる場所です。画像内の座標はGPS座標です。データが火星座標の場合、表示される位置は偏ります。
この 1 キロメートルの範囲では、データの分布が非常に集中している可能性がありますが、$nearSphere が最初にポイント密度を推定し、その周囲のデータが見つからない場合、maxDistance まで拡張されます。これに対する特に良い解決策はありません。考えられる解決策も通常のクエリのパフォーマンスを低下させます。これを確認するには、MongoDB Compass をダウンロードし、loc のデータ分布を確認することをお勧めします。あるいは、半径 5 キロメートル以内の位置データを公開できれば、それをローカルで再現して、どこに問題があるのかを把握できます。一般に、クエリの開始点の分布がデータの分布と類似している場合、平均して結果はそれほど極端ではありません。
最後に、Explain のクエリは制限 30 ではなく制限 1 ですが、問題の性質は同じであるはずです。使用しているバージョンは自分でコンパイルしたものであり、2dshpere 関連のコードに変更はありません。
私たちは常にコードを自分たちでコンパイルしてきました。このバージョンでは、2d または 2dsphere インデックス関連のロジックは変更されていません。
おっしゃるとおり、トラッキング コード ロジックでは、クエリ ポイントからわずかに離れたところに密集したポイントがあることも検出しました。ステップ サイズを増加させるアルゴリズムは乱暴すぎて、最大ステップ サイズに直接ジャンプします。
抽象化されたデータを与えることができるかどうかを確認するために申請する必要がありますが、大きな問題ではありません。
mongo compass を使ったことはありません。とても素晴らしいツールです。試してみます。
制限 1 と制限 30 の問題は、データ収集時に投稿したステートメントの見落としが原因である可能性があります。ただし、両方をテストしましたが、結果は同様でした。
実際、ファジィ近似アルゴリズムのインターフェイスを開くことを検討して、ユーザーが厳密な正確性を放棄することを選択できるようにすることで、パフォーマンスの指数関数的な向上につながります。これが私たちの最適化アイデアです