大資料應用程式最佳選擇：SQL還是NoSQL
阿新 • • 發佈：2019-02-07
執行大資料[注]專案的企業面對的關鍵決策之一是使用哪個資料庫，SQL還是NoSQL?SQL有著驕人的業績，龐大的安裝基礎;而NoSQL正在獲得可觀的收益，且有很多支持者。我們來看看兩位專家對這個問題的看法。
專家
·VoltDB公司首席技術官Ryan Betts表示，SQL已經贏得了大型企業的廣泛部署，大資料是它可以支援的另一個領域。
·Couchbase公司執行長Bob Wiederhold表示，NoSQL是可行的選擇，並且從很多方面來看，它是大資料的最佳選擇，特別是涉及到可擴充套件性時。
SQL經歷時間的考驗，並仍然在蓬勃發展
VoltDB公司首席技術官Ryan Betts
結構化查詢語言(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更適合大資料應用程式
Couchbase公司執行長Bob Wiederhold
NoSQL越來越多地被認為是關係型資料庫的可行替代品，特別是對於大資料應用程式。此外，無模式資料模型通常更適合於現在捕捉和處理的資料種類和型別。
當我們談論NoSQL領域的大資料時，我們指的是從操作資料庫讀取和寫入。不要將操作資料庫與分析資料庫混淆，這通常會檢視大量資料，並從這些資料獲取可視性。
雖然操作資料庫的大資料看起來不具有可分析性，但操作資料庫通常會儲存超大量使用者的大型資料集，這些使用者經常需要訪問資料來實時執行交易。這種資料庫的操作規模也解釋了NoSQL的關鍵特性，也就是為什麼NoSQL是大資料應用程式的關鍵的原因。
NoSQL是可擴充套件性的關鍵
每次技術行業經歷硬體發展的根本性轉變時，都會出現一個拐點。在資料庫領域，從縱向擴充套件到橫向擴充套件的轉變推動了NoSQL的發展。關係型資料庫(包括來自甲骨文和IBM的資料庫)是縱向擴充套件。也就是說，它們是集中式、共享一切的技術，只能通過增加更多昂貴的硬體來擴充套件。
而NoSQL資料庫是分散式橫向擴充套件技術。它們使用了分散式節點集(稱為叢集)來提供高度彈性擴充套件功能，讓使用者可以新增節點來動態處理負載。
分散式橫向擴充套件的做法通常要比縱向做法更加便宜。商業關係型資料庫的授權費用也讓人望而卻步，因為他們的價格是按每臺伺服器來計算。另一方面，NoSQL資料庫通常是開源技術，按照執行的伺服器叢集收費，而且價格相對便宜。
NoSQL是靈活性的關鍵
關係型資料庫和NoSQL資料模型有很大的不同。關係型模式獲取資料，並將資料分配到很多相互關聯的表中，這些表通過外來鍵相互應用。
當用戶需要對資料集執行查詢時，所需資訊需要從多個表中收集(通常涉及數百個企業應用程式)，並結合這些資訊，再提供給應用程式。同樣地，當寫入資料時，需要在多個表協調和執行寫入。當資料相對較少，並且，資料以較慢速度流入資料庫時，關係型資料庫通常能夠捕捉和儲存資訊。然而，現在的應用程式通常需要快速寫入(和讀取)海量資料。
NoSQL資料庫採用非常不同的模式。在其核心，NoSQL資料庫其實是“NoREL”，或者說非關係型，這意味著它們沒有依賴於表以及表之間的聯絡，以儲存和組織資訊。例如，以文件為導向的NoSQL資料庫獲取你想要儲存的資料，並採用JSON格式整合到文件中。每個JSON文件可以被你的應用程式視為一個物件。JSON文件可能會提取跨越25個表的資料，將資料整合到一個文件中。
聚合這些資訊可能會導致資訊重複，但由於儲存已不再是一個成本問題，資料模型靈活性、釋出所產生文件的簡便性以及讀取和寫入效能提高，讓這成為不錯的選擇。
NoSQL是大資料應用程式的關鍵
通過第三方(包括社交媒體網站)，資料正變得越來越容易捕捉和訪問。這些資料包括：個人使用者資訊、地理位置資料、使用者生產的內容、機器記錄資料和感測器產生的資料。企業還可以依賴於大資料來推動其關鍵任務型應用程式。同時，企業正在轉向到NoSQL資料庫，因為這種資料庫非常適合現在新型的資料型別。
開發人員想要一個靈活的資料庫，可以很容易適應新的資料型別，並且，不會受第三方資料供應商的內容結構變化的影響。大多數新資料是非結構化和半結構化，因此，開發人員也需要能夠有效儲存這些資料的資料庫。然而，關係型資料庫採用的嚴格定義的基於模式的做法讓其不可能快速整合新資料型別，並且很不適合於非結構化和半結構化資料。
總體來說，隨著web和移動應用程式的增加、新的趨勢、網上消費者行為的轉變以及新的資料型別的出現，行業需要能夠提供可擴充套件的靈活的資料庫技術來管理和訪問資料。NoSQL技術是有效滿足這些需求的唯一可行解決方案。
專家
·VoltDB公司首席技術官Ryan Betts表示，SQL已經贏得了大型企業的廣泛部署，大資料是它可以支援的另一個領域。
·Couchbase公司執行長Bob Wiederhold表示，NoSQL是可行的選擇，並且從很多方面來看，它是大資料的最佳選擇，特別是涉及到可擴充套件性時。
SQL經歷時間的考驗，並仍然在蓬勃發展
VoltDB公司首席技術官Ryan Betts
結構化查詢語言(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更適合大資料應用程式
Couchbase公司執行長Bob Wiederhold
NoSQL越來越多地被認為是關係型資料庫的可行替代品，特別是對於大資料應用程式。此外，無模式資料模型通常更適合於現在捕捉和處理的資料種類和型別。
當我們談論NoSQL領域的大資料時，我們指的是從操作資料庫讀取和寫入。不要將操作資料庫與分析資料庫混淆，這通常會檢視大量資料，並從這些資料獲取可視性。
雖然操作資料庫的大資料看起來不具有可分析性，但操作資料庫通常會儲存超大量使用者的大型資料集，這些使用者經常需要訪問資料來實時執行交易。這種資料庫的操作規模也解釋了NoSQL的關鍵特性，也就是為什麼NoSQL是大資料應用程式的關鍵的原因。
NoSQL是可擴充套件性的關鍵
每次技術行業經歷硬體發展的根本性轉變時，都會出現一個拐點。在資料庫領域，從縱向擴充套件到橫向擴充套件的轉變推動了NoSQL的發展。關係型資料庫(包括來自甲骨文和IBM的資料庫)是縱向擴充套件。也就是說，它們是集中式、共享一切的技術，只能通過增加更多昂貴的硬體來擴充套件。
而NoSQL資料庫是分散式橫向擴充套件技術。它們使用了分散式節點集(稱為叢集)來提供高度彈性擴充套件功能，讓使用者可以新增節點來動態處理負載。
分散式橫向擴充套件的做法通常要比縱向做法更加便宜。商業關係型資料庫的授權費用也讓人望而卻步，因為他們的價格是按每臺伺服器來計算。另一方面，NoSQL資料庫通常是開源技術，按照執行的伺服器叢集收費，而且價格相對便宜。
NoSQL是靈活性的關鍵
關係型資料庫和NoSQL資料模型有很大的不同。關係型模式獲取資料，並將資料分配到很多相互關聯的表中，這些表通過外來鍵相互應用。
當用戶需要對資料集執行查詢時，所需資訊需要從多個表中收集(通常涉及數百個企業應用程式)，並結合這些資訊，再提供給應用程式。同樣地，當寫入資料時，需要在多個表協調和執行寫入。當資料相對較少，並且，資料以較慢速度流入資料庫時，關係型資料庫通常能夠捕捉和儲存資訊。然而，現在的應用程式通常需要快速寫入(和讀取)海量資料。
NoSQL資料庫採用非常不同的模式。在其核心，NoSQL資料庫其實是“NoREL”，或者說非關係型，這意味著它們沒有依賴於表以及表之間的聯絡，以儲存和組織資訊。例如，以文件為導向的NoSQL資料庫獲取你想要儲存的資料，並採用JSON格式整合到文件中。每個JSON文件可以被你的應用程式視為一個物件。JSON文件可能會提取跨越25個表的資料，將資料整合到一個文件中。
聚合這些資訊可能會導致資訊重複，但由於儲存已不再是一個成本問題，資料模型靈活性、釋出所產生文件的簡便性以及讀取和寫入效能提高，讓這成為不錯的選擇。
NoSQL是大資料應用程式的關鍵
通過第三方(包括社交媒體網站)，資料正變得越來越容易捕捉和訪問。這些資料包括：個人使用者資訊、地理位置資料、使用者生產的內容、機器記錄資料和感測器產生的資料。企業還可以依賴於大資料來推動其關鍵任務型應用程式。同時，企業正在轉向到NoSQL資料庫，因為這種資料庫非常適合現在新型的資料型別。
開發人員想要一個靈活的資料庫，可以很容易適應新的資料型別，並且，不會受第三方資料供應商的內容結構變化的影響。大多數新資料是非結構化和半結構化，因此，開發人員也需要能夠有效儲存這些資料的資料庫。然而，關係型資料庫採用的嚴格定義的基於模式的做法讓其不可能快速整合新資料型別，並且很不適合於非結構化和半結構化資料。
總體來說，隨著web和移動應用程式的增加、新的趨勢、網上消費者行為的轉變以及新的資料型別的出現，行業需要能夠提供可擴充套件的靈活的資料庫技術來管理和訪問資料。NoSQL技術是有效滿足這些需求的唯一可行解決方案。