关系型数据库不适于Hadoop原因有哪些

这篇文章主要介绍了关系型数据库不适于Hadoop原因有哪些，具有一定借鉴价值，感兴趣的朋友可以参考下，希望大家阅读完这篇文章之后大有收获，下面让小编带着大家一起了解一下。

问题要从计算机硬盘说起，现阶段硬盘寻址时间的提升速度远不及传输速率提升的速度。寻址是将磁头移动到特定硬盘位置进行读写操作的过程，它是导致硬盘操作延迟的主要原因，而传输速率取决于硬盘的带宽。形象的来说就是，工人装载货物的效率提高，远不及高速上运输货物的效率。

如果数据的访问模式中包含大量的硬盘寻址，那么读取大量数据集就必然会花更长的时间，而流数据读取模式取决于传输速率。另一方面，如果数据库系统只更新一小部分记录，那么传统的B树就更有优势（关系型数据库中使用的一种数据结构，受限于寻址的比例）。但数据库系统中有大量的数据更新时，B树的效率就明显落后于MapReduce，因为需要使用“排序/合并”来重建数据库。

在许多情况下，可以将MapReduce视为关系型数据库管理系统的补充。

MapReduce和关系型数据库之间的另一个区别在于它们所操作的数据集结构化程度。结构化数据（structured data）是具有既定格式的实体化数据，如XML文档或满足特定的预定义格式的数据库表。这是RDBMS包括的内容。另一方面，半结构化数据(semi-structured data)比较松散，虽然可能有格式，但经常被忽略，所以它只能作为对数据结构的一般性指导。例如电子表格，它在结构上是由单元格组成的网格，但是每个单元格内可以保存任何形式的数据。非结构化数据（unstructured data）没什么特别的内部结构，例如纯文本或图像数据。MapReduce对非结构化数或半结构化数据非常有效，因为它是在处理数据时才对数据时才对数据进行解释。换句话说MapReduce输入的键和值并不是数据的固有属性，而是由分析数据的人来选的。

关系型数据库往往是规范的（normalized），以保持数据的完整性且不含冗余。规范给MapReduce带来了问题，因为它使记录读取成为非本地操作，而MapReduce的核心假设之一就是可以进行高速的流读写操作。比如web服务器日志是典型的非规范化数据记录，例如每一次都要记录客户端主机全名，这回导致同一客户端的全名可能多次出现，这也是MapReduce非常适用于分析各种日志文件的原因之一。

MapReduce是一种线性的可伸缩编程模型，程序员需要写两个函数，分别是map和reduce函数，每个函数定义了一个键值对集合到另一个键值对集合的映射。这些函数不必关注数据集及其所用集群的大小，可以原封不动地应用于小规模数据集或大规模数据集。如果输入的数据量是原来的两倍，那么运行时间也是原来的两倍，但是如果集群规模是原来的两倍，作业的运行速度却仍然与原来的一样快。SQL查询一般不具备该特性。

感谢你能够认真阅读完这篇文章，希望小编分享的“关系型数据库不适于Hadoop原因有哪些”这篇文章对大家有帮助，同时也希望大家多多支持亿速云，关注亿速云行业资讯频道，更多相关知识等着你来学习!