使用 REST 优化 Neo4j 的大批量批量插入

Posted 2023-04-18

【中文标题】使用 REST 优化 Neo4j 的大批量批量插入

【英文标题】：Optimizing high volume batch inserts into Neo4j using REST

【发布时间】：2013-11-19 07:21:40

【问题描述】：

我需要通过 REST API 的 Batch 端点将大量具有它们之间关系的节点插入到 Neo4j 中，大约 5k 记录/秒（仍在增加）。

这将是 24x7 连续插入。每条记录可能只需要创建一个节点，但其他记录可能需要创建两个节点和一个关系。

我可以通过更改程序或修改 Neo4j 的设置来提高插入的性能吗？

我目前的进展：

1.我已经用 Neo4j 测试了一段时间，但我无法获得我需要的性能

测试服务器盒：24 核 + 32GB RAM

Neo4j 2.0.0-M06 作为独立服务安装。

在同一台服务器上运行我的Java应用程序。（Neo4j和Java应用程序将来需要在自己的服务器上运行，因此不能使用嵌入式模式）

REST API 端点：/db/data/batch（目标：/cypher）

使用架构索引、约束、MERGE、CREATE UNIQUE。

2。我的架构：

neo4j-sh (0)$ schema
==> Indexes
==>   ON :REPLY(created_at)   ONLINE                             
==>   ON :REPLY(ids)          ONLINE (for uniqueness constraint) 
==>   ON :REPOST(created_at) ONLINE                             
==>   ON :REPOST(ids)        ONLINE (for uniqueness constraint) 
==>   ON :Post(userId)      ONLINE                             
==>   ON :Post(postId)    ONLINE (for uniqueness constraint) 
==> 
==> Constraints
==>   ON (post:Post) ASSERT post.postId IS UNIQUE
==>   ON (repost:REPOST) ASSERT repost.ids IS UNIQUE
==>   ON (reply:REPLY) ASSERT reply.ids IS UNIQUE

3.我的密码查询和 JSON 请求

3.1.当一条记录需要创建单个节点时，作业描述如下所示

"method" : "POST","to" : "/cypher","body" : "query" : "MERGE (child:Post postId:1001, userId:901)"

3.2.当一条记录需要创建两个具有一种关系的节点时，职位描述如下所示

"method" : "POST","to" : "/cypher","body" : "query" : "MERGE (parent:Post postId:1002, userId:902) MERGE (child:Post postId:1003, userId:903) CREATE UNIQUE parent-[relationship:REPOST ids:'1002_1003', created_at:'Wed Nov 06 14:06:56 AST 2013' ]->child"

3.3.我通常每批发送 100 个职位描述（混合 3.1 和 3.2），大约需要 150~250 毫秒才能完成。

4.性能问题

4.1.并发：

/db/data/batch（目标：/cypher）似乎不是线程安全的，使用两个或多个并发线程进行测试，在几秒~几分钟内导致 Neo4j 服务器停机。

4.2. 带有约束的 MERGE 并不总是有效。

当使用单个查询创建两个节点和一个关系时（上面 3.2. 中提到过），它有时就像一个魅力；但它有时会因 CypherExecutionException 而失败，并说其中一个节点 xxxx 已经存在，带有标签 aaaa 和属性“bbbbb”=[ccccc];据我了解，MERGE 不是假设返回任何异常，而是返回节点（如果它已经存在）。

由于异常，整个批次会失败并回滚，这会影响我的插入率。

我已经在 GitHub 中针对这个问题打开了一个问题，https://github.com/neo4j/neo4j/issues/1428

4.3. 带有约束的 CREATE UNIQUE 并不总是适用于关系创建。

在同一个 github 问题中也提到了这一点。

4.4. 性能：

实际上，在我使用 cypher 批处理之前，我已经尝试使用 get_or_create (/db/data/index/node/Post?uniqueness=get_or_create & /db/data/index/relationship/XXXXX?uniqueness=get_or_create )

