密码查询中的大量关系类型答案

【问题标题】：Large number of relationship types in cypher query密码查询中的大量关系类型
【发布时间】：2017-02-04 04:59:25
【问题描述】：

我正在 Neo4j 中对用户授权/数据保护方案进行原型设计，但我的一个查询遇到了一个奇怪的问题。作为背景，这个概念是，如果用户具有正确的访问标识符，则试图从一个 to be 中获得 to be。因此，我们的边缘是其中具有访问标识符的类型。我正在通过创建大量节点并将成对的节点与不同的访问连接来测试这个方案。也就是说，我有很多套：

(a)-[:ACCESS_A]->(b)

具有不同的访问权限。我查询他们：

{some query} with a match (a)-[:ACCESS_A|:ACCESS_B|<...>|:ACCESS_Z]->(b) return b

边缘匹配中列表的大小随着用户访问次数的增加而增长。

这一切都很好，直到列表达到 201 次访问。此时，配置文件显示 db hits 和 time 上升了。在 200 种关系类型中，配置文件显示 1051 db hits，但 201 种关系类型显示 31801。这是增加了 30 倍的类型！所用时间以类似方式增加。从 199 到 200 只增加了大约 50 次点击，这是由于点击的节点数量越来越多。

经过更多的工作，看起来第 200 轮数字更像是一个红鲱鱼而不是问题。以前，我的关系类型是 4 个字符。当我将它们更改为 9 个字符（添加“EDGE_”，作为测试）时，问题开始出现在 50 种类型 - 50 有 36 次访问，而 51 有 291 次 - 跳跃较小，但与之前相同的增加相比意义重大测试。

似乎关系名称与查询失败的位置有某种关系，但我仍在调查。

我测试过但不感兴趣的东西：

整体查询的长度（字符串大小）：它在完全不同的查询大小与 4 和 9 个字符关系类型时失败
[e:<...>] 子句中列表的长度（字符串大小）。如上所述，它在非常不同的尺寸下失败
图中的节点或边数

【问题讨论】：

标签： neo4j

【解决方案1】：

据我所知，您不应该遇到只有 200 种关系类型的性能问题。

在 3.0 版之前，关系类型的数量上限为 64k。 3.0 版取消了该限制。

【讨论】：

我的问题不在于图表中的类型数量（出于测试原因，它实际上小于我传入的可能类型的数量），而是我的查询中的数量。

【解决方案2】：

我能够找到解决问题的方法。似乎向 Neo4j 询问比现有更多的不同关系类型会导致问题。当这些类型都存在时，我能够使用超过 200 种。因此，解决方案是确保您不要求任何不在图表中的类型。

【讨论】：