基于文檔數(shù)據(jù)庫的NoSQL建模方法

摘 要：電子商務、大型社交網站的出現(xiàn)對數(shù)據(jù)存儲、查詢和管理帶來了新的挑戰(zhàn)，也引起了非結構化的面向信息的數(shù)據(jù)爆炸，海量數(shù)據(jù)的存儲對信息的查詢和管理提出了更高的要求。而傳統(tǒng)的關系數(shù)據(jù)技術在應對超大規(guī)模和高并發(fā)的數(shù)據(jù)處理方面已經顯得力不從心，NoSQL作為一種針對大規(guī)模數(shù)據(jù)應用的新型數(shù)據(jù)庫技術，越來越受到重視。本文以NoSQL數(shù)據(jù)模型的基礎，介紹文檔型數(shù)據(jù)庫建模的方法。

關鍵詞：NoSQL；文檔數(shù)據(jù)庫；建模

中圖分類號：TP311.13

隨著電子商務和大型社交網站等新型應用的興起，對數(shù)據(jù)庫管理技術提出了新的挑戰(zhàn)。海量數(shù)據(jù)存儲、高并發(fā)數(shù)據(jù)訪問、高效的信息查詢，以及高擴展性和高可用性應用的需求，使傳統(tǒng)的關系數(shù)據(jù)庫管理系統(tǒng)（RDBMS）已無法滿足，并暴露出很多難以克服的問題。例如，大型的社交網站FriendFeed，平均每個月產生2.5億條用戶動態(tài)信息，如果用RDBMS來處理，在一張2.5億條記錄的中表中進行SQL訪問，可以想象其低下的效率。NoSQL的出現(xiàn)打破了關系型數(shù)據(jù)結構和ACID理論統(tǒng)治數(shù)據(jù)管理系統(tǒng)的局面，數(shù)據(jù)不按固定的表結構存取，也沒有表之間的連接操作，于是越來越多的研究人員和應用人員將目光轉移到NoSQL技術上來了。

NoSQL（Not Only SQL）即數(shù)據(jù)管理“不僅僅是SQL”。NoSQL數(shù)據(jù)庫指數(shù)據(jù)模型定義不固定的非關系型數(shù)據(jù)庫，典型的NoSQL數(shù)據(jù)庫以鍵值（Key-Value）對存儲，NoSQL打破了在RDBMS中已成為標準的ACID（Atomicity、Consistency、Isolation、Durability），從而減少了一些存儲時間和空間的開銷，保證了海量數(shù)據(jù)訪問的高效性。Apache的MongoDB是用C#開發(fā)的NoSQL系統(tǒng)，據(jù)官方提供的性能測試，當數(shù)據(jù)量達到50GB以上時，MongoDB的數(shù)據(jù)庫訪問速度超過MySQL數(shù)據(jù)庫10倍。

NoSQL與RDMS相比，具有操作簡單、開源等優(yōu)點，如Facebook的Cassandra，Apache的HBase，并可以用于各種商業(yè)目的，如Google的BigTable與Amazon的Dynamo。由于這些公司使用了NoSQL，大大降低了它們的運營成本。

1 NoSQL數(shù)據(jù)模型

NoSQL數(shù)據(jù)庫主要三種主流的數(shù)據(jù)模型，即鍵值（Key-Value）、文檔（Document）和列式（Column-oriented）。典型的NoSQL數(shù)據(jù)庫產品如Google的BigTable、基于Hadoop HDFS的HBase、Amazon的Dynamo、Apache的Cassandra、TokyoCabinet、CouchDB、MongoDB和Redis等。

鍵值（Key-Value）這種模型和傳統(tǒng)的關系型相比更簡單，一個Key對應一個Value，類似于哈希表（HashTable），具有非?？斓牟樵兯俣?、高并發(fā)數(shù)、海量數(shù)據(jù)存儲等特點，常用于通過主鍵對數(shù)據(jù)進行查詢和修改的操作。

文檔（Document）這種模型也是一個Key對應一個Value，與鍵值模型很相似，但是它的Value能轉換成以JSON或XML等結構的文檔，是具有語義的；文檔數(shù)據(jù)模型還可以對Value創(chuàng)建輔助索引（Secondary Index），方便應用層查詢，這是普通鍵值模型的數(shù)據(jù)庫所不能做到的。

