SQL/NoSQL兩大陣營激辯：誰更適合大資料

標籤：style   color   ar   os   使用   sp   資料   div   on   

企業在著手推動大資料項目的過程中，經常會遇到這樣一個關鍵性的決策難題——到底該使用哪種資料庫方案?經過綜合考量，最終的選項往往只剩下 SQL 與 NoSQL 兩種。SQL 具有驕人的業績以及龐大的安裝基礎，但 NoSQL 卻能夠帶來可觀的收益並同樣擁有不少支援者。在今天的辯論當中，我們將一同聽聽兩大陣營中各位專家的意見。

Network World 網站主編 John Dix 專門組織了此次辯論並邀請到多位專家。其中兩位參與專家分別是 VoltDB 公司 CTO Ryan Betts 和 Couchbase 公司 CEO Bob Wiederhold。Ryan Betts 認為 SQL 已經在大型企業當中贏得了穩定的生存空間，而大資料只不過是 SQL 需要支撐的另一項工作內容。Bob Wiederhold 則認為 NoSQL 是一套極具可行性的備選方案，事實上它也在多個領域中成為大資料的卓越配合手段——特別是在可擴充性方面。

觀點一：SQL 已經通過時間考驗，且仍蓬勃發展——VoltDB 公司 CTO Ryan Betts

結構化查詢語言 (SQL)(簡稱 SQL)幾十年來已經用累累戰果以及赫赫聲名證明了自身實力，而且目前仍在繼續投身於多家大資料廠商及相關企業當中，其中包括Google、Facebook、Cloudera 以及 Apache。

雖然後起之秀 NoSQL 確實引起了一定反響，但 SQL 仍然在市場上保持著顯著的份額優勢並繼續在大資料領域不斷贏得投入與採納。

一旦某種技術像 SQL 這樣取得了主導地位，人們往往會忘記其最為核心的競爭優勢。SQL 之所以能夠勝出，主要在於它擁有以下一系列獨特的優勢組合：

1. SQL 能夠加強與資料之間的互動，允許使用者針對單一資料庫設計提出內容廣泛的問題。這正是 SQL 成功的關鍵所在——如果資料不具備互動性、則基本上將失去實用性。而持續增長的互動性又能為資料庫的未來發展帶來新的審視角度、相關問題以及實際意義。

2. SQL 具備標準化特性，允許使用者自由運用源自各類系統的專業知識、同時支援第三方外掛程式及工具。

3. SQL 具備擴充性、功能豐富且經過實際驗證，能夠解決各類難題——包括以寫入為主導的快速交易處理以及涉及頻繁掃描的深層分析。

4. SQL 能夠與資料表現及儲存機制順暢對接。某些 SQL 系統還支援 JSON 以及其它結構化對象格式，從而帶來優於 NoSQL 方案的效能表現及更多功能特性。

“NoSQL”這一表述其實並不準確，但在本次討論中，我採用了 Rick Cattell 博士為 NoSQL 總結出的定義，即“指那些能夠提供鍵/值儲存或者簡單記錄與索引等操作的系統，旨在為這些簡單操作提供垂直可擴充性。”

很明顯，目前市面上的很多新型資料庫彼此之間存在較大差異——準確掌握它們各自特性與深層機制給使用者來的便利與局限是獲得項目部署成功的關鍵所在。 NoSQL 的核心特性使其更適合於解決特定問題。舉例來說，圖形資料庫更適合處理那些將資料根據關係而非傳統行或者文檔形式加以組織的執行個體，而特定文本搜尋系統則比 較擅長處理以即時方式查詢使用者輸入內容的情況。

在這裡，我打算概括性闡述 SQL 系統與簡單鍵/值乃至僅僅在儲存格式及可擴充性方面有所創新的 JSON Object Storage Service系統相比，到底存在哪些差異與主要優勢。

* SQL 帶來互動特性。SQL 是一種聲明性查詢語言。使用者說出自己想要的內容(例如顯示出過去五年來，每年三月份購買量最大的客戶分別來自哪些地區)，資料庫則在內部組建出相關演算法並 根據要求提取對應結果。相比之下，NoSQL 孕育出的編碼創新成果 MapReduce 則是一種規程化查詢技術。MapReduce 要求使用者不僅瞭解自己想要的結果，同時也需要提供擷取結果的具體執行方式。

雖然聽起來只是一種頗為枯燥的技術性差異，但這種特性仍然極為關鍵，原因有以下兩點：首先，聲明性 SQL 查詢能夠更為輕鬆地通過圖形化工具以及對報告產生器的簡單點擊來建立。這種相對較低的使用門檻能夠協助分析師、運營者、管理者以及其他不瞭解軟體編程知識 的使用者享受其核心功能及成效。第二，對資料庫引擎使用內部資訊並選擇高效演算法的方式進行抽象化處理。即使物理層或者資料庫索引出現變動，最佳化演算法仍然能夠 確切完成任務。相比之下，在過去的程式化系統當中、程式員需要重新審視現有處理方式並進行二次編程。這樣既帶來高昂成本，又很有可能導致意外錯誤。

