大資料應用程式最佳選擇：SQL還是NoSQL？

執行大資料項目目的企業面對的關鍵決策之一是使用哪個資料庫，SQL還是NoSQL? SQL有著驕人的業績，龐大的安裝基礎;而NoSQL正在獲得可觀的收益，且有很多支援者。 我們來看看兩位專家對這個問題的看法。

專家

· VoltDB公司首席技術官Ryan Betts表示，SQL已經贏得了大型企業的廣泛部署，大資料是它可以支援的另一個領域。

· Couchbase公司首席執行官Bob Wiederhold表示，NoSQL是可行的選擇，並且從很多方面來看，它是大資料的最佳選擇，特別是涉及到可擴充性時。

SQL經歷時間的考驗，並仍然在蓬勃發展

結構化查詢語言(SQL)是經過時間考驗的勝利者，它已經主宰了幾十年，目前大資料公司和組織(例如谷歌、Facebook、Cloudera和Apache)正在積極投資于SQL。

在成為主導技術(例如SQL)後，有時候我們很容易忘記其優越性。 SQL的獨特優勢包括：

1. SQL能夠加強與資料的交互，並允許對單個資料庫設計提出問題。 這是很關鍵的特徵，因為無法交互的資料基本上是沒用的，並且，增強的交互性能夠帶來新的見解、新的問題和更有意義的未來交互。

2. SQL是標準化的，使使用者能夠跨系統運用他們的知識，並對協力廠商附件和工具提供支援。

3. SQL能夠擴展，並且是多功能和經過時間驗證的，這能夠解決從快寫為主導的傳輸到掃描密集型深入分析等問題。

4. SQL對資料呈現和存儲採用正交形式，一些SQL系統支援JSON和其他結構化物件格式，比NoSQL具有更好的性能和更多功能。

雖然NoSQL的出現帶來了一些影響，但SQL仍然主導著市場，並在大資料領域贏得了很多投資和廣泛部署。

NoSQL的說法很含糊，對於本次討論，我借用Rick Cattell對NoSQL的定義，即提供簡單操作(例如金鑰/數值存儲)或簡單記錄和索引，並專注于這些簡單操作的橫向可擴充性的系統。

很顯然，現在很多新的資料庫並不是都一樣，認識每種資料庫背後的原理以及潛在問題是成功的關鍵。 NoSQL的主要特點使其更適合於特定的問題。 例如，圖形資料庫更適合於資料通過關系組織的情況，而專門的文本搜索系統更適合於需要即時搜索的情況。

在這裡，讓我們看看SQL系統的主要優勢和差異化功能：

* SQL可實現交互性。 SQL是一種聲明性查詢語言。 使用者說出他們想要什麼(例如，顯示過去五年三月份期間頂級客戶的地理位置)，資料庫內部就會構件演算法並提取請求的結果。 相比之下，NoSQL程式設計創新MapReduce是一種程式性查詢技術。 在使用者提出請求時，MapReduce要求使用者不僅說出自己想要什麼，而且要求他們陳述如何產生答案。

這聽起來像一個無趣的技術差異，但這很關鍵，原因在於：首先，聲明性SQL查詢更容易通過圖形化工具以及點擊報告構建器來構建。 這讓分析師、操作員、管理者和其他不具備軟體程式設計能力的員工進行資料庫查詢;其次，資料庫引擎可以利用內部資訊來選擇最有效的演算法。 改變資料庫的物理佈局或資料庫，最佳演算法仍然能夠計算出來。 而在程式性系統中，程式設計人員需要重新訪問和重新程式設計演算法，這是非常昂貴且容易出錯的過程。

市場理解這個關鍵區別。 在2010年，谷歌宣佈部署SQL來補充MapReduce，主要受內部使用者需求所驅動。 最近，Facebook發佈了Presto(一種SQL部署)來查詢其PB級HDFS集群。 根據Facebook表示：「隨著我們的倉庫增長到PB級，以及我們的需求變化，我們清楚地意識到，我們需要一個提供低延時查詢的互動系統。 」此外，Cloudera也正在構建Impala—另一個基於HDFS的SQL部署。

* SQL是標準化的。 雖然供應商有時候會添加自己的語言到SQL介面，但SQL的核心是標準化的，還有其他規格(例如ODBC和JDBC)提供廣泛可用的穩定介面到SQL存儲。 這帶來了一個管理和操作工具生態系統，可以在SQL系統之上設計、監控、檢查、探索和構建應用程式。

SQL使用者和程式師可用跨多個後端系統重複使用其API和UI知識，減少了應用程式的開發時間。 標準化還允許聲明性協力廠商提取、轉換、載入(ETL)工具，使企業可以在資料庫之間以及跨系統傳輸資料。

* SQL可擴展。 認為SQL必須犧牲以獲得可擴充性的看法，完全是錯誤的。 如前所述，Facebook創建了一個SQL介面來查詢PB級資料。 SQL能夠非常有效地運行極快的ACID傳輸。 SQL對資料存儲和索引提供的抽象[注]化允許跨各種問題和資料集大小的一致使用，讓SQL可以跨集群複製資料存儲有效地運行。 使用SQL作為介面獨立于構建雲、規模或HA系統，SQL中並沒有什麼在阻止和限制容錯、高可用性和複製。 事實上，所有現代SQL系統支援雲友好型橫向可擴充性、複製和容錯性。

