如何加快我的neo4j实例

时间:2015-11-09 17:08:29

标签: neo4j

我正在运行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节点。

你会建议什么?如果您告诉我您的需求,我很乐意提供更多信息。

提前致谢了。

3 个答案:

答案 0 :(得分:2)

首先升级到2.3版本,因为它应该可以提高性能 - http://neo4j.com/release-notes/neo4j-2-3-0/

提示

  • IN用于包含一个元素的数组是没有意义的。

使用EXPLAINPROFILE

描述您的查询

答案 1 :(得分:2)

以下是一些如何加快查询速度的想法:

  • 如果只有一个元素,请不要使用IN。使用=
  • 随着节点数量的增加,索引查找显然需要更长的时间。您可以使用id_type属性作为标签,而不是具有索引属性的单个标签。像(l:KnownIDTypeCode1)<-[e1:KNOWN_BY]-(m:KnownIDTypeCode2)
  • 之类的东西
  • 将查询分为两部分。首先MATCH您的KNOWN_BY路径,然后使用WITHMATCH HAS_PERSPECTIVE部分收集您需要的内容。
  • StartDTEndDT属性上的范围查询可能很慢。尝试删除它们以测试是否会降低查询速度。
  • 此外,您似乎可以将>=<替换为=,并指出您在任何地方使用相同的日期。
  • 如果您真的需要过多地过滤日期范围,可能有助于在图表模型中实现它。一种选择是使用Knownby个节点而不是KNOWN_BY个关系,并将它们连接到Date个节点。

答案 2 :(得分:0)

马丁,你的第二个建议,加快了我的匹配路径到单位数秒,我很感谢你的帮助。谢谢。虽然它涉及重构我的图形设计和查询模式,但它以指数方式改进了性能。我决定创建CodeType1,CodeType2,CodeType [N]作为节点标签,并最小化节点属性的使用,除了保持边缘的时间属性。再次感谢你!如果有任何我可以提供的帮助,请告诉我。