我试图在客户端 - 服务器环境中对Neo4j大量插入进行基准测试。 到目前为止，我发现只有两种方法可以做到：
我可以说我们的设计需要能够从许多同时运行的进程/机器中插入，因此使用直接连接的批量插入不是一种选择。
我还想避免实施服务器扩展，因为我们已经有了紧张的时间表。
我通过REST 从一个客户端对大量插入进行基准测试，发送了两种非常简单的Cypher查询：
create (vertex:V {guid: {guid}, vtype: {vtype}, random1: {random1}, random2: {random2} })
match (a:V {guid: {a} }) match (b:V {guid: {b} }) create (a)-[:label]->(b)
Guid 字段有一个索引。
与 Titan或Orient 等竞争产品相比，（10k V + 40k E）在13分钟附近的结果非常糟糕，提供高效的服务器箱子和吞吐量在（10k V + 40k E）/ 1分钟附近。
我尝试了更持久的事务和查询参数，没有任何显着的收益。此外，REST的开销非常小，因为我测试了虚拟查询，并且执行速度要快得多（客户端和服务器都在同一台机器上）。我也尝试从多个线程插入 - 性能不会扩展。
我发现了另一个StackOverflow问题，其中建议批量插入包含数千个命令并定期提交的大型请求。 不幸的是，由于我们如何生成数据的性质，批量处理请求是不可行的。理想情况下，我们希望插入是原子操作，并在执行后立即显示结果（实际上不需要事务）。
因此我的问题是：
答案 0 :(得分：0)
我有很多想法/问题在评论中不太合适;）
您使用的是什么版本的Neo4j？ 2.3介绍了一些可能有用的内容
当你说你有一个索引时，你的意思是新风格而不是遗留索引吗？较新的索引使用CREATE INDEX ON :V(guid)创建，并应用于标签和属性的组合。您可以在前缀为PROFILE的Web控制台中尝试查询，以查看查询是否符合索引以及查询速度可能较慢
如果您可以使用CSV格式获取数据，则可以查看Cypher中的LOAD CSV子句。
我认为这不会对性能有多大帮助，但这样做有点好看：
匹配（a：V {guid：{a}}），（b：V {guid：{b}}）创建（a） - [：label] - ＆gt;（b）
我知道现在没有任何帮助，但是Neo4j 3.0计划有一个名为Bolt的新压缩二进制套接字协议，它应该是对REST的改进。据估计是第二季度
我知道很多这些建议可能不太有帮助，但它们是需要考虑的事情。在这里还有一个关于Neo4j的公共Slack聊天：
http://neo4j.com/blog/public-neo4j-users-slack-group/
我会在那里分享这个问题，看看是否有人有任何想法
修改
Max DeMarzi传递了一篇关于排队请求的文章，这些请求可能很有用：
http://maxdemarzi.com/2014/07/01/scaling-concurrent-writes-in-neo4j/
看起来你需要编写一些Java，但他会为你解决这个问题