这是我使用Neo4j和相关空间插件的第一个项目。我正在经历的性能远远低于我所期望的和低于这个项目所需要的。作为一个新手，我可能会遗漏一些东西或误解一些东西。我很感激你的帮助。
我正在经历Neo4j和空间插件的响应时间非常慢，当试图找到周围的OSM方法到由经度/纬度指定的点来处理驱动行程的GPS读数时。我叫空间。最接近的("layer "， {lon, lat)， 0.01)，需要6-11秒来处理，并返回大约25 - 100个节点。
我正在运行Neo4j社区版3.0.4和空间0.20在MacBook Pro 16GB/512GB SSD上运行。OSM的数据是马萨诸塞州最新的。osm(马萨诸塞州，美国)我通过波特和塞弗进入。仪器测试已经在浏览器客户端、python客户端、java客户端以及报告空间存储过程时间的自定义空间版本中完成。Neo4j数据库的大小大约为44GB，包含76.5万个节点和118.2万个关系。模式和数据是来自OSMImport的"原样"。
为了隔离性能，我添加了一个自定义版本的spatial。最接近()命名为空间。timedClosest()。timmednearest()存储过程接受与space .close()相同的输入并具有相同的调用，但返回一个Stream而不是Stream。Stream有存储过程的计时信息。
存储过程执行时间在getLayerOrThrow()和SpatialTopologyUtils的内部调用之间平均分配。findClosestEdges()。
1) 为什么getLayer(layerName)需要这么长时间来执行?我很惊讶地看到getLayer(layerName)花了这么长时间:2.5 - 5秒。只有一层，OSM层，直接脱离根节点。我在调用spatial.getLayer()时看到了相同的命中。由于层是许多空间过程的参数，所以这是一个大问题。有人对此有什么见解吗?
2) 是否有一种方法来加速spaitaltopologytils。findClosestEdges () ?是否可以添加额外的索引来加快空间接近度搜索?
我的理解是Neo4j能够处理数十亿个节点/关系。对于这个项目，我计划加载北美OSM数据。从我对空间插件的了解来看，它具有空间管理和搜索功能，可以为您提供良好的起步基础。
@郭博，很抱歉回复晚了。我离开Neo4j有一段时间了。我用geohash索引取代了现有的索引(https://en.wikipedia.org/wiki/Geohash)。在加载OSM数据时，对geohash区域的道路和边界进行交叉口测试。Geohash可以很好地进行查找。OSM数据的加载仍然是一个空头。从北美的OSM数据到8核中档AMD服务器上的SATA ssd需要几天到一周的时间。