Database gurus slammed for Google post

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 …

[Anonymous Coward]

They're on the money

As a database professional with 20 odd years experience I'd say the criticism they offer is quite constrained!

[David Tonhofer]

Absolutely something for "semi-coherent computing"

...hopefully

[Anonymous Coward]

Don't you think it's more likely

to have the kind of data these database gurus are used to than the huge blob that Google has no one has data like they have no one ever, anywhere, it's completely specialized no problem just ignore them.

[Ian Michael Gumby]

Both are on the bleeding edge.

It took Informix now IBM 10 years to fully incorporate Stonebraker's Illustra in to IDS.

I'd say that they know what they're talking about.

[Andrew]

The Google Effect

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.

[Anonymous Coward]

How many search engines are built in a DBMS? None?

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...

[Anonymous Coward]

I think the quality of Mr. Manchester's article is pretty low.

Apart from the title, it reads like it was written by the Columbia NLP Newsblaster running in Fox news "fair and balanced" mode. Other than a few errors, the text is just a collection of fragments of what others have said

[Anonymous Coward]

missing the point

My take on the article is not that they dislike mapreduce per se, but more that they're responding to the frequently issued view that mapreduce makes databases redundant because 'google use it and look how much data they index'. As such, fair play to them.

[Anonymous Coward]

DataTypes & Processing

"Imagine if you can't make anything new, unless the database first extends the schema to support it..."

What? Like we couldn't process currency amounts until we had the currency datatype? LOL!

[Anonymous Coward]

The issue as I see 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.

[Steve Martin]

Anonymous Idiot

Any chance of an article soon that has less than 100 comments by the Anonymous Idiot?

[Henry Wertz]

Well..

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.