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

要開始討論數(shù)據(jù)建模技術，我們不得不或多或少地先系統(tǒng)地看一下NoSQL數(shù)據(jù)模型的成長的趨勢，以此我們可以了解一些他們內在的聯(lián)系。下圖是NoSQL家族的進化圖，我們可以看到這樣的進化：Key-Value時代，BigTable時代，Document時代，全文搜索時代，和Graph數(shù)據(jù)庫時代：（陳皓注：注意圖中SQL說的那句話，NoSQL再這樣發(fā)展下去就是SQL了，哈哈。）

NoSQL Data Models#p#

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

• 最終用戶一般更感興趣于數(shù)據(jù)的聚合顯示，而不是分離的數(shù)據(jù)，這主要通過SQL來完成。
• 我們無法通過人手工控制數(shù)據(jù)的并發(fā)性，完整性，一致性，或是數(shù)據(jù)類型校驗這些東西的。這就是為什么SQL需要在事務，二維表結構（schema）和外表聯(lián)合上做很多事。

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

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

• Ordered Key-Value 有序鍵值模型也非常強大，但是，其也沒有對Value提供某種數(shù)據(jù)模型。通常來說，Value的模型可以由應用負責解析和存取。這種很不方便，于是出現(xiàn)了 BigTable類型的數(shù)據(jù)庫，這個數(shù)據(jù)模型其實就是map里有map，map里再套map，一層一層套下去，也就是層層嵌套的key-value（value里又是一個key-value），這種數(shù)據(jù)庫的Value主要通過“列族”（column families），列，和時間戳來控制版本。（陳皓注：關于時間戳來對數(shù)據(jù)的版本控制主要是解決數(shù)據(jù)存儲并發(fā)問題，也就是所謂的樂觀鎖，詳見《多版本并發(fā)控制(MVCC)在分布式系統(tǒ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ù)庫允許構建議圖結構的數(shù)據(jù)模型。它和文檔數(shù)據(jù)庫有關系的原因是，它的很多實現(xiàn)允許value可以是一個map或是一個document。#p#

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

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

• NoSQL 數(shù)據(jù)模型設計一般從業(yè)務應用的具體數(shù)據(jù)查詢入手，而不是數(shù)據(jù)間的關系：
  • 關系型的數(shù)據(jù)模型基本上是分析數(shù)據(jù)間的結構和關系。其設計理念是： ”What answers do I have?”
  • NoSQL 數(shù)據(jù)模型基本上是從應用對數(shù)據(jù)的存取方式入手，如：我需要支持某種數(shù)據(jù)查詢。其設計理念是 ”What questions do I have?”

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

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

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

概念技術 Conceptual Techniques

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

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

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

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

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

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

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

(2) 聚合 Aggregates

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

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

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

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

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

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

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

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

(3) 應用層聯(lián)結 Application Side Joins

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

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

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

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

通用建模技術 General Modeling Techniques

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

(4) 原子聚合 Atomic Aggregates

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

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

Atomic Aggregates

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

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

(5) 可枚舉鍵 Enumerable Keys

也許，對于無順序的Key-Value***的好處是業(yè)務實體可以被容易地hash以分區(qū)在多個服務器上。而排序了的key會把事情搞復雜，但是有些時候，一個應用能從排序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ù)庫。#p#

(6) 降維 Dimensionality Reduction

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

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

Geohash Index

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

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

(7) 索引表 Index Table

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

Index Table Example

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

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

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

(8) 鍵組合索引 Composite Key Index

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

Composite Key Index

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

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

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

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

Counting Unique Users using Composite Keys

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

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

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

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

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

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

Counting Unique Users using Inverse and Direct Indexes

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

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

層級式模型 Hierarchy Modeling Techniques

(11) 樹形聚合Tree Aggregation

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

• 當樹形結構被一次性取出時這會非常有效率（如：我們需要展示一個blog的樹形評論）
• 搜索和任何存取這個實體都會存在問題。
• 對于大多數(shù)NoSQL的實現(xiàn)來說，更新數(shù)據(jù)都是很不經(jīng)濟的（相比起獨立結點來說）

Tree Aggregation

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

(12) 鄰接列表 Adjacency Lists

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

適用性: Key-Value 鍵值對數(shù)據(jù)庫, Document Databases 文檔數(shù)據(jù)庫#p#

(13) Materialized Paths

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

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

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

Query Materialized Paths using RegExp

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

(14) 嵌套集 Nested Sets

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

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

適用性: Key-Value Stores 鍵值數(shù)據(jù)庫, Document Databases 文檔數(shù)據(jù)庫#p#

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

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

Nested Documents Problem

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

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

Nested Document Modeling using Numbered Field Names

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

適用性: Search Engines 全文搜索#p#

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

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

Nested Document Modeling using Proximity Queries

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

適用性: Search Engines 全文搜索

(17) 圖結構批處理 Batch Graph Processing

Graph databases 圖數(shù)據(jù)庫，如 neo4j 是一個出眾的圖數(shù)據(jù)庫，尤其是使用一個結點來探索鄰居結點，或是探索兩個或少量結點前的關系。但是處理大量的圖數(shù)據(jù)是很沒有效率的，因為圖數(shù)據(jù)庫的性能和擴展性并不是其目的。分布式的圖數(shù)據(jù)處理可以被 MapReduce 和 Message Passing pattern 來處理。如： 在我前一篇的文章中的那個示例。這個方法可以讓 Key-Value stores, Document databases, 和 BigTable-style databases 適合于處理大圖。

Applicability: Key-Value Stores, Document Databases, BigTable-style Databases