小編給大家分享一下NOSQL數(shù)據(jù)建模技術(shù)有什么用，相信大部分人都還不怎么了解，因此分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后大有收獲，下面讓我們一起去了解一下吧！

創(chuàng)新互聯(lián)建站-專業(yè)網(wǎng)站定制、快速模板網(wǎng)站建設(shè)、高性價比永城網(wǎng)站開發(fā)、企業(yè)建站全套包干低至880元,成熟完善的模板庫,直接使用。一站式永城網(wǎng)站制作公司更省心,省錢,快速模板網(wǎng)站建設(shè)找我們，業(yè)務(wù)覆蓋永城地區(qū)。費用合理售后完善，十余年實體公司更值得信賴。

NoSQL數(shù)據(jù)建模技術(shù)

NoSql數(shù)據(jù)庫經(jīng)常被用作很多非功能性的地方，如，擴展性，性能和一致性的地方。這些NoSQL的特性在理論和實踐中都正在被大眾廣泛地研究著，研究的熱點正是那些和性能分布式相關(guān)的非功能性的東西，我們都知道CAP 理論被很好地應(yīng)用于了NoSQL系統(tǒng)中（陳皓注：CAP即，一致性(Consistency)，可用性(Availability)，分區(qū)容忍性(Partition
tolerance)，在分布式系統(tǒng)中，這三個要素最多只能同時實現(xiàn)兩個，而NoSQL一般放棄的是一致性）。但在另一方面，NoSQL的數(shù)據(jù)建模技術(shù)卻因為缺乏像關(guān)系型數(shù)據(jù)庫那樣的基礎(chǔ)理論沒有被世人很好地研究。這篇文章從數(shù)據(jù)建模方面對NoSQL家族進行了比較，并討論幾個常見的數(shù)據(jù)建模技術(shù)。

要開始討論數(shù)據(jù)建模技術(shù)，我們不得不或多或少地先系統(tǒng)地看一下NoSQL數(shù)據(jù)模型的成長的趨勢，以此我們可以了一些他們內(nèi)在的聯(lián)系。下圖是NoSQL家族的進化圖，我們可以看到這樣的進化：Key-Value時代，BigTable時代，Document時代，全文搜索時代，和Graph數(shù)據(jù)庫時代：

NoSQL Data Models

首先，我們需要注意的是SQL和關(guān)系型數(shù)據(jù)模型已存在了很長的時間，這種面向用戶的自然性意味著：

• 最終用戶一般更感興趣于數(shù)據(jù)的聚合顯示，而不是分離的數(shù)據(jù)，這主要通過SQL來完成。

• 我們無法通過人手工控制數(shù)據(jù)的并發(fā)性，完整性，一致性，或是數(shù)據(jù)類型校驗這些東西的。這就是為什么SQL需要在事務(wù)，二維表結(jié)構(gòu)（schema）和外表聯(lián)合上做很多事。

另一方面，SQL可以讓軟件應(yīng)用程序在很多情況下不需要關(guān)心數(shù)據(jù)庫的數(shù)據(jù)聚合，和數(shù)據(jù)完整性和有效性進行控制。而如果我們?nèi)コ藬?shù)據(jù)一致性，完整性這些東西，會對性能和分布存儲有著重的幫助。正因為如此，我們才有數(shù)據(jù)模型的進化：

• Key-Value鍵值對存儲是非常簡單而強大的。下面的很多技術(shù)基本上都是基于這個技術(shù)開始發(fā)展的。但是，Key-Value有一個非常致命的問題，那就是如果我們需要查找一段范圍內(nèi)的key。（陳皓注：學(xué)過hash-table數(shù)據(jù)結(jié)構(gòu)的人都應(yīng)該知道，hash-table是非序列容器，其并不像數(shù)組，鏈接，隊列這些有序容器，我們可以控制數(shù)據(jù)存儲的順序）。于是，有序鍵值（Ordered Key-Value）數(shù)據(jù)模型被設(shè)計出來解決這一限制，來從根本上提高數(shù)據(jù)集的問題。

