我有一个包含 7340 个节点的 Neo4j 数据库。每个节点都有一个标签(neoplasm)和 2 个属性(conceptID 和 fullySpecifiedName)。两个属性都启用了自动索引,并且我在 neoplasm:conceptID 和 neoplasm:fullySpecifiedName 上创建了模式索引。节点是术语树中的概念。有一个根节点,其他根节点通常通过多条路径下降到高达 13 层的深度。从一个 SQL Server 实现来看,层次结构如下...
Depth Relationship Count
0 1
1 37
2 360
3 1598
4 3825
5 6406
6 7967
7 7047
8 4687
9 2271
10 825
11 258
12 77
13 3
我正在使用 C# 程序和 neo4jclient 添加关系,它构造和执行像这样的密码查询......
MATCH (child:neoplasm), (parent:neoplasm)
WHERE child.conceptID = "448257000" AND parent.conceptID="372095001"
CREATE child-[:ISA]->parent
将关系添加到第 3 级非常快,第 4 级本身也不错,但在第 5 级时,事情开始变得非常缓慢,平均每个关系超过 9 秒。
上面的示例查询是通过http://localhost:7474/browser/
接口执行的,耗时 12917 毫秒,因此执行时间差不是 C# 代码和 neo4jclient API 的特性。
我认为图形数据库应该快得令人眼花缭乱,而且性能与大小无关。
到目前为止,我只添加了 35362 个关系中的 9033 个。即使速度没有随着关系数量的增加而进一步降低,剩余的添加也需要三天多的时间!
谁能提出为什么这个表现如此糟糕?或者这种性质的写性能是正常的,只是读性能那么好。返回 5 级节点的父节点的示例 Cypher 查询返回 23 个fullySpecifiedName 属性的列表,所用时间比我用秒表测量的时间还短!(不到一秒钟)。