淺談NoSQL數(shù)據(jù)庫的數(shù)據(jù)存儲

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

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

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

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

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

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

2.1以Hbase為代表的列存儲類型

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

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

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

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

2.2以Neo4J為代表的圖存儲類型

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

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

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

2.3以Redis存儲為代表的鍵值存儲類型

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

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

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

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

2.4其他類型

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

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

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

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