我还在尝试使用neo4j来执行复杂的查询（类似于最短路径搜索，除了我有非常奇怪的条件应用于此搜索，例如根据节点遍历计数的最小路径长度）。
我的数据集包含一个单一类型的大约2.5M节点和大约15亿个边缘（也是一个单一类型）。每个给定节点与“下一个”节点平均具有1000个方向关系。
然而，我有一个查询，允许我在给定所有条件的情况下检索这条最短路径，但我发现有一个不错的响应时间（不到一秒）的唯一方法是实际限制每个新节点后的结果数量添加到路径，过滤它，命令它然后继续到下一个节点（这是我认为的一种贪婪的算法）。
我希望限制它们比我更少，以便产生更多的路径，但问题是此搜索的指数复杂性使得从LIMIT 40转到{{1}通常是x10~x100处理时间的问题。
话虽如此，我还在评估几种解决方案以提高请求的速度，但我不确定它们会产生什么结果，因为我不确定neo4j如何真正在内部存储我的数据。
我想到的解决方案是实际向我的关系添加一个属性，该属性是1到15之间的整数，因为我通常只查询具有该属性的一个或两个最大不同值的关系。 （例如，只有具有此属性的关系为8或9）。
正如我可以猜到的那样，对于每个关系，neo4j然后必须收集原始节点属性并使用它来应用我的其他过滤器，这需要很长时间跨越4个节点长路径，每个1000个关系（我猜O （1000 ^ 4））。我是对的吗？
使用关系属性，它是否可以直接访问它而无需进一步提取数据？有没有机会让我的查询更快？如何存储neo4j边缘属性？
更新
按照@logisima的建议，我直接使用neo4j的Java遍历API编写了一个过程。然后我切换到Neo4J的原始Java过程API，以便在我的用例需要时利用更多的功能和灵活性。
结果非常好：下限复杂度总体上比以前少一点但是上限比十倍快，并且当至少一些将用于遍历的节点在缓存中时在Neo4j中，表演变得惊人（当我通常只需要深度4时，我的一次测试不到一秒的深度20）。
但这不是全部。这些程序使其非常容易定制，同时保持最佳性能并最佳地优化每一项操作。结果是我可以在更少的计算时间内使用功能更强大的过滤器，并且可以轻松更新我的过程以添加新功能。最后但并非最不重要的程序很容易插入neo4j的spring-data（我用它来连接neo4j到我的HTTP API）。与cypher一样，我必须自动生成查询（因为非常复杂，有30个java类可以正确地完成这个技巧）我应该使用jdbc for neo4j，同时只为此请求处理一个单独的连接池。不能推荐更多使用真棒neo4j java API。
再次感谢@logisima
答案 0 :(得分：2)
如果您尝试执行自定义短路径算法，则应使用 cypher procedure 编写traversal API。< / p>
Cypher的原则是制作pattern matching，你想以特定的方式遍历图表以找到你的好解决方案。
对于您的用例，响应时间应该更快！