1. 不适合事务/单一请求处理
MapReduce绝对是一个离线批处理系统，对于批处理数据应用得很好：MapReduce（不论是Google的还是Hadoop的）是用于处理不适合传统数据库的海量数据的理想技术。但它又不适合事务/单一请求处理。（HBase使用了来自Hadoop核心的HDFS，在其常用操作中并没有使用MapReduce。）

2. 不能随即读取

3. 以蛮力代替索引
在索引是更好的存取机制时，MapReduce将劣势尽显。

4. low-level语言和操作

“直接开始你想要的 -- 而不是展示一个算法，解释如何工作的。” (关系型数据库的观点) -- High level（DBMS）

“展示数据存取的算法。” (Codasyl 的观点) -- Low level（MapReduce）

5. 性能问题
想想N个map实例产生M个输出文件-每个最后由不同的reduce 实例处理, 这些文件写到运行map实例机器的本地硬盘. 如果N是1,000, M是500, map阶段产生500,000个本地文件. 当reduce阶段开始, 500个reduce实例每个需要读入1,000文件，并用类似FTP协议把它要的输入文件从map实例运行的节点上pull取过来. 假如同时有数量级为100的reduce实例运行, 那么2个或2个以上的reduce实例同时访问同一个map节点来获取输入文件是不可避免的-导致大量的硬盘查找, 有效的硬盘运转速度至少降低20%. 这就是为什么并行数据库系统不实现split文件, 采用push(推到socket套接字)而不是pull. 由于MapReduce的出色容错依赖于如何实现split文件, MapReduce框架是否成功地转向使用push范式, 不是很清楚.

6. 仅提供了现代DBMS功能的一小部分
作为用于分布式处理的算法技术，MapReduce不是数据库，不支持索引、数据更新、事务及完整性约束等，且与多数DBMS工具不兼容。

7. 不适合一般web应用
大部分web应用，只是对数据进行简单的访问，每次请求处理所耗费的资源其实非常小，它的问题是高并发，所以要采用负载均衡技术来分担负载。只有当特殊情况下，比如建索引，进行数据分析等，才可能用MR。