李欣

摘要：大數(shù)據(jù)的出現(xiàn)，使數(shù)據(jù)的存儲需求有所改變，僅使用傳統(tǒng)的關系型數(shù)據(jù)庫已經(jīng)不能滿足大數(shù)據(jù)的需求，因此NoSQL應運而生，然而NoSQL放棄對關系操作的支持，使得系統(tǒng)的移植變得困難。該文提出的存儲方案，不僅可以滿足大數(shù)據(jù)的需求，而且能支持大多數(shù)關系操作。

關鍵詞：大數(shù)據(jù)；RDBMS；NoSQL

中圖分類號：TP311 文獻標識碼：A 文章編號：1009-3044（2015）33-0006-02

隨著云計算和Web2.0技術(shù)的興起，大數(shù)據(jù)成為了并行計算、分布式計算領域的熱點問題。傳統(tǒng)的數(shù)據(jù)庫管理系統(tǒng)利用分布式的事物和鎖機制實現(xiàn)數(shù)據(jù)處理的一致性和容錯性，但是這樣使得數(shù)據(jù)庫管理系統(tǒng)不能獲得良好的可擴展性和可用性。為了應對處理大數(shù)據(jù)的挑戰(zhàn)，非關系數(shù)據(jù)庫通過對關系數(shù)據(jù)庫中一致性、事物、關聯(lián)、索引等功能進行弱化或去除的手段達到了更好的水平可擴展性，但它無法對數(shù)據(jù)進行復雜處理，不支持SQL查詢。因此NoSQL并不能完全取代關系數(shù)據(jù)庫，而是作為解決大數(shù)據(jù)問題的一種方案，與關系數(shù)據(jù)庫相輔相成。

1 RDBMS與NoSQL的簡介

1.1 RDBMS

關系數(shù)據(jù)庫是一門成熟的、同時仍在不斷演進的主流數(shù)據(jù)管理和分析技術(shù)。其主要采用shard-nothing 結(jié)構(gòu)，將關系表在節(jié)點間橫向劃分，并且利用優(yōu)化器來對執(zhí)行過程進行調(diào)度和管理[1]。并行數(shù)據(jù)庫的最大優(yōu)勢在于性能，但是，并行數(shù)據(jù)管理技術(shù)在大數(shù)據(jù)時代喪失了互聯(lián)網(wǎng)搜索這個機會，其主要壓力表現(xiàn)在：擴展性差、對多類型數(shù)據(jù)管理以及對若模式數(shù)據(jù)管理的能力、設計理念的沖突[2]等幾個方面。

1.2 NoSQL

NoSQL是Not SQL的簡稱，是不嚴格遵循二維表范式模型的數(shù)據(jù)庫管理系統(tǒng)。NoSQL數(shù)據(jù)庫采用靈活的、分布式的、對擴展開放的數(shù)據(jù)存儲方式管理數(shù)據(jù)，一般不支持SQL語言接口，也不支持ACID的事物原則[3]。但是NoSQL采用的是基于掃描的處理模式并且對中間結(jié)果步步物化，從而導致較高的I/O代價。在NoSQL中，每個查詢都是直接從文件系統(tǒng)中讀入原始數(shù)據(jù)文件，而非傳統(tǒng)的重數(shù)據(jù)庫中讀入經(jīng)過處理過的文件，因此其元組解析代價遠高于關系數(shù)據(jù)庫[4]。

2 NoSQL與RDBMS的結(jié)合

2.1 非結(jié)構(gòu)化數(shù)據(jù)結(jié)構(gòu)化

非結(jié)構(gòu)化信息管理系統(tǒng)體系結(jié)構(gòu)[5]是一種采用面向?qū)ο蟮姆绞綄Ψ墙Y(jié)構(gòu)化數(shù)據(jù)進行類型定義，本文參考這種方式和面向?qū)ο蟮乃季S模式，同時引入繼承的概念，對原始的非結(jié)構(gòu)化元數(shù)據(jù)進行抽象。類似類的繼承，一個類可以改變部分父類的特性而其他特性保持不變。通過繼承樹這樣的結(jié)構(gòu)來組織類型相似的非結(jié)構(gòu)化數(shù)據(jù)，通過三維模型來表示數(shù)據(jù)與數(shù)據(jù)間的關系。數(shù)據(jù)與數(shù)據(jù)、數(shù)據(jù)與屬性間的關系通過E-R模型在水平方向上描述；同類數(shù)據(jù)間的層級關系通過繼承樹在垂直平面描述。

通過DBMS可以自動管理垂直平面的擴展與映射，通過使用簡單統(tǒng)一數(shù)據(jù)接口完成對整個垂直平面的遍歷；同時，根據(jù)實際數(shù)據(jù)類型，DBMS可以自動選擇對應的處理流程來處理數(shù)據(jù)，因此同一垂直平面內(nèi)不同的數(shù)據(jù)類型可以屏蔽其具體差異，使用完全的不同的操作流程來處理，可以實現(xiàn)數(shù)據(jù)類型的變化對上層應用的透明性。

