【发布时间】：2019-10-18 07:36:07
【问题描述】：
这是我使用 Neo4j 和相关空间插件的第一个项目。我体验到的性能远低于我的预期和该项目所需的性能。作为一个菜鸟，我可能会遗漏一些东西或误解了一些东西。感谢并需要帮助。
当我试图找到周围的 OSM 方式到 lat/lon 指定的点以处理从驾驶行程中读取的 GPS 时，我遇到了 Neo4j 和 Spatial 插件的响应时间非常慢。我正在调用 spatial.closest ("layer', {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 数据。根据我对空间插件的理解，它具有空间管理和搜索功能，可以提供良好的入门基础。
【问题讨论】：
-
不能解决您的问题，但如果您只想要附近的边缘/方式，您可以查看其他项目，如 Postgis 或为这些“地图匹配”目的而调整的项目github.com/graphhopper/map-matching（注意我GraphHopper 的作者之一），那么对于一个城市和 RAM 使用率来说，数据库将低于 100MB。
-
谢谢@Karussell。尽管提出了很好的建议，但该项目是对客户的技术评估/验证/概念证明。这个阶段特别关注 Neo4j，我需要负责任地拉动这个线程。我使用支持 OSM Nominatim 进行反向地理编码的 Postgis 扩展做了一些简单的改进。
-
@Blake，您的帖子已经过去三年多了。我想知道您是否可以分享您是否克服了性能问题，如果是，您是如何做到的。我们正在研究在类似 OSM 的空间应用程序中使用 Neo4J。谢谢！
标签： neo4j openstreetmap spatial