You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tinkerpop.apache.org by "Marko A. Rodriguez (JIRA)" <ji...@apache.org> on 2016/02/18 03:03:18 UTC

[jira] [Created] (TINKERPOP-1164) ReducingBarriersSteps should use ComputerMemory, not MapReduce.

Marko A. Rodriguez created TINKERPOP-1164:
---------------------------------------------

             Summary: ReducingBarriersSteps should use ComputerMemory, not MapReduce.
                 Key: TINKERPOP-1164
                 URL: https://issues.apache.org/jira/browse/TINKERPOP-1164
             Project: TinkerPop
          Issue Type: Improvement
          Components: process
    Affects Versions: 3.1.0-incubating
            Reporter: Marko A. Rodriguez


This just hit me like a ton of bricks. Check this:

{code}
g.V().count()
{code}

That is:

{code}
TraversalVertexProgram + CountMapReduce
{code}

Thats stupid. Just use the "reduction" aspects of {{Memory}}. Replace {{CountMapReduce}} with:

{code}
memory.incr("~reducing", traverser.bulk())
{code}

Thats it. Likewise for all the other reducing barriers! Now, not only do we don't have to do a {{MapReduce}} job, we don't even have to break out of the {{TraversalVertexProgram}} (no more "No mid-barrier steps."). Why? Well, because its in memory, its computed on that iteration and then accessible!

{code}
g.V().group().by('lang').select('java').values("name")
{code}

That would be one TraversalVertexProgram!

.....................why do we even have MapReduce.......................... is Memory all we really need. Crazy.............................................. thats craZy talk................................. but still, think about it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)