索 劍，羅中良

(惠州學院計算機科學系，廣東惠州 516007）

基于Web2.0的應用推動了大數(shù)據(jù)時代到來，傳統(tǒng)關系型數(shù)據(jù)庫面臨著高并發(fā)讀寫、高可擴展性、高可用性要求的挑戰(zhàn)，大量的數(shù)據(jù)處理不僅涉及結構化數(shù)據(jù)，也面向準結構化數(shù)據(jù)和非結構化數(shù)據(jù)。隨著系統(tǒng)的不斷增大，關系型數(shù)據(jù)庫逐漸力不從心，NoSQL數(shù)據(jù)庫逐漸進入應用領域。

為了承載大規(guī)模數(shù)據(jù)通常采用的是分布式數(shù)據(jù)庫系統(tǒng)，目前比較一致的觀點是在分布式系統(tǒng)中一致性 (Consistent)、可用性 (Available)和分區(qū)容錯性 (Partition-tolerant)，很難同時滿足［1－4］。RDBMS的基石是保證服務器端和客戶端的一致性，同時保證良好的響應性能和用戶體驗，但保障跨區(qū)域以及良好的擴展性較為困難;NoSQL運動試圖在跨區(qū)域系統(tǒng)不斷擴展的現(xiàn)實驅動下，滿足良好的用戶體驗，這樣只能犧牲即時一致性，通過最終一致性 (Eventually Consistancy)滿足數(shù)據(jù)存取需求［5］。將不同特性和機制視為矛盾并不可取，有效地將二者結合起來有更廣闊的應用場景。

正是由于兩類數(shù)據(jù)庫不同的特點和具體應用場景的約束，關于關系型數(shù)據(jù)庫和NoSQL的結合與擴展逐漸成為業(yè)界討論的熱點。唐李洋等以分布式多節(jié)點架構的索引構建為背景，提出了建立在分布可擴展的數(shù)據(jù)存儲Cassandra(一種NoSQL)之上的分布式反向索引，進行擴展性的討論［6］;姚林等提出將NoSQL作為鏡像引入關系數(shù)據(jù)庫架構系統(tǒng)以實現(xiàn)分布式存儲和改進［7］;張國榮將關系數(shù)據(jù)庫的基礎數(shù)據(jù)通過MongoDB非關系型的實現(xiàn)了電子表單系統(tǒng)［8］;基于此方向的研究和應用還有很多［9－14］，事實上，MySQL、Oracle 等已開始在傳統(tǒng)關系型數(shù)據(jù)庫的基礎上融合NoSQL思想的實踐。

總體來看，兩種方案可以實現(xiàn)數(shù)據(jù)在此場景下的存儲:一是將數(shù)據(jù)分別存儲在關系型數(shù)據(jù)庫和NoSQL數(shù)據(jù)庫中，以關系數(shù)據(jù)庫和NoSQL數(shù)據(jù)庫相應完整的機制分別驅動支撐;二是將數(shù)據(jù)存儲在關系數(shù)據(jù)庫中，關系型的數(shù)據(jù)遵守關系數(shù)據(jù)庫的規(guī)則，非關系存儲的數(shù)據(jù)通過對關型數(shù)據(jù)庫的無模式改造而實現(xiàn)。本文正是基于后者思想而實現(xiàn)的。

1 關系型數(shù)據(jù)庫存取機制和基本原理

從外部訪問到內部磁盤存儲，RDBMS為了保證ACID(原子性 Atomicity、一致性 Consistency、隔離性Isolation、持久性Durability)特性，設計了復雜的多層結構。從數(shù)據(jù)存取的架構上來看，可以分為三層:訪問接口層、邏輯處理層、物理存儲層。訪問接口層負責為不同類型的數(shù)據(jù)訪問進程提供接口，面向外部鏈接;邏輯處理層是RDBMS的核心，負責查詢處理、事務管理、恢復管理、存儲管理，由統(tǒng)一的資源管理支撐，實現(xiàn)ACID的保障;物理存儲層面向磁盤等物理存儲設備，處理中間數(shù)據(jù)和結果數(shù)據(jù)的外部存儲。

在客戶端對關系型數(shù)據(jù)庫進行存取數(shù)據(jù)時，首先建立客戶端和服務器的聯(lián)系，在接收客戶端的數(shù)據(jù)訪問指令后，RDBMS對訪問指令進行詞法、語法、完整性驗證、語義分析，并根據(jù)數(shù)據(jù)字典等資源實施合適的的優(yōu)化處理、事務管理 (包括鎖的實現(xiàn)和執(zhí)行)策略，分析后的操作指令在統(tǒng)一的保障環(huán)境下執(zhí)行，執(zhí)行后的中間數(shù)據(jù)、結果等以指定方式存儲或返回。

圖1 關系數(shù)據(jù)庫數(shù)據(jù)存取機制Fig.1 The data access mechanism in relational database

從結構上來看，每一次數(shù)據(jù)存取，都必須經(jīng)過上述三層結構，執(zhí)行從查詢處理子系統(tǒng)、事務管理子系統(tǒng)、恢復管理子系統(tǒng)到存儲管理子系統(tǒng)的每一步操作。所涉及的索引、靜態(tài)數(shù)據(jù)結構、存儲引擎、并發(fā)控制、連接等基礎功能性操作需考慮大量的一致性、準確性問題，從而導致存取效率較低、擴展不易以及分布式實現(xiàn)代價高。

2 NoSQL的存取機制

NoSQL不僅僅可以使用SQL的方式進行數(shù)據(jù)管理，還可結合多種數(shù)據(jù)模型和操作模型。由于產(chǎn)品繁多，同時不像關系數(shù)據(jù)庫那樣成熟標準，因此提供了多種的架構方式，通常并沒有強制的數(shù)據(jù)結構約束。但總體思想是類同的，最常見的是基于Key值的存儲模型，主要有:Key-Values、Key－結構化數(shù)據(jù)、Key－文檔類型、列式存儲、BigTable、行式存儲等，除此之外還有圖結構存儲摸型。No-SQL系統(tǒng)通常注重性能和擴展性，而非強事務機制，通常NoSQL系統(tǒng)僅提供行級別的原子性保證，也就是說同時對同一個Key下的數(shù)據(jù)進行的兩個操作，在實際執(zhí)行時是會串行的，從而保證每一個Key-Value對不會被破壞。NoSQL適宜使用分布式架構，通過使用HASH環(huán)算法實現(xiàn)分布存儲與拓展［1，7］，保證數(shù)據(jù)的最終一致性。

3 關系數(shù)據(jù)庫中無模式數(shù)據(jù)的存取方法

3.1 基本存取思想

通過對關系型數(shù)據(jù)庫分析可以看出，RDBMS為了保證ACID會實施很多保障性措施，若借助NoSQL的思想，在RDBMS中數(shù)據(jù)服務器對客戶端發(fā)送數(shù)據(jù)與指令執(zhí)行解釋執(zhí)行的時候，重新改寫并實現(xiàn)查詢處理功能，使之在處理SQL解釋、鎖管理、查詢優(yōu)化、解釋操作等時選擇性執(zhí)行，如圖2所示，使數(shù)據(jù)可以根據(jù)選擇分兩種方式進入執(zhí)行和操作階段。一是按原有RDBMS中的規(guī)范執(zhí)行，保持一致性但效率較低;二是最小度執(zhí)行這些保障性內容，效率較高但一致性較低。同時根據(jù)需要，以同一思想重建事務管理和數(shù)據(jù)存儲。這樣可以加快所有的數(shù)據(jù)處理。

圖2 無模式數(shù)據(jù)存取思想Fig.2 The design of schema-Less data access

這樣的存取思想需要解決好兩個問題:存取的數(shù)據(jù)間可以實現(xiàn)分組存取，解決好數(shù)據(jù)與數(shù)據(jù)間的關系問題;連接關系型數(shù)據(jù)庫并兼容原有功能與SQL語句的操作。

3.2 無模式存取的設計架構

如圖3，按照上述思想，可以將處理劃分為三個層次，分別是接口處理層、核心處理層、數(shù)據(jù)處理層。

3.2.1 接口處理層 從外部應用程序獲取數(shù)據(jù)訪問的指令和參數(shù)，并對指令作解釋，對數(shù)據(jù)模式初始化，做出相應轉換;同時作為通道返回最終處理的數(shù)據(jù)結果集。該層主要由參數(shù)收集模塊、模式判斷模塊、初始化處理模塊、上層Helper管理文件模塊、Error Message等幾個模塊構成。

參數(shù)收集模塊對外部發(fā)送過來的數(shù)據(jù)與指令進行收集。主要收集的內容有連接關系型數(shù)據(jù)庫配置參數(shù)，包括適配器、host、數(shù)據(jù)庫用戶名與密碼、數(shù)據(jù)庫名稱、進程數(shù)量等;數(shù)據(jù)庫模式類型;上層Helper方法的調用參數(shù);外部接口需要提供的最基本表結構類型;底層數(shù)據(jù)結構需要的參數(shù);外部接口傳輸過來需要操作的數(shù)據(jù)參數(shù)等。

圖3 結構示意圖Fig.3 Structural diagram

模式判斷模塊由參數(shù)收集模塊根據(jù)傳送的數(shù)據(jù)類型來判斷觸發(fā)，若傳輸DB type參數(shù)為無模式擴展的類型時，將返回參數(shù)收集模塊，并繼續(xù)正常運行;若為普通模式，把此M－數(shù)據(jù)模型定為普通Table表，按照關系模式進行處理，并返回信息提示給參數(shù)收集停止其他運行操作。

初始化處理模塊根據(jù)參數(shù)收集模塊傳過來的數(shù)據(jù)參數(shù)、類型、索引等幾個主要參數(shù)在模塊內初始化，將直接被數(shù)據(jù)處理層用于鏈接關系型數(shù)據(jù)庫與對數(shù)據(jù)庫進行操作。

上層Helper管理文件模塊針對無模式模型，由參數(shù)收集模塊發(fā)送數(shù)據(jù)模型參數(shù)，Helper管理模塊根據(jù)這些參數(shù)動態(tài)生成Model擁有的相應字段方法，而后這些方法將會直接在核心處理層的方法管理模塊other helper中注冊，以便在外部調用。

Error Message模塊用于返回以上操作過程中出現(xiàn)的錯誤。

3.2.2 核心處理層 使這些數(shù)據(jù)直接保存為Storage格式，規(guī)避ACID特性相應的附加操作;提供其他應用與框架的主要接口層功能，提供多進程處理操作。包括參數(shù)集解釋處理器、主進程管理模塊、方法管理模塊、表結構模型、數(shù)據(jù)集編碼和數(shù)據(jù)集解碼等模塊。

參數(shù)解釋處理主要負責解釋由上層命令接收發(fā)來參數(shù)。主要參數(shù)包括字段、字段默認值配置、索引表名、進程處理數(shù)、調用方法名、集群數(shù)據(jù)庫參數(shù)、M－模型名等。

主進程管理模塊對分發(fā)的進程進行管理。在原有的關系型數(shù)據(jù)庫模式中，沒有采用分布式的數(shù)據(jù)操作，因為其中的數(shù)據(jù)都是有關系的，采用分布式操作數(shù)據(jù)反而會加大數(shù)據(jù)操作困難與關系掉鏈［17］。但由于減弱了關系型數(shù)據(jù)庫中數(shù)據(jù)的關聯(lián)，所以這些操作數(shù)據(jù)間都是各自獨立的，包括操作過程中也是互不影響的，所以添加了擴展的關系型數(shù)據(jù)庫是能比較簡便的采用分發(fā)多進程處理操作。Web應用程序每次調用運行時，默認提供一個主進程運行，通過進程處理數(shù) (Process Number)來分發(fā)出對應的進程數(shù)量。當子進程運行時，主進程等待，待標志的所有子進程運行完畢后，主進程繼續(xù)運行，并收集各子進程運行結果，所以對外返回數(shù)據(jù)與信息都是只有通過主進程，子進程只是參與內部運算操作。未被標志的子進程自行運行到任務結束，無需返回任何信息給主進程。

方法管理模塊中的方法分為兩類:一類是實體數(shù)據(jù)對象方法，這類方法主要存放在OtherHelper模塊，屬于關系型數(shù)據(jù)庫操作方法。第二類方法是無模式的類方法，這類方法主要存放在ClassMethod這個方法管理塊中，接口處理層中賦予M－數(shù)據(jù)模型的Helpers方法主要就是類方法。類方法與對象方法都保存在Method塊中，便于代碼管理與提高代碼的可讀性。這里提供了6種常用的類方法:Create、Update、Save、Query、Delete、Drop。

表結構模型將會根據(jù)傳來參數(shù)Index、Attribute與Model所構建的兩種類型無模式數(shù)據(jù)存儲結構，實體數(shù)據(jù)存儲結構與弱關聯(lián)索引表結構［15］，同時索引表也建立弱關聯(lián)關系。用Primary_key表示關系型數(shù)據(jù)庫表主鍵，id表示無模式數(shù)據(jù)實體唯一實體標志，采用uuid時間生成格式，contents表示無模式數(shù)據(jù)實體存儲的字段，created_at、updated_at默認提供時間顯示字段。

數(shù)據(jù)集編碼主要的任務是根據(jù)數(shù)據(jù)實體不同需要進行Json Key-Values編碼，存儲到contents字段中。數(shù)據(jù)集編碼后，在Web應用程序對數(shù)據(jù)集進行搜索時，需要對返回結果進行數(shù)據(jù)集解碼，以便獲取適合外部調用的數(shù)據(jù)。

3.2.3 數(shù)據(jù)處理層 提供不同關系型數(shù)據(jù)庫連接適配器，與數(shù)據(jù)庫連接并支持將不同數(shù)據(jù)根據(jù)規(guī)則保存到分布式的數(shù)據(jù)倉庫集群中。主要包括參數(shù)結果收集模塊、對外連接模塊和數(shù)據(jù)庫連接模塊等。

參數(shù)結果收集模塊分為參數(shù)子模塊與結果子模塊，前者針對上層參數(shù)收集與等待傳送，后者進行底層分布式數(shù)據(jù)庫集群數(shù)據(jù)獲取的收集，并且提供共享緩存點。

對外連接模塊提供了端口的監(jiān)聽方式，當有請求 (例如HTTP請求)來對端口進行數(shù)據(jù)操作處理時，這時候會根據(jù)操作類型提供不同回調方法，若操作時存儲數(shù)據(jù)，這時候就會對在參數(shù)結果收集模塊中的參數(shù)數(shù)據(jù)進行分組，然后分發(fā)到對外連接模塊，然后再通過原有的請求方法把數(shù)據(jù)發(fā)送過去;倘若操作時獲取數(shù)據(jù)，就通過對外連接模塊把請求回來的數(shù)據(jù)暫存在參數(shù)結果收集模塊中的結果子模塊中，等待所有數(shù)據(jù)都獲取完成后，主進程再把最后的數(shù)據(jù)結果集發(fā)送到上層分層結構中。

數(shù)據(jù)庫連接模塊分為適配器子模塊、SQL方法擴展子模塊、插件子模塊三層。適配器子模塊針對諸如 Sqlite、 Mysql、 Oracle、 Postgres、 Sql server ado等不同關系型數(shù)據(jù)庫提供不同的適配器用于連接;SQL方法擴展子模塊用于對應不同關系型數(shù)據(jù)庫對標準的SQL語言進行的擴展［16］;插件子模塊用于在底層擴展新功能提供的協(xié)調。

3.3 無模式存取方法的實現(xiàn)

在關系數(shù)據(jù)庫中實現(xiàn)無模式數(shù)據(jù)的存取流程可用圖4描述。

圖4 存取流程圖Fig.4 Access flow diagram

在Linux Ubuntu11.10操作系統(tǒng)環(huán)境下，使用關系型數(shù)據(jù)庫Mysql，通過Ruby1.9.2語言實現(xiàn)了上述三層結構，進行了數(shù)據(jù)庫的模擬運行，功能正常。

4 性能測試與對比

在關系數(shù)據(jù)庫中實現(xiàn)了無模式數(shù)據(jù)的存取后，與關系存取性能做了對比測試。更新測試、查詢測試、DDL阻塞測試描述如下。

測試環(huán)境是一臺三星筆記本計算機，處理器為Intel酷睿i3，主頻2.2 GHz，物理內存2 G，SATA硬盤500 G。

4.1 數(shù)據(jù)插入測試

測試模擬微博網(wǎng)站短時間內并發(fā)數(shù)據(jù)分別以傳統(tǒng)關系存儲方式和無模式擴展方式 (進程數(shù)為1)寫入，模擬數(shù)據(jù)量將分為100條、1000條、100000條三類，測試兩種方式插入所需的時間，單位為秒(s)。插入的數(shù)據(jù)庫表結構為:Create table materiel(mid int primary key，name vachar(200)，models vachar(200)，making vachar(200)，customer vachar(233)，quantity integer)。并發(fā)插入 100、1000、10000條記錄的測試結果如表1。

表1 并發(fā)數(shù)據(jù)插入測試Table 1 Concurrent insertion test

測試結果表明無模式擴展存儲的并發(fā)插入速度明顯優(yōu)于關系型數(shù)據(jù)庫操作，隨著并發(fā)數(shù)據(jù)量逐漸增多，關系型存儲方式的數(shù)據(jù)插入效率明顯越來越低。在增加進程數(shù)后，無模式擴展以原有效率可支持更多的并發(fā)數(shù)。

4.2 查詢測試

查詢是數(shù)據(jù)庫存取的關鍵指標，短時間響應查詢設定關系型模式存儲數(shù)據(jù)和進程數(shù)分別為1、2、5的無模式擴展針對50000、100000、1000000條記錄的查詢，其中進程數(shù)2和5針對進程數(shù)取了平均值，測試結果如表2。

從上測試結果可以看出，無模式存儲方式的檢索速度明顯優(yōu)于關系型存儲模式，在針對分布式數(shù)據(jù)庫集群中以及多進程數(shù)據(jù)搜索中，無模式存儲方式可開啟多進程處理查詢請求，搜索速度將進一步提高。

表2 查詢測試Table 2 Query test

4.3 DDL阻塞測試

前已敘及，為了保證ACID特性，關系數(shù)據(jù)庫在數(shù)據(jù)存取前后必須進行加鎖解鎖處理，這樣一旦出現(xiàn)DDL相關修改，勢必影響存取速度。圖5是模擬刪除索引表的DDL阻塞，可以看出在50000條數(shù)據(jù)集中完成插入的1條數(shù)據(jù)操作所耗費時間為0.1 s，在刪除索引表時DDL阻塞情況下完成插入1條數(shù)據(jù)的時間2.4 s，阻塞等待時間約2.3 s;相同環(huán)境下也做了刪除1條數(shù)據(jù)的測試，時間基本等同。若數(shù)據(jù)集很大，則堵塞時間將會進一步增加。

圖5 DDL阻塞測試1Fig.5 DDL blocking test 1

無模式擴展存取方式的設計方案規(guī)避了鎖處理的過程，插入和刪除相當于對于單表操作，可有效避免關系型數(shù)據(jù)庫的DDL阻塞。圖6是無模式數(shù)據(jù)測試插入和刪除1條數(shù)據(jù)的時間，可以看出沒有引起DDL阻塞。

圖6 DDL阻塞測試2Fig.6 DDL blocking test 2

事實上在關系模型下引發(fā)DDL阻塞的情況還有很多，例如若表結構發(fā)生了改變，不僅會引起DDL阻塞，而且還需對數(shù)據(jù)庫表結構進行重新的編碼過程，這樣既引發(fā)效率問題也增加了出現(xiàn)錯誤的風險。在無模式環(huán)境下基于上述思想，只要在M－模型中添加需要的字段，就可以直接改變屬性集，較好的解決了問題。

除了以上基本的存取測試，還做了擴展性的測試。模擬分布式集群下分別并發(fā)插入10000條數(shù)據(jù)，檢索10000條記錄通過 HTTP請求發(fā)送到Memcached的共享緩存點的過程。測試結果表明無模式存儲方式的擴展，能支持分布式數(shù)據(jù)集群，把數(shù)據(jù)按照定好的規(guī)則保存到數(shù)據(jù)庫中，也能在所有的數(shù)據(jù)庫集群中獲取響應檢索的數(shù)據(jù)，返回數(shù)據(jù)結果集。

5 結語

相比傳統(tǒng)關系數(shù)據(jù)庫支持的ACID語義約束了大數(shù)據(jù)量高效訪問，NoSQL讓數(shù)據(jù)庫具備了非關系、可水平擴展、可分布和開源等特點，將關系數(shù)據(jù)庫和NoSQL模式融合在一起可以提供不同應用場景的需求，可在滿足數(shù)據(jù)一致性的同時提供高效存取和分布式應用和拓展，這種融合可以應用在Web應用服務器、內容管理系統(tǒng)、結構化事件記錄、移動應用專用的服務器端存儲、文件存儲等多個方面。本文提出了一種在關系型數(shù)據(jù)庫中構建無模式數(shù)據(jù)存取的方法，將主要的數(shù)據(jù)與這些數(shù)據(jù)的索引分離開來，定義一種新的數(shù)據(jù)存儲模式存儲數(shù)據(jù)，減弱關系型模式數(shù)據(jù)庫中數(shù)據(jù)間的聯(lián)系，形成自定義的一種“無模式”持久方案，從而實現(xiàn)關系型模式數(shù)據(jù)庫與無模式結合，進行并行數(shù)據(jù)存取。提供了在強調一致性、高關系性的場景中采用關系型模式的ACID模型，在強調高可用性、高擴展性與多變數(shù)據(jù)模式的場景采用BASE(Basis Availability，Soft Status，Eventually Consistancy)模型的一種方案。

［1］WETH C，DATTA A.GutenTag:A multi-term caching optimilized tag query processor for key-value based noSQL storage systems［EB/OL］.http://arxiv.org/pdf/1105.4452，2011 －06，2012 －11.

［2］GILBERT S，LYNCH N.Brewer's conjecture and the feasibility of consistent，available，partition-toleram Web services［J］.SI－ GACT News，2002，33(2):51 －59.

［3］ERIC Brewer.CAP twelve years later:How the“rules”have changed［EB/OL］.http://www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-changed;jsessionid=25A629918DB53CE5EB24C6A7EEF3D01D，2012 －05，2012 －10.

［4］BANQ.CAP 原理和 BASE 思想［EB/OL］.http://www.jdon.com/37625.2009 －11，2012 －11.

［5］VOGELS W.Eventually consistent［J］.Queue，2008，6(6):14－19.

［6］唐李洋，倪志偉，李應.基于Cassandra的可擴展分布式反向索引的構建［J］.計算機科學，2011，6:187 －190.

［7］姚林，張永庫.NoSQL的分布式存儲與擴展解決方法［J］.計算機工程，2012，3:40 －42.

［8］張國榮.基于關系型與非關系型數(shù)據(jù)庫的電子表單系統(tǒng)設計與實現(xiàn)［D］.廣州:中山大學，2012.

［9］呂美英，郭顯娥.NOSQL和可擴展的SQL［J］.大同大學學報:自然科學版，2012，5;15 －18.

［10］曾凱，曾斌，楊英，等.擴展SQL跟蹤數(shù)據(jù)技術在數(shù)據(jù)庫性能診斷上的應用［J］.計算機應用與軟件，2006，1:128－130.

［11］王銳.基于MongoDB的關系網(wǎng)絡分析技術研究與應用［D］.長沙:國防科學技術大學，2011.

［12］劉一夢.基于MongoDB的云數(shù)據(jù)管理技術的研究與應用［D］.北京:北京交通大學，2012.

［13］蔡柳青.基于MongoDB的云監(jiān)控設計與應用［D］.北京:北京交通大學，2011.

［14］王光磊.MongoDB數(shù)據(jù)庫的應用研究和方案優(yōu)化［J］.中國科技信息，2011，20:93 －94，96.

［15］BRET Taylor.How friend feed uses MySQL to store schema-less data［EB/OL］.http://www.zhmy.com/jinghuarizhi_2010_08_663.html，2009 －2，2012 － 10.

［16］周淵，王力生.Mysql中InnoDB存儲引擎在NUMA系統(tǒng)上的優(yōu)化［J］.科技傳播，2011.1:155－156.

［17］馮祖洪.MySQL的分布式數(shù)據(jù)庫訪問法［J］.計算機應用，2002，8:4 －6.