MapReduce — a Major Step Backwards?

The Database Column has an interesting, if negative, look at MapReduce and what it means for the database community. MapReduce is a software framework developed by Google to handle parallel computations over large data sets on cheap or unreliable clusters of computers. "As both educators and researchers, we are amazed at the hype that the MapReduce proponents have spread about how it represents a paradigm shift in the development of scalable, data-intensive applications. MapReduce may be a good idea for writing certain types of general-purpose computations, but to the database community, it is: a giant step backward in the programming paradigm for large-scale data intensive applications; a sub-optimal implementation, in that it uses brute force instead of indexing; not novel at all -- it represents a specific implementation of well known techniques developed nearly 25 years ago; missing most of the features that are routinely included in current DBMS; incompatible with all of the tools DBMS users have come to depend on."

Blink blink

[Thelasko]

Once I saw the word paradigm in the summary I just glazed over like I do whenever our CEO gives a speech.

Re:may be missing the (data)points

[Anonymous Coward]

You missed points 6 through 9:

6. New things are scary.
7. Google is on their lawn.
8. Matlock is the best television show ever.

A step from where?

[644bd346996]

If you are starting with a good database, MapReduce is definitely a step backwards. But that isn't what MapReduce is designed to replace. In reality, MapReduce replaces the for loop [joelonsoftware.com], and viewed from that perspective, it is a major step forward. Most languages (C, C++, Java, etc.) define the for loop and other iteration facilities in such a way that the compiler can seldom safely parallelize the loop. MapReduce gives the programmer an easy way to convert probably 90% of their for loops into highly scalable code.

like Spider Robinson sang..

[hmaon]

"...I taped twenty cents to my transmission
So I could shift my pair 'a dimes..."

Re:Blink blink

[spun]

Ah, the old "eyes glazing over" paradigm. Definitely no synergy in that. Here's an action item: leverage your value added intellectual capital to architect a new scenario.

Re:may be missing the (data)points

[Anonymous Coward]

And its from The Database Column, a blog that from its own "About" page is comprised of experts from the database industry
 
Yes, I'm sure they are, but notice that they were unable to resolve a many to many relationship for authors and articles on their own website's db:
 
  [Note: Although the system attributes this post to a single author, it was written by David J. DeWitt and Michael Stonebraker]

In related news: Screwdrivers suck because...

[DragonWriter]

1) They don't look like hammers,
2) They don't work like hammers,
3) You can already drive in a screw with a hammer,
4) They aren't good at ripping out nails, and
5) They aren't good at driving nails.

Brought to you by The Hammer Column, a blog written by experts in the hammer industry, and launched by Hammertron, makers of a revolutionary new kind of hammer [vertica.com].

Re:may be missing the (data)points

[Anonymous Coward]

9. Profit!

Re:may be missing the (data)points

[abscondment]

It's also terrible for painting.

1. Since the bucket doesn't enforce any schema, you never know what color paint the bucket might hold. Heck, it could even be full of honey. You just can't know, and not being able to know is, well, like programming assembly.
2. Buckets aren't indexed, so you're not able to find that one ounce of paint that you really want to use next. You've got to split up all of the paint into ounce cups each time and examine very cup. It's very intensive, and really slows down your painting. If you stored the paint in a B-tree of ounce cups, your search for the right ounce of paint would be much more efficient.
3. Painting is so old. I mean, get with the program. Gold plate your house, or something newer (since newer is always better!). In fact, decades of research into titanium has determined that it'll hold up better to the elements, anyway, so you should just get titanium siding instead of painting.
4. Painting is an incomplete process. What if you want a window? Yeah, you can't paint a window for yourself, now can you? Did you need a jacuzzi? A fireplace? A new car? Sorry! Painting doesn't support those features yet. You'd better not paint at all if you want those things.
5. Painting, believe it or not, is incompatible with tennis. There's no racket, there's no court, and there's no ball. There's not even a net (unless you're working from a really tall building, in which case you might fall and so a net is often used). I mean, you don't even need to paint with another person. It's so... incompatible.

Re:Indexing is useless here.

[Timothy Brownawell]

Imagine a database with its main column being VARCHAR(255) and using about full length of it, then search using a lot of LIKE and AND, picking various short pieces out of that column, and the database being terabytes big. Try to invent a way to index it.

Convert it to an HTML table and put it where googlebot can see it.