我正在尝试将大型数据集加载到新4j-3中,并寻找这些选项。我找到了一个新4j导入,但问题是它只适用于初始加载。我每周都要载入200万张唱片。我试着通过shell加载,但是有一些性能问题,我尝试了如下。1)预先创建约束。2)在单独的查询中创建节点和关系。3)堆空间8G 4) dbms.memory.pagecache 4G
很多时候,进口只是挂起,几个小时内什么也不做。
正在执行的编辑- CSV加载:
USING PERIODIC COMMIT 5000
LOAD CSV WITH HEADERS
FROM "file:///my_sds_39_joe.csv"
AS row
OPTIONAL MATCH (per:Person {UID : "Person."+row.player_cardnum})
WHERE per IS NULL
MERGE (p:Person {CardNumber : row.player_cardnum})
ON CREATE SET p.Creation Date = timestamp(), p.Modification Date = timestamp() ;发布于 2016-08-28 18:30:09
编辑
再看一看,似乎您正在尝试为插入实现某种条件逻辑。
看起来,您想要做的是找出一个UID是否存在:Person (派生自与row.player_cardnum的某种连接),在这种情况下:Person不存在,匹配失败,MERGE a:row.player_cardnum给出的CardNumber的人。
如果这是您的目标,那么您的查询就快完成了。问题在于您的WHERE子句。
请理解WHERE子句与前面的MATCH、OPTIONAL MATCH或WITH链接,并且只影响链接子句。
对于那个WHERE上的OPTIONAL MATCH,per将始终为null,但更重要的是,您的行仍然存在,并且对于CSV中的所有行,始终会发生以下MERGE。这可能是您放缓的原因,因为它正在为所有行创建新的:Person节点。
如果您试图在OPTIONAL MATCH击中现有的:Person (因此在这种情况下不会发生MERGE )时将该行完全空出,则需要添加一个WITH子句,并确保将WHERE子句应用于该行,而不是OPTIONAL MATCH。
此外,确保您在Person.UID和Person.CardNumber上具有唯一的约束或索引。至于UID匹配,我听说当您正在匹配的东西有某种字符串连接时,不使用索引,所以您可能需要先组装它并将它传递给WITH。
最后的查询如下所示:
USING PERIODIC COMMIT 5000
LOAD CSV WITH HEADERS
FROM "file:///my_sds_39_joe.csv"
AS row
// first build the UID so we can take advantage of the index
WITH row, "Person." + row.player_cardnum AS UID
OPTIONAL MATCH (per:Person {UID : UID})
// the WHERE now applies to the WITH, which will filter out and null out the row when an OPTIONAL MATCH is found
WITH row, per
WHERE per IS NULL
MERGE (p:Person {CardNumber : row.player_cardnum})
ON CREATE SET p.Creation Date = timestamp(), p.Modification Date = timestamp() ;https://stackoverflow.com/questions/39188423
复制相似问题