They're on the money
As a database professional with 20 odd years experience I'd say the criticism they offer is quite constrained!
A database pioneer and honored computer science professor have come under heavy fire for issuing a strong critique of Google's MapReduce technology for processing large unstructured databases. Ingres inventor and Postgres architect Mike Stonebraker and his colleague, University of Wisconsin computer science professor David …
While I'll admit I haven't looked into this case too deeply, Im wondering how many of the "you don't know what your talking about' comments on their blog came from Google Fanboys who think the big G can do no wrong.
The statistic of 20PB of data is fairly pointless to unless you know how much computing power they are using to process that, it could be the traditional methods could process only a fraction of that, but we don't know.
You can quicksort in MapReduce, but you can't grammar search in a DBMS. So his argument is just a defence of the status quo.
Geeze we've had maps.google.com for years, but SQL Server is only just getting Spatial data types!
Imagine if you can't make anything new, unless the database first extends the schema to support it...
"Stonebraker and DeWitt had criticized MapReduce and slammed moves to introduce MapReduce into the academic curriculum."...as a data-management system. As a distributed data-processing system, I suspect they care less (although they do address their concerns with scalable-performace; ie. the push/pull transfer of data). All-in-all, good criticism.
These DBMS experts are right, they just miss the big picture.
MapReduce is quite suboptimal. It really does duplicate a lot of work, and do other work very inefficiently. The thing they have missed, doing it in a more optimal manner would require an absolutely collosal machine or closely coupled cluster, which I think simply could not scale to anywhere near the size someone like Google has.
MapReduce proper isn't novel -- it's been known in comp sci for decades. It IS novel to use it in such a huge setup as Google has and make it do useful work though. DBMS setups simply wouldn't scale this high.
They are also quite right that MapReduce won't use traditional DBMS tools -- some, such as backups and various tacked-on rollback functionality, are simply unneeded in something like the google cluster (files are inherently backed up -- there's always multiple copies, and things are cross-checked so if a machine croaks, it's contents are re-backed up out of the backups.) I wouldn't use MapReduce in replacement of a DBMS setup. But that's just not what it's really used for...
Anyway, I wouldn't say they're all totally full of crap etc. like some have said, I would just say they argued against using MapReduce for a DBMS and missed what it's really used for.
Biting the hand that feeds IT © 1998–2020