2d 인덱스는 구형 쿼리 자체를 지원하기 때문에 성능 문제가 크므로 주로 2dsphere 인덱스를 사용하여 두 번째 결과를 봅니다.

쿼리 설명 결과로 볼 때 정상적으로 작동하는 것으로 나타났습니다. 아래 그림에서 원은 쿼리의 maxDistance이고, 사각형은 데이터를 읽는 위치입니다. 사진의 좌표는 GPS 좌표입니다. 데이터가 화성 좌표인 경우 표시되는 위치가 편중됩니다.

이 1km 범위에서는 데이터 분포가 매우 집중되어 있지만 초기 지점에서 멀리 떨어져 있을 수 있습니다. $nearSphere가 처음에 지점 밀도를 추정하고 주변 데이터를 찾을 수 없으면 maxDistance로 확장됩니다. 이에 대한 특별히 좋은 해결책은 없습니다. 가능한 해결책은 일반 쿼리의 성능도 저하시킵니다. 이를 확인하려면 MongoDB Compass를 다운로드하고 loc의 데이터 분포를 살펴보는 것이 좋습니다. 아니면 반경 5km 이내의 위치 데이터를 공개할 수 있다면 로컬에서 재현해 문제가 어디에 있는지 파악할 수 있다. 일반적으로 쿼리 시작점의 분포가 데이터 분포와 유사하면 결과는 평균적으로 그렇게 극단적이지 않습니다.

마지막으로 explain의 쿼리는 30개로 제한되지 않고 1개로 제한되지만 문제의 성격은 동일해야 합니다. 사용하신 버전은 직접 컴파일한 것이며, 2dshpere 관련 코드에는 변경사항이 없어야 합니다.

우리는 항상 코드를 직접 컴파일해 왔습니다. 이 버전은 2d 또는 2dsphere 인덱스 관련 로직을 수정하지 않았습니다.
맞습니다. 저희 추적 코드 로직에서도 쿼리 지점에서 약간 떨어진 곳에 밀집 지점이 있다는 사실을 발견했습니다. 단계 크기를 늘리는 알고리즘은 너무 거칠고 최대 단계 크기로 직접 점프합니다.
추출된 데이터를 제공받을 수 있는지 신청을 해봐야 하는데 큰 문제는 되지 않습니다.
저는 몽고 나침반을 사용해 본 적이 없습니다. 정말 놀라운 도구입니다. 사용해 보겠습니다.
한도 1과 한도 30의 문제는 제가 자료를 수집할 때 게시한 진술의 실수로 인한 것일 수 있습니다. 그러나 두 가지를 모두 테스트했는데 결과는 비슷했습니다.
실제로 퍼지 근사 알고리즘을 위한 인터페이스를 열어 사용자가 엄격한 정확성을 포기하도록 선택할 수 있도록 허용하면 성능이 기하급수적으로 향상되는 것을 고려할 수 있습니다. 이것이 우리가 가지고 있는 최적화 아이디어입니다