大數(shù)據(jù)趨勢下的RD與NoSQL融合

1、.大數(shù)據(jù)趨勢下的RD與NoSQL融合-工程論文大數(shù)據(jù)趨勢下的RD與NoSQL融合 儲智廣 滕征岑 張志偉 王博（北京中油瑞飛信息技術(shù)有限責(zé)任公司北京100007）摘要：隨著互聯(lián)網(wǎng)技術(shù)的飛速發(fā)展，對數(shù)據(jù)存儲技術(shù)提出了更高的需求。本文結(jié)合NoSQL應(yīng)用案例，分析了關(guān)系型數(shù)據(jù)庫和非關(guān)系型數(shù)據(jù)庫兩大數(shù)據(jù)存儲類型，對企業(yè)未來應(yīng)對大數(shù)據(jù)存儲選擇問題提出新的思路和看法。關(guān)鍵詞：大數(shù)據(jù)；數(shù)據(jù)存儲；關(guān)系型數(shù)據(jù)庫；RD；NoSQL隨著互聯(lián)網(wǎng)的飛速發(fā)展，對數(shù)據(jù)存儲技術(shù)提出了更高的要求。雖然關(guān)系型數(shù)據(jù)庫(RD)在數(shù)據(jù)存儲方面有較大優(yōu)勢，但在低延遲的讀寫速度、支持海量的數(shù)據(jù)流量、大規(guī)模集群的管理、降低成本等方面，已經(jīng)很

2、難滿足企業(yè)的實際需求，非關(guān)系型數(shù)據(jù)庫 NoSQL)應(yīng)運而生。NoSQL非常關(guān)注對數(shù)據(jù)高并發(fā)地讀寫和對海量數(shù)據(jù)的存儲等，與關(guān)系型數(shù)據(jù)庫相比，在架構(gòu)和數(shù)據(jù)模型方面做了“減法”，而在擴(kuò)展和并發(fā)等方面做了“加法”。1為什么選擇NoSQL數(shù)據(jù)庫1.1 RD的不足(1)大數(shù)據(jù)量的寫入處理。在數(shù)據(jù)讀入方面，由復(fù)制產(chǎn)生的主從模式可以通過增加從數(shù)據(jù)庫簡單地實現(xiàn)規(guī)模化，但在數(shù)據(jù)寫入方面則沒這么簡單。例如：數(shù)據(jù)的寫入規(guī)?；梢钥紤]把主數(shù)據(jù)庫從一臺增加到兩臺，作為互相關(guān)聯(lián)復(fù)制的二元主數(shù)據(jù)庫，這樣可以減少每臺主數(shù)據(jù)庫的負(fù)荷，但更新處理會發(fā)生沖突，可能造成數(shù)據(jù)的不一致，因此需要把每個表的請求分別分配給合適的主數(shù)據(jù)庫來處理

3、，這樣就使問題變得復(fù)雜化。(2)為有數(shù)據(jù)更新的表做索引或表結(jié)構(gòu)變更。使用關(guān)系型數(shù)據(jù)庫時，為了加快查詢速度需要創(chuàng)建索引，增加必要的字段就一定要改變表結(jié)構(gòu)，這需要對表進(jìn)行共享鎖定。共享鎖定期間無法進(jìn)行數(shù)據(jù)的變更（更新、插入、刪除等）。如果共享鎖定較長，可造成數(shù)據(jù)長時間無法更新。(3)字段不固定時的應(yīng)用。如果字段不固定，利用關(guān)系型數(shù)據(jù)庫也是比較困難的。有人用“需要的時候增加字段”的方法，但是在實際中不易實現(xiàn)。也有人采取預(yù)留大量字段的方法，但時間久了很容易被忘記。1.2 NoSQL的優(yōu)勢(1)易于數(shù)據(jù)的分散。關(guān)系型數(shù)據(jù)庫是以JOIN為前提（即各個數(shù)據(jù)之間存在一定的關(guān)聯(lián)），進(jìn)行JOIN處理時不得不把數(shù)據(jù)

