My use case is that, given a very capable single node system, how do I make a single invocation of the example above (or the like) fully utilize this node ? In other words, it goes back to the theme that I mentioned in a previous post of making single deep searches parallel.
I find it difficult/impossible to keep such a system busy with serial sets of matches. Subsequent searches depend on the o/p of previous searches. Wayne On Tuesday, 18 April 2017 08:26:42 UTC+1, Max De Marzi Jr. wrote: > > Scale to do what exactly? > > On Monday, April 17, 2017 at 1:47:15 AM UTC-5, [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.
