[英]Neo4J query poor performance
我正在使用NEO4J數據庫執行“壓力測試”。 沒什么大不了的,但是部分結果使我懷疑這種技術是否適合在線應用程序(或者我根本不了解Cypher)。
第一個測試是像
(1° node) -[:NEXT_FRAME]-> () -[:NEXT_FRAME]-> () -[:NEXT_FRAME]-> () -[:NEXT_FRAME]-> ... -[:NEXT_FRAME]-> (last node)
然后使用此查詢檢索整個路徑
START n=node:Frame(node_id="0"), m=node:Frame(node_id="9000")
MATCH p=(n)-[:FRAME_NEXT*]->(m)
RETURN p
ORDER BY m.node_id DESC
LIMIT 1
注意,當m.node_id == 2
,查詢大約需要100毫秒。 現在有約9000個節點,最多可能需要30秒。 我不是專家,但是時間太多了! 我認為9K節點不會產生太大的變化。
那么,我想念什么?
干杯(和聖誕快樂)
編輯:
我正在使用py2neo並以這種方式計時查詢:
q_str = """
START n=node:Frame(node_id="0"), m=node:Frame(node_id="%d")
MATCH p=(n)-[:FRAME_NEXT*]->(m)
RETURN p
ORDER BY m.node_id DESC
LIMIT 1
""" % (i,)
print q_str
before = datetime.datetime.now()
query = neo4j.CypherQuery(graph_db, q_str)
record, = query.execute().data
after = datetime.datetime.now()
diff = after - before
diff_ms = diff.total_seconds() *1000
print 'Query took %.2f ms' % (diff_ms)
這是Cypher的缺點,目前無法很好地處理較長的可變長度路徑。
您可以嘗試MATCH p=shortestPath((n)-[:FRAME_NEXT*]->(m))
嗎?
另外,如果可以,您是否可以嘗試Neo4j 2.0,而不是使用標簽和新索引來使用舊索引。 根據查詢計划,應該使用更快的雙向遍歷匹配器。
MATCH (n: Frame {node_id:"0"})-[:FRAME_NEXT*]->(m:Frame {node_id:"9000"})
RETURN p
另外,使用REST遍歷器可能會更好: http : //docs.neo4j.org/chunked/milestone/rest-api-traverse.html
或REST-graph-algo: http : //docs.neo4j.org/chunked/milestone/rest-api-graph-algos.html
如果只有一條路徑,則可以刪除ODER BY
和LIMIT
。 另外,嘗試使用shortestPath
函數,即使您的圖形中只有一條匹配的路徑(即,即使所有路徑都是最短的),它也可以更快。 最后,如果您知道可變深度關系的深度,請在您的模式中聲明該深度,並且如果您僅大致知道深度,則指定一個范圍。 嘗試將這些組合進行比較,您可以在neo4j-shell中對其進行概要分析,並查看執行計划。
MATCH p=(n)-[:FRAME_NEXT*9000]->(m)
MATCH p=(n)-[:FRAME_NEXT*8900..9100]->(m)
MATCH p=shortestPath( (n)-[:FRAME_NEXT*]->(m) )
MATCH p=shortestPath( (n)-[:FRAME_NEXT*8900..9100]->(m) )
聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.