4、存儲在同一個服務(wù)器中，這不利于數(shù)據(jù)的分散。相反，NoSQL是不支持JOIN處理的，各個數(shù)據(jù)都是獨立設(shè)計的，很容易分散到多個服務(wù)器或者PC上，減少了每臺服務(wù)器的數(shù)據(jù)量。即使需要進(jìn)行大量數(shù)據(jù)的寫入操作，處理起來也很容易。同理，數(shù)據(jù)的讀取操作也比較容易實現(xiàn)。(2)提升性能和增大規(guī)模。想要服務(wù)器輕松處理更大量的數(shù)據(jù)，只有兩個選擇：一是提升性能，二是增大規(guī)模（圖1）。前者通過提高現(xiàn)行服務(wù)器自身的性能和配置來提高處理能力，不需要變更程序，但需要一定的費用。目前市場上購買性能翻倍的服務(wù)器，花費一般比原來高2倍，甚至可達(dá)510倍。后者就是使用更多廉價的服務(wù)器來提高處理能力，這樣可以降低成本，但需要變更程序。

5、通過對程序進(jìn)行變更來提升性能是可行的，但是在云技術(shù)時代，各種應(yīng)用層出不窮，數(shù)據(jù)處理的瓶頸是關(guān)系型存儲方式。這也是NoSQL出現(xiàn)的原因。1.3 NoSQL的應(yīng)用現(xiàn)狀NoSQL因互聯(lián)網(wǎng)而生，故目前大部分應(yīng)用在互聯(lián)網(wǎng)企業(yè)中。現(xiàn)在主流的NoSQL數(shù)據(jù)庫有BigTable、HBase、Cassandra、SimpleDB、CouchDB、MongoDB和Redis等（表1）。 2 NoSQL典型產(chǎn)品分析NoSQL在存儲數(shù)據(jù)模型上遵循schema-free原則，目前主要有列式( Column)、文檔型(Document)、鍵值對(Key-Value)、圖型(Graph)等4類。根據(jù)不同的模型，NoSQL還

6、可以分為不同種類的數(shù)據(jù)庫（表2）。 根據(jù)市場上的應(yīng)用情況和實際數(shù)據(jù)測試分析，對部分產(chǎn)品的特點進(jìn)行了簡單的整理。Memcached：揮發(fā)性的鍵值存儲；一般用作RD的緩存；存在數(shù)據(jù)丟失的可能，一般用來處理不需要持久保存的數(shù)據(jù)；用于需要定期清除數(shù)據(jù)時；使用Consistent Hashing算法（即一致性hash算法）來分散數(shù)據(jù)。Tokyo Tyrant:持久的鍵值存儲；用來處理需要持久保存、高速處理的數(shù)據(jù)；用于不需要定期清除數(shù)據(jù)時；使用Consistent Hashing算法來分配數(shù)據(jù)。Redis:兼具M(jìn)emcached和Tokyo Tyrant優(yōu)勢的鍵值存儲；擅長處理數(shù)組類型的數(shù)據(jù)；可以高速處理

7、時間序列的數(shù)據(jù)，易于處理集合運算；擁有很多可以進(jìn)行原子處理的方法；使用Consistent Hashing算法來分散數(shù)據(jù)。MongoDB:具有無需定義表結(jié)構(gòu)的文檔數(shù)據(jù)；通過BSON( Binary Serialized Document Format)形式可以保存和查詢?nèi)魏晤愋偷臄?shù)據(jù)；無法進(jìn)行Join處理，但是可以通過嵌入來實現(xiàn)該功能；使用sharding（范圍分割）算法來分散數(shù)據(jù)。上述產(chǎn)品均具有非?？斓奶幚硭俣?。3 NoSQL和RD的融合 3.1 NoSQL面臨的挑戰(zhàn)NosoL數(shù)據(jù)庫通過自身易擴(kuò)展性、支持大數(shù)據(jù)、高性能、高可用性、低成本和靈活的數(shù)據(jù)模型等特點彌補(bǔ)了RD的一些不足。但是，Nos

