作者：Michael Stonebraker &Daniel Abadi et. 2010-1
原文：http://database.cs.brown.edu/papers/stonebraker-cacm2010.pdf
译者：phylips@bmy 2011-10-5
译文：http://duanple.blog.163.com/blog/static/7097176720119720494/
序
MapReduce弥补了DBMS的不足，因为数据库不是设计用于执行ETL任务，而在这方面MapReduce更擅长。
MR(MapReduce)模式被称为是用于大规模高并行性数据访问的革命性新平台[16]。某些支持者甚至声称MR的高度可扩展性将使关系数据库管理系统(DBMS)成为过时技术。至少已经有一个公司，Facebook使用MR技术实现了大规模数据仓库系统而不是DBMS。
这里，我们认为使用MR系统来执行那些DBMS最擅长的工作还远没有达到令人满意的结果，需要指出的是MR更像一个ETL(extract-transform-load)系统而不是一个DBMS。因此，它对DBMS技术只是一个补充而不是竞争关系。我们也会讨论下MR系统和数据库系统架构上的不同，来看一下这两个系统是如何相互补充的。
最近各种技术性出版物都在关注着“云计算”。该名称特指利用大量并行工作的低端处理器来解决计算问题。实际上，这意味着通过罗列大量低端服务器而不是采用少量的高端服务器来构建数据中心。随着人们对该技术兴趣的上升，已经产生出一系列在此之上进行编程的工具，而MR就是这样的一个工具，它之所以备受关注是因为它提供了一种让用户可以编写相对复杂的分布式程序的简单模型。
随着商业上和学术上对MR模型的兴趣的增大，很自然地会问MR系统是否会取代并行数据库系统。并行数据库系统投入商业化使用都已经快20年了，同时市场上也存在了很多的产品。作为一种健壮的，高性能计算平台，它们提供了高级的编程环境和方便的并行化。尽管MR系统和并行DBMS系统看起来是不同的，但是几乎所有的并行处理任务都可以编写为一组数据库查询或者是一组MapReduce jobs。
通过与MR用户的讨论，我们总结出对于MR最常见的使用场景来说，MR更像一个ETL系统。正因如此，才说它是DBMS的一个良好补充，而不是竞争性的技术，因为数据库并不擅长于ETL任务。这里，我们描述下我们所认为的MR技术的理想使用方式，并指出MR和并行数据库之间的区别。
最近，我们使用流行的开源MR实现和两个并行DBMS，进行了一项benchmark研究[17]。结果表明，一旦数据加载完成之后，DBMS系统性能要远高于MR系统，但是与此同时，数据库系统的数据加载阶段也花费了相当长的时间。这里，我们讨论下这些性能差异的原因，包含了我们所能想到的这两种系统架构上的限制因素，最后我们觉得伴随着未来的大规模数据分析发展趋势，MR和DBMS系统应该互相学习。
并行数据库系统
早在20世纪80年代中期，Teradata和Gamma项目就开始探索一种基于通过高速互联网络连接的“share-nothing节点”(具有独立CPU，主存和磁盘)组成的集群的全新并行数据库架构模式。自从那时起，几乎所有的并行数据库系统都用到了这两个项目的技术：关系表的水平分区，以及SQL查询语句的分区执行。
水平分区的背后思想是将关系表的行在集群节点上进行划分，这样它们就可以被并行地处理。比如将一个10-million-行的表在一个50节点的集群上进行划分，每个节点具有4个磁盘，这样每个磁盘上将会有50,000个行。绝大多数的并行数据库系统都提供了多种划分策略，包括hash，range以及round-robin划分[8]。在基于hash的分区模式下，当每行被加载的时候，会对每行里的一个或多个属性应用一个hash函数来决定该行所应该存放的目标节点和磁盘。
水平分区的使用是获取SQL查询性能可扩展性的关键，同时这也自然地导致了SQL操作(selection,aggregation,join,projection及update)的分区执行概念。作为一个并行DBMS的数据分区过程的例子，考虑如下SQL查询语句：
SELECT custId, amount FROM Sales
WHERE date BETWEEN
“12/1/2009” AND “12/25/2009”;
因为销售表在集群节点间进行了水平分区，该查询通过对集群的每个节点上满足给定日期断言的销售记录执行一个SELECT操作就可以实现并行执行。之后为了向应用程序返回该查询产生的最终结果，来自每个节点的中间结果会发送个同一个节点执行MERGE操作。
假设我们现在想知道相同日期区间内每个custID的总购买量。可以通过如下查询语句完成：
SELECT custId, SUM(amount)
FROM Sales
WHERE date BETWEEN
“12/1/2009” AND “12/25/2009”
GROUP BY custId;
如果销售表在集群节点间是基于round-robin进行划分的，那么单个客户的对应的行会分布到多个节点上。DBMS会将该查询语句编译为图(a)中的三个操作组成的pipeline，之后在集群的所有节点上并行执行该查询计划。每个SELECT操作将会扫描存储在该节点上的销售表片段。任何满足了该日期断言的行将会被发送给SHUFFLE操作，它会对这些行进行动态的重划分；通常是通过在custID值上应用一个hash函数来完成，从而将相同custID的记录映射到某个特定的节点上。这样同一个客户的那些行就被发送到了同一个节点上，之后就可以计算每个客户的最终结果了。
作为最后一个例子，考虑下面的用于查找那些在给定的假期时间内购买了某个超过价值$1000的物品的客户名字和email地址的查询语句：
SELECT C.name, C.email FROM
Customers C, Sales S
WHERE C.custId = S.custId
AND S.amount > 1000
AND S.date BETWEEN
“12/1/2009” AND
“12/25/2009”;
还是假设销售表在集群节点间是基于round-robin进行划分的，但是现在假设客户表是基于Customer.custID属性进行划分的。DBMS会将该查询语句编译为图(b)中的三个操作组成的pipeline，之后在集群的所有节点上并行执行该查询计划。每个SELECT操作将会扫描存储在该节点上的销售表片段，找到满足如下断言的行：
S.amount > 1000 and S.date
BETWEEN “12/1/2009” and
“12/25/2009.”
满足条件的行将会被传递给shuffle操作，该操作会将输入行通过在Sales.custID上的hash进行重划分。通过在加载Customer表的行时使用相同的hash函数(在Customer.custID上进行hash分区)，shuffle操作符将满足条件的行发送给对应的Customer元组所在的节点上，这样join操作(C.custID=S.custID)就可以在节点上并行执行了。
并行DBMS的另一个关键优势是，系统自动地管理查询涉及到的表的各种分区策略。比如如果Sales和Customers都是基于custID进行分区的话，查询优化器就能够识别出来这两个表都是基于join属性进行hash分区的，就可以忽略掉查询计划中的shuffle操作。同样的，如果两个表都是基于round-robin进行的分区，那么查询优化器就会为这两个表都插入一个shuffle操作，以保证它们两个进行join的元组最终会落到相同节点上。所有这些对于用户和应用程序来说都是透明的。
很多可用的商业化实现，包括Teradata，Netezza，DataAllegro，ParAccel，Greenplum，Aster，Vertica和DB2。它们都运行在非共享集群节点上，使用了水平分区。
Mapping 并行DBMS onto MapReduce
MR编程模型一个非常吸引人的特性就是简单性。每个MR程序只有两个函数—Map和Reduce—由用户编写用于key/value数据对处理。输入数据集合存储在分布式文件系统中。该程序会被插入到一个分布式处理框架中，按照用户描述的行为执行。MR模型最初是由Google在2004年提出，今天已经有大量的开源和商业化实现。最流行的MR系统是Hadoop，一个由Yahoo!和Apache软件基金会开发的开源项目(http://hadoop.apache.org/)。
MR模型的语义并不是独一无二的，因为针对各个数据项的过滤和转换也可以通过采用了SQL的现代并行DBMS来执行。对于那些很难用SQL表达的Map操作来说，很多DBMS也支持用户自定义函数；UDF扩展提供了与Map操作等价的功能。作为UDF扩展的SQL聚合操作和用户自定义聚合器提供给DBMS用户与MR风格相同的reduce功能。最后，发生在Map和Reduce之间的reshuffle等价于SQL里的GROUP BY操作。所以，并行DBMS实际提供了与MR等价的计算模型，同时还具有使用了声明式语言(SQL)带来的额外好处。
并行DBMS的线性可扩展性也早已历经了20年的洗礼；这意味着，随着节点的增加，数据库大小可以在维持原有响应时间的情况下成比例地增加。目前已有一些用户使用了运行在100节点规模上的具有数PB容量的数据库产品。管理这些数据库的人们还没有提出更高的并行性需求。因此，并行DBMS已经提供了用户所需要的可扩展性。同时如果有需求，它也没有理由达不到Jeffrey Dean和Sanjay Ghemawat所报告[7]的可扩展性级别。
可能应用
尽管并行DBMS可以执行与MR相同语义的工作，下面提到的这些应用场景，MR模型可能会是比DBMS更好的选择：
ETL和”read once”数据集 作为MR的典型应用，可以归纳为如下5个操作步骤：
l 读取来自不同源的服务器日志信息
l 解析和清理日志数据
l 执行复杂的转换(比如会话持久化)
l 决定对哪些数据进行存储
l 将信息加载入DBMS或者其他存储系统
这些步骤类似于ETL系统中的extract，transform和load阶段；MR系统可以对原始数据进行必要的处理加工(cooking)成由另一个存储系统使用的有用信息。因此，MR系统可以看做是一种通用的并行ETL系统。
对于并行DBMS来说，有很多产品可以用来执行ETL，包括Ascential，Informatica，Jaspersoft，和Talend。市场很广阔，因为几乎所有的大企业都需要使用ETL系统来将大量数据加载到数据仓库中。正是因为每种系统所提供给用户的是完全不同的东西，所以造就了它们之间共生的关系：DBMS不会尝试去做ETL，而ETL系统也不会尝试提供DBMS服务。一个ETL系统通常处于DBMS的上游，作为加载阶段将数据直接喂给DBMS。
复杂的分析 在很多数据挖掘和数据聚类应用中，程序必须对数据进行多遍的处理。这样的应用没法用单个的SQL聚合查询来完成，而是需要一种复杂的数据流程序，某个的输出通常作为下一个的输入。对于这样的应用来说，MR是一个不错的选择。
半结构化数据 不像DBMS，MR系统并不要求用户为数据定义schema。因此MR类型的系统很容易地存储和处理半结构化数据。在我们的使用中，这些数据通常类似于一系列的key-value对，每个给定的记录内的属性个数是不同的；由不同的源产生的web流量日志是这种类型数据的一个典型代表。
如果使用关系型DBMS，对这类数据进行建模的一种方式是使用一个具有可以容纳多个记录类型的多个属性的wide table。如果给定的记录中不存在该属性就用NULL来表示。基于行的DBMS在处理这种表时基本上都会有问题，通常性能会很低。另一方面，基于列的DBMS(比如Vertica)可以通过只读取那些必需的列及自动化的禁止NULL值来缓解这个问题[3]。这些技术在处理RDF数据集时已经表现出很好的性能，我们预计对于半结构化数据来说应该也是类似的。
如果还希望这些半结构化数据能够使用前面所说的”cooking”模式(即，数据可以为加载到后端数据处理系统中做好准备)，那么MR类型的系统就很适合。如果这种半结构化数据主要用于分析性的查询，我们认为并行的列存储方式是一个更好的解决方案。
Quick-and-dirty分析 很多当前的并行DBMS让人失望的一点是，它们很难正确地安装和配置，因为为了让系统高效地工作，用户经常需要面对无数的调优参数。与安装两个商业化并行数据库系统的用户体验相比，开源MR实现提供了更好的开箱即用(out-of-the-box)用户体验；也就是说与这两个DBMS相比，我们可以更快速地让MR系统启动起来并运行查询。
一旦DBMS正常启动和运行之后，程序员还必须要为它们的数据编写schema，然后将数据集加载到系统中。该过程DBMS通常要比MR系统花费更长的时间，因为DBMS必须对元组中的每个数据项进行解析和验证。与此相比，对于MR程序员来说，默认的数据加载方式(因此也是最常用的)通常只是将数据拷贝到MR系统的底层分布式存储系统中。
如果程序员只是在某些临时性的数据上执行一次性的分析，那么MR的快速启动特性明显要更好一些。另一方面，专业的DBMS程序员和管理员更希望有更长的学习曲线和启动时间，因为通过更快速的查询所得到的性能弥补了之前的开销。
Limited-budget operations MR系统的另一个长处是大部分都是开源的，可以免费使用的。DBMS，尤其是并行DBMS通常都很昂贵；尽管也有一些单节点的开源解决方案，但是据我们所知，没有一种健壮的，有社区支持的并行DBMS。尽管企业用户有很强烈的需求，但是需要为商业化的系统提供庞大的预算，由这些系统所提供的各种工具，支持和服务协议还会需要额外的预算，那些具有不多的预算或更多需求的用户，会觉得开源系统更有吸引力。这样数据库社区就因为没有提供更完整的并行开源解决方案而丧失了一个机会。
强力的工具 MR系统是一个进行ETL类型应用和复杂分析任务的强力工具。此外，它们还非常适合于进行Quick-and-dirty分析，以及那些只有有限预算的用户。另一方面，如果应用程序是查询敏感的，半结构化或者是结构化的，那么DBMS会是一个更好的选择。下一节里，我们通过实际使用案例讨论下DBMS所具有的性能优势；这些处理任务涵盖了那些本应是MR系统擅长处理的非常复杂的查询。
DBMS “Sweet Spot”
为了研究并行DBMS和MR系统间的性能差异，我们采用了一个由5个不同类型的tasks组成的benchmark，来将2个并行DBMS和Hadoop MR框架进行比较[17]。我们采用了2个数据库系统：Vertica，一个商业列存式关系数据库，和DBMS-X，来自某大厂商的基于行的数据库。我们的benchmark研究包括了来自Google原始MR论文中的一个benchmark，其余的4个是一些可以使用这两类系统完成的更复杂的分析任务。我们在一个100节点的shared-nothing集群上进行了所有的实验。论文[17]中包含了我们所有实验的完整结果和讨论，包括加载时间。这里我们提供了其中最有趣的一些结论。
Hadoop是目前为止最流行的MR框架(Google的版本可能更快但是对于我们来说是不可用的)，同时DBMS-X和Vertica也分别是目前最流行的行式和列式并行数据库系统。
在论文发表之后，我们一直在对三个系统不断进行调优。此外，我们也收到了来自Hadoop社区关于改进性能的很多建议。我们都进行了尝试，因此这里的结果已经代表了在来自三个系统的大量专家的帮助下，我们所能达到的最好性能。事实上，我们花在Hadoop调优上的时间已经超过了其他两个系统。尽管Hadoop提供了一种开箱即用的用户体验，但是对它进行调优以达到最好的性能仍然是一件需要格外努力的任务。很明显，性能是一个变化中的指标，因为这三个产品也在不断地产生新的版本。
原始的MR Grep task 我们的第一个benchmark实验是来自原始MR论文的“Grep task”。对于该task来说，每个系统都必须要扫描100B条记录的数据集来查找一个3字符子串。每条记录有10字节的key和90字节的value组成。只能在每10,000条记录的最后90个字节找到该3字符子串。我们使用分布在100个节点上的1TB数据(10GB/node)。数据集由10 bilion条记录组成，每个100B。由于这本质上是一个针对数据集的顺序搜索，因此它代表了系统扫描一系列记录的速度。该task无法利用任何的sorting或者indexing，同时可以很容易地使用MR和SQL来描述。因此，可能会让人觉得直接运行在文件系统(HDFS)之上的底层接口(比如Hadoop)应该会比重量级的DBMS执行地更快。
然而，表中的执行时间展示了一个令人吃惊的结果：数据库系统比Hadoop快了大概2倍。后面的章节中我们会从架构的不同上解释下这种结果的原因。
Web log task 第二个task是一个在web服务器日志的表上使用了GROUP BY的传统SQL聚合操作。数据是典型的web日志，该查询是用来进行流量分析的。对于该实验，我们使用了一个分布在100个节点上的由155 million条记录组成的2TB数据集(20GB/node)。每个系统必须计算出日志中给定的IP地址对应的总的ad收入。与前面的task类似，所有的记录都必须被读取，因此DBMS也没法使用索引。人们可能会觉得Hadoop应该更擅长这种工作，因为该任务就是一个很直接的计算，但是表中的结果表明Hadoop依然被DBMS打败了，而且是以比Grep task中更大的优势。
Join task 这是我们讨论的最后一个task，它是一个需要在两个表上进行额外的聚合和过滤操作的复杂的join操作。来自前一个task的用户访问数据集要跟另一个具有18 million个URL的PageRank值组成的100GB表进行join。该join task由在两个数据集上进行复杂计算的两个子task组成。在该task的第一部分，每个系统必须要在用户访问表中找到特定日期区间内具有最高收入值的那个IP地址。一旦中间记录生成之后，系统必须计算出该区间内所有被访问页面的平均PageRank大小。
DBMS擅长处理具有复杂join操作的查询任务。如表所示，DBMS分别比Hadoop快了36和21倍。下一节，我们会讨论下这些结果的原因。
架构上的区别
Hadoop和DBMS间的性能差异实际上是由多种因素造成的。在讨论具体细节之前，我们首先来看一下由这两类系统具体实现方式的不同而不是模型本身的不同，所导致的那些差异。比如，MR处理模型本身独立于底层存储系统，因此理论上数据在加载阶段也可以进行处理，索引，压缩以及细致的重组，正如DBMS那样。因此，我们的研究目的在于比较这两种模型的代表性实现之间的实际性能差异。
重复的记录解析 Hadoop性能比较低的一个因素是Hadoop默认情况下会将数据以文本格式保存在HDFS上。因此，这种默认的存储方式需要用户代码来解析每条记录。而且是需要在Map和Reduce阶段重复解析，并将字符串类型字段转换为真正的类型。Hadoop提供了可以将数据序列化为key/value对元组的SequenceFile格式支持，但是如果记录的value部分包含了多个属性的话仍然需要用户代码去进行解析。因此，我们发现使用未采用压缩的SequenceFile在我们的benchmark中表现出了更低的性能。注：使用未采用压缩的SequenceFile是由MR社区所提供的可能提高Hadoop性能的策略之一。
与MR需要重复性的解析相比，DBMS只需要在数据首次加载时进行记录解析。在该初始加载步骤中，允许DBMS存储管理器使用最高效地存储格式，仔细调整记录布局使得它的那些属性可以在运行时直接被寻址。正因如此，DBMS在查询执行期间就无需再进行记录的解析。
当然MR模型也并非不能对数据进行提前解析和以最优的数据结构进行存储。比如数据可以使用Protocol Buffers存储(Google的平台无关的可扩展的结构化数据序列化机制)在底层文件系统上；但是这在Hadoop中是不可用的。此外，人们也可以将数据移到MR框架之外的存在于每个节点上的一个关系型DBMS，这样就可以使用一个DBMS类型的存储系统取代HDFS存储层。
通过这些方式都可以对Hadoop系统进行改进。但是，记录解析开销目前的确是个问题，而且SequenceFile也不是一个有效的解决方案。未来开发中需要对该问题提起重视。
压缩 我们发现在DBMS中使用数据压缩可以大大地提高性能。Benchmarks结果表明在Vertica和DBMS-X中使用压缩后，性能提高了2-4倍。另一方面，当我们在Hadoop中使用压缩的情况下，执行通常都是变慢的；最好情况下，压缩也只提高了15%的性能；Dean和Ghemawat[7]的benchmark结果中也没有使用压缩。
我们不太清楚为什么与商业性的SQL数据仓库相比，Hadoop的性能提升如此微弱。我们认为可能是因为商业性的DBMS使用了经过精心调优的压缩算法，可以保证元组解压产生的开销不会超过因读取压缩的数据而降低了IO开销后带来的性能提升。比如，我们也发现现代处理器上的标准Unix gzip和bzip实现通常运行速度都太慢了根本提供不了任何优势。
Pipelining 所有的并行DBMS都是通过在执行期创建一个分布到相应节点的查询计划进行操作的。当该计划中的某个操作必须向下一个操作发送数据时，不管它们是运行在同一个还是不同的节点上，满足条件的数据都会被第一个操作推送给下一个操作。因此数据是流式地从生产者发送到消费者，中间数据不会写入磁盘。这种流式技术与MR系统采用的策略不同，在MR中，生产者会把数据写入到本地磁盘，然后消费者会去拉取数据。由于数据可能会很大，而系统必须要把它们写入磁盘，这就会产生潜在的性能瓶颈。尽管将数据写入磁盘使得Hadoop可以在Map的中间输出设置一些检查点，但是这也显著地增加了性能开销。
调度 在并行DBMS中，根据查询计划每个节点都知道自己要做什么以及什么时候去做。因为所需做的操作事先就已经知道，系统就可以对执行计划进行优化以最小化节点间的数据传输。与此相比，MR系统中的每个任务是以处理节点上的一个存储块进行调度的。这种以存储块为粒度的运行时调度要比DBMS的编译时调度更昂贵。当然正如某些人所指出的，它也有自己的优势，可以让MR调度器根据节点间性能和负载的差异进行动态调度。
列式存储 在列存式数据库(比如Vertica)中，系统只需要读取必需的那些属性。这使得它与需要从磁盘读取所有属性的传统按行存储数据库相比，具有更好的性能。DBMS-X和Hadoop/HDFS都是按行存储的，而Vertica是按列存储的，这就使得在我们的web log benchmark task中，它的性能远远高于其他两个。
讨论 Hadoop社区可能会在未来的版本中解决压缩上存在的问题。此外，某些其他的并行数据库性能优势(比如按列存储及可直接操纵压缩的数据)也可以通过用户代码在MR系统中实现。同时，MR框架的其他实现(比如Google的私有实现)可能会有更好的性能表现。调度机制和数据传输的拉取模式，是由MR块级别的容错模型根本决定的，因此不太可能改变。
与此同时，DBMS提供了事务级的容错。DBMS研究者也指出，伴随着数据库规模的增大和节点数的增加，细粒度的容错需求也会上升。DBMS希望可以通过将查询计划中的一个或多个操作标记为”restart操作”来满足这种需求。运行时系统会将这些操作的结果存储到磁盘，以实现操作级别的重启。可以将任意数目的操作进行这样的标记，同时也允许调整重启的粒度。这种机制可以很容易地添加到现有的DBMS查询执行框架中。据我们所知，至少有两个独立的研究小组在进行这方面的研究，一个是在华盛顿大学，另一个是在加州伯克利。
我们希望ETL和复杂的分析任务可以由MR系统来完成，查询敏感的工作负载则交给DBMS运行。因此，最好的解决方案是将MR框架集成到DBMS，这样MR就可以进行一些复杂的分析任务，以及通过与DBMS的交互进行一些嵌入式的查询。HadoopDB，Hive，Aster，Greenplum，Cloudera，和Vertica目前都已经有了商业化的可用产品或者是采用了这种混合策略的原型。
互相学习 MR可以从DBMS那里学到什么呢？MR的支持者们应该参考并行DBMS的技术尤其是它高效的查询并行执行技术。工程师们应该站在前人的肩膀上，而不是脚趾上。并行DBMS执行器中有很多好的想法值得MR系统开发者们学习。
同时我们认为更高级的语言对于数据处理系统来说肯定是一个好选择。通过一种更高更具有生产力的抽象，关系DBMS已经取得了巨大成功。通过这个抽象，用户只需要描述他们想要什么，而不是编写一个如何从系统中得到这些东西的算法。在我们的benchmark研究中，我们发现为每个任务编写SQL代码要远比编写MR代码简单。
目前已经有些建立在MR/Hadoop之上的高级接口，比如Hive[21]，Pig[15]，Scope[6]，Dryad/Linq[12]以及其他的一些项目。
DBMS可以MR那里学到什么呢？大多数DBMS的开箱即用用户体验还不够理想，用户没法很快地安装和开始执行查询。商业性的DBMS产品应该能够提供：一键安装，可以进行正确的自动化调优，具有更好示例代码的网页，更好的查询生成器，以及更好的说明文档。
绝大多数的数据库系统没法很好的处理存储在文件系统上的数据(insitu data)。目前用户必须要进行数据的加载，如果数据只需要分析一两次，那么加载过程就是很浪费的。最好是能够不进行加载就可以直接处理本地磁盘数据。DBMS也没有理由不能处理insitu数据。尽管某些数据库系统(比如PostgreSQL,DB2和SQL Server)已经具有了这方面的能力，但是还需要更好的灵活性。
结论
我们这里所讨论的绝大多数架构上的不同都是由于这两类系统侧重点的不同所导致的。并行DBMS更擅长于进行大规模数据上的查询；MR系统更擅长于进行ETL任务和复杂的分析任务。二者都没法同时擅长两个方面。因此，这两种技术是一种补充性的关系，我们希望MR系统可以作为DBMS的上游工具来执行ETL。
很多复杂的分析性问题，需要这两种系统共同协作。这种需求也推动着这两种系统的结合，使得每个系统可以去做它们所擅长的工作。这要比单纯让一个系统完成所有的工作要更高效。That is,”smart software” is always a good idea。
致谢
This work is supported in part by National Science Foundation grants CRI-0707437, CluE-0844013, and CluE-0844480.
参考文献
1. A badi, D.J., Madden, S.R., and Hachem, N. Columnstores vs. row-stores: How different are they really? In Proceedings of the SIGMOD Conference on Management of Data. ACM Press, New York, 2008.
2. A badi, D.J., Marcus, A., Madden, S.R., and Hollenbach, K.Scalable semantic Web data management using vertical partitioning. In Proceedings of the 33rd International Conference on Very Large Databases, 2007.
3. A badi, D.J. Column-stores for wide and sparse data.In Proceedings of the Conference on Innovative Data Systems Research, 2007.
4. A bouzeid, A., Bajda-Pawlikowski, K., Abadi, D.J.,Silberschatz, A., and Rasin, A. HadoopDB: An architectural hybrid of MapReduce and DBMS technologies for analytical workloads. In Proceedings of the Conference on Very Large Databases, 2009.
5. B oral, H. et al. Prototyping Bubba, a highly parallel database system. IEEE Transactions on Knowledge and Data Engineering 2, 1 (Mar. 1990), 4–24.
6. Chaiken, R., Jenkins, B., Larson, P., Ramsey, B.,Shakib, D., Weaver, S., and Zhou, J. SCOPE: Easy and efficient parallel processing of massive data sets.In Proceedings of the Conference on Very Large Databases, 2008.
7. D ean, J. and Ghemawat, S. MapReduce: Simplified the Sixth Conference on Operating System Design and Implementation (Berkeley, CA, 2004).
8. D eWitt, D.J. and Gray, J. Parallel database systems:The future of high-performance database systems.Commun. ACM 35, 6 (June 1992), 85–98.
9. D eWitt, D.J., Gerber, R.H., Graefe, G., Heytens, M.L.,Kumar, K.B., and Muralikrishna, M. GAMMA: A high-performance dataflow database machine. In Proceedings of the 12th International Conference on Very Large Databases. Morgan Kaufmann Publishers,Inc., 1986, 228–237.
10. E nglert, S., Gray, J., Kocher, T., and Shah, P. A benchmark of NonStop SQL Release 2 demonstrating near-linear speedup and scaleup on large databases.Sigmetrics Performance Evaluation Review 18, 1(1990), 1990, 245–246.
11. Fushimi, S., Kitsuregawa, M., and Tanaka, H. An overview of the system software of a parallel relational database machine. In Proceedings of the 12th International Conference on Very Large Databases,Morgan Kaufmann Publishers, Inc., 1986, 209–219.
12. Isard, M., Budiu, M., Yu, Y., Birrell, A., and Fetterly,D. Dryad: Distributed data-parallel programs from sequential building blocks. SIGOPS Operating System Review 41, 3 (2007), 59–72.
13. Monash, C. Some very, very, very large data warehouses. In NetworkWorld.com community blog, May 12, 2009;
http://www.networkworld.com/community/node/41777
14. Monash, C. Cloudera presents the MapReduce bull case. In DBMS2.com blog, Apr. 15, 2009;
http://www.dbms2.com/2009/04/15/cloudera-presents-themapreduce-bull-case/
15. O lston, C., Reed, B., Srivastava, U., Kumar, R., and Tomkins, A. Pig Latin: A not-so-foreign language for data processing. In Proceedings of the SIGMOD Conference. ACM Press, New York, 2008, 1099–1110.
16. Patterson, D.A. Technical perspective: The data center is the computer. Commun. ACM 51, 1 (Jan. 2008), 105.
17. Pavlo, A., Paulson, E., Rasin, A., Abadi, D.J., DeWitt,D.J., Madden, S.R., and Stonebraker, M. A comparison of approaches to large-scale data analysis. In Proceedings of the 35th SIGMOD International Conference on Management of Data. ACM Press, New York, 2009, 165–178.
18. S tonebraker, M. and Rowe, L. The design of Postgres.In Proceedings of the SIGMOD Conference, 1986,340–355.
19. S tonebraker, M. The case for shared nothing. Data Engineering 9 (Mar. 1986), 4–9.
20. T eradata Corp. Database Computer System Manual,Release 1.3. Los Angeles, CA, Feb. 1985.
21. T husoo, A. et al. Hive: A warehousing solution over a Map-Reduce framework. In Proceedings of the Conference on Very Large Databases, 2009,1626–1629.
Michael Stonebraker (stonebraker@csail.mit.edu) is anadjunct professor in the Computer Science and Artificial Intelligence Laboratory at the Massachusetts Institute of Technology, Cambridge, MA.
Daniel J. Abadi (dna@cs.yale.edu) is an assistant professor in the Department of Computer Science at Yale University, New Haven, CT.
David J. DeWitt (dewitt@microsoft.com) is a technical fellow in the Jim Gray Systems Lab at Microsoft Inc.,Madison, WI.
Samuel Madden (madden@csail.mit.edu) is a professor in the Computer Science and Artificial Intelligence Laboratory at the Massachusetts Institute of Technology,Cambridge, MA.
Erik Paulson (epaulson@cs.wisc.edu) is a Ph.D. candidate in the Department of Computer Sciences at the University of Wisconsin-Madison, Madison, WI.
Andrew Pavlo (pavlo@cs.brown.edu) is a Ph.D. candidate in the Department of Computer Science at Brown University, Providence, RI.
Alexander Rasin (alexr@cs.brown.edu) is a Ph.D.candidate in the Department of Computer Science atBrown University, Providence, RI.
. 2010 ACM 0001-0782/10/0100 $10.00