我有一个有7340个节点的Neo4j数据库。每个节点都有一个标签(肿瘤)和 2 个属性(概念 ID 和完全指定名称)。在这两个属性上都启用了自动索引,我已经在 tumor:conceptID 和 neoplasm:fullSpecified Name 上创建了一个模式索引。节点是术语树中的概念。有一个根节点,其他节点通常通过多条路径下降到多达 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 的功能。
我认为图形数据库应该快得令人眼花缭乱,并且性能与大小无关。
到目前为止,我只添加了 9033 个关系中的 35362 个。即使速度不会随着关系数量的增加而进一步降低,添加剩余的也需要三天以上!
谁能说出为什么这种表现如此糟糕?还是这种性质的写入性能正常,只是读取性能才如此出色。返回 5 级节点父级的示例 Cypher 查询返回 23 个完全指定名称属性的列表,其时间比我用秒表测量的时间要短!(远在一秒钟内)。
当同时在标签上使用不同的索引时,Cypher (尚未)选择它们以使查询更快,而是尝试提供使用它们的提示,请参阅 http://docs.neo4j.org/chunked/milestone/query-using.html#using-query-using-multiple-index-hints
PROFILE
MATCH (child:neoplasm), (parent:neoplasm)
WHERE child.conceptID = "448257000" AND parent.conceptID="372095001"
USING INDEX child:neoplasm(conceptID)
USING INDEX parent:neoplasm(conceptID)
CREATE child-[:ISA]->parent
这会改善事情吗?另外,请发布配置文件输出以获得更好的见解。
你说你正在使用自动索引。但是,查询将使用架构索引,而不是自动索引。根据属性自动索引节点,并且不绑定到标签。模式索引是 Neo4j 2.0 的一项全新功能。
因此,摆脱自动索引,并按照 Tatham 的建议,使用以下方法创建架构索引:
CREATE INDEX ON :neoplasm(conceptId)
即使使用架构索引,插入关系也会随着图形的增长而变慢,因为索引通常在 log(n) 级别扩展。但是,它应该比您观察到的时间快得多。
我似乎已经找到了答案。我重新启动了Neop4j数据库(Neop4j 2.0.0-M06),并得到了Neo4j将在几秒钟内准备就绪的通常消息。半个多小时后,状态变为绿色。在那段时间里,我正在监视这个过程,它似乎正在重建 lucene 索引。
此后,我尝试加载更多关系,现在它们以可接受的速度添加(每个关系~100毫秒)。
感谢您的评论