A recent article on the Database Column by David J. DeWitt and Michael Stonebraker attempts to compare the increasingly popular MapReduce programming paradigm to a relational database. The article goes so far as to say:
...As a data processing paradigm, MapReduce represents a giant step backwards. The database community has learned the following three lessons from the 40 years that have unfolded since IBM first released IMS in 1968....Given the experimental evaluations to date, we have serious doubts about how well MapReduce applications can scale. Moreover, the MapReduce implementers would do well to study the last 25 years of parallel DBMS research literature.
The article goes on to list criteria such as:
- MapReduce is a poor implementation (in comparison to B-trees)
- MapReduce is not novel
- MapReduce is missing features (such as loading and indexing)
- MapReduce is incompatible with the DBMS tools
The blogsphere has quickly called foul on the comparison and its reasoning. Greg Jorgensen provides a detailed rebuttal. Among the items he notes are that MapReduce is not a database but an algorithmic technique for distributed processing and should not be compared to one. Jorgensen proposes that a better comparison would have been to SimpleDB:
...What the authors really want to gripe about is distributed “cloud” data management systems like Amazon’s SimpleDB; in fact if you change “MapReduce” to “SimpleDB” the original article almost makes sense...
Rich Skrenta comments on the angle of disruption:
...The thing that disrupts you is always uglier and worse in some way. Less features, less developed. But if there's a 10X price win in there somewhere, the cheap rickety thing wins in the end. Think Linux vs. AT&T Unix, or mysql vs. Oracle...
Lengthy debate and comment on the topic can also be found on reddit and ycombinator.