非常重的密码匹配查询

我有不同类型的节点和边的图。我想获取两个节点（索引WORD）之间的所有路径，这些节点通过edge（relation NEXT_WORD）与属性edgeLevel = 1相连。我不想在“edgeLevel！= 1”处获得连接。我写了一个查询非常重的密码匹配查询

MATCH p=(a:WORD{wholeWord:"are"})-[r:NEXT_WORD*1..3{edgeLevel:1}]->(b:WORD{wholeWord: "you"}) RETURN length(p);

但它很重。我试图找出如何优化这个密码查询，但我不知道。有没有更快，更不重要的方式来做到这一点？该查询在7931毫秒内返回了32行。

来源

2016-03-06 Piotr0123456

您似乎已经有:WORD(wholeWord)的索引。但是，您的查询不使用索引来查找a和b。该查询应该会更快：

MATCH p=(a:WORD { wholeWord:"are" })-[r:NEXT_WORD*..3 {edgeLevel:1}]->(b:WORD { wholeWord: "you" }) 
USING INDEX a:WORD(wholeWord) 
USING INDEX b:WORD(wholeWord) 
RETURN length(p);

但是，如果你不要求你的（因为较少的DB命中）关系的特定属性值，特别是因为没有方法来创建一个索引的查询可以更快为了关系。所以，如果你可以使用一个[:NEXT_WORD_1]关系，而不是[:NEXT_WORD {edgeLevel:1}]关系，这将是最快的：

MATCH p=(a:WORD { wholeWord:"are" })-[r:NEXT_WORD_1*..3]->(b:WORD { wholeWord: "you" }) 
USING INDEX a:WORD(wholeWord) 
USING INDEX b:WORD(wholeWord) 
RETURN length(p);

来源

2016-03-06 22:34:06 cybersam

感谢您的答复。但是添加USING INDEX b：WORD（wholeWord）并没有加快查询速度。以前的查询成本：378082总分贝命中，你的第一个命题：规划师：规则。 10984317总分贝命中。添加新的关系NEXT_WORD_1相当适合这种情况，但我认为这是剩下的唯一选择。我会尝试重新实现这个图结构，我会在下一个评论中给你答案。 – Piotr0123456

我已经实现了新类型的关系，现在它的工作速度更快。我用新类型的关系'NEXT_WORD_1' planner查询：COST。 61194总分贝命中188毫秒。你的第一个解决方案（使用两个索引和'NEXT_WORD_1'）规划器：RULE。 19993总分贝命中172毫秒。 – Piotr0123456

非常重的密码匹配查询

回答

相关问题