「長すぎる」の長さは非常に相対的である可能性があるため、どれくらいの長さかを知っておくと便利です。また、実行しているバージョンと、実行しているハードウェアの種類を知ることも役立ちます。
ただし、上記の情報だけを考えると、潜在的な速度低下の 1 つは、
collection.EnsureIndex(IndexKeys.GeoSpatial("PlacePoint"));
コレクションにインデックスを作成するのは一度だけなので、すべてのクエリの前にそれを実行しているようです。
次のように、mongo シェルからコマンドを実行してみてください (もちろん、プレースホルダーを実際の値に置き換えてください)。
db.runCommand( { geoNear: "<collectionName>", near: [<lon>,<lat>], num: <num>, spherical:true } )
次に、「統計」情報を見て、何か問題があるかどうかを確認します。私は個人的に、地理空間インデックスを含む 234107 の場所を含むコレクションを持っており、コレクション内のどの場所からも意図的に離れた座標を使用して geoNear コマンドを実行し、すべての場所を確実にスキャンできるようにしました。次の結果が得られました (適度に強力なハードウェアでバージョン 2.2.3 を実行: Core i5、16 GB RAM、7200 RPM HDD - 緯度/経度ポイント + 少量の追加データで構成されるかなり小さなドキュメントで構成されるデータ セット):
"stats" : {
"time" : 261,
"btreelocs" : 0,
"nscanned" : 234107,
"objectsLoaded" : 133,
"avgDistance" : 1.380670166668938,
"maxDistance" : 1.3807179692447809
},
私のコレクション内の場所に近いクエリで、次の結果が得られました。
"stats" : {
"time" : 15,
"btreelocs" : 0,
"nscanned" : 6211,
"objectsLoaded" : 29,
"avgDistance" : 0.003811909711576418,
"maxDistance" : 0.003919781450489085
},
ここでの「時間」はミリ秒単位であり、私には非常に合理的です。C# で GeoNear 関数を実行すると、常にほぼ瞬時に返されるので、C# ドライバーの非効率性が原因で結果が遅くなるとは思いません。