The addition of the 2nd label (+ index) will change your query from a full
graph scan with property filter to an index lookup or seek with an expand,
which is many times more efficient.
If you use counts you should also know when to use *size ((n)-[:FOO]->())*
to get a fast degree.
This should work:
WITH 10 as partitions
MATCH (n:Entity) where n.name IN ['a1', 'a2', 'a3', 'a4', 'a5']
WITH partitions, collect(n) as nodes
UNWIND nodes as n
call apoc.cypher.mapParallel2("
MATCH path = allShortestPaths( (n)-[*..2]-(_) )
RETURN path
", {n:n}, nodes, partitions) yield value
RETURN value.path as path limit 1000;
Cheers, Michael
On Tue, Apr 18, 2017 at 7:00 PM, unrealadmin23 via Neo4j <
[email protected]> wrote:
>
> Interesting - I rarely observe a speed up adding the 2nd label but I will
> bear this in mind.
> The number of results returned vary from 0 to tens of thousands or perhaps
> just counts.
> I often parse these and feed into new queries. I use Linux bash for this;
> it doesn't really matter; its the queries that take the time.
>
> So should the apoc cypher.mapParallel directive improve the real-time
> performance / parallelisation of my use case above ?
>
> There are few examples of using this directive on the web.
>
> How might I re-write :
>
> MATCH (n:Entity) where n.name IN ['a1', 'a2', 'a3', 'a4', 'a5'] WITH
> collect(n) as nodes UNWIND nodes as n UNWIND nodes as m MATCH path =
> allShortestPaths( (n:Entity)-[*..2]-(m:Entity) ) RETURN path limit 1000;
>
> using the mapParallel directive as an example ?
>
> Wayne
>
>
> On Tuesday, 18 April 2017 10:15:48 UTC+1, Michael Hunger wrote:
>>
>> Btw. your query
>>
>> match (n:Entity)-[*4]-(p) where p.name contains "......."
>>
>> Add a label to p, add an index to :Label(name)
>>
>> Then it should perform better,
>> What do you do with the results from that pattern match ?
>>
>> How many do you return?
>>
>> Michael
>>
>> On Mon, Apr 17, 2017 at 8:47 AM, unrealadmin23 via Neo4j <
>> [email protected]> wrote:
>>
>>> I have 128 threads. However access to systems with much more than this
>>> is an option. Currently though, I cannot get Neo4j to scale....
>>>
>>> Wayne
>>>
>>> On Monday, 3 April 2017 11:52:17 UTC+1, Michael Hunger wrote:
>>>>
>>>> There is some of that in apoc.cypher.mapParallel, but it's not as
>>>> performant as it should be, I have to check again what keeps it back from
>>>> performing.
>>>>
>>>> How many CPUs do you have on your system?
>>>>
>>>> Cheers, Michael
>>>>
>>>>
>>>> On Sat, Apr 1, 2017 at 10:53 AM, unrealadmin23 via Neo4j <
>>>> [email protected]> wrote:
>>>>
>>>>> So is there a generic way of parallel threading for searches ?
>>>>>
>>>>> match (n:Entity)-[*4]-(p) where p.name contains "......." Takes a
>>>>> long time on my system and uses 1 thread....
>>>>>
>>>>> If so, could this not be part of apoc or the like ?
>>>>>
>>>>>
>>>>> On Friday, 31 March 2017 15:56:07 UTC+1, Max De Marzi Jr. wrote:
>>>>>>
>>>>>> This POC hits a bunch of your points => https://maxdemarzi.com/2017
>>>>>> /01/06/multi-threading-a-traversal/
>>>>>>
>>>>>> On Friday, March 31, 2017 at 3:58:26 AM UTC-5,
>>>>>> [email protected] wrote:
>>>>>>>
>>>>>>> So I would like to see a benchmark that majors on the 'deep search'
>>>>>>> performance of the various graph databases, which would draw upon:
>>>>>>>
>>>>>>> 1. Multi threading (for single searches mainly) but for other
>>>>>>> operations also - limited by the capability of the graph DB
>>>>>>> 2. In memory enhancements.- limited by the capability of the graph DB
>>>>>>> 3. The ability to pointer chase (for optimisation) - limited by the
>>>>>>> capability of the graph DB
>>>>>>> 4. The graph data should comprise complex relationships, not just
>>>>>>> straight forward hierarchies.
>>>>>>> 5. The benchmark should be scalable (including the ability to fully
>>>>>>> utilise very capable nodes).
>>>>>>>
>>>>>>> Wayne.
>>>>>>>
>>>>>>> On Thursday, 30 March 2017 21:49:27 UTC+1, Andrii Stesin wrote:
>>>>>>>>
>>>>>>>> http://orientdb.com/orientdb-vs-neo4j/
>>>>>>>>
>>>>>>>> what are they speaking about, I wonder?!
>>>>>>>>
>>>>>>>> WBR,
>>>>>>>> Andrii
>>>>>>>>
>>>>>>> --
>>>>> 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 [email protected].
>>>>> 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 [email protected].
>>> 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 [email protected].
> 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 [email protected].
For more options, visit https://groups.google.com/d/optout.
