Hi Michael,
Haha, true.
The statement in the manual is for the core (Java) API, we're currently
working on making that kind of performance available through cypher too.
Just a few questions:
* can you share your graph.db/messages.log for diagnostics on config.
* do you run your queries in the browser? or via the neo4j-shell? or from a
program?
* what does the output of :schema look like?
* what is the maximum depth in your tree?
* can you try to prefix your query with cypher 2.1.experimental (which is
the new query planner)
* as you bound both nodes and you have a tree, what you're interested in is
the shortest path between those (I think)
MATCH (assy:Assy {k_ebene: 'MODEL'}), (mat:Mat {m_matnr: "A4420380071"})
MATCH shortestPath((assy)-[:HAS*..]->(mat))
RETURN distinct assy.k_vari order by assy.k_vari limit 1000
* how many paths does this return?
MATCH (assy:Assy {k_ebene: 'MODEL'})-[:HAS*..]->(mat:Mat {m_matnr:
"A4420380071"})
RETURN count(*)
I asusme that :Mat is more selective, so can you try using:
MATCH (assy:Assy {k_ebene: 'MODEL'})-[:HAS*..]->(mat:Mat {m_matnr:
"A4420380071"})
USING INDEX mat:Mat(m_matnr)
RETURN count(*)
Depending the # of returned paths, sorting all of them by assy.k_vari can
take time too, same for creating the distin
can you try how much time this takes?
MATCH (assy:Assy {k_ebene: 'MODEL'})-[:HAS*..]->(mat:Mat {m_matnr:
"A4420380071"})
RETURN distinct assy.k_vari
HTH
Michael
On Sun, Nov 23, 2014 at 11:07 AM, <m...@docware.de> wrote:
> Hi (or should I already say "Hi Michael Hunger" because you seem to answer
> most questions),
>
> We currently maintain a "directed acyclic graph" in SQL databases (the
> usual products). For large graphs traversing is a problem. A typical
> question is "Tell me all nodes with a certain property that have a
> relationshop to a given node". In SQL we do a usual recursive depth-first
> traversal. Already visited nodes are stored in white or black lists. So
> typically this involves several thousands SQL statements and at the end you
> habe also several thousands nodes in the white or black lists. The query
> usually takes from a few seconds to say 30 seconds. The SQL server is
> connected locally or through a LAN.
>
> We would like to find out if a graph database like neo4j could be an
> improvement here. So we did an import of one of our bigger databases into
> neo4j Enterprise 2.1.5 evaluation. Here are the numbers: 3.2 M nodes (2
> types), 24 M properties, 22 M relationships (1 uni-directed type), disk
> usage 9,6 GB.
>
> To our disappointment, the query times are comparable to our SQL results.
> Sometimes they are 100% better, but in no way an order of magnitude, which
> we hoped from what the neo4j manual promises ("Querying is performed
> through traversals, which can perform millions of traversal steps per
> second").
> This is the query we use:
> MATCH (assy:Assy {k_ebene: 'MODEL'})-[:HAS*..]->(mat:Mat {m_matnr:
> "A4420380071"})
> RETURN distinct assy.k_vari order by assy.k_vari limit 1000
>
> Upfront indices have been created for the Assy and Mat nodes.
>
> So far we use a default setup on a fast Windows 8 developer machine with a
> lot memory.
>
> Our question is, do you see any potential for a performance boost for us
> here?
>
> Thanks in advance!
>
>
> Michael (yes also Michael)
>
> --
> You received this message because you are subscribed to the Google Groups
> "Neo4j" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to neo4j+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
--
You received this message because you are subscribed to the Google Groups
"Neo4j" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to neo4j+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
