本文格式為Word版，下載可任意編輯——淺談NoSQL數(shù)據(jù)庫(kù)的數(shù)據(jù)存儲(chǔ)摘要本文通過(guò)對(duì)NoSQL數(shù)據(jù)庫(kù)的概念與特性進(jìn)行簡(jiǎn)要的闡述，分析其在數(shù)據(jù)存儲(chǔ)方面的優(yōu)勢(shì)與不足，并結(jié)合其發(fā)展歷程與目前的應(yīng)用狀況對(duì)這種新的數(shù)據(jù)庫(kù)形式進(jìn)行簡(jiǎn)要探討。

關(guān)鍵詞NoSQL數(shù)據(jù)庫(kù);數(shù)據(jù)存儲(chǔ);非關(guān)系型數(shù)據(jù)庫(kù)

1NoSQL數(shù)據(jù)庫(kù)的概念與特性

所謂NoSQL數(shù)據(jù)庫(kù)，即NotOnlySQL（不僅僅是SQL）的縮寫。傳統(tǒng)SQL數(shù)據(jù)庫(kù)為關(guān)系型的數(shù)據(jù)存儲(chǔ)，需要嚴(yán)格的數(shù)據(jù)模式。而NoSQL數(shù)據(jù)庫(kù)提倡非關(guān)系型的數(shù)據(jù)存儲(chǔ)，都沒(méi)有模式。NoSQL數(shù)據(jù)庫(kù)打破了曾經(jīng)占據(jù)主導(dǎo)地位的關(guān)系型數(shù)據(jù)庫(kù)壟斷，不需要事先設(shè)計(jì)表結(jié)構(gòu)便能夠輕易實(shí)現(xiàn)數(shù)據(jù)的非結(jié)構(gòu)存儲(chǔ)。

除了非關(guān)系型這一特點(diǎn)，NoSQL還具有分布式、API形式簡(jiǎn)單、適合大數(shù)據(jù)存儲(chǔ)、無(wú)架構(gòu)等其他特點(diǎn)。傳統(tǒng)關(guān)系型數(shù)據(jù)庫(kù)經(jīng)過(guò)多年發(fā)展，雖已健全成熟，但仍舊有受限于固有模式而無(wú)法優(yōu)化的缺陷。而NoSQL面對(duì)這些缺點(diǎn)，能夠表現(xiàn)出異常優(yōu)秀的性能——這也就是NoSQL自提出后就一直受到廣泛關(guān)注的原因[1]。

2NoSQL的數(shù)據(jù)存儲(chǔ)

2.1以Hbase為代表的列存儲(chǔ)類型

列存儲(chǔ)類型，顧名思義，是依照列來(lái)存儲(chǔ)數(shù)據(jù)的。與之相對(duì)的，傳統(tǒng)關(guān)系型數(shù)據(jù)庫(kù)大都使用行存儲(chǔ)方式。圖中顯示兩種數(shù)據(jù)存儲(chǔ)的模式。左為傳統(tǒng)型行存儲(chǔ)模式，右為列存儲(chǔ)模式。

存儲(chǔ)結(jié)果如下（上為行存儲(chǔ)模式，下為列存儲(chǔ)模式）。

顯而易見(jiàn)，在需要讀取同一列數(shù)據(jù)的場(chǎng)合下，列存儲(chǔ)類型能表現(xiàn)出十分優(yōu)異的性能。此外，列式數(shù)據(jù)庫(kù)的空間利用率要優(yōu)于行式數(shù)據(jù)庫(kù)，原因在于列式存儲(chǔ)更有利于進(jìn)行空間壓縮操作，十分適合稀疏數(shù)據(jù)的存儲(chǔ)。相較于小量數(shù)據(jù)，列式存儲(chǔ)更適合TB級(jí)及以上的大數(shù)據(jù)存儲(chǔ)。但它的數(shù)據(jù)由于分布較廣，并不適合大范圍查詢。

Hbase數(shù)據(jù)庫(kù)為列存儲(chǔ)類型數(shù)據(jù)庫(kù)的代表，除此以外還有Cassandra、Hypertable等。往往被使用在數(shù)據(jù)量較大且還會(huì)持續(xù)增長(zhǎng)的場(chǎng)合之中。

2.2以Neo4J為代表的圖存儲(chǔ)類型

圖是離散數(shù)學(xué)中的概念。在數(shù)據(jù)結(jié)構(gòu)中，圖形結(jié)構(gòu)也是四種基本規(guī)律結(jié)構(gòu)之一。在關(guān)系型數(shù)據(jù)庫(kù)時(shí)代，人們就試圖將圖投入到數(shù)據(jù)庫(kù)中使用，卻面臨著設(shè)計(jì)笨拙、性能低下的窘境。而基于NoSQL理念，以Neo4J為代表的圖形數(shù)據(jù)庫(kù)打破了這一限制，解決了長(zhǎng)久以來(lái)的問(wèn)題。