列式（Column-oriented）主要使用表（Table）這樣的模型，與關系型數(shù)據(jù)庫不同，它不支持Join這樣的多表操作。在存儲時，不像關系型數(shù)據(jù)庫按Row進行儲存，而是圍繞Column來儲存數(shù)據(jù)，即盡可能把同一Column的數(shù)據(jù)存放在硬盤的同一個頁（Page）中，它的優(yōu)勢是適合聚合（Aggregation）和數(shù)據(jù)倉庫這類應用。

2 文檔模型數(shù)據(jù)庫的特點

文檔模型數(shù)據(jù)庫簡稱文檔數(shù)據(jù)庫，文檔數(shù)據(jù)庫與傳統(tǒng)數(shù)據(jù)庫的區(qū)別于它是用來管理文檔的，傳統(tǒng)數(shù)據(jù)把信息分割成離散的數(shù)據(jù)項或字段，而文檔數(shù)據(jù)是把文檔作為處理信息的基本單位，文檔的特點是無結構、數(shù)據(jù)復雜、長度無限。

文檔（Document）模型可以看成是以Key-Document方式的存儲，它具有兩個特點：（1）Value值支持多種結構的定義，其Value值主要是以JSON或者XML這類結構化文檔存儲的；（2）支持數(shù)據(jù)庫索引的定義，按照字段名來組織索引，省去了在應用層中使用大量代碼將查詢轉換為SQL的時間。若是按字段值來組織索引，就是全文搜索引擎（Full Text Search Engines）所采用的模型。MongoDB、CouchDB等都是基于文檔數(shù)據(jù)模型的NoSQL系統(tǒng)。

3 文檔數(shù)據(jù)庫建模方法

作為數(shù)據(jù)庫開發(fā)者總是希望能夠靈活地隨意組織文檔存儲結構，但是這種隨意性文檔結構會導致應用層的查詢變得非常復雜。因此，文檔數(shù)據(jù)庫的建模在數(shù)據(jù)庫邏輯設計階段顯得尤其重要。下面列舉幾種不同于RDBMS的數(shù)據(jù)建模方法來介紹基于NoSQL的文檔數(shù)據(jù)庫如何建模。

3.1 反規(guī)范化法（Denormalization）

在RDBMS中設計數(shù)據(jù)庫遵循規(guī)范化（Normalization），對應的數(shù)據(jù)屬于干凈整齊、非冗余型，而反規(guī)范化（Denormalization）則允許數(shù)據(jù)冗余或者同樣的數(shù)據(jù)存儲于不同的多個位置。

反規(guī)范化法是NoSQL文檔數(shù)據(jù)庫建模中經常用到的方法，為了簡化和提高查詢效率，把相同的數(shù)據(jù)拷貝到不同的文檔或是表中，也就是把RDBMS中的實體（Entity）和與實體之間的關系，存儲到NoSQL的同一個表格中。

例如在RDBMS的規(guī)范化數(shù)據(jù)建模中，有兩個表格：Student（StudentID，StudentName，Tutor，CourseID），Course（CourseID，CourseName），有時需要讀取這兩個表的信息，然后用視圖（View）連接在一起獲得學生選課的詳細信息，如圖1的規(guī)范化法；而在NoSQL文檔數(shù)據(jù)庫系統(tǒng)中，只建一個表Student（StudentID，StudentName，Tutor，CourseID，CourseName），包含了學生基本信息和所有選課的相關信息，這樣查詢時只需要讀取一次，就可以獲取所需的信息了?？傊匆?guī)范化法以最簡便快速的查詢方式來構建數(shù)據(jù)結構，因此它是一種以降低查詢的復雜度為目的數(shù)據(jù)建模方法。

3.2 聚合法（Aggregate）

把一組相互關聯(lián)的對象視為一個整體單元來操作，而這個單元就叫聚合。在涉及數(shù)據(jù)操作與一致性管理時，更是如此。一般情況下，我們通過原子操作（atomic operation）更新聚合的值，并且在與數(shù)據(jù)存儲通信時也以聚合為單位。這個技術非常符合文檔數(shù)據(jù)庫的工作方式，因為用聚合為單位來復制和分片顯得比較自然。

