Comments on: Stonebraker, DeWitt, et al. compare MapReduce to DBMS http://www.dbms2.com/2009/04/14/stonebraker-dewitt-et-al-compare-mapreduce-to-dbms/ Choices in data management and analysis Thu, 09 Feb 2012 13:48:12 +0000 hourly 1 http://wordpress.org/?v=3.0.3 By: Daniel Abadi on Kickfire and related subjects | DBMS2 -- DataBase Management System Services http://www.dbms2.com/2009/04/14/stonebraker-dewitt-et-al-compare-mapreduce-to-dbms/#comment-124496 Daniel Abadi on Kickfire and related subjects | DBMS2 -- DataBase Management System Services Sun, 07 Jun 2009 22:26:09 +0000 http://www.dbms2.com/?p=748#comment-124496 [...] In general, seeing Abadi be so favorable toward Vertica competitors adds credibiity to the recent Hadoop vs. DBMS paper. [...] [...] In general, seeing Abadi be so favorable toward Vertica competitors adds credibiity to the recent Hadoop vs. DBMS paper. [...]

]]> By: Vertica Gathers Momentum with New Release « Market Strategies for IT Suppliers http://www.dbms2.com/2009/04/14/stonebraker-dewitt-et-al-compare-mapreduce-to-dbms/#comment-120305 Vertica Gathers Momentum with New Release « Market Strategies for IT Suppliers Thu, 07 May 2009 01:30:49 +0000 http://www.dbms2.com/?p=748#comment-120305 [...] up for his usual provocative comments - see the discussion of Mapreduce on Curt Monash’s blog here for a great example, if you like to dig deep. (Curt also has several useful posts about Vertica well [...] [...] up for his usual provocative comments – see the discussion of Mapreduce on Curt Monash’s blog here for a great example, if you like to dig deep. (Curt also has several useful posts about Vertica well [...]

]]> By: Ashwin Jayaprakash http://www.dbms2.com/2009/04/14/stonebraker-dewitt-et-al-compare-mapreduce-to-dbms/#comment-116864 Ashwin Jayaprakash Tue, 14 Apr 2009 19:56:35 +0000 http://www.dbms2.com/?p=748#comment-116864 Something very odd about the Hadoop/Java tests. The JVM arguments say "-client". Now, anybody who has worked on Java can tell you that you are supposed to use the "-server" option. The server and client JVM optimizations are worlds apart. Something very odd about the Hadoop/Java tests. The JVM arguments say “-client”. Now, anybody who has worked on Java can tell you that you are supposed to use the “-server” option. The server and client JVM optimizations are worlds apart.

]]> By: Steve Wooledge http://www.dbms2.com/2009/04/14/stonebraker-dewitt-et-al-compare-mapreduce-to-dbms/#comment-116841 Steve Wooledge Tue, 14 Apr 2009 14:03:46 +0000 http://www.dbms2.com/?p=748#comment-116841 While we agree with many of the points in the study, it misses the big picture…why wouldn’t you use both SQL AND MapReduce? Asking if you should use SQL OR MapReduce is like asking if you should tie your left or right hand behind your back. SQL is very good at some things, and MapReduce is very good at others. Why not leverage the best of both worlds - use SQL for traditional database operations and MapReduce for richer analysis that cannot be expressed by SQL, in a single system. While the study notes that MapReduce also requires developers to write features or perform tasks manually that can be done automatically by most SQL databases, we have eliminated that hassle by providing both SQL and MapReduce capabilities. So essentially, our customers can maximize developer productivity, using SQL for regular data processing and MapReduce for richer analysis. At the end of the day, MapReduce is a technology that some vendors are and should be quite afraid of (isn’t that usually why they sponsor studies? ;-), since it provides some amazing capabilities. As a developer or DBA, why on earth wouldn’t you leverage the power of both? Thanks, Steve P.S. We recently blogged about our Enterprise-class MapReduce capabilities and noted the key advantages that a system like ours provides over a pureplay MapReduce implementation - http://www.asterdata.com/blog/index.php/2009/04/02/enterprise-class-mapreduce/ Here are even more examples of why you would want to use both SQL and MapReduce: http://www.asterdata.com/blog/index.php/2009/03/13/sqlmapreduce-faster-answers-to-your-toughest-queries/ While we agree with many of the points in the study, it misses the big picture…why wouldn’t you use both SQL AND MapReduce? Asking if you should use SQL OR MapReduce is like asking if you should tie your left or right hand behind your back. SQL is very good at some things, and MapReduce is very good at others. Why not leverage the best of both worlds – use SQL for traditional database operations and MapReduce for richer analysis that cannot be expressed by SQL, in a single system.

While the study notes that MapReduce also requires developers to write features or perform tasks manually that can be done automatically by most SQL databases, we have eliminated that hassle by providing both SQL and MapReduce capabilities. So essentially, our customers can maximize developer productivity, using SQL for regular data processing and MapReduce for richer analysis.

At the end of the day, MapReduce is a technology that some vendors are and should be quite afraid of (isn’t that usually why they sponsor studies? ;-) , since it provides some amazing capabilities. As a developer or DBA, why on earth wouldn’t you leverage the power of both?

Thanks,
Steve

P.S. We recently blogged about our Enterprise-class MapReduce capabilities and noted the key advantages that a system like ours provides over a pureplay MapReduce implementation – http://www.asterdata.com/blog/index.php/2009/04/02/enterprise-class-mapreduce/

Here are even more examples of why you would want to use both SQL and MapReduce: http://www.asterdata.com/blog/index.php/2009/03/13/sqlmapreduce-faster-answers-to-your-toughest-queries/

]]> By: Steven http://www.dbms2.com/2009/04/14/stonebraker-dewitt-et-al-compare-mapreduce-to-dbms/#comment-116839 Steven Tue, 14 Apr 2009 13:42:46 +0000 http://www.dbms2.com/?p=748#comment-116839 I'm neither anti or pro MapReduce, probably because I have only read about it. Is it purely that it indirectly casts aside a DBMS? MapReduce strikes me as something to be used to categorize (key) large blobs of data where the only three things you know at the time of categorization are that you have a blob of data, you'll get some random key, and you'll get more blobs of data at a later time. Are the anti-MapReduce (pro-DBMS?) people saying that you should go analyze all the blobs and key them every possible way into a schema? Or are they saying that there is a solution in between the two solutions? I’m neither anti or pro MapReduce, probably because I have only read about it. Is it purely that it indirectly casts aside a DBMS? MapReduce strikes me as something to be used to categorize (key) large blobs of data where the only three things you know at the time of categorization are that you have a blob of data, you’ll get some random key, and you’ll get more blobs of data at a later time. Are the anti-MapReduce (pro-DBMS?) people saying that you should go analyze all the blobs and key them every possible way into a schema? Or are they saying that there is a solution in between the two solutions?

]]> By: There always seems to be a fire drill around MapReduce news | DBMS2 -- DataBase Management System Services http://www.dbms2.com/2009/04/14/stonebraker-dewitt-et-al-compare-mapreduce-to-dbms/#comment-116814 There always seems to be a fire drill around MapReduce news | DBMS2 -- DataBase Management System Services Tue, 14 Apr 2009 09:10:22 +0000 http://www.dbms2.com/?p=748#comment-116814 [...] the benchmark particulars, and eventually posted a link to the paper to. And I rushed out several related blog [...] [...] the benchmark particulars, and eventually posted a link to the paper to. And I rushed out several related blog [...]

]]>