很明顯，目前市面上的很多新型數(shù)據(jù)庫(kù)彼此之間存在較大差異——準(zhǔn)確掌握它們各自特性與深層機(jī)制給用戶來(lái)的便利與局限是獲得項(xiàng)目部署成功的關(guān)鍵所在。NoSQL的核心特性使其更適合于解決特定問(wèn)題。舉例來(lái)說(shuō)，圖形數(shù)據(jù)庫(kù)更適合處理那些將數(shù)據(jù)根據(jù)關(guān)系而非傳統(tǒng)行或者文檔形式加以組織的實(shí)例，而特定文本搜索系統(tǒng)則比較擅長(zhǎng)處理以實(shí)時(shí)方式查詢用戶輸入內(nèi)容的情況。

    在這里，我打算概括性闡述SQL系統(tǒng)與簡(jiǎn)單鍵/值乃至僅僅在存儲(chǔ)格式及可擴(kuò)展性方面有所創(chuàng)新的JSON對(duì)象存儲(chǔ)系統(tǒng)相比，到底存在哪些差異與主要優(yōu)勢(shì)。

    *SQL帶來(lái)交互特性。SQL是一種聲明性查詢語(yǔ)言。用戶說(shuō)出自己想要的內(nèi)容(例如顯示出過(guò)去五年來(lái)，每年三月份購(gòu)買(mǎi)量最大的客戶分別來(lái)自哪些地區(qū))，數(shù)據(jù)庫(kù)則在內(nèi)部組建出相關(guān)算法并根據(jù)要求提取對(duì)應(yīng)結(jié)果。相比之下，NoSQL孕育出的編碼創(chuàng)新成果MapReduce則是一種規(guī)程化查詢技術(shù)。MapReduce要求用戶不僅了解自己想要的結(jié)果，同時(shí)也需要提供獲取結(jié)果的具體執(zhí)行方式。

    市場(chǎng)對(duì)于這種本質(zhì)差異倒是非常了然。早在2010年，谷歌就宣布引入一套SQL方案以強(qiáng)化MapReduce，從而滿足內(nèi)部用戶的實(shí)際需求。最近，F(xiàn)acebook則發(fā)布了自己的SQL方案Presto，意在對(duì)其PB級(jí)別HDFS集群數(shù)據(jù)進(jìn)行查詢。根據(jù)Facebook方面的說(shuō)法：“由于我們的數(shù)據(jù)倉(cāng)庫(kù)規(guī)模已經(jīng)增長(zhǎng)至PB級(jí)別、業(yè)務(wù)需求也逐步發(fā)展，我們顯然需要一套經(jīng)過(guò)優(yōu)化的交互式系統(tǒng)以實(shí)現(xiàn)更低的查詢延遲?！背酥?，Cloudera正在HDFS以上建立自己的SQL方案Impala。前面提到的這一系列發(fā)展都立足于Hive——一套面向Hadoop、長(zhǎng)期存在且得到廣泛采用的SQL外殼。

    SQL用戶及程序員也因此得以重新使用自己積累自多種后端系統(tǒng)的API以及用戶界面知識(shí)，從而縮減應(yīng)用程序開(kāi)發(fā)時(shí)間。標(biāo)準(zhǔn)化特性還允許擁有聲明許可的第三方打造提取、轉(zhuǎn)換以及加載(簡(jiǎn)稱ETL)工具，旨在幫助企業(yè)以流程化方式處理不同數(shù)據(jù)庫(kù)及系統(tǒng)之間的數(shù)據(jù)流。

    *SQL具備可擴(kuò)展性。有些朋友可能誤以為SQL必須通過(guò)犧牲性能的方式來(lái)獲得可擴(kuò)展性，這其實(shí)是完全錯(cuò)誤的。如上所述，F(xiàn)acebook打造了一款SQL接口對(duì)PB級(jí)別的數(shù)據(jù)加以查詢。SQL在運(yùn)行ACID事務(wù)處理任務(wù)時(shí)同樣具備極快的速度表現(xiàn)。SQL為數(shù)據(jù)存儲(chǔ)及檢索機(jī)制提供的抽象化手段允許用戶以統(tǒng)一化方式完成處理工作，而且無(wú)需考慮具體任務(wù)類(lèi)型以及數(shù)據(jù)規(guī)模;這使得SQL能夠高效運(yùn)行在各類(lèi)集群化副本數(shù)據(jù)存儲(chǔ)體系之間。將SQL作為接口的作法不涉及云創(chuàng)建、具體規(guī)?；蛘逪A系統(tǒng)，而且SQL當(dāng)中也沒(méi)有任何固有因素會(huì)對(duì)容錯(cuò)性、高可用性以及復(fù)制能力產(chǎn)生限制。事實(shí)上，目前所有現(xiàn)代化SQL系統(tǒng)都能夠很好地支持云體系中的橫向可擴(kuò)展性、復(fù)制能力以及容錯(cuò)性。

    *SQL支持JSON。幾年之前，很多SQL系統(tǒng)開(kāi)始將XML文檔支持能力納入自身設(shè)計(jì)思路。時(shí)至今日，隨著JSON逐步成為主流數(shù)據(jù)交換格式之一，各SQL廠商也在積極為JSON提供支持。鑒于當(dāng)下敏捷化編程流程以及對(duì)互聯(lián)網(wǎng)接入基礎(chǔ)設(shè)施正常運(yùn)行時(shí)間的要求，結(jié)構(gòu)化數(shù)據(jù)類(lèi)型的支持能力已經(jīng)成為不可或缺的重要一環(huán)。Oracle12c、PostgreSQL9.2、VoltDB以及其它各類(lèi)數(shù)據(jù)庫(kù)方案都開(kāi)始支持JSON——其性能基準(zhǔn)水平普遍優(yōu)于“原生”JSONNoSQL方案。

    SQL將繼續(xù)在市場(chǎng)份額的爭(zhēng)奪戰(zhàn)中占據(jù)主動(dòng)，也將繼續(xù)吸引到更多投資方與采納者的支持。NoSQL數(shù)據(jù)庫(kù)在提供專有查詢語(yǔ)言或者簡(jiǎn)單鍵-值語(yǔ)義的同時(shí)，卻無(wú)法從深入的技術(shù)層面帶來(lái)差異性，這無(wú)疑嚴(yán)重影響了其挑戰(zhàn)市場(chǎng)統(tǒng)治者的能力。現(xiàn)代SQL系統(tǒng)能夠在保持甚至超越原有可擴(kuò)展性的同時(shí)，支持豐富的查詢語(yǔ)義、建立并培養(yǎng)用戶基礎(chǔ)、拓展生態(tài)系統(tǒng)集成效果并在企業(yè)環(huán)境內(nèi)深化采納程度。

    目前已經(jīng)有越來(lái)越多的企業(yè)開(kāi)始將NoSQL視為關(guān)系型數(shù)據(jù)庫(kù)的一種可行性替代方案;特別是在大數(shù)據(jù)應(yīng)用程序領(lǐng)域，很多企業(yè)用戶意識(shí)到規(guī)模化操作的實(shí)際表現(xiàn)要優(yōu)于標(biāo)準(zhǔn)化集群與商用服務(wù)器所帶來(lái)的效果。除此之外，采用無(wú)模式化數(shù)據(jù)模型往往更適合當(dāng)下各類(lèi)不同數(shù)據(jù)的捕捉與處理工作。

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

    技術(shù)行業(yè)在每一次迎來(lái)硬件發(fā)展的根本性轉(zhuǎn)變時(shí)，都必然經(jīng)歷過(guò)渡拐點(diǎn)。在數(shù)據(jù)庫(kù)領(lǐng)域，這種由向上擴(kuò)展轉(zhuǎn)為向外擴(kuò)展架構(gòu)的轉(zhuǎn)變也成為推動(dòng)NoSQL快速成長(zhǎng)的主要因素。關(guān)系型數(shù)據(jù)庫(kù)，其中包括由甲骨文及IBM等巨頭所打造的具體方案，專注于解決向上擴(kuò)展難題。也就是說(shuō)，它們采取集中式、全局共享技術(shù)，只能通過(guò)添加價(jià)格更為昂貴的硬件設(shè)備滿足擴(kuò)展需求。

    分布式向外擴(kuò)展方案往往還會(huì)帶來(lái)低于向上擴(kuò)展機(jī)制的使用成本。后者屬于一整套龐大、復(fù)雜、具備容錯(cuò)性機(jī)制的服務(wù)器體系，因此無(wú)論是設(shè)計(jì)、建造還是后期支持都會(huì)帶來(lái)高昂的成本支出。商用關(guān)系型數(shù)據(jù)庫(kù)的許可成本同樣不容忽視，因?yàn)槠溆?jì)費(fèi)策略以單一服務(wù)器為基本單位。在另一方面，NoSQL數(shù)據(jù)庫(kù)則通常屬于開(kāi)源項(xiàng)目，以服務(wù)器集群為整體計(jì)費(fèi)單位、價(jià)格也相比較低。

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

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

    信息匯總工作可能導(dǎo)致信息內(nèi)容出現(xiàn)重復(fù)，不過(guò)由于目前存儲(chǔ)資源已經(jīng)不再屬于主要成本來(lái)源，因此這類(lèi)數(shù)據(jù)模型能夠帶來(lái)更出色的靈活性、便于高效分配由此產(chǎn)生的文檔并改進(jìn)讀取與寫(xiě)入操作的性能表現(xiàn)、從而提升Web應(yīng)用程序的替代性效果。

    時(shí)至今日，我們已經(jīng)能夠愈發(fā)便捷地通過(guò)第三方環(huán)境、包括社交媒體網(wǎng)站對(duì)數(shù)據(jù)進(jìn)行捕捉與訪問(wèn)。個(gè)人用戶信息、地理位置數(shù)據(jù)、用戶產(chǎn)生的內(nèi)容、設(shè)備登錄數(shù)據(jù)以及傳感器數(shù)據(jù)等只是這股風(fēng)潮當(dāng)中的少數(shù)典型代表，數(shù)據(jù)來(lái)源清單正在不斷拓展。同時(shí)，企業(yè)也越來(lái)越依賴大數(shù)據(jù)技術(shù)的力量、旨在驅(qū)動(dòng)其關(guān)鍵性業(yè)務(wù)應(yīng)用?？傮w而言，各企業(yè)已經(jīng)開(kāi)始向NoSQL伸出橄欖枝，因?yàn)檫@類(lèi)方案是惟一能夠適應(yīng)當(dāng)前新興數(shù)據(jù)類(lèi)型的處理手段。

    開(kāi)發(fā)人員需要一套更為靈活、能夠輕松適應(yīng)最新數(shù)據(jù)類(lèi)型的數(shù)據(jù)庫(kù)方案，從而避免破壞第三方數(shù)據(jù)供應(yīng)商所提供的內(nèi)容結(jié)構(gòu)調(diào)整。大部分新型數(shù)據(jù)屬于非結(jié)構(gòu)化或者半結(jié)構(gòu)化類(lèi)型，因此開(kāi)發(fā)人員還需要自己的數(shù)據(jù)庫(kù)有能力高效對(duì)其加以保存。遺憾的是，關(guān)系型數(shù)據(jù)庫(kù)所采取的嚴(yán)格定義、以模式為基礎(chǔ)的設(shè)計(jì)思路令我們無(wú)法快速接納全新數(shù)據(jù)類(lèi)型，自然也難以適應(yīng)非結(jié)構(gòu)化及半結(jié)構(gòu)化數(shù)據(jù)。NoSQL帶來(lái)的數(shù)據(jù)模型則能夠更好地與其實(shí)際需求加以映射。

                                                                                                         數(shù)據(jù)分析師