Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-29116

Issue with $geoNear optimizations

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Incomplete
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Aggregation Framework, Geo
    • Labels:
      None
    • Operating System:
      ALL
    • Steps To Reproduce:
      Hide

      Mongo Version 3.2.x
      Create a collection with 100 documents with location field (spread randomly within the city)
      Add a field say 'status' - 'active' to only one document.
      Create 2dsphere index
      Do $geoNear aggregation query with $match (

      {status: 'active'}

      ), $sort pipelines after $geoNear with radius 50 Kms
      Do this query repeatedly for locations within 100 km range of city.
      The document is not listed in all places within the circle of radius 50kms from the point of interest.

      Show
      Mongo Version 3.2.x Create a collection with 100 documents with location field (spread randomly within the city) Add a field say 'status' - 'active' to only one document. Create 2dsphere index Do $geoNear aggregation query with $match ( {status: 'active'} ), $sort pipelines after $geoNear with radius 50 Kms Do this query repeatedly for locations within 100 km range of city. The document is not listed in all places within the circle of radius 50kms from the point of interest.

      Description

      We had our server running Mongo v3.0 and $geoNear worked fine.
      When we have upgraded it to Mongo v3.2 and we started getting issues with $geoNear.

      Our application has some Point of Interests spread throughout the city kept in a collection with 2dsphere index. We query the DB using aggregation query with $geoNear as mentioned below.

      [ {
         '$geoNear': {
            near: [ lng, lat ], 
            distanceField: 'distance',
            spherical: true,
            num: 10000,
            maxDistance: 0.007848061528802385,
            query: {
               status: 'active',
               'location.geofence': {
                  '$exists': false }
            }    
         }
      }
      , {
         '$match': {
            '$or': [ {
               name: {
                  '$regex': 'search', '$options': 'i' }
            }, { 
               'location.locality': {
                  '$regex': 'search', '$options': 'i' }
            }, { 
               keywords: {
                  '$regex': 'search', '$options': 'i' }
            }
            ] }
      }
      , {
         '$project': {
            _id: 1,
            name: 1,
            rating: '$ratings.overall',
            'location.locality': '$location.locality',
            'location.coordinates': '$location.coordinates',
            'location.coords': '$location.coords',
            distance: '$distance' }
      }
      , {
         '$sort': {
            distance: 1 }
      }
      ]
      

      This query is supposed to get all the point of interests within a radius of 50 Kms. But when I simulate the user's location and run the queries, I get a plot as given below.

      Though there are multiple documents distributed throughout the city, there is only one document matching the above query whose location is marked by Blue dot. And the matrix shows the customer locations with green dot where the document is returned and red dot where the document is not returned for the query. So clearly point of interest is shown in places which are 49 kms away and sparsely populated documents but not within 10 kms away and densely populated documents.

      This seems to have introduced because of the optimizations mentioned here
      https://www.mongodb.com/blog/post/geospatial-performance-improvements-in-mongodb-3-2

        Attachments

          Activity

            People

            Assignee:
            mark.agarunov Mark Agarunov
            Reporter:
            manikandan.citeee@gmail.com Manikandan TS
            Participants:
            Votes:
            0 Vote for this issue
            Watchers:
            7 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: