是否有支持地理空间查询的图形文档数据库？

Question

以下是我需要的内容：

• 图表数据库
• 每个节点都是一个文件;将有数百个类型的节点;这几百种类型中的每一种都有自己的一致模式。
• 可以扩展到数十亿个节点
• 除节点之间的边缘
外，每个节点还有一个（lat，lng）坐标
• 我想使用（lat，lng）作为分片键，因此可以将其缩放为大型分片，复制群集。边缘遍历将在附近（纬度，纬度）位置内发生~95％。
• 我希望能够发出地理位置+文档查询。例如＆＃34;显示符合此查询的所有图形节点/文档{...}按距离（lat_0，lng_0）＆＃34;
的距离排序
• 我想要一些记录良好，有活跃的开发人员社区，建议用于生产，并且可能存在多年的东西。

以下是现有数据库的问题：

• MongoDB：没有图表支持，没有加入
• Neo4j：没有分片
• OrientDB：没有地理空间索引
• ArangoDB：可以执行WITHIN查询，但不能有其他查询子句（例如MongoDB＆＃39; geoNear有查询参数）

有什么适合我的用例吗？

Answer 1

你想要一个独角兽和一台打印无限数量的100美元钞票的机器吗？ Har har har ....

好的但是说真的，你在那里订了很高的订单。您需要一个将这些东西混合在一起的自定义系统。首先，正如你所观察到的那样，＆＃34; graph / document＆＃34;数据库。

作为系统研究的一般领域，许多人正在研究混合系统。一个例子是你在neo4j中维护你的图形结构，并且neo4j中的节点ID指向MongoDB中文档的标识符。通过这种方式，您可以拥有图形/文档数据库，但它实际上是两个数据库。这种混合系统充满了权衡。首先，跨两个系统编写查询将非常困难。对于两者，您将在它们之间引入数据依赖关系，这样在不更改文档的情况下更新图形结构可能并不容易，反之亦然。

对于非常强烈的性能要求，混合系统有时是唯一的出路。但是，根据经验，每100次你看到有人说他们需要这样的解决方案，大概80次他们最好选择一个数据库，然后生活在它提供的优点和缺点他们。技术最终是关于选择，优点和缺点，并学会与你所选择的一起生活。 ：）

为了对你提出的问题给出一个简洁的答案，没有什么可以做到这一切。我建议您与可以深入探索您的需求的架构师或顾问合作，并就哪种架构最适合您的大多数需求，平衡简单性和成本提出建议。这同样是一门科学艺术。