在gremlin上使用關係索引相對較慢

Question

在Neo4j中，我有一個包含約180000個邊的關係索引'index_e_ASSOC_sMETHdGEXP'，全部都有一個屬性'property'。我想做一個簡單的查詢，在索引中列出200條邊，無論屬性值如何（稍後執行一個查詢，像獲取邊緣屬性爲< = 0.01的200個第一個邊的頂點的相同屬性值），並從出的節點取幾個屬性值：

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。它開始看起來像一個緩存問題。

的數據庫日誌的有趣片段：

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

您是否嘗試過運行查詢多次，所以你在一個溫暖的圖形和索引操作？