Question

在Neo4j中，我有一个关系索引'index_e_ASSOC_sMETHdGEXP'，包含大约180000个边，都带有属性'property'。我想做一个简单的查询，列出索引中的200条边，此时不论属性值如何（稍后进行查询，例如获取边缘属性<= 0.01的200个第一边出顶点的相同属性值），并从out节点获取一些属性值：

time = System.currentTimeMillis();
t = new Table(); g.idx('index_e_ASSOC_sMETHdGEXP')[[property: Neo4jTokens.QUERY_HEADER + "*"]][0..200].outV().id.as('nodeId').back(1).alias.as("alias").back(1).chr.as('chr').table(t,["nodeId","alias","chr"]).iterate();
System.currentTimeMillis() - time

= 713ms

从索引获取200个第一条边需要 262ms ：

time = System.currentTimeMillis();
g.idx('index_e_ASSOC_sMETHdGEXP')[[property: Neo4jTokens.QUERY_HEADER + "*"]][0..200];
System.currentTimeMillis() - time

为什么第一个查询的完成速度如此之慢？从“预定列表”中获取200个边缘并从每个输出节点获取一些属性值不应该花这么长时间。对于Cypher和Gremlin来说，我是一个完全新手，那么在Cypher或Gremlin中有更快的方法来进行这种查询吗？

编辑：运行查询（1）23次：

==> 1124
==> 983
==> 951
==> 864
==> 1175
==> 1189
==> 889
==> 917
==> 822
==> 872
==> 795
==> 736
==> 840
==> 1189
==> 723
==> 756
==> 691
==> 44609
==> 644
==> 640
==> 1110
==> 1007
==> 819

Edit2：我已经使用以下配置重新导入数据库：

dump_configuration=true
cache_type=gcr
neostore.nodestore.db.mapped_memory=100M
neostore.relationshipstore.db.mapped_memory=4G
neostore.propertystore.db.mapped_memory=200M
neostore.propertystore.db.strings.mapped_memory=1G
neostore.propertystore.db.arrays.mapped_memory=1G
neostore.propertystore.db.index.keys.mapped_memory=1G
neostore.propertystore.db.index.mapped_memory=1G
relationship_cache_array_fraction=8
node_cache_array_fraction=8
node_cache_size=3G
relationship_cache_size=6G

现在查询（1）实际上需要更长的时间： 23849 ms 。它开始看起来像缓存问题。

db log的有趣片段：

2012-07-06 10:51:49,149 DEBUG [neo4j.diagnostics]: System memory information:
2012-07-06 10:51:49,152 DEBUG [neo4j.diagnostics]: Total Physical memory: 26,37 GB
2012-07-06 10:51:49,152 DEBUG [neo4j.diagnostics]: Free Physical memory: 11,99 GB
2012-07-06 10:51:49,153 DEBUG [neo4j.diagnostics]: Committed virtual memory: 16,43 GB
2012-07-06 10:51:49,153 DEBUG [neo4j.diagnostics]: Total swap space: 27,00 GB
2012-07-06 10:51:49,153 DEBUG [neo4j.diagnostics]: Free swap space: 26,96 GB
2012-07-06 10:51:49,154 DEBUG [neo4j.diagnostics]: JVM memory information:
2012-07-06 10:51:49,154 DEBUG [neo4j.diagnostics]: Free  memory: 1,84 GB
2012-07-06 10:51:49,154 DEBUG [neo4j.diagnostics]: Total memory: 1,87 GB
2012-07-06 10:51:49,154 DEBUG [neo4j.diagnostics]: Max   memory: 13,33 GB
2012-07-06 10:51:49,588 DEBUG [neo4j.diagnostics]: Storage files:
2012-07-06 10:51:49,589 DEBUG [neo4j.diagnostics]: messages.log: 304,72 kB
2012-07-06 10:51:49,589 DEBUG [neo4j.diagnostics]: neostore.propertystore.db.index: 1,02 kB
2012-07-06 10:51:49,589 DEBUG [neo4j.diagnostics]: neostore.propertystore.db: 401,18 MB
2012-07-06 10:51:49,590 DEBUG [neo4j.diagnostics]: neostore.relationshipstore.db.id: 9,00 B
2012-07-06 10:51:49,590 DEBUG [neo4j.diagnostics]: index.db: 1,42 kB
2012-07-06 10:51:49,590 DEBUG [neo4j.diagnostics]: tm_tx_log.1: 0,00 B
2012-07-06 10:51:49,590 DEBUG [neo4j.diagnostics]: neostore.relationshiptypestore.db.names.id: 9,00 B
2012-07-06 10:51:49,591 DEBUG [neo4j.diagnostics]: neostore.propertystore.db.id: 9,00 B
2012-07-06 10:51:49,591 DEBUG [neo4j.diagnostics]: neostore.nodestore.db: 478,88 kB
2012-07-06 10:51:49,591 DEBUG [neo4j.diagnostics]: nioneo_logical.log.active: 4,00 B
2012-07-06 10:51:49,591 DEBUG [neo4j.diagnostics]: neostore.nodestore.db.id: 9,00 B
2012-07-06 10:51:49,591 DEBUG [neo4j.diagnostics]: neostore.propertystore.db.strings.id: 9,00 B
2012-07-06 10:51:49,592 DEBUG [neo4j.diagnostics]: neostore.id: 9,00 B
2012-07-06 10:51:49,592 DEBUG [neo4j.diagnostics]: neostore.propertystore.db.strings: 34,15 MB
2012-07-06 10:51:49,592 DEBUG [neo4j.diagnostics]: neostore.relationshiptypestore.db.id: 9,00 B
2012-07-06 10:53:01,486 INFO  [neo4j]: GC Monitor: Application threads blocked for an additional 14826ms [total block time: 14.826s]
2012-07-06 10:54:24,019 INFO  [neo4j]: GC Monitor: Application threads blocked for an additional 875ms [total block time: 15.701s]
2012-07-06 10:55:25,441 INFO  [neo4j]: GC Monitor: Application threads blocked for an additional 559ms [total block time: 16.26s]
2012-07-06 11:00:16,962 INFO  [neo4j]: GC Monitor: Application threads blocked for an additional 775ms [total block time: 17.035s]

JVM参数包括

-XX:+DisableExplicitGC
-Xms2000m,
-Xmx15360m

垃圾收集器似乎干扰了执行，为什么会这样？使用JVM参数，我告诉服务器实例使用最大量~15GB的内存应该足够了。

Edit4：执行查询（1）将以下内容添加到日志中：

2012-07-06 11:40:31,973 INFO  [neo4j]: GC Monitor: Application threads blocked for an additional 23745ms [total block time: 23.745s]
2012-07-06 11:40:33,961 INFO  [neo4j]: RelationshipCache array size: 17895751 purge count: 0 size is: 0b, 100.0% misses, NaN% collisions (0).
2012-07-06 11:40:33,966 INFO  [neo4j]: NodeCache array size: 17895751 purge count: 0 size is: 0b, 100.0% misses, NaN% collisions (0).

Answer 1

您是否尝试过多次运行查询，因此您正在使用热图和索引进行操作？

在gremlin上使用关系索引相对较慢

1 个答案: