title: Alternative to MongoDB's GeoNear
body: <p>Currently, in one deployed application in which all our content entities are stored in MongoDB, we are using the built in Mongo <code>geoNear</code> command to collect all the entities who have <code>lat</code> and <code>lon</code> properties within a given radius.  This data set is then fed into a parallelized search module and filtered per a user's query.  Performance is strong enough for the traffic levels the app has had thus far.</p>
  
  <p>The really basic approach used is exactly what 10gen has on the Mongo site:</p>
  
  <p><a href="http://www.mongodb.org/display/DOCS/Geospatial+Indexing/" rel="nofollow noreferrer">http://www.mongodb.org/display/DOCS/Geospatial+Indexing/</a></p>
  
  <p>The approach has a few issues built in that I understand 10gen are currently working out.</p>
  
  <p><a href="https://stackoverflow.com/questions/5503562/sorting-mongodb-geonear-results-by-something-other-than-distance">Sorting MongoDB GeoNear results by something other than distance?</a></p>
  
  <p><a href="https://stackoverflow.com/questions/9782080/can-geonear-in-mongodb-return-a-subset-of-fields-in-a-document">Can geoNear in MongoDB return a subset of fields in a document?</a></p>
  
  <p><a href="https://jira.mongodb.org/browse/SERVER-1982" rel="nofollow noreferrer">https://jira.mongodb.org/browse/SERVER-1982</a></p>
  
  <p>The client in question is considering a revamp of the data architecture of this feature as the development team grows, to make the code within a little more intuitive for the new developers.  After having everything explained, they are interested in changing the approach to ranged queries since they are hesitant about making this relatively new feature in Mongo such a core component in our architecture (since it gets the first limited set of data on which all other filters are applied)</p>
  
  <p>I am curious if there are any strong alternatives.  As the person who will be tasked with developing this portion of the logic, I can think of a few, but I can only guess at their strengths/weaknesses.  After googling around this is what I've come up with:</p>
  
  <ol>
  <li><p>Store the objects themselves in Mongo, then associate the ObjectIds with their spatial coordinates in SQL tables on a SQL server that support spatial indexing.  I like that this approach will place all the spatial data in a single index, but the SQL talent that is abundant here leans towards MySQL, whose implementation of Spatial indexing seems, from the docs, to be an afterthought much like the one in mongo.  Also, as far as I know, we will then be fixed solely to MyISAM tables.</p></li>
  <li><p>As far as dedicated spatial solutions over SQL go, the one I can find the most documentation on the web for is Postgres with PostGIS.  Currently, all we are doing is radius search using haversign distance calculation, so one of the strengths of this would be support for more advanced limiting using vectors and polygons, perhaps allowing us in the future to scale up to something like region-based limiting.  The main limitation here is that we have no in house Postgres talent at all, and I am not certain if this would necessitate a new hire or not.  </p></li>
  <li><p>Look at a different NoSQL solution for the objects themselves, and leave the location metadata embedded within them.  Neo4j seems to promise a lot in this department:
  <a href="http://www.oscon.com/oscon2011/public/schedule/detail/19822" rel="nofollow noreferrer">http://www.oscon.com/oscon2011/public/schedule/detail/19822</a>  There are certainly some compelling examples given in the documentation.</p></li>
  </ol>
  
  <p>I am curious if there is any kind of key-value storage solution that implements spatial indexing as a core mission objective?  If not, what approach would be the most recommended for good separation of responsibilities and max maintainability?</p>