• Ordered Key-Value有序鍵值模型也非常強大，但是，其也沒有對Value提供某種數(shù)據(jù)模型。通常來說，Value的模型可以由應(yīng)用負責(zé)解析和存取。這種很不方便，于是出現(xiàn)了BigTable類型的數(shù)據(jù)庫，這個數(shù)據(jù)模型其實就是map里有map，map里再套map，一層一層套下去，也就是層層嵌套的key- value（value里又是一個key-value），這種數(shù)據(jù)庫的Value主要通過“列族”（column families），列，和時間截來控制版本。（陳皓注：關(guān)于時間截來對數(shù)據(jù)的版本控制主要是解決數(shù)據(jù)存儲并發(fā)問題，也就是所謂的樂觀鎖，詳見《多版本并發(fā)控制(MVCC)在分布式系統(tǒng)中的應(yīng)用》）

• Document databases 文檔數(shù)據(jù)庫 改進了BigTable模型，并提供了兩個有意義的改善。第一個是允許Value中有主觀的模式（scheme），而不是map套map。第二個是索引。Full Text Search Engines全文搜索引擎可以被看作是文檔數(shù)據(jù)庫的一個變種，他們可以提供靈活的可變的數(shù)據(jù)模式（scheme）以及自動索引。他們之間的不同點主要是，文檔數(shù)據(jù)庫用字段名做索引，而全文搜索引擎用字段值做索引。

• Graph data models圖式數(shù)據(jù)庫 可以被認為是這個進化過程中從Ordered Key-Value數(shù)據(jù)庫發(fā)展過來的一個分支。圖式數(shù)據(jù)庫允許構(gòu)建議圖結(jié)構(gòu)的數(shù)據(jù)模型。它和文檔數(shù)據(jù)庫有關(guān)系的原因是，它的很多實現(xiàn)允許value可以是一個map或是一個document。

NoSQL數(shù)據(jù)模型摘要

本文剩下的章節(jié)將向你介紹數(shù)據(jù)建模的技術(shù)實現(xiàn)和相關(guān)模式。但是，在介紹這些技術(shù)之前，先來一段序言：

• NoSQL數(shù)據(jù)模型設(shè)計一般從業(yè)務(wù)應(yīng)用的具體數(shù)據(jù)查詢?nèi)胧?，而不是?shù)據(jù)間的關(guān)系：

• 關(guān)系型的數(shù)據(jù)模型基本上是分析數(shù)據(jù)間的結(jié)構(gòu)和關(guān)系。其設(shè)計理念是： “What answers do I have?”

• NoSQL數(shù)據(jù)模型基本上是從應(yīng)用對數(shù)據(jù)的存取方式入手，如：我需要支持某種數(shù)據(jù)查詢。其設(shè)計理念是 ”What questions do I have?”

• NoSQL數(shù)據(jù)模型設(shè)計比關(guān)系型數(shù)據(jù)庫需要對數(shù)據(jù)結(jié)構(gòu)和算法的更深的了解。在這篇文章中我會和大家說那些盡人皆知的數(shù)據(jù)結(jié)構(gòu)，這些數(shù)據(jù)結(jié)構(gòu)并不只是被NoSQL使用，但是對于NoSQL的數(shù)據(jù)模型卻非常有幫助。

• 數(shù)據(jù)冗余和反規(guī)格化是一等公民。

• 關(guān)系型數(shù)據(jù)庫對于處理層級數(shù)據(jù)和圖式數(shù)據(jù)非常的不方便。NoSQL用來解決圖式數(shù)據(jù)明顯是一個非常好的解決方案，幾乎所有的NoSQL數(shù)據(jù)庫可以很強地解決此類問題。這就是為什么這篇文章專門拿出一章來說明層級數(shù)據(jù)模型。

下面是NoSQL的分類表，也是我用來寫這篇文章時做實踐的產(chǎn)品：

• Key-Value 存儲: Oracle Coherence, redis, Kyoto Cabinet

• 類BigTable存儲: Apache HBase, Apache Cassandra

• 文檔數(shù)據(jù)庫: MongoDB, CouchDB

• 全文索引: Apache Lucene, Apache Solr

• 圖數(shù)據(jù)庫: neo4j, FlockDB

