目前，在一个部署的应用程序中，我们所有的实体内容都存储在MongoDB中，我们使用的是内置的蒙戈geoNear命令收集所有谁具有给定半径内lat和lon性质的实体。然后将此数据集输入并行化的搜索模块，并根据用户的查询进行过滤。性能足以满足该应用程序迄今为止的流量级别。替代MongoDB的GeoNear
使用的真正的基本方法是什么10gen公司对蒙戈网站：
http://www.mongodb.org/display/DOCS/Geospatial+Indexing/
该方法具有内置的，我明白10gen公司目前正尝试的几个问题。
Sorting MongoDB GeoNear results by something other than distance?
Can geoNear in MongoDB return a subset of fields in a document?
https://jira.mongodb.org/browse/SERVER-1982
有问题的客户正在考虑这一功能的数据架构的改造作为开发团队的成长，使内更直观一点的代码新的开发者。在解释了所有内容之后，他们有兴趣改变范围查询的方法，因为他们对Mongo中的这个相对较新的特性犹豫不决，因为它在我们的体系结构中是一个核心组件（因为它获得了所有其他过滤器的第一个有限数据集应用）
我很好奇，如果有任何强有力的选择。作为负责开发这部分逻辑的人员，我可以想到几个，但我只能猜测他们的优缺点。后解决此谷歌搜索是我想出：
存储的对象在蒙戈自己，那么用的ObjectID在SQL Server上的SQL表的空间坐标，支持空间索引关联。我喜欢这种方法将所有的空间数据放在一个单一的索引中，但是这里丰富的SQL人才倾向于MySQL，从文档看来，空间索引的实现看起来很像mongo中的那种。另外，据我所知，我们将只修复MyISAM表格。至于专门的SQL解决方案空间解决方案，我可以在网上找到大多数Postgres和PostGIS的文档。目前，我们所做的全部工作都是使用横坐标距离计算进行半径搜索，因此其中一个优势是支持使用向量和多边形进行更高级的限制，这可能使我们在将来可以扩展到基于区域的限制。这里主要的限制是我们根本没有Postgres的内部人才，而且我不确定这是否会需要新雇用。
查看对象本身的不同NoSQL解决方案，并将位置元数据嵌入其中。 Neo4j似乎在这个部门承诺很多： http://www.oscon.com/oscon2011/public/schedule/detail/19822在文档中肯定有一些引人注目的例子。
我很好奇，是否有任何一种键值存储解决方案实现空间索引作为核心任务目标？如果不是，那么最好的方法是什么方法来完善职责分工和最大可维护性？