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

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

中圖分類號(hào)：TP311.13

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.2 聚合法（Aggregate）

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

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

3.3 實(shí)體化路徑法（Materialized Paths）

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

因?yàn)閷?shí)體化路徑法把一個(gè)樹形結(jié)構(gòu)轉(zhuǎn)成了一個(gè)路徑文檔，這對(duì)于全文搜索引擎來講是一種非常有效有技術(shù)。例如，每種商品都有一個(gè)分類，分類中都包含了它的祖先結(jié)點(diǎn)的名稱。所以查詢時(shí)，可以用一條語句完成——只需給定一個(gè)分類名，比如查詢男式T恤，其分類名為{Category：Shirts}，如圖3所示。

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

4 結(jié)束語

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

參考文獻(xiàn)：

[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非關(guān)系型數(shù)據(jù)庫的發(fā)展及應(yīng)用初探[J].福建電腦，2010（07）：30-31.

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

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

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

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