8、oL數(shù)據(jù)庫還存在以下不足：(1)支持度低。大部分的NosoL系統(tǒng)都是開源項目，沒有足夠能力和支持資源，或者說沒有類似于Oracle、Microsoft等大公司的信用支持。(2)成熟度低。目前大部分NosoL產(chǎn)品還有大量的關(guān)鍵特性有待實現(xiàn)。(3)零管理難以實現(xiàn)。NosoL的設(shè)計目標(biāo)是提供零管理的解決方案，但此目標(biāo)遠(yuǎn)遠(yuǎn)沒有實現(xiàn)。目前的NosoL系統(tǒng)需要大量的技術(shù)進(jìn)行升級和維護(hù)。(4)尚不支持soL。soL是數(shù)據(jù)存儲的工業(yè)標(biāo)準(zhǔn)，不支持soL將會使用戶產(chǎn)生一定的學(xué)習(xí)和應(yīng)用遷移成本，推廣實施難度大。NosoL與RD各有優(yōu)缺點（表3），如果雙方可以融合或者汲取對方的優(yōu)點，將是一個很有價值的發(fā)展方向。 3_

9、2 RD數(shù)據(jù)NoSQL化典型案例分析3.2.1 HandlerSocketHandlerSocket是一個MySql的插件。通過這個插件可以直接跟MysoL后端的存儲引擎做key-value式的交互，每秒查詢率可以達(dá)到75W。NosoL是為了彌補(bǔ)關(guān)系型數(shù)據(jù)的不足而開發(fā)的，而HandlerSocket卻是完全不同的解決方案，它可以使關(guān)系型數(shù)據(jù)庫本身具有NosoL的功能，有比memcached還要高的處理速度。由于數(shù)據(jù)庫還是MysoL，只是讀取數(shù)據(jù)有所不同，使用方便而且還有豐富的經(jīng)驗可循，一時間HandlerSocket成為NosoL的焦點。3.2.2 HandlerSocket性能測試前提是需要

10、為MysoL安裝插件、PHP（超文本預(yù)處理器）擴(kuò)展。創(chuàng)建如下的表，然后向其插入20000條數(shù)據(jù)。 在讀取數(shù)據(jù)部分，需要用user_id進(jìn)行查詢，因此事先要為user_id創(chuàng)建索引，其中InnoDB開啟了索引功能（表5）。 可以看出，HandlerSocket的處理速度更快，與開啟了索引功能的memcached相比有較大優(yōu)勢。通過驗證可以知道，HandlerSocket使用簡單，有非常高的處理速度。雖然穩(wěn)定性有待驗證，但已經(jīng)有公司開始使用它了。3.3 RD與NoSOL市場融合趨勢InnoDB的性能已經(jīng)足夠好，并可以直接提供NosoL的功能。但HandlerSocket的出現(xiàn)，給人更多意外。它最大

11、的優(yōu)點就是可以共享MysoL的功能。可能是受HandlerSocket啟發(fā)，MysoL開始關(guān)注NosoL領(lǐng)域的應(yīng)用，并在MysoL5.6 2版本開始增加了通過Memcached協(xié)議直接訪問原生InnoDB API的功能。InnoDBwith Memcached是在提供MysoL服務(wù)的同一進(jìn)程中提供Memcached服務(wù)，這與HandlerSocket的架構(gòu)模式幾乎一樣。因為MysoL Cluster提供了99.99%的高可用性，并提供了去中心化的無縫可擴(kuò)展性，所以對于依賴key-value查詢和寫入的海量數(shù)據(jù)存儲需求來說，MysoL Cluster withMemcached搭配是一個更好的選擇。4結(jié)語網(wǎng)絡(luò)資源爆炸式的增長，使得對NosoL的需求越來越大，已經(jīng)有越來越多的公司和開發(fā)者投入到NosoL產(chǎn)品應(yīng)用和研發(fā)中來。但由于自身成熟度低、不支持soL等因素，NosoL短期內(nèi)不會替代soL。NosoL不會替代RD的原因有3個：傳統(tǒng)行業(yè)的數(shù)據(jù)業(yè)務(wù)可以用Oracle rac等方案解決；現(xiàn)在很多網(wǎng)站只是離線應(yīng)用NosoL，在要求強(qiáng)一致性的廣告系統(tǒng)里依然采用RD，如阿里巴巴、新浪微博、騰訊等；根據(jù)CAP理論，NosoL選擇的是CP、沒有兼顧A，RD選擇