A PL/SQL function is not parallelizeable by default when executed inside a DBMS. When (not if) this happens, a DBMS will be able to do what MapReduce can do.

According to the paper’s conclusions: “DBMS-X was 3.2 times faster than Map/Reduce and Vertica was 2.3 times faster than DBMS-X”.

I have a presentation posted online for anyone looking for a primer on Hadoop and HBase and how they compare to relational databases. I address some of the limitations of each and what their strong points are.

http://www.docstoc.com/docs/2996433/Hadoop-and-HBase-vs-RDBMS

Setting aside performance questions for a moment, there are good reasons why many programmers prefer to express their problems in MapReduce rather than SQL. And likewise why DBAs and analysts generally prefer SQL rather than getting their hands dirty writing code. Each is trained to approach problems in a certain way, and they prefer the mode of expression that best fits with their skills and experience.

The good news is that Hadoop isn’t synonymous with MapReduce from a performance perspective. Here at Greenplum we’ve implemented MapReduce natively on our parallel dataflow engine, using the same building blocks used to execute SQL at high performance and massive scale. That means that user get the best of both worlds — the ability to analyze their data using SQL, MapReduce or both together in the same program — with industry-leading performance in either case.

http://www.greenplum.com/news/196/231/Product-Perspective-SQL-and-MapReduce-The-choice-is-yours/d,blog/

Most of the tasks being benchmarked were optimized for SQL DBs because they were the most cost-effective systems when those business processes were designed. We will be soon assigning them to the long, slow profitable declining category of “legacy systems.” As with any other transition, the change will not be universal. Mainframes are still the best for a number of tasks but no longer for the bulk of them.

Lookery and hundreds of other companies, many cloud-hosted, are building new business processes that are optimized for MapReduce and similar architectures. In many — even most — cases, these business processes will be far more cost-effective than the ones they will replace. New incumbents will arise, new benchmarks written, and new statistics reported by analysts with new biases.

Companies invested in SQL apps that can be replaced, most often indirectly, by MapReduce-esque apps need to start self-cannibalizing.

Also, Hadoop isnt a variant of MapReduce, it turns tasks into MapReduce jobs to be carried out over large data sets.

This is kinda what the Enterprise is geared up today with EDW and core applications as seperate departments , the difference is going to be the near-realtime nature of EDW providing the readonly views for consumption for core applications

More interestingly, the tradeoff is not inherent to databases but the result of a longstanding unsolved algorithm problem in computer science — the MapReduce/SQL dichotomy is the result of workaround hacks. If a company solved that underlying problem, you could build a distributed database system that had capabilities markedly superior to both the current crop of both Hadoop/Google type databases and clustered SQL databases. There are a lot of applications and data sets that are inadequately served by either existing database model.

Great stuff and a welcome improvement in the market, but MapReduce and SQL are not likely to be the last word.