Question

我有一个复杂的分层查询，如下所示：

MATCH (comp:Company {id: 7})-[:HAS_SPACE]->(s:Space)-[:HAS_BOARD]->(b),
(col)<-[:HAS_COLUMN]-(b)-[:HAS_LANE]->(lane)
OPTIONAL MATCH (b)-[:HAS_CARD]->(card {archived: false}),
(cardCol:Column)-[:HAS_CARD]->(card {archived: false})<-[:HAS_CARD]-(cardLane:Lane)
WITH s, b, col, lane, { id: card.id, title: card.title, sort_order: card.sort_order, column_id: cardCol.id, lane_id: cardLane.id } as crd
WITH s, { id: b.id, title: b.title, left: b.left, top: b.top,
columns: collect(distinct {id: col.id, title: col.title, col_count: col.col_count, sort_order: col.sort_order}), 
lanes: collect(distinct {id: lane.id, title: lane.title, row_count: lane.row_count, sort_order: lane.sort_order}), 
cards: collect(distinct crd)} as brd 
RETURN {id: s.id, title: s.title, boards: collect(distinct brd)}

当卡片数量大约为200时，此查询速度会降至10秒。问题是什么，以及如何对其进行分析？看起来有一个PROFILE关键字，但输出看起来不像真正的信息。顺便说一句，我们在heroku上使用GrapheneDB。

Answer 1

我认为你对这个问题的一个问题是路径上的组合爆炸，你可以帮助加密一下（下一个版本会更加巧妙）。

你的“可选关系”在哪里？董事会和卡之间？

create index on :Company(id);

MATCH (comp:Company {id: 7})-[:HAS_SPACE]->(s:Space)-[:HAS_BOARD]->(b)
WITH distinct s, b
MATCH  (col)<-[:HAS_COLUMN]-(b)-[:HAS_LANE]->(lane)
OPTIONAL MATCH (b)-[:HAS_CARD]->(card {archived: false})
WITH distinct s, b, col, lane, b, card
MATCH (cardCol:Column)-[:HAS_CARD]->(card {archived: false})<-[:HAS_CARD]-(cardLane:Lane)

WITH s, b, col, lane, 
  { id: card.id, title: card.title, sort_order: card.sort_order, 
    column_id: cardCol.id, lane_id: cardLane.id } as crd

WITH s, 
  { id: b.id, title: b.title, left: b.left, top: b.top,
    columns: collect(distinct {id: col.id, title: col.title, 
                               col_count: col.col_count, sort_order: col.sort_order}), 
    lanes: collect(distinct {id: lane.id, title: lane.title, row_count: lane.row_count, 
                              sort_order: lane.sort_order}), 
    cards: collect(distinct crd)} as brd 

RETURN {id: s.id, title: s.title, boards: collect(distinct brd)}

它有助于分别分析查询的不同部分，并查看组合爆炸的位置。然后用不同的方法修复该部分的基数。

您还可以通过在cypher 2.1.experimental

前面添加查询前缀来尝试新的查询规划器

Answer 2

经过一些研究发现，如果我们＆＃34;反规范化，那么这个查询的运行速度要快20倍。节点有点添加lane_id和column_id到卡。它仍然不是最快的解决方案，我不喜欢这种消除关系的非规范化。所以我会感激任何其他解决方案

neo4j复杂的hieharchical Cypher查询性能缓慢

2 个答案: