19 January 2008

Inflating MapReduce

There has been a lot of coverage regarding the Database Column's take on MapReduce.

Greg Jorgensen wrote a good rebuttal. A little too good... That bit about replacing 'MapReduce' with 'SimpleDB' was going to be my angle! There are also some good comments, on Slashdot.

I can see where DeWitt and Stonebraker are coming from and I agree with many of their points--though in general, and not necessarily related to MapReduce. I think that they failed to fully frame where they are coming from. They reference universities teaching MapReduce; is this an academia trend that they are seeing? Do they perceive MapReduce as being tought in lieu of relational theory? Now that would be cause for concern as they solve two different problems. Google is not claiming that MapReduce is a solution to data management, are they?

One point that I feel compelled to partially defend DeWitt and Stonebraker on is one that everyone seems to be having a go at: "Given the experimental evaluations to date, we have serious doubts about how well MapReduce applications can scale." Many people are saying, "Scaling? Google? That's a laugh!" They have a point, but they are only considering scaling in one direction; Google's data is largely narrow. Do DeWitt and Stonebraker mean scaling horizontally? Or do they mean performance acceptably scales with the hardware? Again, I think that they failed to frame their argument. As well, they failed to justify their reasoning on why MapReduce is their target.

A few months ago Stonebraker called RDBMSes "legacy technology." My interpretation, he was saying RDBMSes are not one-size-fits-all and you should buy his product because it is column-oriented and it is really fast... for data warehousing. To his credit, he does say that DBMS engines should allow for vertical internals. With the escalating sizes of databases, I imagine the larger DBMS players will get around to this. Is he threatened by the "new" technology he asked for a few months ago? Or maybe he wants publicity for his product? Either way, wearing business and theory hats at the same time is not good practice.

No comments: