英文原文：http://www.networkworld.com/article/2226514/tech-debates/what-s-better-for-your-big-data-application--sql-or-nosql-.html

　　企業在著手推動大數據項目的過程中，經常會遇到這樣一個關鍵性的決策難題——到底該使用哪種數據庫方案?經過綜合考量，最終的選項往往只剩下 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)幾十年來已經用累累戰果以及赫赫聲名證明了自身實力，而且目前仍在繼續投身于多家大數據廠商及相關企業當中，其中包括谷歌、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 對象存儲系統相比，到底存在哪些差異與主要優勢。

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

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

　　市場對于這種本質差異倒是非常了然。早在 2010 年，谷歌就宣布引入一套 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 領域討論大數據話題時，我們主要針對的是操作型數據庫當中的讀取與寫入流程——也就是指人們在日常在線事務處理過程中所涉及的交互任務(例如利用大數據指導在線航班預定)。操作型數據庫與分析型數據庫有所不同，前者一般需要打理大量數據并收集數據當中所蘊含的分析結論(例如利用大數據分析特定某一天會有多少乘客預定某次航班)。

　　不過對于操作型數據庫中的大數據而言，其設計主旨并非圍繞分析性工作所展開;操作型數據庫通常需要為無數用戶提供龐大的數據集，幫助他們進行持續性數據訪問并進行實時事務處理。用于操作并管理大數據內容的此類數據庫都具備龐大的規模，這也解釋了 NoSQL 特性的重要意義及其在大數據應用程序中扮演核心角色的原因。

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

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

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

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

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

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

　　當用戶需要對一組數據進行查詢時，所需信息必須由多個表中收集獲得——通常涉及數百種當下常用的企業應用程序——并將其加以整合，而后才能交付終端應用。與之相似，在寫入數據時、寫入流程需要加以協調并在執行過程中面向多個表。當數據量相對較小、向數據庫內導入的速度并不太快的情況下，關系型數據庫通常具備捕捉并存儲信息的能力。不過目前的應用程序通常需要處理海量數據的讀取與寫入操作、且要求以近實時方式完成，這就超出了操作型數據庫的能力范圍。

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

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

　　* NoSQL 是支撐大數據應用的關鍵所在

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

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

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