neo4j直接访问和通过OGM之间的显着性能差异

时间:2017-05-11 09:10:07

标签: java neo4j neo4j-ogm

我正在使用插入,更新,删除和查询的简单基准来评估Neo4j图形数据库的性能。使用Neo4j OGM与通过Neo4j驱动程序直接访问相比,我发现执行时间明显变慢(约2-4倍)。例如,对于10K节点和我的机器上的11K关系,删除操作(参见下面的代码)在500ms到1200ms内完成。我想知道为什么会发生这种情况,特别是因为下面的删除代码甚至不使用任何节点实体。我可以想象OGM有一些开销,但这似乎太多了。任何人都知道为什么它会变慢?

示例节点:

public abstract class AbstractBaseNode {

    @GraphId
    @Index(unique = true)
    private Long id;

    public Long getId() {
        return id;
    }
}

@NodeEntity
public class Company extends AbstractBaseNode {

    private String name;

    public Company(String name) {
        this.name = name;
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }
}

通过驱动程序删除的示例代码:

driver = GraphDatabase.driver( "bolt://localhost:7687", AuthTokens.basic( "neo4j", "secret" ) );
session = driver.session();

long start = System.nanoTime();

session.run("MATCH (n) DETACH DELETE n").list();

System.out.println("Deleted all nodes " + ((System.nanoTime() - start) / 1000) + "μs");

通过OGM删除的示例代码:

public org.neo4j.ogm.config.Configuration neo4jConfiguration() {
    org.neo4j.ogm.config.Configuration config =  new org.neo4j.ogm.config.Configuration();
    config.autoIndexConfiguration().setAutoIndex(AutoIndexMode.DUMP.getName());
    config.driverConfiguration()
            .setDriverClassName("org.neo4j.ogm.drivers.bolt.driver.BoltDriver")
            .setURI("bolt://neo4j:secret@localhost")
            .setConnectionPoolSize(10);

    return config;
}

sessionFactory = new SessionFactory(neo4jConfiguration(), "net.mypackage");
session = sessionFactory.openSession();

long start = System.nanoTime();

session.query("MATCH (n) DETACH DELETE n", Collections.emptyMap()).forEach(x -> {});

System.out.println("Deleted all nodes " + ((System.nanoTime() - start) / 1000) + "μs");

1 个答案:

答案 0 :(得分:2)

我将首先指出您的测试样本很差。在花时间采样时,您需要对系统施加压力,以便花费相当多的时间。测试还应测试您感兴趣的内容(您是否测试了创建和删除连接的速度?Max Cypher通过put?单个大型事务的速度?)对于大麦的测试,我们无法确定是否存在差异性能是查询调用,或者只是启动开销(尽管名称,在调用查询(...)之前会话实际上并不连接)。

据我所知,两个版本在正常设置中的表现大致相同。我唯一能想到的就是影响这一点的原因是,OSGM正在做些什么来挨饿其他系统资源进程。

更新

UNWIND {rows} as row 
CREATE (n:Company) 
SET n=row.props 
RETURN row.nodeRef as ref, ID(n) as id, row.type as type with params {rows=[{nodeRef=-1206180304, type=node, props={name=company_1029}}]}

VS

CREATE (a:Company {name: {name}}) // X10,000

驱动程序和OGM之间的关键区别在于驱动程序完全按照您的要求执行操作,这是最有效的处理方式;并且OGM尝试为您管理查询逻辑(返回什么,如何保存事物,尝试保存什么)。 OGM版本更可靠,因为它会自动尝试将节点合并到数据库(如果可能),并且只会保存实际已更改的内容。由于您的节点类没有要合并的主键,因此必须创建所有内容。 OGM Cypher功能更多,但它还需要更多的内存使用/访问。 SET n.name="rawr"每个属性命中1分贝。 SET n={name:"rawr"}是3 db命中(大约1 + 2 * #_ of_props。{name:“rawr”,id:2}是5 db hits)。这就是OGM Cypher速度较慢的原因。然而,OGM具有智能管理功能,因此如果您编辑一个节点并尝试保存它,则驱动程序必须要么全部保存,要么必须实现自己的管理器。 OGM只会保存更新的。

简而言之,OGM Cyphers的效率低于使用驱动程序编写的效果,但OGM内置的智能管理可以使其比实际业务逻辑情境中的盲驱动器实现更快(加载/编辑大型)节点数)。当然,您可以使用驱动程序实现自己的管理更快,因此这是速度和开发工作的折衷。你想要的速度越快,你就需要花费更多的时间来管理每一个微小的方面(OGM的目的是插入它并且它只是工作)。