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

Question

我正在Neo4j中对用户授权/数据保护方案进行原型设计,我遇到了一个奇怪的问题.对于背景,概念是如果用户具有正确的访问标识符,则尝试从a到达的用户可以成为.因此,我们的边缘是具有访问标识符的类型.我正在通过创建大量节点来测试这个方案,并通过不同的访问来连接它们.也就是说,我有很多套:

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

随着不同的访问.我用以下方法查询它们:

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

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

这一切都很有效,直到列表获得201次访问.此时,配置文件显示db命中和时间.在200种关系类型中,配置文件显示1051 db命中,但201种关系类型显示31801.这是另外一种类型的30倍增加!所用时间以类似方式增加.从199到200只上升约50次点击,这是由于节点数量增加所致.

经过更多的工作,看起来圆形的200号码比问题更像红色鲱鱼.以前,我的关系类型是4个字符.当我将它们改为9个字符时(在"EDGE_"之前,作为测试),问题开始发生在50种类型--50有36次访问,而51有291 - 较小的跳跃,但与之前相同的增加相比显着测试.

似乎关系名称与查询失败的位置存在某种关系,但我仍在调查中.

我测试过但没有发现感兴趣的东西:

• 整个查询的长度(字符串大小):它以完全不同的查询大小失败,具有4和9个字符关系类型
• [e:<...>]子句中列表的长度(字符串大小).如上所述,它的尺寸非常不同
• 图中的节点数或边数

Answer 1

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

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