我不知道为什么有这么多关于“像Hadoop这样的MapReduce式数据库vs SQL关系数据库”的疑惑。其实很简单。

人们用数据库做两件事：“Select”和“整合/报告”，一个词“处理”。

“Select”就是筛选：基于像时间、分类等属性找到特定的数据。“整合/报告”就是最基本的数据表格处理：鼓捣一行行的数据。

那么，我们怎么让数据库做这两件事？过去30年里，我们用SQL语言连接数据库。SQL最适合在关系数据库中。SQL有很多很cool的功能：建立表格、插入、修改数据，以集合的形式返回结果集。SQL已经30岁了，冗长且不擅长处理关系表之外的事。

一些开发人员很快就发现了SQL能做什么，另外一些人发现SQL是“另外一种计算机语言”。通过 “集成”进入他们同样的SQL开发，面向对象数据库和其他连续存储系统也成为了他们程序的一部分。Python有”pickling”，Perl用DBM绑hash。

MapReduce是一个在面向对象世界刚出现的开发概念，但是随着脚本语言的兴起和处理的并行化变得更加流行。MapReduce模式强迫/允许开发者将任务分割派发给各种“计算小组”，让“计算小组”完成计算后收回结果。这种方法很好地将多种现代语言对数据的处理进行了分解，同样也可作用于大数据量数据库。

因此，仔细想来，Hadoop和SQL数据库做的是同样的事：Select数据（Map阶段）并加以处理Reduce阶段。

那么为什么会有这场骚动？我总结如下：

• Hadoop是开发人员工具：他们用java这样的开发语言而不是SQL。使用Hadoop需要开发人员而部署数据库管理员。
•  Hadoop面向大数据，而不针对“存存储行，取成行，遵循ACID”的传统数据库。对于“银行账户”、“音乐目录”这样的表，Hadoop并不是适合的工具。Hadoop不适合“SELECT * WHERE USERID=12”这样的东西。
• 同样，尽管数据库不断进化出PL/SQL、TransactSQL、cursors等功能，处理现代化大规模数据操作和数据挖掘SQL数据库是不够的。关系数据库模型拼命降低并行处理的成本，SQL语言却没有给开发者留下针对复杂并行处理的操作。

以下是对MapReduce系统的强化：Facebook贡献出了Hive，Business.com发布了包含SQL语言支持的Hadoop的变种CloudBase。另一类是“非SQL但比原始MapReduce简单”的语言：Microsoft为其云计算创建了Dryad，Yahoo!开发了PIG语言。

一些数据库玩家也开始将MapReduce引擎集成进SQL/关系数据库的存储层。Greenplum，几年前并行化了PostGreSQL（BizGreSQL BI-oriented PostGreSQL被取代后，被开源）。Aster Data并不太知名，却被视为海量数据库系统。

看看这些宣传语：一旦并行化，你可以通过“云”进行分布，可以通过“Software as Service (SaaS)”在“云”中进行数据分析。

Hadoop将是处理海量数据的最佳方案。如果报告和存储相对简单，连续存储且数据大小合适，关系数据库则更合适。如此便可以解决你的开发问题了。

当然，他们最终会结合，而你不再用作出选择：所有主流数据库系统将同时拥有SQL层、查询优化引擎和MapReduce能力。

但是，我们还没到那个阶段。因此，不要认为Hadoop是万灵药——它只适合处理数据。当然也不要认为只有Oracle的“grid”或“Teradata”能进行海量数据处理。你将惊讶于Hadoop轻易地满足了你的需求。