概念技術(shù)Conceptual Techniques

這一節(jié)主要介紹NoSQL數(shù)據(jù)模型的基本原則。

(1)反規(guī)格化Denormalization

反規(guī)格化Denormalization可以被認為是把相同的數(shù)據(jù)拷貝到不同的文檔或是表中，這樣就可以簡化和優(yōu)化查詢，或是正好適合用戶的某中特別的數(shù)據(jù)模型。這篇文章中所說的絕大多數(shù)技術(shù)都或多或少地導(dǎo)向了這一技術(shù)。

總體來說，反規(guī)格化需要權(quán)衡下面這些東西：

• 查詢數(shù)據(jù)量 /查詢IO VS 總數(shù)據(jù)量。使用反規(guī)格化，一方面可以把一條查詢語句所需要的所有數(shù)據(jù)組合起來放到一個地方存儲。這意味著，其它不同不同查詢所需要的相同的數(shù)據(jù)，需要放在別不同的地方。因此，這產(chǎn)生了很多冗余的數(shù)據(jù)，從而導(dǎo)致了數(shù)據(jù)量的增大。

• 處理復(fù)雜度 VS 總數(shù)據(jù)量. 在符合范式的數(shù)據(jù)模式上進行表連接的查詢，很顯然會增加了查詢處理的復(fù)雜度，尤其對于分布式系統(tǒng)來說更是。反規(guī)格化的數(shù)據(jù)模型允許我們以方便查詢的方式來存構(gòu)造數(shù)據(jù)結(jié)構(gòu)以簡化查詢復(fù)雜度。

適用性：Key-Value Store 鍵值對數(shù)據(jù)庫，Document Databases文檔數(shù)據(jù)庫，BigTable風(fēng)格的數(shù)據(jù)庫。

(2)聚合Aggregates

所有類型的NoSQL數(shù)據(jù)庫都會提供靈活的Schema（數(shù)據(jù)結(jié)構(gòu)，對數(shù)據(jù)格式的限制）：

• Key-Value Stores 和 Graph Databases基本上來說不會Value的形式，所以Value可以是任意格式。這樣一來，這使得我們可以任意組合一個業(yè)務(wù)實體的keys。比如，我們有一個用戶帳號的業(yè)務(wù)實體，其可以被如下這些key組合起來： UserID_name，UserID_email, UserID_messages等等。如果一個用戶沒有email或message，那么相應(yīng)也不會有這樣的記錄。

• BigTable模型通過列集合來支持靈活的Schema，我們稱之為列族（column family）。BigTable還可以在同一記錄上出現(xiàn)不同的版本（通過時間截）。

• Document databases文檔數(shù)據(jù)庫是一種層級式的“去Schema”的存儲，雖然有些這樣的數(shù)據(jù)庫允許檢驗需要保存的數(shù)據(jù)是否滿足某種Schema。

靈活的Schema允許你可以用一種嵌套式的內(nèi)部數(shù)據(jù)方式來存儲一組有關(guān)聯(lián)的業(yè)務(wù)實體（陳皓注：類似于JSON這樣的數(shù)據(jù)封裝格式）。這樣可以為我們帶來兩個好處。

• 最小化“一對多”關(guān)系——可以通過嵌套式的方式來存儲實體，這樣可以少一些表聯(lián)結(jié)。

• 可以讓內(nèi)部技術(shù)上的數(shù)據(jù)存儲更接近于業(yè)務(wù)實體，特別是那種混合式的業(yè)務(wù)實體。可能存于一個文檔集或是一張表中。

下圖示意了這兩種好處。圖中描給了電子商務(wù)中的商品模型（陳皓注：我記得我在“挑戰(zhàn)無處不在”一文中說到過電商中產(chǎn)品分類數(shù)據(jù)庫設(shè)計的挑戰(zhàn)）

• 首先，所有的商品Product都會有一個ID，Price和Description。

• 然后，我們可以知道不同的類型的商品會有不同的屬性。比如，作者是書的屬性，長度是牛仔褲的屬性。其些屬性可能是“一對多”或是“多對多”的關(guān)系，如：唱片中的曲目。

