mongodb - MongoDB 的 GeoNear 的替代品

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

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

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

有问题的客户正在考虑随着开发团队的壮大修改此功能的数据架构，以使新开发人员可以更直观地了解代码。在解释完所有内容后，他们有兴趣改变范围查询的方法，因为他们对将 Mongo 中的这个相对较新的功能作为我们架构中的核心组件犹豫不决(因为它获得了第一个有限的数据集，所有其他过滤器都基于这些数据集)应用)

我很好奇是否有任何强大的替代品。作为负责开发这部分逻辑的人，我可以想到一些，但我只能猜测它们的长处/短处。在谷歌搜索之后，这就是我想出的:

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

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

最佳答案

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

Neo4J 包括 JTS，所以我很确定您可以使用它来获得出色的空间功能。

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

关于mongodb - MongoDB 的 GeoNear 的替代品，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/11455583/