Neo4J中的圖沿用了數(shù)據(jù)結(jié)構(gòu)中的概念，保存了點(diǎn)和邊的基本概念。其中，點(diǎn)代表實(shí)體，邊代表實(shí)體之間的關(guān)系。所有的實(shí)體作為一個(gè)個(gè)點(diǎn)，散亂地分布在圖上，存在特定關(guān)系的實(shí)體之間用邊相連。其儲(chǔ)存方式實(shí)現(xiàn)類似鄰接表，每個(gè)節(jié)點(diǎn)通過(guò)指針指向相鄰節(jié)點(diǎn)，且有單獨(dú)的邊集和點(diǎn)集。這一模式有利于從任何一個(gè)節(jié)點(diǎn)出發(fā)都可以遍歷整個(gè)圖，查找速度十分快，且只要沿著關(guān)系邊集就可查找，時(shí)間繁雜度不受總數(shù)據(jù)量的影響。

需要注意的是，圖存儲(chǔ)結(jié)構(gòu)受到數(shù)據(jù)關(guān)系特點(diǎn)的影響，在那些關(guān)系繁雜且緊湊的數(shù)據(jù)中有著良好的性能，但對(duì)于普通的大數(shù)據(jù)則會(huì)有反效果。除了Neo4J外，常用的還有FlockDB、ArangoDB等數(shù)據(jù)庫(kù)。

2.3以Redis存儲(chǔ)為代表的鍵值存儲(chǔ)類型

鍵值存儲(chǔ)類型即Key-Value存儲(chǔ)類型。在這種模式下，所有的數(shù)據(jù)以鍵值對(duì)的形式存入數(shù)據(jù)庫(kù)中，并且以這種形式繼續(xù)支持后續(xù)的操作。

在鍵值存儲(chǔ)類型中，每個(gè)數(shù)據(jù)值（Value）都對(duì)應(yīng)一個(gè)關(guān)鍵字，即Key，用于索引和查找。在操作過(guò)程中只能通過(guò)鍵來(lái)查詢，不能使用值來(lái)查詢。每個(gè)數(shù)據(jù)也是相對(duì)獨(dú)立的，兩個(gè)鍵之間沒(méi)有關(guān)聯(lián)。

尋常，鍵值存儲(chǔ)類型只適用于那些關(guān)系簡(jiǎn)單的數(shù)據(jù)，適用面較狹窄。但是在其適用范圍內(nèi)，表現(xiàn)出極高的IO性能。

Redis、MemcacheDB、LevelDB是此類數(shù)據(jù)庫(kù)的代表，常用于用戶信息存儲(chǔ)方面。

2.4其他類型

除去上述三種類型，還有以MongoDB為代表的文檔存儲(chǔ)類型，其數(shù)據(jù)以.json和.xml格式的文檔存儲(chǔ)，可以任意存儲(chǔ)讀取數(shù)據(jù)而不受數(shù)據(jù)關(guān)系和規(guī)模的約束;以db4o為代表的對(duì)象存儲(chǔ)類型，其語(yǔ)法類似c++等面向?qū)ο笳Z(yǔ)言，通過(guò)對(duì)象來(lái)保存數(shù)據(jù);以ElasticSearch為代表的全文探尋引擎，主要針對(duì)傳統(tǒng)關(guān)系型數(shù)據(jù)全文探尋功能低下而產(chǎn)生的優(yōu)化數(shù)據(jù)庫(kù)，等等[2]。

3NoSQL數(shù)據(jù)庫(kù)存儲(chǔ)數(shù)據(jù)的發(fā)展進(jìn)程與現(xiàn)狀

最早發(fā)現(xiàn)關(guān)系型數(shù)據(jù)庫(kù)限制的是谷歌公司，為解決自身發(fā)展面臨的技術(shù)問(wèn)題，它最早開(kāi)發(fā)了GFS，順利戰(zhàn)勝了關(guān)系型數(shù)據(jù)庫(kù)技術(shù)的固有矛盾，后來(lái)為使得半結(jié)構(gòu)化數(shù)據(jù)能夠更加便捷地進(jìn)行存儲(chǔ)，谷歌公司又相繼開(kāi)發(fā)出BigTable、MapReduce等數(shù)據(jù)庫(kù)類型。國(guó)內(nèi)NoSQL數(shù)據(jù)庫(kù)的領(lǐng)軍者主要是騰訊公司及其他眾多的新型互聯(lián)網(wǎng)公司。

目前為止，市場(chǎng)上共有二十多種NoSQL數(shù)據(jù)