* SQL支援JSON。 幾年前，很多SQL系統增加了XML文檔支援。 現在，隨著JSON成為一種流行的資料交換格式，SQL供應商也紛紛加入了JSON型的支援。 基於現在靈活的程式設計過程和web基礎設施的正常執行時間要求，我們很需要結構化資料類型的支援。 Oracle 12c、PostgreSQL 9.2、VoltDB和其他支援JSON的資料庫，通常具有優於「原生」JSON的性能。

SQL將繼續贏得市場份額，並會繼續看到新的投資和部署。 NoSQL資料庫提供專有查詢語言或簡單的鍵值語義，而沒有更深層次的技術差異化。 現代SQL系統提供可擴充性的同時，還支援更豐富的查詢語義，並有龐大的使用者安裝基礎，廣泛的生態系統整合和深度企業部署。

NoSQL更適合大資料應用程式

NoSQL越來越多地被認為是關聯式資料庫的可行替代品，特別是對於大資料應用程式。 此外，無模式資料模型通常更適合於現在捕捉和處理的資料種類和類型。

當我們談論NoSQL領域的大資料時，我們指的是從運算元據庫讀取和寫入。 不要將運算元據庫與分析資料庫混淆，這通常會查看大量資料，並從這些資料獲取可視性。

雖然運算元據庫的大資料看起來不具有可分析性，但運算元據庫通常會存儲超大量使用者的大型資料集，這些使用者經常需要訪問資料來即時執行交易。 這種資料庫的操作規模也解釋了NoSQL的關鍵特性，也就是為什麼NoSQL是大資料應用程式的關鍵的原因。

NoSQL是可擴充性的關鍵

每次技術行業經歷硬體發展的根本性轉變時，都會出現一個拐點。 在資料庫領域，從縱向擴展到橫向擴展的轉變推動了NoSQL的發展。 關聯式資料庫(包括來自甲骨文和IBM的資料庫)是縱向擴展。 也就是說，它們是集中式、共用一切的技術，只能通過增加更多昂貴的硬體來擴展。

而NoSQL資料庫是分散式橫向擴展技術。 它們使用了分散式節點集(稱為集群)來提供高度彈性擴展功能，讓使用者可以添加節點來動態處理負載。

分散式橫向擴展的做法通常要比縱向做法更加便宜。 商業關聯式資料庫的授權費用也讓人望而卻步，因為他們的價格是按每台伺服器來計算。 另一方面，NoSQL資料庫通常是開源技術，按照運行的伺服器集群收費，而且價格相對便宜。

NoSQL是靈活性的關鍵

關聯式資料庫和NoSQL資料模型有很大的不同。 關聯式模式獲取資料，並將資料分配到很多相互關聯的表中，這些表通過外鍵相互應用。

當使用者需要對資料集執行查詢時，所需資訊需要從多個表中收集(通常涉及數百個企業應用程式)，並結合這些資訊，再提供給應用程式。 同樣地，當寫入資料時，需要在多個表協調和執行寫入。 當資料相對較少，並且，資料以較慢速度流入資料庫時，關聯式資料庫通常能夠捕捉和存儲資訊。 然而，現在的應用程式通常需要快速寫入(和讀取)海量資料。

NoSQL資料庫採用非常不同的模式。 在其核心，NoSQL資料庫其實是「NoREL」，或者說非關聯式，這意味著它們沒有依賴于表以及表之間的聯繫，以存儲和組織資訊。 例如，以文檔為導向的NoSQL資料庫獲取你想要存儲的資料，並採用JSON格式整合到文檔中。 每個JSON文檔可以被你的應用程式視為一個物件。 JSON文檔可能會提取跨越25個表的資料，將資料整合到一個文檔中。

聚合這些資訊可能會導致資訊重複，但由於存儲已不再是一個成本問題，資料模型靈活性、發佈所產生文檔的簡便性以及讀取和寫入性能提高，讓這成為不錯的選擇。

NoSQL是大資料應用程式的關鍵

通過協力廠商(包括社交媒體網站)，資料正變得越來越容易捕捉和訪問。 這些資料包括：個人使用者資訊、地理位置資料、使用者生產的內容、機器記錄資料和感應器產生的資料。 企業還可以依賴于大資料來推動其要徑任務型應用程式。 同時，企業正在轉向到NoSQL資料庫，因為這種資料庫非常適合現在新型的資料類型。

開發人員想要一個靈活的資料庫，可以很容易適應新的資料類型，並且，不會受協力廠商資料供應商的內容結構變化的影響。 大多數新資料是非結構化和半結構化，因此，開發人員也需要能夠有效存儲這些資料的資料庫。 然而，關聯式資料庫採用的嚴格定義的基於模式的做法讓其不可能快速整合新資料類型，並且很不適合于非結構化和半結構化資料。

總體來說，隨著web和移動應用程式的增加、新的趨勢、網上消費者行為的轉變以及新的資料類型的出現，行業需要能夠提供可擴展的靈活的資料庫技術來管理和訪問資料。 NoSQL技術是有效滿足這些需求的唯一可行解決方案。