<?xml version="1.0" encoding="utf-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: MapReduce compared to parallel SQL databases</title>
	<atom:link href="http://ebiquity.umbc.edu/blogger/2009/04/16/mapreduce-compared-to-parallel-sql-databases/feed/" rel="self" type="application/rss+xml" />
	<link>http://ebiquity.umbc.edu/blogger/2009/04/16/mapreduce-compared-to-parallel-sql-databases/</link>
	<description>EBB is the ebiquity research group\\\'s blog at the University of Maryland, Baltimore County (UMBC).  We focus on technologies that facilitate the design, implementation and control of distributed, intelligent information systems -- mobile and pervasive computing, ad hoc networking, multiagent systems, knowledge representation and reasoning, and the semantic web.  As the tides of technology ebb and flow, we hope the good ideas wash up on our beach and the bad ones drift back out to sea.</description>
	<lastBuildDate>Tue, 06 Dec 2011 19:29:16 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: vlad</title>
		<link>http://ebiquity.umbc.edu/blogger/2009/04/16/mapreduce-compared-to-parallel-sql-databases/comment-page-1/#comment-29168</link>
		<dc:creator>vlad</dc:creator>
		<pubDate>Thu, 16 Apr 2009 14:48:45 +0000</pubDate>
		<guid isPermaLink="false">http://ebiquity.umbc.edu/blogger/?p=1825#comment-29168</guid>
		<description>There was some talk about this paper at yesterday&#039;s hadoop meeting.   It was said that this paper has two major flaws.  First is that the workload that was selected for the task was a type of workload that favors the Relational Database model.  Typical MapReduce workload is when you have to process all your data and terabytes of it in the batchmode, whereas Relational Databases are optimized for retrieving relatively small amounts of data very quickly.  Second Flaw is that the MapReduce code that was used in benchmarking is not very optimal.

Also one has to consider the cost of setting up the processing cluster,  the setup described in the paper runs about $100K per terabyte in hardware and licensing cost, a typical hadoop setup would run about $1K per terabyte</description>
		<content:encoded><![CDATA[<p>There was some talk about this paper at yesterday&#8217;s hadoop meeting.   It was said that this paper has two major flaws.  First is that the workload that was selected for the task was a type of workload that favors the Relational Database model.  Typical MapReduce workload is when you have to process all your data and terabytes of it in the batchmode, whereas Relational Databases are optimized for retrieving relatively small amounts of data very quickly.  Second Flaw is that the MapReduce code that was used in benchmarking is not very optimal.</p>
<p>Also one has to consider the cost of setting up the processing cluster,  the setup described in the paper runs about $100K per terabyte in hardware and licensing cost, a typical hadoop setup would run about $1K per terabyte</p>
]]></content:encoded>
	</item>
</channel>
</rss>