• 接下來，我們知道，某些業(yè)務(wù)實體不可能使用固定的類型。如：牛仔褲的屬性并不是所有的牌子都有的，而且，有些名牌還會搞非常特別的屬性。

對于關(guān)系型數(shù)據(jù)庫來說，要設(shè)計這樣的數(shù)據(jù)模型并不簡單，而且設(shè)計出來的絕對離優(yōu)雅很遠很遠。而我們NoSQL中靈活的Schema允許你使用一個聚合Aggregate (product) 可以建出所有不同種類的商品和他們的不同的屬性：

Entity Aggregation

上圖中我們可以比較關(guān)系型數(shù)據(jù)庫和NoSQL的差別。但是我們可以看到在數(shù)據(jù)更新上，非規(guī)格化的數(shù)據(jù)存儲在性能和一致性上會有很大的影響，這就是我們需要重點注意和不得不犧牲的地方。

適用性: Key-Value Store鍵值對數(shù)據(jù)庫，Document Databases文檔數(shù)據(jù)庫，BigTable風(fēng)格的數(shù)據(jù)庫。

(3)應(yīng)用層聯(lián)結(jié)Application Side Joins

表聯(lián)結(jié)基本上不被NoSQL支持。正如我們前面所說的，NoSQL是“面向問題”而不是“面向答案”的，不支持表聯(lián)結(jié)就是“面向問題”的后果。表的聯(lián)結(jié)是在設(shè)計時被構(gòu)造出來的，而不是在執(zhí)行時建造出來的。所以，表聯(lián)結(jié)在運行時是有很大開銷的（陳皓注：搞過SQL表聯(lián)結(jié)的都知道笛卡爾積是什么東西，大可以在參看以前酷殼的“圖解數(shù)據(jù)庫表Joins”），但是在使用了Denormalization和Aggregates技術(shù)后，我們基本不用進行表聯(lián)結(jié)，如：你們使用嵌套式的數(shù)據(jù)實體。當(dāng)然，如果你需要聯(lián)結(jié)數(shù)據(jù)，你需要在應(yīng)用層完成這個事。下面是幾個主要的Use
Case：

• 多對多的數(shù)據(jù)實體關(guān)系——經(jīng)常需要被連接或聯(lián)結(jié)。

• 聚合Aggregates并不適用于數(shù)據(jù)字段經(jīng)常被改變的情況。對此，我們需要把那些經(jīng)常被改變的字段分到另外的表中，而在查詢時我們需要聯(lián)結(jié)數(shù)據(jù)。例如，我們有個Message系統(tǒng)可以有一個User實體，其包括了一個內(nèi)嵌的Message實體。但是，如果用戶不斷在附加message，那么，最好把message拆分到另一個獨立的實體，但在查詢時聯(lián)結(jié)這User和Message這兩個實體。如下圖：

適用性: Key-Value Store鍵值對數(shù)據(jù)庫，Document Databases文檔數(shù)據(jù)庫，BigTable風(fēng)格的數(shù)據(jù)庫，Graph Databases圖數(shù)據(jù)庫。

通用建模技術(shù)General Modeling Techniques

在本書中，我們將討論NoSQL中各種不同的通用的數(shù)據(jù)建模技術(shù)。

(4)原子聚合Atomic Aggregates

很多NoSQL的數(shù)據(jù)庫（并不是所有）在事務(wù)處理上都是短板。在某些情況下，他們可以通過分布式鎖技術(shù)或是應(yīng)用層管理的MVCC技術(shù)來實現(xiàn)其事務(wù)性（陳皓注：可參看本站的“多版本并發(fā)控制(MVCC)在分布式系統(tǒng)中的應(yīng)用”）但是，通常來說只能使用聚合Aggregates技術(shù)來保證一些ACID原則。

這就是為什么我們的關(guān)系型數(shù)據(jù)庫需要有強大的事務(wù)處理機制——因為關(guān)系型數(shù)據(jù)庫的數(shù)據(jù)是被規(guī)格化存放在了不同的地方。所以，Aggregates聚合允許我們把一個業(yè)務(wù)實體存成一個文檔、存成一行，存成一個key-value，這樣就可以原子式的更新了：

