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

尹妍 朱立偉

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

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

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

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

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

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

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

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

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

顯而易見，在需要讀取同一列數(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ù)結構中，圖形結構也是四種基本邏輯結構之一。在關系型數(shù)據(jù)庫時代，人們就試圖將圖投入到數(shù)據(jù)庫中使用，卻面臨著設計笨拙、性能低下的困境。而基于NoSQL理念，以Neo4J為代表的圖形數(shù)據(jù)庫打破了這一限制，解決了長久以來的問題。

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

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

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

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

在鍵值存儲類型中，每個數(shù)據(jù)值（Value）都對應一個關鍵字，即Key，用于索引和查找。在操作過程中只能通過鍵來查詢，不能使用值來查詢。每個數(shù)據(jù)也是相對獨立的，兩個鍵之間沒有關聯(liá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ī)模的約束;以db4o為代表的對象存儲類型，其語法類似c++等面向?qū)ο笳Z言，通過對象來保存數(shù)據(jù);以ElasticSearch為代表的全文搜索引擎，主要針對傳統(tǒng)關系型數(shù)據(jù)全文搜索功能低下而產(chǎn)生的優(yōu)化數(shù)據(jù)庫，等等[2]。

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

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

目前為止，市場上共有二十多種NoSQL數(shù)據(jù)庫，盡管都是非關系型數(shù)據(jù)庫，但是彼此有各自的優(yōu)勢所在，需要使用者了解其不同特性，根據(jù)具體的需求靈活使用。可以說，NoSQL數(shù)據(jù)庫的出現(xiàn)是數(shù)據(jù)庫技術發(fā)展的必然趨勢，需要人們發(fā)揮自身的才智對其進行不斷完善。

參考文獻

[1] 劉玉程，李港.NoSQL數(shù)據(jù)庫與關系型數(shù)據(jù)庫對比[J].中國新通信，2018，20（07）：81.

[2] 雷宇輝，鐘雯，何清，等.Nosql數(shù)據(jù)庫研究文獻綜述[J].電子世界，2017，（04）：11-12.