目前，在一个我们所有内容实体都存储在MongoDB中的部署应用程序中，我们正在使用内置的Mongo geoNear 命令来收集所有具有给定半径内的lat和lon属性的实体。然后将此数据集馈送到并行搜索模块中，并根据用户的查询进行过滤。目前的性能足够强大，可以处理该应用程序迄今为止的流量水平。
所使用的基本方法与10gen在Mongo网站上的方法完全相同：
http://www.mongodb.org/display/DOCS/Geospatial+Indexing/
这种方法内置了一些问题，我了解到10gen正在解决这些问题。
如何对MongoDB GeoNear结果按距离之外的其他内容进行排序？
https://jira.mongodb.org/browse/SERVER-1982
考虑到开发团队的增长，该客户正在考虑对此功能的数据架构进行改进，以使代码更加直观易懂。在了解完所有情况后，他们有兴趣将方法更改为范围查询，因为他们对于将这个相对较新的Mongo功能作为我们架构的核心组件持怀疑态度（因为它获取了所有其他过滤器应用的第一个有限数据集）。
我很好奇是否有任何强大的替代方案。作为负责开发此部分逻辑的人，我可以想出一些替代方案，但只能猜测它们的优缺点。在Google搜索后，我找到了以下内容：
- 将对象本身存储在Mongo中，然后在支持空间索引的SQL服务器上将其ObjectIds与它们的空间坐标相关联。我喜欢这种方法将所有空间数据放在单个索引中，但是这里丰富的SQL人才倾向于MySQL，从文档中看来，它对空间索引的实现似乎像mongo一样是一个事后的想法。此外，据我所知，我们将被固定在MyISAM表上。
- 就专用于SQL的空间解决方案而言，我在网上找到的文档最多的是Postgres和PostGIS。目前，我们所做的只是使用haversign距离计算进行半径搜索，因此这个方案的一个优点是支持使用向量和多边形进行更高级别的限制，也许允许我们在未来扩展到基于区域的限制。主要的局限性在于我们没有内部Postgres人才，我不确定这是否需要招聘新员工。
- 查看其他NoSQL解决方案，将位置元数据嵌入其中。Neo4j在这方面似乎承诺很多：http://www.oscon.com/oscon2011/public/schedule/detail/19822 文档中给出了一些引人注目的例子。
我很好奇是否有任何实现空间索引作为核心任务的键值存储解决方案？如果没有，什么样的方法对于职责分离和最大可维护性是最推荐的？