Atomic Aggregates

當(dāng)然，原子聚合Atomic Aggregates這種數(shù)據(jù)模型并不能實現(xiàn)完全意義上的事務(wù)處理，但是如果支持原子性，鎖，或test-and-set指令，那么，Atomic Aggregates是可以適用的。

適用性: Key-Value Store鍵值對數(shù)據(jù)庫，Document Databases文檔數(shù)據(jù)庫，BigTable風(fēng)格的數(shù)據(jù)庫。

(5)可枚舉鍵Enumerable Keys

也許，對于無順序的Key-Value最大的好處是業(yè)務(wù)實體可以被容易地hash以分區(qū)在多個服務(wù)器上。而排序了的key會把事情搞復(fù)雜，但是有些時候，一個應(yīng)用能從排序key中獲得很多好處，就算是數(shù)據(jù)庫本身不提供這個功能。讓我們來思考下email消息的數(shù)據(jù)模型：

1. 一些NoSQL的數(shù)據(jù)庫提供原子計數(shù)器以允許生一些連續(xù)的ID。在這種情況下，我們可以使用 userID_messageID 來做為一個組合key。如果我們知道最新的message ID，就可以知道前一個message，也可能知道再前面和后面的Message。

2. Messages可以被打包。比如，每天的郵件包。這樣，我們就可以對郵件按指定的時間段來遍歷。

適用性: Key-Value Store鍵值對數(shù)據(jù)庫。

(6)降維Dimensionality Reduction

Dimensionality Reduction降維是一種技術(shù)可以允許把一個多維的數(shù)據(jù)映射成一個Key-Value或是其它非多給的數(shù)據(jù)模型。

傳統(tǒng)的地理位置信息系統(tǒng)使用一些如“四分樹QuadTree”或“R-Tree”來做地理位置索引。這些數(shù)據(jù)結(jié)構(gòu)的內(nèi)容需要被在適當(dāng)?shù)奈恢酶拢⑶?，如果?shù)據(jù)量很大的話，操作成本會很高。另一個方法是我們可以遍歷一個二維的數(shù)據(jù)結(jié)構(gòu)并把其扁平化成一個列表。一個眾所周知的例子是Geohash（地理哈希）。一個Geohash使用“之字形”的路線掃描一個2維的空間，而且遍歷中的移動可以被簡單地用0和1來表示其方向，然后在移動的過程中產(chǎn)生0/1串。下圖展示了這一算法：（陳皓注：先把地圖分成四份，經(jīng)度為第一位，緯度為第二位，于是左邊的經(jīng)度是0，右邊的是1，緯度也一樣，上面是為1，下面的為0，這樣，經(jīng)緯度就可以組合成01，11，00，10這四個值，其標(biāo)識了四塊區(qū)域，我們可以如此不斷的遞歸地對每個區(qū)域進行四分，然后可以得到一串1和0組成的字串，然后使用0-9，b-z去掉（去掉a,
i, l, o）這32個字母進行base32編碼得到一個8個長度的編碼，這就是Geohash的算法）

Geohash Index

Geohash的最強大的功能是使用簡單的位操作就可以知道兩個區(qū)域間的距離，就像圖中所示（陳皓：proximity框著的那兩個，這個很像IP地址了）。Geohash把一個二維的坐標(biāo)生生地變成了一個一維的數(shù)據(jù)模型，這就是降維技術(shù)。BigTable的降維技術(shù)參看到文章后面的[6.1]。更多的關(guān)于Geohash和其它技術(shù)可以參看[6.2] 和 [6.3]。

適用性: Key-Value Store鍵值對數(shù)據(jù)庫，Document Databases文檔數(shù)據(jù)庫，BigTable風(fēng)格的數(shù)據(jù)庫。

(7)索引表 Index Table

Index Table索引表是一個非常直白的技術(shù)，其可以你在不支持索引的數(shù)據(jù)庫中得到索引的好處。BigTable是這類最重要的數(shù)據(jù)庫。這需要我們維護一個有相應(yīng)存取模式的特別表。例如，我們有一個主表存著用戶帳號，其可以被UserID存取。某查詢需要查出某個城市里所有的用戶，于是我們可以加入一張表，這張表用城市做主鍵，所有和這個城市相關(guān)的UserID是其Value，如下所示：

