我正在运行neo4j 2.2.5版。我喜欢所有CYPHER语言,Python集成,易用性和响应迅速的用户社区。
我开发了一个应用程序的原型,并且遇到了一些非常糟糕的性能时间。我已经阅读了许多与性能调优相关的链接。我将尝试在此概述我的整个数据库,以便有人可以为我提供指导。
我的机器是MacBook Pro,16GB内存和500GB SSD。我在Spark + Python + Hadoop中做的其他事情都非常快。它对Neo4j来说也很快,但是当我想要2-4M节点然后它的速度非常慢。
我已经使用这两个命令来启动neo4j,认为它们会有所帮助,而且它们都没有帮助:
./neo4j-community-2.2.5/bin/neo4j start -Xms512m -Xmx3g -XX:+UseConcMarkSweepGC
./neo4j-community-2.2.5/bin/neo4j start -Xms512m -Xmx3g -XX:+UseG1GC
我的neo4j.properties文件如下:
################################################################
# Neo4j
#
# neo4j.properties - database tuning parameters
#
################################################################
# Enable this to be able to upgrade a store from an older version.
#allow_store_upgrade=true
# The amount of memory to use for mapping the store files, in bytes (or
# kilobytes with the 'k' suffix, megabytes with 'm' and gigabytes with 'g').
# If Neo4j is running on a dedicated server, then it is generally recommended
# to leave about 2-4 gigabytes for the operating system, give the JVM enough
# heap to hold all your transaction state and query context, and then leave the
# rest for the page cache.
# The default page cache memory assumes the machine is dedicated to running
# Neo4j, and is heuristically set to 75% of RAM minus the max Java heap size.
dbms.pagecache.memory=6g
# Enable this to specify a parser other than the default one.
#cypher_parser_version=2.0
# Keep logical logs, helps debugging but uses more disk space, enabled for
# legacy reasons To limit space needed to store historical logs use values such
# as: "7 days" or "100M size" instead of "true".
#keep_logical_logs=7 days
# Enable shell server so that remote clients can connect via Neo4j shell.
#remote_shell_enabled=true
# The network interface IP the shell will listen on (use 0.0.0 for all interfaces).
#remote_shell_host=127.0.0.1
# The port the shell will listen on, default is 1337.
#remote_shell_port=1337
# The type of cache to use for nodes and relationships.
#cache_type=soft
要从一个全新的开始创建我的数据库,我首先创建这些索引,它们在我的所有节点类型和我正在使用的边上。
CREATE CONSTRAINT ON (id:KnownIDType) ASSERT id.id_type_value IS UNIQUE;
CREATE CONSTRAINT ON (p:PerspectiveKey) ASSERT p.perspective_key IS UNIQUE;
CREATE INDEX ON :KnownIDType(id_type);
CREATE INDEX ON :KnownIDType(id_value);
CREATE INDEX ON :KNOWN_BY(StartDT);
CREATE INDEX ON :KNOWN_BY(EndDT);
CREATE INDEX ON :HAS_PERSPECTIVE(Country);
我有8,601,880个节点。
我运行此查询,需要9分钟。
MATCH (l:KnownIDType { id_type:'CodeType1' })<-[e1:KNOWN_BY]-(m:KnownIDType { id_type:'CodeType2' })-[e2:KNOWN_BY]->(n:KnownIDType)<-[e3:KNOWN_BY]-(o:KnownIDType { id_type:'CodeType3' })-[e4:KNOWN_BY]->(p:KnownIDType { id_type:'CodeType4' }), (n)-[e5:HAS_PERSPECTIVE]->(q:PerspectiveKey {perspective_key:100})
WHERE 1=1
AND l.id_type IN ['CodeType1']
AND m.id_type IN ['CodeType2']
AND n.id_type IN ['CodeTypeA', 'CodeTypeB', 'CodeTypeC']
AND o.id_type IN ['CodeType3']
AND p.id_type IN ['CodeType4']
AND 20131231 >= e1.StartDT and 20131231 < e1.EndDT
AND 20131231 >= e2.StartDT and 20131231 < e2.EndDT
AND 20131231 >= e3.StartDT and 20131231 < e3.EndDT
AND 20131231 >= e4.StartDT and 20131231 < e4.EndDT
WITH o, o.id_value as KnownIDValue, e5.Country as Country, count(distinct p.id_value) as ACount
WHERE AmbiguousCount > 1
RETURN 20131231 as AsOfDate, 'CodeType' as KnownIDType, 'ACount' as MetricName, count(ACount) as MetricValue
;
我正在寻找更多15秒或更短的响应时间。像我一样&lt; 1M节点。
你会建议什么?如果您告诉我您的需求,我很乐意提供更多信息。
提前致谢了。
答案 0 :(得分:2)
首先升级到2.3版本,因为它应该可以提高性能 - http://neo4j.com/release-notes/neo4j-2-3-0/
提示
IN
用于包含一个元素的数组是没有意义的。使用EXPLAIN
和PROFILE
答案 1 :(得分:2)
以下是一些如何加快查询速度的想法:
IN
。使用=
id_type
属性作为标签,而不是具有索引属性的单个标签。像(l:KnownIDTypeCode1)<-[e1:KNOWN_BY]-(m:KnownIDTypeCode2)
。MATCH
您的KNOWN_BY
路径,然后使用WITH
和MATCH
HAS_PERSPECTIVE
部分收集您需要的内容。StartDT
和EndDT
属性上的范围查询可能很慢。尝试删除它们以测试是否会降低查询速度。>=
和<
替换为=
,并指出您在任何地方使用相同的日期。Knownby
个节点而不是KNOWN_BY
个关系,并将它们连接到Date
个节点。答案 2 :(得分:0)
马丁,你的第二个建议,加快了我的匹配路径到单位数秒,我很感谢你的帮助。谢谢。虽然它涉及重构我的图形设计和查询模式,但它以指数方式改进了性能。我决定创建CodeType1,CodeType2,CodeType [N]作为节点标签,并最小化节点属性的使用,除了保持边缘的时间属性。再次感谢你!如果有任何我可以提供的帮助,请告诉我。