这是我使用Neo4j和相关空间插件的第一个项目。我的性能远低于我的预期，低于此项目所需的性能。作为一个菜鸟，我可能会遗漏一些东西或者误解了一些东西。感谢和需要帮助。
当我试图找到由lat / lon指定的点来处理来自驾驶旅行的GPS读数的周围OSM方式时，Neo4j和Spatial插件的响应时间非常慢。我正在调用spatial.closest（＆＃34; layer＆＃39;，{lon，lat），0.01）这需要6-11秒来处理并返回大约25-100个节点。
我在MacBook Pro 16GB / 512GB SSD上运行Neo4j社区版3.0.4和空间0.20。 OSM数据是massachusetts-latest.osm（美国马萨诸塞州）。我通过bolt和Cypher访问它。已经从浏览器客户端，python客户端，Java客户端以及报告空间存储过程的时间的自定义空间版本完成了检测测试。 Neo4j数据库大小约为44GB，包含76.5M节点和118.2M关系。架构和数据按原样排列。来自OSMImport。
为了隔离性能，我添加了一个名为spatial.timedClosest（）的自定义版本的spatial.closest（）。 timedClosest（）存储过程采用相同的输入并具有与spatial.closest（）相同的调用，但返回Stream而不是Stream。 Stream具有存储过程的计时信息。
存储过程执行时间在内部调用getLayerOrThrow（）和SpatialTopologyUtils.findClosestEdges（）之间平均分配。
1）为什么getLayer（layerName）需要这么长才能执行？我很惊讶地发现getLayer（layerName）需要这么长时间：2.5 - 5秒。只有一个层，即OSM层，直接位于根节点之外。我看到对spatial.getLayer（）的调用同样命中。由于该层是许多空间过程的参数，因此这是一个大问题。有人对此有所了解吗？
2）有没有办法加速SpaitalTopologyUtils.findClosestEdges（）？是否有其他索引可以添加以加速空间邻近搜索？
我的理解是Neo4j能够处理数十亿个节点/关系。对于这个项目，我计划加载北美OSM数据。根据我对空间插件的理解，它具有空间管理和搜索功能，可以提供良好的起点基础。
答案 0 :(得分：1)
@郭波，对您的延迟回复表示抱歉。我已经远离Neo4j了。我用geohash索引（https://en.wikipedia.org/wiki/Geohash）替换了现有索引。加载OSM数据后，对道路和边界进行了测试，以检查geohash地区的交叉点。 Geohash很好地进行了查找。 OSM数据的加载仍然很麻烦。使用SATA SSD从8核中端AMD服务器上的OSM数据中获取北美数据将需要几天到一周的时间。