Index Table Example

可見，城市索引表的需要和對主表用戶表保持一致性，因此，主表的每一個更新可能需要對索引表進行更新，不然就是一個批處理更新。無論哪個方式，這都會損傷一些性能，因為需要保持一致性。

Index Table索引表可以被認為是關(guān)系型數(shù)據(jù)庫中的視圖的等價物。

適用性：BigTable數(shù)據(jù)庫。

(8)鍵組合索引 Composite Key Index

Composite key鍵組合是一個很常用的技術(shù)，對此，當(dāng)我們的數(shù)據(jù)庫支持鍵排序時能得到極大的好處。Composite key組合鍵的拼接成為第二排序字段可以讓你構(gòu)建出一種多維索引，這很像我們之前說過的 Dimensionality Reduction降維技術(shù)。例如，我們需要存取用戶統(tǒng)計。如果我們需要根據(jù)不同的地區(qū)來統(tǒng)計用戶的分布情況，我們可以把Key設(shè)計成這樣的格式 (State:City:UserID)，這樣一來，就使得我們可以通過State到City來按組遍歷用戶，特別是我們的NoSQL數(shù)據(jù)庫支持在key上按區(qū)查詢（如：BigTable類的系統(tǒng)）：

SELECT Values WHERE state="CA:*" SELECT Values WHERE city="CA:San Francisco*"

Composite Key Index

適用性: BigTable 數(shù)據(jù)庫。

(9)鍵組合聚合 Aggregation with Composite Keys

Composite keys鍵組合技術(shù)并不僅僅可以用來做索引，同樣可以用來區(qū)分不用的類型的數(shù)據(jù)以支持數(shù)據(jù)分組?？紤]一個例子，我們有一個海量的日志數(shù)組，這個日志記錄了互聯(lián)網(wǎng)上的用戶的訪問來源。我們需要計算從某一網(wǎng)站過來的獨立訪客的數(shù)量，在關(guān)系型數(shù)據(jù)庫中，我們可能需要下面這樣的SQL查詢語句：

SELECT count(distinct(user_id)) FROM clicks GROUP BY site

我們可以在NoSQL中建立如下的數(shù)據(jù)模型：

Counting Unique Users using Composite Keys

這樣，我們就可以把數(shù)據(jù)按UserID來排序，我們就可以很容易把同一個用戶的數(shù)據(jù)（一個用戶并不會產(chǎn)生太多的event）進行處理，去掉那些重復(fù)的站點（使用hash table或是別的什么）。另一個可選的技術(shù)是，我們可以對每一個用戶建立一個數(shù)據(jù)實體，然后把其站點來源追加到這個數(shù)據(jù)實體中，當(dāng)然，這樣一來，數(shù)據(jù)的更新在性能相比之下會有一定損失。

適用性: Ordered Key-Value Store 排序鍵值對數(shù)據(jù)庫， BigTable風(fēng)格的數(shù)據(jù)庫。

(10)反轉(zhuǎn)搜索 Inverted Search – 直接聚合 Direct Aggregation

這個技術(shù)更多的是數(shù)據(jù)處理技術(shù)，而不是數(shù)據(jù)建模技術(shù)。盡管如此，這個技術(shù)還是會影響數(shù)據(jù)模型。這個技術(shù)最主要的想法是使用一個索引來找到滿足某條件的數(shù)據(jù)，但是把數(shù)據(jù)聚合起需要使用全文搜索。還是讓我們來說一個示例。還是用上面那個例子，我們有很多的日志，其中包括互聯(lián)網(wǎng)用戶和他們的訪問來源。讓我們假定每條記錄都有一個UserID，還有用戶的種類 (Men，Women，Bloggers，等)，以及用戶所在的城市，和訪問過的站點。我們要干的事是，為每個用戶種類找到滿足某些條件（訪問源，所在城市，等）的的獨立用戶。

