鑒于Hadoop是一個數據處理框架，而在當前大多數應用中數據處理的主力是標準的關系數據庫，那又是什么使得Hadoop更具優勢呢？其中一個原因是，SQL(結構化查詢語言)是針對結構化數據設計的，而Hadoop最初的許多應用針對的是文本這種非結構化數據。從這個角度來看，Hadoop比SQL提供了一種更為通用的模式。

若只針對結構化數據處理，則需要做更細致的比較。原則上，SQL和Hadoop可以互補，因為SQL是一種查詢語言，它可將Hadoop作為其執行引擎 。但實際上，SQL數據庫往往指代一整套傳統技術，有幾個主要的廠商，并面向一組歷史悠久的應用進行優化。許多這些現有的商業數據庫無法滿足Hadoop設計所面向的需求。

考慮到這一點，讓我們從特定視角將Hadoop與典型的SQL數據庫做更詳細的比較。

1. 用向外擴展代替向上擴展

擴展商用關系型數據庫的代價是非常昂貴的。它們的設計更容易向上擴展。要運行一個更大的數據庫，就需要買一個更大的機器。事實上，往往會看到服務器廠商在市場上將其昂貴的高端機標稱為“數據庫級的服務器”。不過有時可能需要處理更大的數據集，卻找不到一個足夠大的機器。更重要的是，高端的機器對于許多應用并不經濟。例如，性能4倍于標準PC的機器，其成本將大大超過將同樣的4臺PC放在一個集群中。Hadoop的設計就是為了能夠在商用PC集群上實現向外擴展的架構。添加更多的資源，在Hadoop集群上意味著增加更多的機器。一個Hadoop集群的標配是十至數百臺計算機。事實上，如果不是為了開發目的，沒有理由在單個服務器上運行Hadoop。

2. 用鍵/值對代替關系表

關系數據庫的一個基本原則是讓數據按某種模式存放在具有關系型數據結構的表中。雖然關系模型具有大量形式化的屬性，許多當前的應用所處理的數據類型并不能很好地適合這個模型。文本、圖片和XML文件是最典型的例子。此外，大型數據集往往是非結構化或半結構化的。Hadoop使用鍵/值對作為基本數據單元，可足夠靈活地處理較少結構化的數據類型。在Hadoop中，數據的來源可以有任何形式，但最終會轉化為鍵/值對以供處理。

3. 用函數式編程(MapReduce)代替聲明式查詢(SQL)

SQL從根本上說是一個高級聲明性語言。查詢數據的手段是，聲明想要的查詢結果并讓數據庫引擎判定如何獲取數據。在MapReduce中，實際的數據處理步驟是你指定的，這更類似于SQL引擎的一個執行計劃。SQL使用查詢語句，而MapReduce則使用腳本和代碼。MapReduce允許你采用比SQL查詢更為一般化的數據處理方式。例如，你可以建立復雜的數據統計模型，或者改變圖像數據的格式。而SQL就不能很好地適應這些任務。

另一方面，當數據處理非常適合于關系型數據結構時，有些人可能會發現使用MapReduce并不自然。那些習慣于SQL范式的人可能會發現用MapReduce來思考是一個挑戰。我希望本書中的練習和示例能幫你更輕松地掌握MapReduce編程。不過值得注意的是，這里還有很多擴展可用，它們允許人們采用更熟悉的范式來編程，同時擁有Hadoop的可擴展性優勢。事實上，一些擴展會允許你使用一種類似SQL的查詢語言，并自動將查詢編譯為可執行的MapReduce代碼。我們將在第10章和第11章介紹其中的一些工具。

4. 用離線批量處理代替在線處理

Hadoop是專為離線處理和大規模數據分析而設計的，它并不適合那種對幾個記錄隨機讀寫的在線事務處理模式。事實上，在本書寫作時(以及在可預見的未來)，Hadoop最適合一次寫入、多次讀取的數據存儲需求。在這方面它就像SQL世界中的數據倉庫。

你已經從宏觀上看到Hadoop與分布式系統和SQL數據庫之間的關系。那么，讓我們開始學習如何用它來編程。為此，我們首先需要了解Hadoop中MapReduce的范式。

摘自《Hadoop實戰》

總結

以上是生活随笔為你收集整理的图像存在hadoop比在mysql中_比较SQL数据库和Hadoop的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。