市場對於這種本質差異倒是非常瞭然。早在 2010 年，Google就宣布引入一套 SQL 方案以強化 MapReduce，從而滿足內部使用者的實際需求。最近，Facebook 則發布了自己的 SQL 方案 Presto，意在對其 PB 層級 HDFS 叢集資料進行查詢。根據 Facebook 方面的說法：“由於我們的資料倉儲規模已經增長至 PB 層級、業務需求也逐步發展，我們顯然需要一套經過最佳化的互動式系統以實現更低的查詢延遲。”除此之外，Cloudera 正在 HDFS 以上建立自己的 SQL 方案 Impala。前面提到的這一系列發展都立足於 Hive——一套面向 Hadoop、長期存在且得到廣泛採用的 SQL 外殼。

* SQL 具備標準化特性。雖然供應商有時候會對自己的 SQL 介面進行特殊調整與定製，但從本質上講 SQL 核心仍然是一套標準化程度很高的方案，以 ODBC 以及 JDBC 為代表的其它規範同樣提供廣泛可用的、面向 SQL 系統的穩定介面。由此衍生出的管理及操作工具生態系統能夠協助大家以 SQL 系統為基礎，實現應用程式的設計、監控、檢查、探索以及開發。

SQL 使用者及程式員也因此得以重新使用自己積累自多種後端系統的 API 以及使用者介面知識，從而縮減應用程式開發時間。標準化特性還允許擁有聲明許可的第三方打造提取、轉換以及載入(簡稱 ETL)工具，旨在協助企業以流程化方式處理不同資料庫及系統之間的資料流。

* SQL 具備可擴充性。有些朋友可能誤以為 SQL 必須通過犧牲效能的方式來獲得可擴充性，這其實是完全錯誤的。如上所述，Facebook 打造了一款 SQL 介面對 PB 層級的資料加以查詢。SQL 在運行 ACID 交易處理任務時同樣具備極快的速度表現。SQL 為資料存放區及檢索機制提供的抽象化手段允許使用者以統一化方式完成處理工作，而且無需考慮具體任務類型以及資料規模;這使得 SQL 能夠高效運行在各類叢集化副本資料存放區體系之間。將 SQL 作為介面的作法不涉及雲建立、具體規模或者 HA 系統，而且 SQL 當中也沒有任何固有因素會對容錯性、高可用性以及複製能力產生限制。事實上，目前所有現代化 SQL 系統都能夠很好地支援雲體系中的橫向可擴充性、複製能力以及容錯性。

* SQL 支援 JSON。幾年之前，很多 SQL 系統開始將 XML 文檔支援能力納入自身設計思路。時至今日，隨著 JSON 逐步成為主流資料交換格式之一，各 SQL 廠商也在積極為 JSON 提供支援。鑒於當下敏捷化編程流程以及對互連網接入基礎設施正常已耗用時間的要求，結構化資料類型的支援能力已經成為不可或缺的重要一環。Oracle 12c、PostgreSQL 9.2、VoltDB 以及其它各類資料庫方案都開始支援 JSON——其效能基準水平普遍優於“原生”JSON NoSQL 方案。

SQL 將繼續在市場份額的爭奪戰中佔據主動，也將繼續吸引到更多投資方與採納者的支援。NoSQL 資料庫在提供專有查詢語言或者簡單鍵-值語義的同時，卻無法從深入的技術層面帶來差異性，這無疑嚴重影響了其挑戰市場統治者的能力。現代 SQL 系統能夠在保持甚至超越原有可擴充性的同時，支援豐富的查詢語義、建立並培養使用者基礎、拓展生態系統整合效果並在企業環境內深化採納程度。

觀點二：NoSQL 更適合大資料應用程式——Couchbase 公司 CEO Bob Wiederhold

目前已經有越來越多的企業開始將 NoSQL 視為關係型資料庫的一種可行性替代方案;特別是在大資料應用程式領域，很多企業使用者意識到規模化操作的實際表現要優於標準化叢集與商用伺服器所帶來的效 果。除此之外，採用無模式化資料模型往往更適合當下各類不同資料的捕捉與處理工作。

在 NoSQL 領域討論大資料話題時，我們主要針對的是操作型資料庫當中的讀取與寫入流程——也就是指人們在日常線上交易處理過程中所涉及的互動任務(例如利用大資料指 導線上航班預定)。操作型資料庫與AnalyticDB有所不同，前者一般需要打理大量資料並收集資料當中所蘊含的分析結論(例如利用大資料分析特定某一天會有多 少乘客預定某次航班)。

不過對於操作型資料庫中的大資料而言，其設計主旨並非圍繞分析性工作所展開;操作型資料庫通常需要為無數使用者提供龐大的資料集，協助他們進行持久性 資料訪問並進行即時交易處理。用於操作並管理大資料內容的此類資料庫都具備龐大的規模，這也解釋了 NoSQL 特性的重要意義及其在大資料應用程式中扮演核心角色的原因。

