Neo4j 密码匹配查询速度

Neo4j 密码匹配查询速度,neo4j,cypher,Neo4j,Cypher,我在一台有12个处理器和64GB内存的windows机器上安装了Neo4j。我没有更改Neo4j允许的任何内存设置 我的数据库有380万个节点,其中210000个被标记为地理标记,总共有650000个关系。我正在尝试运行以下查询,我想知道这是否是一个非常密集的查询,可能需要相当长的时间 Messages.csv是我的关系文件。已经创建了关系,但由于我不知道如何将关系创建与下面的距离生成结合起来,我正在加载并运行关系文件两次 USING PERIODIC COMMIT 15000 LOAD CSV

我在一台有12个处理器和64GB内存的windows机器上安装了Neo4j。我没有更改Neo4j允许的任何内存设置

我的数据库有380万个节点,其中210000个被标记为地理标记,总共有650000个关系。我正在尝试运行以下查询,我想知道这是否是一个非常密集的查询,可能需要相当长的时间

Messages.csv是我的关系文件。已经创建了关系,但由于我不知道如何将关系创建与下面的距离生成结合起来,我正在加载并运行关系文件两次

USING PERIODIC COMMIT 15000
LOAD CSV WITH HEADERS FROM "file:d:/messages.csv" AS line
MATCH (a:Geotagged { username: line.sender }) - [r:MSGED] -> (b:Geotagged { username: line.recipient })
SET r.Distance = (2 * 6371 * asin(sqrt(haversin(radians(toFloat(b.statusLat) - toFloat(a.statusLat))) + cos(radians(toFloat(b.statusLat))) * cos(radians(toFloat(a.statusLat))) * haversin(radians(toFloat(b.statusLon) - toFloat(a.statusLon))))));
初始关系生成大约需要3-5分钟。我让上面的程序运行了一个多小时,但仍然没有完成。我运行了一个类似的算法,尽管它在同一初始数据库上还有几个trig调用,并让它运行了18个多小时,但仍然没有完成

我的问题:这是一个非常密集的问题吗?我没有给它足够的时间吗?更重要的是,我有没有办法优化它

我尝试添加WHERE NOT HASr.Distance以排除算法已设置距离的节点对,但我不确定该匹配是一次性匹配还是将匹配CSV文件中的每一行


如果您对此有任何想法,我将不胜感激。

我开始调试的一种方法是使用以下工具对其进行限制:

这样,您就可以更改限制数量,以查看性能如何随着限制的增加而降低

此外,是否是地理标签的用户名属性索引?如果不是,它肯定应该是这样的:

CREATE INDEX ON :Geotagged(username)
如果它是唯一的,并且您希望数据库强制执行:

CREATE CONSTRAINT ON (g:Geotagged) ASSERT g.username IS UNIQUE

这是对Brian回答的补充:

您的语句的查询计划显示渴望验证运行

EXPLAIN explain LOAD CSV WITH HEADERS FROM "file:d:/messages.csv" AS line
WITH line LIMIT 100
MATCH (a:Geotagged { username: line.sender }) - [r:MSGED] -> (b:Geotagged { username: line.recipient })
SET r.Distance = (2 * 6371 *asin(sqrt(haversin(radians(toFloat(b.statusLat) - toFloat(a.statusLat))) + cos(radians(toFloat(b.statusLat))) * cos(radians(toFloat(a.statusLat))) * haversin(radians(toFloat(b.statusLon) - toFloat(a.statusLon))))));
对加载CSV的渴望非常糟糕,请参阅以下博客帖子,原因是:

按照Mark的建议,使用匹配集上的合并替换匹配/集,我们可以将其重构为:

explain LOAD CSV WITH HEADERS FROM "file:d:/messages.csv" AS line
WITH line LIMIT 100
MATCH (a:Geotagged { username: line.sender }), (b:Geotagged { username: line.recipient })
MERGE (a)-[r:MSGED]->(b)
ON MATCH SET r.Distance = (2 * 6371 * asin(sqrt(haversin(radians(toFloat(b.statusLat) - toFloat(a.statusLat))) + cos(radians(toFloat(b.statusLat))) * cos(radians(toFloat(a.statusLat))) * haversin(radians(toFloat(b.statusLon) - toFloat(a.statusLon))))));

渴望消失了

抱歉,是的,我已经将用户名限制为唯一的,尽管我觉得该限制会自动创建索引….?Stefan,谢谢,我不知道配置文件功能,甚至不知道使用Earge时的问题。此后,我按照您的建议更改了查询,并以10和100的限制运行。两者都进行了0次修改,即这些行不代表从一个地理标记用户发送给另一个地理标记用户的消息。10行耗时11.5秒,100行耗时71秒。该文件有3712112行,因此根据71sec/100行推断,大约需要30天。这到底是令人惊讶还是正常?仅供参考,我最初的查询在36秒内运行了100行,是修订语法的一半。这太慢了。我想你可以通过切换到Linux获得很多。嗨,Stefan,windows的实现真的那么不可靠吗?我还更改了页面缓存,没有任何更改。我还提出了另一个问题,但是当我运行“index-indexes”时,由unique约束创建的索引没有显示在shell中,这正常吗?到目前为止,我所知道的大多数生产安装都在Linux上运行。在Neo4j中,您仍然拥有NodeByLabel扫描stefan:
explain LOAD CSV WITH HEADERS FROM "file:d:/messages.csv" AS line
WITH line LIMIT 100
MATCH (a:Geotagged { username: line.sender }), (b:Geotagged { username: line.recipient })
MERGE (a)-[r:MSGED]->(b)
ON MATCH SET r.Distance = (2 * 6371 * asin(sqrt(haversin(radians(toFloat(b.statusLat) - toFloat(a.statusLat))) + cos(radians(toFloat(b.statusLat))) * cos(radians(toFloat(a.statusLat))) * haversin(radians(toFloat(b.statusLon) - toFloat(a.statusLon))))));