2

我有以下图形结构

  • 4m 节点
  • 23m 房产
  • 13m 关系

爪哇版

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

Neo4j 版本

  • neo4j-community-2.0.0-M03

机器

  • Mac OS X 10.8.4
  • 2.5 GHz 英特尔酷睿 i5
  • 8 GB 1600 MHz DDR3

问题

我正在用三个查询做一些实验。#1 需要 16 秒，#2 需要 8 分钟，#3 是“崩溃”。#2 和 #3 都将所有可用的 CPU 内核都置于 ~90% 的使用率。我正在使用 Web 界面来评估这些查询（我将使用 REST API 将应用程序与 neo4j 集成）

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

密码查询

查询 #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
4

2 回答 2

1

在寻找性能时，请使用 Neo4j 的最新稳定版本（编写此答案时为 1.9.x）。

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

于 2013-08-05T15:36:00.393 回答
1

免责声明：此建议适用于 1.8 和 1.9。如果您使用的是 2.0 或 2.1，这些注释可能不再有效。
查询1：让你的返回，并跳过那个额外的步骤。

查询 2：不要像现在这样在 WITH 中做不同的事情。在不做不同的情况下尽可能地走远。这看起来像是查询中的过早优化，使其不会变得懒惰，并且必须存储更多中间结果来计算 WITH 结果。

查询 3：不要做 -[*1..1]->; 这与 -[]-> 或 --> 相同，但是当它真的只需要相邻节点并且可以使用快速匹配器时，它对可变长度路径使用较慢的匹配器。使 WITH 成为您的 RETURN 并取出它需要通过的额外管道，以便它可以更懒惰（尽管这种顺序使得它很难变得懒惰）。看看你是否可以在没有订单的情况下完成它。

如果您需要更快的响应并且无法根据我的建议将其从查询中挤出，您可能需要转向 Java API，直到 Cypher 2.x 的性能得到改进。非托管扩展方法使这些易于从 REST 接口调用。

于 2013-08-02T18:04:17.233 回答