News for hackers. Stuff that matters.
Re:Google's Introduction to Parallel Programming and MapReduce by gruseom on Sunday October 23, 2011 @02:22PM (#3146822)
Couldn't it at least perform the reduce on the portion it does have? i.e. transfer partial reductions from M to R, instead of the raw map results? Presumably there are many problems where this would be a win.
Re:Google's Introduction to Parallel Programming and MapReduce by moultano on Sunday October 23, 2011 @02:29PM (#3146837)
Yes that's sometimes an option, but very often the reduce isn't associative.
Re:Google's Introduction to Parallel Programming and MapReduce by gruseom on Sunday October 23, 2011 @02:41PM (#3146865)
Ah, so that's the reason. Do you ever have the problem that the reduce computation, for a given key, is too big for one reduce worker and itself needs to be parallelized? Or does this boil down to the same thing as my previous question - i.e. if the reduce computation isn't associative, you couldn't parallelize it anyway, and if it is then you can just do partial reductions on M.
Re:Google's Introduction to Parallel Programming and MapReduce by moultano on Sunday October 23, 2011 @02:59PM (#3146925)
Yes that is often a problem and is probably my biggest criticism of mapreduce as a framework. Extreme reduce keys often have to be handled differently and in a way dependent on the nature of the problem. Mapreduce doesn't provide great tools for handling it, though I'm not even sure what abstraction you could build that would be comprehensive enough.