MongoDB GeoNear 的替代品答案

【问题标题】：Alternative to MongoDB's GeoNearMongoDB GeoNear 的替代品
【发布时间】：2012-07-12 15:45:18
【问题描述】：

目前，在一个部署的应用程序中，我们所有的内容实体都存储在 MongoDB 中，我们使用内置的 Mongo geoNear 命令来收集给定半径内具有lat 和lon 属性的所有实体.然后将该数据集输入并行搜索模块并根据用户的查询进行过滤。性能足以满足应用程序迄今为止的流量水平。

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

该方法存在一些问题，据我所知 10gen 目前正在解决。

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

我很好奇是否有任何强有力的替代方案。作为负责开发这部分逻辑的人，我可以想到一些，但我只能猜测它们的优缺点。在谷歌搜索之后，这是我想出的：

将对象本身存储在 Mongo 中，然后将 ObjectId 与其在支持空间索引的 SQL 服务器上的 SQL 表中的空间坐标相关联。我喜欢这种方法将所有空间数据放在一个索引中，但是这里丰富的 SQL 人才倾向于 MySQL，从文档来看，它的空间索引实现似乎是事后的想法，就像 mongo 中的那样。此外，据我所知，我们将只针对 MyISAM 表进行修复。
就 SQL 上的专用空间解决方案而言，我可以在 Web 上找到最多文档的是带有 PostGIS 的 Postgres。目前，我们所做的只是使用 hasrsign 距离计算进行半径搜索，因此其中一个优势是支持使用矢量和多边形进行更高级的限制，也许将来允许我们扩大到类似基于区域的限制。这里的主要限制是我们根本没有内部 Postgres 人才，我不确定这是否需要新员工。
查看对象本身的不同 NoSQL 解决方案，并将位置元数据嵌入其中。 Neo4j 似乎在这个部门做出了很多承诺： http://www.oscon.com/oscon2011/public/schedule/detail/19822 文档中肯定有一些令人信服的例子。

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

【问题讨论】：

【解决方案1】：

最新版本的 Postgresql (9.2) 具有键值存储类型表，但我不确定您是否可以将其与 PostGIS 结合以获得真正强大的空间功能。

Neo4J 包含 JTS，因此我很确定您可以将它用于出色的空间功能。

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

【讨论】：