MongoDB的替代方案'；s GeoNear

目前，在一个部署的应用程序中，我们的所有内容实体都存储在MongoDB中，我们使用内置的Mongo

geoNear

命令来收集给定半径内具有

lat

和

lon

属性的所有实体。然后将该数据集输入并行搜索模块，并根据用户的查询进行过滤。性能足以满足该应用迄今为止的流量水平

使用的真正基本方法正是10gen在Mongo站点上的做法：

据我所知，10gen目前正在解决一些内置问题

随着开发团队的发展，有问题的客户正在考虑对该特性的数据体系结构进行改进，以使新开发人员对其中的代码更加直观。在解释了所有内容之后，他们对改变范围查询的方法很感兴趣，因为他们对在Mongo中将这一相对较新的功能作为我们架构中的核心组件犹豫不决（因为它获得了应用所有其他过滤器的第一组有限数据）

我很好奇是否有强有力的替代方案。作为负责开发这部分逻辑的人，我可以想到一些，但我只能猜测他们的优势/劣势。在谷歌上搜索后，我得出了以下结论：

将对象本身存储在Mongo中，然后将ObjectID与支持空间索引的SQL server上SQL表中的空间坐标相关联。我喜欢这种方法将所有的空间数据放在一个索引中，但是这里丰富的SQL人才倾向于MySQL，从文档来看，MySQL的空间索引实现似乎是一种事后思考，很像mongo中的实现。另外，据我所知，我们将只固定到MyISAM表

就SQL上的专用空间解决方案而言，我能在网上找到的关于Postgres和PostGIS的文档最多。目前，我们所做的只是使用haversign距离计算进行半径搜索，因此其优势之一是支持使用向量和多边形进行更高级的限制，也许将来我们可以扩展到类似基于区域的限制。这里的主要限制是我们根本没有内部博士后人才，我不确定这是否需要新员工

为对象本身寻找不同的NoSQL解决方案，并将位置元数据嵌入其中。Neo4j在这个部门似乎有很多承诺： 文档中肯定给出了一些引人注目的例子

---

我很好奇，是否有任何一种键值存储解决方案将空间索引作为核心任务目标来实现？如果没有，最好推荐哪种方法来实现良好的职责分离和最大的可维护性？

最新版本的Postgresql（9.2）具有键值存储类型表，尽管我不确定您是否可以将其与PostGIS结合以实现真正强大的空间功能

Neo4J包括JTS，所以我很确定您可以使用它实现出色的空间功能

如果您的数据存储是用C/C++编写的，那么请寻找Geos集成 对于Java，您需要JTS