2.2 非結(jié)構(gòu)化數(shù)據(jù)存儲方案設計

2.2.1 數(shù)據(jù)的存儲方案

非結(jié)構(gòu)化數(shù)據(jù)有兩個特性：原子性和大小不確定性。在關系數(shù)據(jù)庫存儲中有多種存儲此類數(shù)據(jù)的方法，本文是使用數(shù)據(jù)庫系統(tǒng)提供的大數(shù)據(jù)類型來存儲，因為在多態(tài)機制下，原始數(shù)據(jù)本身也可以作為元數(shù)據(jù)的一種，參與數(shù)據(jù)管理過程。這種方式不會有安全性問題和數(shù)據(jù)一致性問題，但是它增加了數(shù)據(jù)庫查詢過程中的IO工作，因而查詢效率較低。

2.2.2 繼承與多態(tài)的實現(xiàn)方案

本文中使用不僅包含原有E-R模型的關聯(lián)關系，還有使用繼承樹表示繼承關系。繼承樹實際是實體關系模型的一種特例，但是與傳統(tǒng)E-R模型的區(qū)別是，該模型對父類的所有操作都要映射到子類中，在繼承樹中，存在一個中間件來表示繼承樹的繼承關系，該中間件存在于數(shù)據(jù)存儲之上，因此具有繼承關系的兩個實體間不存在任何關系。

2.2.3 海量數(shù)據(jù)的存儲

關系數(shù)據(jù)庫通常通過數(shù)據(jù)復制和數(shù)據(jù)切分來擴展集群的計算能力。本系統(tǒng)采用繼承樹，各個類在數(shù)據(jù)存儲層面不需要定義關系，因此可以分開來存儲，因此采用按照列表進行劃分切片，這種方式需要切分健是枚舉類型，根據(jù)切分健的枚舉值進行劃分。但是關系數(shù)據(jù)庫中，不同實體間可能存在關聯(lián)關系，整個數(shù)據(jù)庫的不同數(shù)據(jù)表之間也可能存在關聯(lián)關系，為了解決上述問題，我們在類的基礎上再劃分，當某個類的大小超過一定值時，系統(tǒng)會自動擴展出一個新類，擴展的類在物理存儲中按照一個普通子類來處理。類的擴展可以使用戶控制的，因此用戶可以根據(jù)數(shù)據(jù)本身的特點獲得最佳的性能。

下圖為對海量數(shù)據(jù)實現(xiàn)數(shù)據(jù)切分和存儲的方案示意圖：

2.3 并行處理

并行計算的實現(xiàn)實際就是查詢的分發(fā)過程與結(jié)果的匯總。本文對并行處理的過程分為以下幾個步驟：

首先，系統(tǒng)將用戶對數(shù)據(jù)的每次操作都精確到每個子類，系統(tǒng)可以得到該子類對應的物理數(shù)據(jù)庫，對該子類的所有操作都會是直接操作該數(shù)據(jù)庫。

其次，數(shù)據(jù)抽象模塊會收集所有數(shù)據(jù)格式，包括子類間的關系，因此當用戶對兩個類進行連接查詢時，系統(tǒng)會細化到最小的子類來完成。

最后，引入MapReduce[6]技術(shù)實現(xiàn)查詢結(jié)果的匯總。通過使用Map函數(shù)將大量數(shù)據(jù)劃分為多個組，然后通過在不同主機上并行處理這些組，通過Reduce函數(shù)將不同主機的結(jié)果進行匯總，形成統(tǒng)一結(jié)果。

3 總結(jié)

本論文通過對大數(shù)據(jù)的基本特征的分析，指明關系數(shù)據(jù)庫難以實現(xiàn)大數(shù)據(jù)的存儲和使用NoSQL處理大數(shù)據(jù)的技術(shù)難點后，提出一種支持繼承關系的關系樹模型，該模型可以提高關系模型的擴展性，并引入多態(tài)機制，滿足非結(jié)構(gòu)化數(shù)據(jù)的存儲要求。

參考文獻：

[1] 王珊，王會舉，覃雄派，等.架構(gòu)大數(shù)據(jù)：挑戰(zhàn)、現(xiàn)狀與展望[J].計算機學報，2011，34（10）：1741-1752.

[2] 孟小峰，慈祥.大數(shù)據(jù)管理：概念、技術(shù)與挑戰(zhàn)[J].計算機研究與發(fā)展，2013，50（1）：146-169

[3] 姚林，張永庫.NoSQL的分布式存儲與擴展解決方法[J].計算機工程，2012，38（6）：40-42.

[4] 李馮筱，羅高松. NoSQL 理論體系及應用[J].電信科學，2013，28（12）：23-30.

[5] 李艷，季新生，項君.基于UIMA 的知識發(fā)現(xiàn)框架研究及實現(xiàn)[J].計算機工程，2010，36（21）：277-279.

[6] Afrati F N， Ullman J D. Optimizing joins in a map-reduce environment[C]. Proc. Thirteenth Intl. Conf. on Extending Database Technology，2010.