Neo4j空间数据和OSM数据的性能问题

Question

这是我第一个使用Neo4j和相关的空间插件的项目。我正在经历的表现远远低于我的预期，低于所需的这个项目。作为一个菜鸟，我可能遗漏了什么，或者误解了什么。帮助是被欣赏和需要的。

我正经历非常缓慢的Neo4j和空间插件的响应时间，当我试图寻找周围的OSM方法指定的点，由lat/lon处理全球定位系统读取从驱动行程。我调用spatial.closest (“layer”，{lon，lat)，0.01)，它需要6-11秒来处理和返回大约25-100个节点。

我正在运行Neo4j社区版本3.0.4和空间0.20，运行在MacBook Pro 16 on /512 on上。OSM数据是马萨诸塞州-最近的.OSM(马萨诸塞州，美国)我是通过螺栓和塞弗访问它的。已从浏览器客户端、python客户端、java客户端以及空间存储过程定时报告的自定义空间版本进行了测试。Neo4j数据库的大小约为44 is，包含76.5M节点和1182m关系。模式和数据是来自OSMImport的“as-is”。

为了隔离性能，我添加了一个名为spatial.timedClosest( )的定制版本的spatial.timedClosest()。timedClosest()存储过程接受相同的输入，具有与spatial.closest()相同的调用，但是返回一个流而不是一个流。流具有存储过程的定时信息。

存储过程执行时间在对getLayerOrThrow( )和SpatialTopologyUtils.findClosestEdges( )的内部调用之间平均分配。

1) 为什么getLayer(layerName)要这么长时间才能执行？--我很惊讶地观察到getLayer(layerName)花了这么长时间:2.5秒-5秒。只有一个层，OSM层，直接离开根节点。我在调用spatial.getLayer()时也看到了同样的情况。由于这一层是许多空间过程的一个论据，所以这是一件大事。有人对此有洞察力吗？

2) 是否有加速SpaitalTopologyUtils.findClosestEdges( )的方法？是否可以添加额外的索引来加速空间邻近搜索？

我的理解是，Neo4j能够处理数十亿个节点/关系。对于这个项目，我计划加载北美OSM数据。据我对空间插件的理解，它具有空间管理和搜索功能，这将提供一个良好的启动基础。

Answer 1

@博果，很抱歉没有及时回复。我离开Neo4j有一段时间了。我用地理哈希索引(https://en.wikipedia.org/wiki/Geohash)代替了现有的索引。随着OSM数据的加载，道路和边界被测试了在地理哈希区域的交叉口。Geohash在查找方面做得很好。OSM数据的加载仍然是一个负担。北美从OSM数据8核心中程AMD服务器与SATA SSD将需要数天至一周。