Neo4j:通过CYPHER/REST慢速创建节点

Question

我尝试使用Cypher的MERGE-statement通过REST API创建/更新节点。每个节点具有大约1kb的属性(所有大小的总和)。我为每个请求创建/更新1个节点。(我知道还有其他方法可以在批处理中创建大量节点，但这里不是问题所在。)

我在Windows Server2008CPU企业版(24个CPU，64 24)上使用Neo4j社区2.1.6，数据库目录位于SAN驱动器上。我得到了每秒4-6个节点的速率。换句话说，一次创建或更新大约需要200ms。这对我来说似乎相当慢。

该查询如下所示：

MERGE (a:TYP1 { name: {name}, version: {version} }) 
SET 
    a.ATTR1={param1},
    a.ATTR2={param2},
    a.ATTR3={param3},
    a.ATTR4={param4},
    a.ATTR5={param5} 
return id(a)

有一个关于名称、版本和两个属性的索引。

为什么花了这么长时间？我能做些什么来改善这种情况呢？

我可以想象，一个问题是每个请求都必须创建一个新的连接？有没有办法让http连接对多个请求保持开放？

Answer 1

对于一个查询，我敢肯定每个查询每个标签只能使用一个索引，因此根据您的数据，它们的索引使用可能效率不高。

就持久连接而言，这是可能的，尽管我认为这取决于您用来连接到REST API的库。在ruby neo4j gem中，我们使用具有NetHttpPersistent适配器的Faraday gem。

Answer 2

1. 仅当您将一个属性与merge
2. 一起使用时才使用索引。如果您需要对这两个属性进行合并，请创建复合属性，对其进行索引(或者最好使用约束)，然后对
3. 在create SET上使用的复合属性进行合并。否则，您每次都会(覆盖)写入属性，即使您并未实际创建节点。

改编的语句

MERGE (a:TYP1 { name_version: {name_version} }) 
ON CREATE SET 
    a.version = {version}
    a.name = {name}  
    a.ATTR1={param1},
    a.ATTR2={param2},
    a.ATTR3={param3},
    a.ATTR4={param4},
    a.ATTR5={param5} 
return id(a)

Answer 3

这是一个示例，展示了如何在与Neo4j的一次通信中从nodejs执行一批密码查询。要运行它，

• 安装nodejs (如果您尚未安装)
• 从https://developers.facebook.com/tools/explorer获取令牌，允许您访问node as >node {yourFileName}.js {yourToken}

前提条件：

var request=require("request") ;
var graph = require('fbgraph');
graph.setAccessToken(process.argv[2]);

function now() {
    instant = new Date();
    return instant.getHours() 
        +':'+ instant.getMinutes() 
        +':'+ instant.getSeconds()  
        +'.'+ instant.getMilliseconds();
} 

获取facebook数据：

graph.get('me?fields=groups,friends', function(err,res) {
    if (err) {
        console.log(err);
        throw now() +' Could not get groups from faceBook';
    }

Create cypher语句

    var batchCypher = [];
    res.groups.data.forEach(function(group) {
        var singleCypher = {
            "statement" : "CREATE (n:group{group}) RETURN n, id(n)",
            "parameters" : { "group" : group }
        }
        batchCypher.push(singleCypher);

一个接一个地运行

        var fromNow = now();
        request.post({
            uri:"http://localhost:7474/db/data/transaction/commit", 
            json:{statements:singleCypher}
        }, function(err,res) { 
            if (err) {
                console.log('Could not commit '+ group.name);
                throw err;
            }
            console.log('Used '+ fromNow +' - '+ now() +' to commit '+ group.name);
            res.body.results.forEach(function(cypherRes) {
                console.log(cypherRes.data[0].row);
            });
        })
    });

批量运行它们

    var fromNow = now();
    request.post({
        uri:"http://localhost:7474/db/data/transaction/commit", 
        json:{statements:batchCypher}
    }, function(err,res) { 
        if (err) {
            console.log('Could not commit the batch');
            throw err;
        }
        console.log('Used '+ fromNow +' - '+ now() +' to commit the batch');
    }) 
});

日志显示，5个组的事务比1个组的事务慢得多，但比每个组的5个事务要快得多。

Used 20:38:16.19 - 20:38:16.77 to commit Voiture occasion Belgique
Used 20:38:16.29 - 20:38:16.82 to commit  Marches & Randonnées
Used 20:38:16.31 - 20:38:16.86 to commit Vlazarus
Used 20:38:16.34 - 20:38:16.87 to commit Wijk voor de fiets
Used 20:38:16.33 - 20:38:16.91 to commit Niet de bestemming maar de route maakt de tocht goed.
Used 20:38:16.35 - 20:38:16.150 to commit the batch

我刚刚读了你的评论，Andreas，这对你不适用，但你可以用它来找出时间是花在沟通上还是花在更新上