|
英文原文:http://www.NETworkworld.com/article/2226514/tech-debates/what-s-better-for-your-big-data-application--sql-or-nosql-.html
企業(yè)在著手推動大數(shù)據(jù)項目的過程中,經(jīng)常會遇到這樣一個關(guān)鍵性的決策難題——到底該使用哪種數(shù)據(jù)庫方案?經(jīng)過綜合考量,最終的選項往往只剩下 SQL 與 NoSQL 兩種。SQL 具有驕人的業(yè)績以及龐大的安裝基礎(chǔ),但 NoSQL 卻能夠帶來可觀的收益并同樣擁有不少支持者。在今天的辯論當(dāng)中,我們將一同聽聽兩大陣營中各位專家的意見。
NETwork World 網(wǎng)站主編 John Dix 專門組織了此次辯論并邀請到多位專家。其中兩位參與專家分別是 VoltDB 公司 CTO Ryan Betts 和 Couchbase 公司 CEO Bob Wiederhold。Ryan Betts 認(rèn)為 SQL 已經(jīng)在大型企業(yè)當(dāng)中贏得了穩(wěn)定的生存空間,而大數(shù)據(jù)只不過是 SQL 需要支撐的另一項工作內(nèi)容。Bob Wiederhold 則認(rèn)為 NoSQL 是一套極具可行性的備選方案,事實上它也在多個領(lǐng)域中成為大數(shù)據(jù)的卓越配合手段——特別是在可擴展性方面。
觀點一:SQL 已經(jīng)通過時間考驗,且仍蓬勃發(fā)展——VoltDB 公司 CTO Ryan Betts
結(jié)構(gòu)化查詢語言(簡稱 SQL)幾十年來已經(jīng)用累累戰(zhàn)果以及赫赫聲名證明了自身實力,而且目前仍在繼續(xù)投身于多家大數(shù)據(jù)廠商及相關(guān)企業(yè)當(dāng)中,其中包括谷歌、Facebook、Cloudera 以及 Apache。
雖然后起之秀 NoSQL 確實引起了一定反響,但 SQL 仍然在市場上保持著顯著的份額優(yōu)勢并繼續(xù)在大數(shù)據(jù)領(lǐng)域不斷贏得投入與采納。
一旦某種技術(shù)像 SQL 這樣取得了主導(dǎo)地位,人們往往會忘記其最為核心的競爭優(yōu)勢。SQL 之所以能夠勝出,主要在于它擁有以下一系列獨特的優(yōu)勢組合:
1. SQL 能夠加強與數(shù)據(jù)之間的互動,允許用戶針對單一數(shù)據(jù)庫設(shè)計提出內(nèi)容廣泛的問題。這正是 SQL 成功的關(guān)鍵所在——如果數(shù)據(jù)不具備互動性、則基本上將失去實用性。而持續(xù)增長的互動性又能為數(shù)據(jù)庫的未來發(fā)展帶來新的審視角度、相關(guān)問題以及實際意義。
2. SQL 具備標(biāo)準(zhǔn)化特性,允許用戶自由運用源自各類系統(tǒng)的專業(yè)知識、同時支持第三方插件及工具。
3. SQL 具備擴展性、功能豐富且經(jīng)過實際驗證,能夠解決各類難題——包括以寫入為主導(dǎo)的快速事務(wù)處理以及涉及頻繁掃描的深層分析。
4. SQL 能夠與數(shù)據(jù)表現(xiàn)及存儲機制順暢對接。某些 SQL 系統(tǒng)還支持 JSON 以及其它結(jié)構(gòu)化對象格式,從而帶來優(yōu)于 NoSQL 方案的性能表現(xiàn)及更多功能特性。
“NoSQL”這一表述其實并不準(zhǔn)確,但在本次討論中,我采用了 Rick Cattell 博士為 NoSQL 總結(jié)出的定義,即“指那些能夠提供鍵/值存儲或者簡單記錄與索引等操作的系統(tǒng),旨在為這些簡單操作提供垂直可擴展性。”
很明顯,目前市面上的很多新型數(shù)據(jù)庫彼此之間存在較大差異——準(zhǔn)確掌握它們各自特性與深層機制給用戶來的便利與局限是獲得項目部署成功的關(guān)鍵所在。NoSQL 的核心特性使其更適合于解決特定問題。舉例來說,圖形數(shù)據(jù)庫更適合處理那些將數(shù)據(jù)根據(jù)關(guān)系而非傳統(tǒng)行或者文檔形式加以組織的實例,而特定文本搜索系統(tǒng)則比較擅長處理以實時方式查詢用戶輸入內(nèi)容的情況。
在這里,我打算概括性闡述 SQL 系統(tǒng)與簡單鍵/值乃至僅僅在存儲格式及可擴展性方面有所創(chuàng)新的 JSON 對象存儲系統(tǒng)相比,到底存在哪些差異與主要優(yōu)勢。
* SQL 帶來交互特性。SQL 是一種聲明性查詢語言。用戶說出自己想要的內(nèi)容(例如顯示出過去五年來,每年三月份購買量最大的客戶分別來自哪些地區(qū)),數(shù)據(jù)庫則在內(nèi)部組建出相關(guān)算法并根據(jù)要求提取對應(yīng)結(jié)果。相比之下,NoSQL 孕育出的編碼創(chuàng)新成果 MapReduce 則是一種規(guī)程化查詢技術(shù)。MapReduce 要求用戶不僅了解自己想要的結(jié)果,同時也需要提供獲取結(jié)果的具體執(zhí)行方式。
雖然聽起來只是一種頗為枯燥的技術(shù)性差異,但這種特性仍然極為關(guān)鍵,原因有以下兩點:首先,聲明性 SQL 查詢能夠更為輕松地通過圖形化工具以及對報告生成器的簡單點擊來創(chuàng)建。這種相對較低的使用門檻能夠幫助分析師、運營者、管理者以及其他不了解軟件編程知識的用戶享受其核心功能及成效。第二,對數(shù)據(jù)庫引擎使用內(nèi)部信息并選擇高效算法的方式進行抽象化處理。即使物理層或者數(shù)據(jù)庫索引出現(xiàn)變動,優(yōu)化算法仍然能夠確切完成任務(wù)。相比之下,在過去的程序化系統(tǒng)當(dāng)中、程序員需要重新審視現(xiàn)有處理方式并進行二次編程。這樣既帶來高昂成本,又很有可能導(dǎo)致意外錯誤。
市場對于這種本質(zhì)差異倒是非常了然。早在 2010 年,谷歌就宣布引入一套 SQL 方案以強化 MapReduce,從而滿足內(nèi)部用戶的實際需求。最近,F(xiàn)acebook 則發(fā)布了自己的 SQL 方案 Presto,意在對其 PB 級別 HDFS 集群數(shù)據(jù)進行查詢。根據(jù) Facebook 方面的說法:“由于我們的數(shù)據(jù)倉庫規(guī)模已經(jīng)增長至 PB 級別、業(yè)務(wù)需求也逐步發(fā)展,我們顯然需要一套經(jīng)過優(yōu)化的交互式系統(tǒng)以實現(xiàn)更低的查詢延遲。”除此之外,Cloudera 正在 HDFS 以上建立自己的 SQL 方案 Impala。前面提到的這一系列發(fā)展都立足于 Hive——一套面向 Hadoop、長期存在且得到廣泛采用的 SQL 外殼。
* SQL 具備標(biāo)準(zhǔn)化特性。雖然供應(yīng)商有時候會對自己的 SQL 接口進行特殊調(diào)整與定制,但從本質(zhì)上講 SQL 內(nèi)核仍然是一套標(biāo)準(zhǔn)化程度很高的方案,以 ODBC 以及 JDBC 為代表的其它規(guī)范同樣提供廣泛可用的、面向 SQL 系統(tǒng)的穩(wěn)定接口。由此衍生出的管理及操作工具生態(tài)系統(tǒng)能夠幫助大家以 SQL 系統(tǒng)為基礎(chǔ),實現(xiàn)應(yīng)用程序的設(shè)計、監(jiān)控、檢查、探索以及開發(fā)。
SQL 用戶及程序員也因此得以重新使用自己積累自多種后端系統(tǒng)的 API 以及用戶界面知識,從而縮減應(yīng)用程序開發(fā)時間。標(biāo)準(zhǔn)化特性還允許擁有聲明許可的第三方打造提取、轉(zhuǎn)換以及加載(簡稱 ETL)工具,旨在幫助企業(yè)以流程化方式處理不同數(shù)據(jù)庫及系統(tǒng)之間的數(shù)據(jù)流。
* SQL 具備可擴展性。有些朋友可能誤以為 SQL 必須通過犧牲性能的方式來獲得可擴展性,這其實是完全錯誤的。如上所述,F(xiàn)acebook 打造了一款 SQL 接口對 PB 級別的數(shù)據(jù)加以查詢。SQL 在運行 ACID 事務(wù)處理任務(wù)時同樣具備極快的速度表現(xiàn)。SQL 為數(shù)據(jù)存儲及檢索機制提供的抽象化手段允許用戶以統(tǒng)一化方式完成處理工作,而且無需考慮具體任務(wù)類型以及數(shù)據(jù)規(guī)模;這使得 SQL 能夠高效運行在各類集群化副本數(shù)據(jù)存儲體系之間。將 SQL 作為接口的作法不涉及云創(chuàng)建、具體規(guī)模或者 HA 系統(tǒng),而且 SQL 當(dāng)中也沒有任何固有因素會對容錯性、高可用性以及復(fù)制能力產(chǎn)生限制。事實上,目前所有現(xiàn)代化 SQL 系統(tǒng)都能夠很好地支持云體系中的橫向可擴展性、復(fù)制能力以及容錯性。
* SQL 支持 JSON。幾年之前,很多 SQL 系統(tǒng)開始將 XML 文檔支持能力納入自身設(shè)計思路。時至今日,隨著 JSON 逐步成為主流數(shù)據(jù)交換格式之一,各 SQL 廠商也在積極為 JSON 提供支持。鑒于當(dāng)下敏捷化編程流程以及對互聯(lián)網(wǎng)接入基礎(chǔ)設(shè)施正常運行時間的要求,結(jié)構(gòu)化數(shù)據(jù)類型的支持能力已經(jīng)成為不可或缺的重要一環(huán)。Oracle 12c、PostgreSQL 9.2、VoltDB 以及其它各類數(shù)據(jù)庫方案都開始支持 JSON——其性能基準(zhǔn)水平普遍優(yōu)于“原生”JSON NoSQL 方案。
SQL 將繼續(xù)在市場份額的爭奪戰(zhàn)中占據(jù)主動,也將繼續(xù)吸引到更多投資方與采納者的支持。NoSQL 數(shù)據(jù)庫在提供專有查詢語言或者簡單鍵-值語義的同時,卻無法從深入的技術(shù)層面帶來差異性,這無疑嚴(yán)重影響了其挑戰(zhàn)市場統(tǒng)治者的能力。現(xiàn)代 SQL 系統(tǒng)能夠在保持甚至超越原有可擴展性的同時,支持豐富的查詢語義、建立并培養(yǎng)用戶基礎(chǔ)、拓展生態(tài)系統(tǒng)集成效果并在企業(yè)環(huán)境內(nèi)深化采納程度。
觀點二:NoSQL 更適合大數(shù)據(jù)應(yīng)用程序——Couchbase 公司 CEO Bob Wiederhold
目前已經(jīng)有越來越多的企業(yè)開始將 NoSQL 視為關(guān)系型數(shù)據(jù)庫的一種可行性替代方案;特別是在大數(shù)據(jù)應(yīng)用程序領(lǐng)域,很多企業(yè)用戶意識到規(guī)模化操作的實際表現(xiàn)要優(yōu)于標(biāo)準(zhǔn)化集群與商用服務(wù)器所帶來的效果。除此之外,采用無模式化數(shù)據(jù)模型往往更適合當(dāng)下各類不同數(shù)據(jù)的捕捉與處理工作。
在 NoSQL 領(lǐng)域討論大數(shù)據(jù)話題時,我們主要針對的是操作型數(shù)據(jù)庫當(dāng)中的讀取與寫入流程——也就是指人們在日常在線事務(wù)處理過程中所涉及的交互任務(wù)(例如利用大數(shù)據(jù)指導(dǎo)在線航班預(yù)定)。操作型數(shù)據(jù)庫與分析型數(shù)據(jù)庫有所不同,前者一般需要打理大量數(shù)據(jù)并收集數(shù)據(jù)當(dāng)中所蘊含的分析結(jié)論(例如利用大數(shù)據(jù)分析特定某一天會有多少乘客預(yù)定某次航班)。
不過對于操作型數(shù)據(jù)庫中的大數(shù)據(jù)而言,其設(shè)計主旨并非圍繞分析性工作所展開;操作型數(shù)據(jù)庫通常需要為無數(shù)用戶提供龐大的數(shù)據(jù)集,幫助他們進行持續(xù)性數(shù)據(jù)訪問并進行實時事務(wù)處理。用于操作并管理大數(shù)據(jù)內(nèi)容的此類數(shù)據(jù)庫都具備龐大的規(guī)模,這也解釋了 NoSQL 特性的重要意義及其在大數(shù)據(jù)應(yīng)用程序中扮演核心角色的原因。
* NoSQL 是實現(xiàn)可擴展性的關(guān)鍵所在
技術(shù)行業(yè)在每一次迎來硬件發(fā)展的根本性轉(zhuǎn)變時,都必然經(jīng)歷過渡拐點。在數(shù)據(jù)庫領(lǐng)域,這種由向上擴展轉(zhuǎn)為向外擴展架構(gòu)的轉(zhuǎn)變也成為推動 NoSQL 快速成長的主要因素。關(guān)系型數(shù)據(jù)庫,其中包括由甲骨文及 IBM 等巨頭所打造的具體方案,專注于解決向上擴展難題。也就是說,它們采取集中式、全局共享技術(shù),只能通過添加價格更為昂貴的硬件設(shè)備滿足擴展需求。
與之相反,NoSQL 數(shù)據(jù)庫從設(shè)計思路上就考慮到了分布式特性,屬于徹頭徹尾聲的向外擴展技術(shù)。它們利用一系列分布式節(jié)點(構(gòu)成一套整體集群)來提供具備卓越彈性的擴展能力,從而幫助用戶隨意添加更多節(jié)點以應(yīng)對持續(xù)增加的工作負(fù)載。
分布式向外擴展方案往往還會帶來低于向上擴展機制的使用成本。后者屬于一整套龐大、復(fù)雜、具備容錯性機制的服務(wù)器體系,因此無論是設(shè)計、建造還是后期支持都會帶來高昂的成本支出。商用關(guān)系型數(shù)據(jù)庫的許可成本同樣不容忽視,因為其計費策略以單一服務(wù)器為基本單位。在另一方面,NoSQL 數(shù)據(jù)庫則通常屬于開源項目,以服務(wù)器集群為整體計費單位、價格也相比較低。
* NoSQL 是實現(xiàn)靈活性的關(guān)鍵所在
關(guān)系型與 NoSQL 數(shù)據(jù)模型可謂完全不同。關(guān)系型模型需要將數(shù)據(jù)拆分成包含行與列的多個關(guān)聯(lián)性表,這些表通過同樣保存在列中的外鍵實現(xiàn)相互引用。
當(dāng)用戶需要對一組數(shù)據(jù)進行查詢時,所需信息必須由多個表中收集獲得——通常涉及數(shù)百種當(dāng)下常用的企業(yè)應(yīng)用程序——并將其加以整合,而后才能交付終端應(yīng)用。與之相似,在寫入數(shù)據(jù)時、寫入流程需要加以協(xié)調(diào)并在執(zhí)行過程中面向多個表。當(dāng)數(shù)據(jù)量相對較小、向數(shù)據(jù)庫內(nèi)導(dǎo)入的速度并不太快的情況下,關(guān)系型數(shù)據(jù)庫通常具備捕捉并存儲信息的能力。不過目前的應(yīng)用程序通常需要處理海量數(shù)據(jù)的讀取與寫入操作、且要求以近實時方式完成,這就超出了操作型數(shù)據(jù)庫的能力范圍。
NoSQL 數(shù)據(jù)庫采取的模式則完全不同。從核心角度看,NoSQL 數(shù)據(jù)庫真正實現(xiàn)了“NoREL”、也就是非關(guān)系型,也就是說此類方案在保存并整理信息的過程中并不依賴于表以及各個表之間的關(guān)系。舉例來說,一套面向文檔的 NoSQL 數(shù)據(jù)庫會首先獲取到我們需要的數(shù)據(jù),而后將其整合成采用 JSON 格式的文檔。每個 JSON 文檔都可以被視為能供應(yīng)用程序使用的對象。JSON 文檔可以把原本需要 25 個關(guān)系型數(shù)據(jù)庫表才能存放的數(shù)據(jù)保存在同一行當(dāng)中,并將其整理為單一文檔/對象。
信息匯總工作可能導(dǎo)致信息內(nèi)容出現(xiàn)重復(fù),不過由于目前存儲資源已經(jīng)不再屬于主要成本來源,因此這類數(shù)據(jù)模型能夠帶來更出色的靈活性、便于高效分配由此產(chǎn)生的文檔并改進讀取與寫入操作的性能表現(xiàn)、從而提升 Web 應(yīng)用程序的替代性效果。
* NoSQL 是支撐大數(shù)據(jù)應(yīng)用的關(guān)鍵所在
時至今日,我們已經(jīng)能夠愈發(fā)便捷地通過第三方環(huán)境、包括社交媒體網(wǎng)站對數(shù)據(jù)進行捕捉與訪問。個人用戶信息、地理位置數(shù)據(jù)、用戶產(chǎn)生的內(nèi)容、設(shè)備登錄數(shù)據(jù)以及傳感器數(shù)據(jù)等只是這股風(fēng)潮當(dāng)中的少數(shù)典型代表,數(shù)據(jù)來源清單正在不斷拓展。同時,企業(yè)也越來越依賴大數(shù)據(jù)技術(shù)的力量、旨在驅(qū)動其關(guān)鍵性業(yè)務(wù)應(yīng)用。總體而言,各企業(yè)已經(jīng)開始向 NoSQL 伸出橄欖枝,因為這類方案是惟一能夠適應(yīng)當(dāng)前新興數(shù)據(jù)類型的處理手段。
開發(fā)人員需要一套更為靈活、能夠輕松適應(yīng)最新數(shù)據(jù)類型的數(shù)據(jù)庫方案,從而避免破壞第三方數(shù)據(jù)供應(yīng)商所提供的內(nèi)容結(jié)構(gòu)調(diào)整。大部分新型數(shù)據(jù)屬于非結(jié)構(gòu)化或者半結(jié)構(gòu)化類型,因此開發(fā)人員還需要自己的數(shù)據(jù)庫有能力高效對其加以保存。遺憾的是,關(guān)系型數(shù)據(jù)庫所采取的嚴(yán)格定義、以模式為基礎(chǔ)的設(shè)計思路令我們無法快速接納全新數(shù)據(jù)類型,自然也難以適應(yīng)非結(jié)構(gòu)化及半結(jié)構(gòu)化數(shù)據(jù)。NoSQL 帶來的數(shù)據(jù)模型則能夠更好地與其實際需求加以映射。
總體來說,隨著 Web 與移動應(yīng)用程序的不斷普及、新興趨勢的推波助瀾外加面向在線消費者行為與新型數(shù)據(jù)類別的轉(zhuǎn)變,業(yè)界中的各類流程方案都渴望著一種能夠為數(shù)據(jù)的管理及訪問帶來可擴展性與靈活性的數(shù)據(jù)庫技術(shù)。在這樣的背景下,NoSQL 技術(shù)正是能夠有效滿足上述需求的惟一解決方案。
it知識庫:SQL/NoSQL兩大陣營激辯:誰更適合大數(shù)據(jù),轉(zhuǎn)載需保留來源!
鄭重聲明:本文版權(quán)歸原作者所有,轉(zhuǎn)載文章僅為傳播更多信息之目的,如作者信息標(biāo)記有誤,請第一時間聯(lián)系我們修改或刪除,多謝。