Neo4j cypher查询真的很慢

时间:2013-08-02 15:26:52

标签: performance neo4j cypher

我有以下图表结构

  • 4m节点
  • 23m物业
  • 13米关系

Java版

  • Java(TM)SE运行时环境(版本1.7.0_25-b15)
  • Java HotSpot(TM)64位服务器VM(内置版本23.25-b01,混合模式)

Neo4j版

  • 的Neo4j-社区2.0.0-M03

  • Mac OS X 10.8.4
  • 2.5 GHz Intel Core i5
  • 8 GB 1600 MHz DDR3

问题

我正在做三个查询的实验。 #1需要16秒,#2需要8分钟而#3正在“崩溃”。 #2和#3都将所有可用CPU核心的使用率降低了约90%。我正在使用Web界面来评估这些查询(我将使用REST API将应用程序与neo4j集成)

我想知道这些查询有什么问题,以及如何优化它们。我目前正在使用默认设置。

Cypher查询

查询#1(目前需要16秒(预热后))

START root=node:source(id="2")
MATCH root-[]->movies<-[]-others
WITH COUNT(movies) as movie_count, others as others
RETURN others.id, movie_count
ORDER BY movie_count DESC
LIMIT 10

查询#2(8分钟)

START root=node:source(id="2")
MATCH 
    root-[]->stuff<-[]-others

WITH DISTINCT(others) as dothers
MATCH dothers-[]->different

RETURN different.id, COUNT(different) as count
ORDER BY count DESC
LIMIT 10

查询#3(OutOfMemoryError - 超出GC开销限制)

START root=node:source(id="2")
MATCH root-[*1..1]->stuff<-[*1..1]-other-[*1..1]->different
WHERE stuff.id <> different.id
WITH COUNT(different) as different_count, different as different
RETURN different.id, different_count
ORDER BY different_count DESC
LIMIT 10

2 个答案:

答案 0 :(得分:1)

免责声明:此建议适用于1.8和1.9。如果您使用的是2.0或2.1,则这些评论可能不再有效 查询1:使用你的RETURN,并跳过额外的步骤。

查询2:不要像现在这样在WITH中做区别。尽量做到尽可能不做。这看起来像查询中的过早优化,使其不是懒惰的,并且必须存储更多的中间结果来计算WITH结果。

查询3:不要 - [* 1..1] - &gt ;;这与 - [] - &gt;相同或 - &gt;,但当它真正需要相邻节点并且可以使用快速匹配器时,它使用较慢的匹配器用于可变长度路径。使用你的RETURN并取出它需要经过的额外管道,这样它可以更加懒惰(虽然按种类排序使它很难变得懒惰)。看看你是否可以在没有订单的情况下完成它。

如果您需要更快的响应并且无法使用我的建议将其从查询中删除,您可能需要转向Java API,直到2.x中的Cypher性能改进为止。非托管扩展方法可以从REST界面轻松调用它们。

答案 1 :(得分:1)

在寻找性能时,请使用Neo4j的最新稳定版本(撰写此答案的时间点为1.9.x)。

2.0.0.M03是一个里程碑版本,尚未优化。到目前为止,重点是关于标签和基于标签的索引的新概念的特征完整性。