Fair enough. If that is your evaluation of the article, then that's cool. I usually try not to completely write off people that I know are smarter than I am in a particular area (Stonebraker), just because I don't understand or agree with all of their arguments.
I think the article is much less of a fanboy article and more of an academic "thought provoking" article, though. I think their tone is a little too adversarial, but I believe they are essentially arguing that people can learn a great deal from older DBMS technologies and apply that knowledge to their applications...without always reinventing the wheel. They're arguing that people not forget the past when they look to the future, because combining ideas from both 'camps' might lead to a better solution. A "Best of Both Worlds" approach. Where would we be now if most of the Lisp discoveries and lessons had been assimilated into the programming culture sooner, for example?
I personally think the original article is more in the vein of suggesting deficiencies in using MapReduce for most applications than saying it is a complete dead-end. They acknowledge that "MapReduce may be a good idea for writing certain types of general-purpose computations." They say they are excited by its fault tolerance, etc. They just think it is being misused in many instances where other technologies are superior. I strongly agree with them on that point: there are relatively few use cases where MapReduce is ideal. And even when it is appropriate to use MapReduce, it should usually be augmented by other technology as well. They cite several deficiencies in the MapReduce approach that are completely valid, and I think your 30,000 foot overview of their criticism is misleading.
I think too many people are missing the forest for the trees with the original article (which is partly the fault of the authors, since they could have worded some of their arguments better.) People seem to think that just because Google is doing something that it is the optimal solution...but even Google uses BigTable to get around some of the deficiencies of MapReduce. And what is BigTable? A column-oriented DBMS! And who is one of the world's leading experts on and proponents of those? Why, Michael Stonebraker, the ivory-tower moron who wants to use RDBMS for everything!
As bayareaguy noted: "You have to read the original article very closely or you'll miss their point: in terms of distributed database research, MapReduce is a step backwards."
You said: As bayareaguy noted: "You have to read the original article very closely or you'll miss their point: in terms of distributed database research, MapReduce is a step backwards."
This to me is really funny since I don't think you can view MapReduce as distributed database research. I haven't used it, and while I admit that I might have gotten it all wrong, to me its a library/dsl/paradigm/technique for parallelization of certain data-processing tasks. So to me that statement makes as much sense as "lisp, viewed as a monitor , is a step backward compared to lcds".
Also, while it was a while since i viewed the techtalk on bigtable, and I really agree BigTable is a column-based DBMS, I can't seem to remember that they built it to get around deficiencies in MapReduce, I understood it as a compliment. BUT it might have been much more constructive if, as someone said higher up, they wrote the original article about BigTable, because I do believe that their criticism is actually valid (as in apples vs apples) in some cases regarding BigTable.
I think the article is much less of a fanboy article and more of an academic "thought provoking" article, though. I think their tone is a little too adversarial, but I believe they are essentially arguing that people can learn a great deal from older DBMS technologies and apply that knowledge to their applications...without always reinventing the wheel. They're arguing that people not forget the past when they look to the future, because combining ideas from both 'camps' might lead to a better solution. A "Best of Both Worlds" approach. Where would we be now if most of the Lisp discoveries and lessons had been assimilated into the programming culture sooner, for example?
I personally think the original article is more in the vein of suggesting deficiencies in using MapReduce for most applications than saying it is a complete dead-end. They acknowledge that "MapReduce may be a good idea for writing certain types of general-purpose computations." They say they are excited by its fault tolerance, etc. They just think it is being misused in many instances where other technologies are superior. I strongly agree with them on that point: there are relatively few use cases where MapReduce is ideal. And even when it is appropriate to use MapReduce, it should usually be augmented by other technology as well. They cite several deficiencies in the MapReduce approach that are completely valid, and I think your 30,000 foot overview of their criticism is misleading.
I think too many people are missing the forest for the trees with the original article (which is partly the fault of the authors, since they could have worded some of their arguments better.) People seem to think that just because Google is doing something that it is the optimal solution...but even Google uses BigTable to get around some of the deficiencies of MapReduce. And what is BigTable? A column-oriented DBMS! And who is one of the world's leading experts on and proponents of those? Why, Michael Stonebraker, the ivory-tower moron who wants to use RDBMS for everything!
As bayareaguy noted: "You have to read the original article very closely or you'll miss their point: in terms of distributed database research, MapReduce is a step backwards."