以一個電子商務網站的商品模型為例，每種商品Product都會有一個ID，Price和Description，不同類型的商品有不同的屬性。如，顏色是衣服的屬性，作者是書的屬性。屬性還分多值屬性、復合屬性和派生屬性。多值屬性是一對多或多對多的情形，如顏色有紅、綠、黃；復合屬性，如發(fā)貨地址address有{“state”：state，“city”：city，“street”：street }；派生屬性，如同校是運動服的商品，有些名牌會有非常特別的屬性，這些屬性并不是所有牌子的運動服都有的。對于RDBMS來講，按照屬性來設計這樣的數(shù)據(jù)模型并不簡單，而NoSQL文檔數(shù)據(jù)庫允許使用一個聚合，便可以構建出所有不同種類的商品和它們的不同屬性。如圖2所示。

3.3 實體化路徑法（Materialized Paths）

實體化路徑法原來是用來解決在SQL中樹形結構的建模方法。針對樹形結構的模型，實現(xiàn)高效的數(shù)據(jù)存儲，它避免了在樹形結構中遞歸遍歷帶來的巨大成本。這個技術也可以被認為是反規(guī)范化的另一種技術。實體化路徑法是為每個結點附加其父結點或子結點標識的屬性，沿著結點的這種標識屬性就可形成了一條具體的路徑，在數(shù)據(jù)查詢時，不需要遍歷每個結點，按照路徑就能找到其所查詢的信息。

因為實體化路徑法把一個樹形結構轉成了一個路徑文檔，這對于全文搜索引擎來講是一種非常有效有技術。例如，每種商品都有一個分類，分類中都包含了它的祖先結點的名稱。所以查詢時，可以用一條語句完成——只需給定一個分類名，比如查詢男式T恤，其分類名為{Category：Shirts}，如圖3所示。

如果把每個結點定義一個ID，這個ID由該結點到根結點的若干個ID組成的一個字符串，這個字符串就是每個結點到根結點的路徑，那么就可以通過一個正則表達式來搜索一個特定的分支路徑了。以圖3的商品為例，服裝類商品的實體化路徑見表1。

4 結束語

文檔模型數(shù)據(jù)庫采用松散的數(shù)據(jù)組織形式是一種常見的NoSQL數(shù)據(jù)庫存儲模式。本文通過NoSQL數(shù)據(jù)庫邏輯結構，根據(jù)不同于關系數(shù)據(jù)庫的規(guī)范化設計思想，以及文檔存儲模型自身的特點，提出了反規(guī)范化、聚合和實體化路徑三種數(shù)據(jù)建模的方法。在數(shù)據(jù)時代，信息量越來越龐大，對信息的檢索提出了更高的要求，基于文檔數(shù)據(jù)庫技術的應用將越來越廣泛。然而數(shù)據(jù)建模還應該考慮很多綜合的問題，如查詢的數(shù)據(jù)量、數(shù)據(jù)的I/O、處理的復雜度、數(shù)據(jù)的總量與冗余度等等，NoSQL技術的高效性和高擴展性在文檔檢索、海量數(shù)據(jù)存儲方面有優(yōu)異的表現(xiàn)，在此領域的研究、開發(fā)和應用一定會受到更多的重視。

參考文獻：

[1]CAP theorem[Z].http：//en.wikipedia.org/wiki/ CAP_theorem，2011.

[2]Fay Chang，Jeffrey Dean and etc..Bigtable：A Distributed Storage System for Structured Data[R]，2006.

[3]NOSQL Databases[Z].http：//nosql-database.org/，2011.

[4]NoSQL DEFINITION.http：//nosql-database.org/.

[5]Ilya Katsov.http：//highlyscalable.wordpress.com/2012/03/01/nosql-data-modeling-techniques/.

[6]Amy Brown，Greg Wilson.The Architecture of Open Source Applications.Lulu.com，2011.

[7]黃賢立.NoSQL非關系型數(shù)據(jù)庫的發(fā)展及應用初探[J].福建電腦，2010（07）：30-31.

[8]范凱.NoSql數(shù)據(jù)庫綜述[J].程序員，2010（06）：76-78.

[9]沈姝.NoSQL數(shù)據(jù)庫技術及其應用研究[D].南京：南京信息工程大學，2012.

作者簡介：別祖杰（1965-），男，重慶人，碩士，副教授，研究方向：數(shù)據(jù)挖掘技術。

作者單位：重慶科技學院 信息化處，重慶 400042