很明顯，我們需要搜索那些滿足條件的用戶，如果我們使用反轉(zhuǎn)搜索，這會讓我們把這事干得很容易，如： {Category -> [user IDs]} 或 {Site -> [user IDs]}。使用這樣的索引，我們可以取兩個或多個UserID要的交集或并集（這個事很容易干，而且可以干得很快，如果這些UserID是排好序的）。但是，我們要按用戶種類來生成報表會變得有點麻煩，因為我們用語句可能會像下面這樣

SELECT count(distinct(user_id)) ... GROUP BY category

但這樣的SQL很沒有效率，因為category數(shù)據(jù)太多了。為了應(yīng)對這個問題，我們可以建立一個直接索引 {UserID -> [Categories]}然后我們用它來生成報表：

Counting Unique Users using Inverse and Direct Indexes

最后，我們需要明白，對每個UserID的隨機查詢是很沒有效率的。我們可以通過批查詢處理來解決這個問題。這意味著，對于一些用戶集，我們可以進行預(yù)處理（不同的查詢條件）。

適用性: Key-Value Store鍵值對數(shù)據(jù)庫，Document Databases文檔數(shù)據(jù)庫，BigTable風(fēng)格的數(shù)據(jù)庫。

層級式模型Hierarchy Modeling Techniques

(11)樹形聚合Tree Aggregation

樹形或是任意的圖（需反規(guī)格化）可以被直接打成一條記錄或文檔存放。

• 當(dāng)樹形結(jié)構(gòu)被一次性取出時這會非常有效率（如：我們需要展示一個blog的樹形評論）

• 搜索和任何存取這個實體都會存在問題。

• 對于大多數(shù)NoSQL的實現(xiàn)來說，更新數(shù)據(jù)都是很不經(jīng)濟的（相比起獨立結(jié)點來說）

Tree Aggregation

適用性：Key-Value鍵值對數(shù)據(jù)庫，Document Databases文檔數(shù)據(jù)庫

(12)鄰接列表 Adjacency Lists

Adjacency Lists鄰接列表是一種圖–每一個結(jié)點都是一個獨立的記錄，其包含了所有的父結(jié)點或子結(jié)點。這樣，我們就可以通過給定的父或子結(jié)點來進行搜索。當(dāng)然，我們需要通過hop查詢遍歷圖。這個技術(shù)在廣度和深度查詢，以及得到某個結(jié)點的子樹上沒有效率。

適用性：Key-Value鍵值對數(shù)據(jù)庫，Document Databases文檔數(shù)據(jù)庫

(13) Materialized Paths

Materialized Paths可以幫助避免遞歸遍歷（如：樹形結(jié)構(gòu)）。這個技術(shù)也可以被認為是反規(guī)格化的一種變種。其想法是為每個結(jié)點加上父結(jié)點或子結(jié)點的標(biāo)識屬性，這樣就可以不需要遍歷就知道所有的后裔結(jié)點和祖先結(jié)點了：

Materialized Paths for eShop Category Hierarchy

這個技術(shù)對于全文搜索引擎來說非常有幫助，因為其可以允許把一個層級結(jié)構(gòu)轉(zhuǎn)成一個文檔。上面的示圖中我們可以看到所有的商品或Men’s Shoes下的子分類可以被一條很短的查詢語句處理——只需要給定個分類名。

Materialized Paths可以存儲一個ID的集合，或是一堆ID拼出的字符串。后者允許你通過一個正則表達式來搜索一個特定的分支路徑。下圖展示了這個技術(shù)（分支的路徑包括了結(jié)點本身）：

Query Materialized Paths using RegExp

適用性：Key-Value鍵值對數(shù)據(jù)庫，Document Databases文檔數(shù)據(jù)，Search Engines搜索引擎

(14)嵌套集 Nested Sets

Nested sets嵌套集是樹形結(jié)構(gòu)的標(biāo)準(zhǔn)技術(shù)。它被廣泛地用在了關(guān)系性數(shù)據(jù)庫中，它完全地適用于Key-Value鍵值對數(shù)據(jù)庫和Document Databases文檔數(shù)據(jù)庫。這個技術(shù)的想法是把葉子結(jié)點存儲成一個數(shù)組，并通過使用索引的開始和結(jié)束來映射每一個非葉子結(jié)點到一個葉子結(jié)點集，就如下圖所示一樣：