* NoSQL 是實現可擴充性的關鍵所在

技術行業在每一次迎來硬體發展的根本性轉變時，都必然經曆過渡拐點。在資料庫領域，這種由向上擴充轉為向外擴充架構的轉變也成為推動 NoSQL 快速成長的主要因素。關係型資料庫，其中包括由甲骨文及 IBM 等巨頭所打造的具體方案，專註於解決向上擴充難題。也就是說，它們採取集中式、全域共用技術，只能通過添加價格更為昂貴的硬體裝置滿足擴充需求。

與之相反，NoSQL 資料庫從設計思路上就考慮到了分布式特性，屬於徹頭徹尾聲的向外擴充技術。它們利用一系列分布式節點(構成一套整體叢集)來提供具備卓越彈性的擴充能力，從而協助使用者隨意添加更多節點以應對持續增加的工作負載。

分布式向外擴充方案往往還會帶來低於向上擴充機制的使用成本。後者屬於一整套龐大、複雜、具備容錯性機制的伺服器體系，因此無論是設計、建造還是後 期支援都會帶來高昂的成本支出。商用關係型資料庫的許可成本同樣不容忽視，因為其計費策略以單一伺服器為基本單位。在另一方面，NoSQL 資料庫則通常屬於開源項目，以伺服器叢集為整體計費單位、價格也相比較低。

* NoSQL 是實現靈活性的關鍵所在

關係型與 NoSQL 資料模型可謂完全不同。關係型模型需要將資料拆分成包含行與列的多個關聯性表，這些表通過同樣儲存在列中的外鍵實現相互引用。

當使用者需要對一組資料進行查詢時，所需資訊必須由多個表中收集獲得——通常涉及數百種當下常用的公司專屬應用程式程式——並將其加以整合，而後才能交付終端 應用。與之相似，在寫入資料時、寫入流程需要加以協調並在執行過程中面向多個表。當資料量相對較小、向資料庫內匯入的速度並不太快的情況下，關係型資料庫 通常具備捕捉並儲存資訊的能力。不過目前的應用程式通常需要處理海量資料的讀取與寫入操作、且要求以近即時方式完成，這就超出了操作型資料庫的能力範圍。

NoSQL 資料庫採取的模式則完全不同。從核心角度看，NoSQL 資料庫真正實現了“NoREL”、也就是非關係型，也就是說此類方案在儲存並整理資訊的過程中並不依賴於表以及各個表之間的關係。舉例來說，一套面向文檔 的 NoSQL 資料庫會首先擷取到我們需要的資料，而後將其整合成採用 JSON 格式的文檔。每個 JSON 文檔都可以被視為能供應用程式使用的對象。JSON 文檔可以把原本需要 25 個關係型資料庫表才能存放的資料儲存在同一行當中，並將其整理為單一文檔/對象。

資訊匯總工作可能導致資訊內容出現重複，不過由於目前儲存資源已經不再屬於主要成本來源，因此這類資料模型能夠帶來更出色的靈活性、便於高效分配由此產生的文檔並改進讀取與寫入操作的效能表現、從而提升 Web 應用程式的替代性效果。

* NoSQL 是支撐大資料應用的關鍵所在

時至今日，我們已經能夠愈發便捷地通過第三方環境、包括社交媒體網站對資料進行捕捉與訪問。個人使用者資訊、地理位置資料、使用者產生的內容、裝置登入 資料以及感應器資料等只是這股風潮當中的少數典型代表，資料來源清單正在不斷拓展。同時，企業也越來越依賴大資料技術的力量、旨在驅動其關鍵性業務應用。 總體而言，各企業已經開始向 NoSQL 伸出橄欖枝，因為這類方案是惟一能夠適應當前新興資料類型的處理手段。

開發人員需要一套更為靈活、能夠輕鬆適應最新資料類型的資料庫方案，從而避免破壞第三方資料供應商所提供的內容結構調整。大部分新型資料屬於非結構 化或者半結構化類型，因此開發人員還需要自己的資料庫有能力高效對其加以儲存。遺憾的是，關係型資料庫所採取的嚴格定義、以模式為基礎的設計思路令我們無 法快速接納全新資料類型，自然也難以適應非結構化及半結構化資料。NoSQL 帶來的資料模型則能夠更好地與其實際需求加以映射。

總體來說，隨著 Web 與行動裝置 App程式的不斷普及、新興趨勢的推波助瀾外加面向線上消費者行為與新型資料類別的轉變，業界中的各類流程方案都渴望著一種能夠為資料的管理及訪問帶 來可擴充性與靈活性的資料庫技術。在這樣的背景下，NoSQL 技術正是能夠有效滿足上述需求的惟一解決方案。

SQL/NoSQL兩大陣營激辯：誰更適合大資料