關系型數據庫不適于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原因有哪些”這篇文章對大家有幫助，同時也希望大家多多支持億速云，關注億速云行業資訊頻道，更多相關知識等著你來學習!