Modeling of eCommerce Catalog using Nested Sets

這樣的數(shù)據(jù)結(jié)構(gòu)對于immutable data不變的數(shù)據(jù)有非常不錯的效率，因為其點內(nèi)存空間小，并且可以很快地找出所有的葉子結(jié)點而不需要樹的遍歷。盡管如此，在插入和更新上需要很高的性能成本，因為新的葉子結(jié)點需要大規(guī)模地更新索引。

適用性：Key-Value Stores鍵值數(shù)據(jù)庫，Document Databases文檔數(shù)據(jù)庫

(15)嵌套文檔扁平化：有限的字段名Nested Documents Flattening：Numbered Field Names

搜索引擎基本上來說和扁平文檔一同工作，如：每一個文檔是一個扁平的字段和值的例表。這種數(shù)據(jù)模型的用來把業(yè)務(wù)實體映射到一個文本文檔上，如果你的業(yè)務(wù)實體有很復(fù)雜的內(nèi)部結(jié)構(gòu)，這可能會變得很有挑戰(zhàn)。一個典型的挑戰(zhàn)是把一個有層級的文檔映映射出來。例如，文檔中嵌套另一個文檔。讓我們看看下面的示例：

Nested Documents Problem

上面的每一個業(yè)務(wù)實體代碼一種簡歷。其包括了人名和一個技能列表。我把這個層級文檔映射成一個文本文檔，一種方法是創(chuàng)建Skill和Level字段。這個模型可以通過技術(shù)或是等級來搜索一個人，而上圖標(biāo)注的那樣的組合查詢則會失敗。（陳皓注：因為分不清Excellent是否是Math還是Poetry上的）

在引用中的[4.6]給出了一種解決方案。其為每個字段都標(biāo)上數(shù)字 Skill_i 和 Level_i，這樣就可以分開搜索每一個對（下圖中使用了OR來遍歷查找所有可能的字段）:

Nested Document Modeling using Numbered Field Names

這樣的方式根本沒有擴展性，對于一些復(fù)雜的問題來說只會讓代碼復(fù)雜度和維護工作變大。

適用性：Search Engines全文搜索

(16)嵌套文檔扁平化：鄰近查詢 Nested Documents Flattening: Proximity Queries

在附錄[4.6]中給出了這個技術(shù)用來解決扁平層次文檔。它用鄰近的查詢來限制可被查詢的單詞的范圍。下圖中，所有的技能和等級被放在一個字段中，叫 SkillAndLevel，查詢中出現(xiàn)的“Excellent”和“Poetry”必需一個緊跟另一個：

Nested Document Modeling using Proximity Queries

附錄[4.3]中講述了這個技術(shù)被用在Solr中的一個成功案例。

適用性：Search Engines全文搜索

(17) 圖結(jié)構(gòu)批處理 Batch Graph Processing

Graph databases圖數(shù)據(jù)庫，如neo4j是一個出眾的圖數(shù)據(jù)庫，尤其是使用一個結(jié)點來探索鄰居結(jié)點，或是探索兩個或少量結(jié)點前的關(guān)系。但是處理大量的圖數(shù)據(jù)是很沒有效率的，因為圖數(shù)據(jù)庫的性能和擴展性并不是其目的。分布式的圖數(shù)據(jù)處理可以被MapReduce 和 Message Passing pattern來處理。

以上是“NoSQL數(shù)據(jù)建模技術(shù)有什么用”這篇文章的所有內(nèi)容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內(nèi)容對大家有所幫助，如果還想學(xué)習(xí)更多知識，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道！

標(biāo)題名稱：NoSQL數(shù)據(jù)建模技術(shù)有什么用
轉(zhuǎn)載來于：http://jinyejixie.com/article14/ijcgde.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站設(shè)計公司、定制網(wǎng)站、標(biāo)簽優(yōu)化、手機網(wǎng)站建設(shè)、App設(shè)計、網(wǎng)站策劃

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)