由于那些遗留索引端点的性质（它们返回索引中数据的位置，而不是实际数据存储中数据的位置），所以我不能在批处理中使用它们（需要在前面创建的引用节点的功能同一批）

我知道我可以启用 auto_indexing，并直接处理数据存储而不是旧索引，但他们从 2.0.0 开始提到，建议使用模式索引而不是旧索引，所以我决定切换到批处理 + 密码 + 模式索引接近。

但是，使用批处理 + 密码，我每秒只能获得大约 200 个工作描述的插入率，如果带有约束的 MERGE 始终有效，那么它会高得多，比如说大约 600~800/s，但仍然很多低于 5k/s。 我还尝试了没有任何约束的模式索引，它最终在插入率方面的性能更低。

【问题讨论】：

你一直在使用 Streaming JSON 吗？ docs.neo4j.org/chunked/2.0.0-M06/rest-api-streaming.html。下一件事是关于使用旧索引端点。您仍然可以在另一个批处理操作中参考创建。例子。使用 uniquness get/create 创建一个节点。然后批处理中的下一个项目是使用START n=node:IndexName(Key=value) .... 的密码。所以你不能通过 batchid 引用它，但你仍然可以利用 get/create 部分。

谢谢 LameCoder！是的，我查看了流式传输，并认为这更多的是从服务器检索，而不是发送到服务器，所以我没有尝试，但我现在会尝试。另外，感谢遗留索引的提示。 :)

感谢 @plasmid87 纠正我的拼写、语法和格式。

@GoSkyLine 不客气，希望你能得到有用的答案！

@LameCoder 启用流式传输和批量大小：1000，我能够以 2000+/s 的速度获得插入速率，哇！这绝对是一个进步！！但是，我也看到了一些行为变化，1. 我不再收到那个异常（他们都成功了还是不再返回异常？）； 2. 我没有看到数据库中的所有数据。因为我的测试有大约 230 万条记录，但只创建了 101,318 个节点。 3. 我在计算应用程序运行时数据库中的节点总数，但数量并不总是增加，8->...->63082->62873->62503->62669->62516->62462- >...->101318 任何想法

【参考方案1】：

在 2.0 中，我将使用事务端点批量创建您的语句，例如每个 http 请求 100 或 1000 个，每个事务大约 30k-50k（直到您提交）。

有关新的流式事务端点的格式，请参见此处：

http://docs.neo4j.org/chunked/milestone/rest-api-transactional.html

对于如此高性能、连续插入的端点，我强烈建议编写一个服务器扩展，该扩展将针对嵌入式 API 运行，并且每秒可以轻松插入 10k 或更多节点和关系，请参阅此处获取文档：

http://docs.neo4j.org/chunked/milestone/server-unmanaged-extensions.html

对于纯插入，您不需要 Cypher。对于并发性，只需在一个众所周知的（每个要插入的子图）节点上加锁，这样并发插入就不会出现问题，您可以使用tx.acquireWriteLock() 或从节点中删除不存在的属性（@ 987654326@).

有关编写非托管扩展（但使用密码）的另一个示例，请查看此项目。它甚至有一种模式可能对您有所帮助（将 CSV 文件发布到服务器端点以使用每行的密码语句执行）。

https://github.com/jexp/cypher-rs

【讨论】：

哇，太棒了！我会试试看。感谢您的所有建议。我阅读了博客文章 - 对您的 Streaming REST API 实验室工作的采访，很高兴能得到您的帮助，这让我很惊讶。 :)

按照您的建议，我创建了一个服务器扩展（使用 Java Core API），它执行了大约 1000 条记录/1000~1200ms（批量大小：1000，每批次一个事务，一次一个请求调用）。我可以看到改进，我觉得我正朝着正确的方向前进，但是，我需要更好的表现。对于并发，如果我同时发送两个请求，我会得到随机 NPE。 GitHub Issue, @Michael Hunger，你还有什么建议吗？谢谢！

@Michael Hunger 这个答案还有吗？