大數據架構師NoSQL建模技術

從數據建模的角度對NoSQL家族系統作了比較簡單的比較，並簡要介紹幾種常見建模技術。

1.前言

爲了適應大數據應用場景的要求，Hadoop以及NoSQL等與傳統企業平臺徹底不一樣的新興架構迅速地崛起。而下層技術基礎的革命必將影響上層建築：數據模型和算法。簡單地將傳統基於第四範式結構化關係型數據庫的模型拷貝到新的引擎上，無異於削足適履，不只增長了大數據應用開發的難度和複雜度，又沒法發釋放新框架的潛能。

該如何構建基於NoSQL的數據模型？如今能供參考的公開知識積累要麼是空虛簡單的一句「去規範化「或粗暴的寬表化（將query和應用須要訪問的全部字段「排排坐「，放在一個有不少列的結構化表中），要麼是針對具體工具或具體場景的實現細節，（如《HBase權威指南》中對於如何設計HBase主鍵的探討）。沒有一個像編程的設計模式同樣的，在模型架構層面能夠遵循的方法論。

在比較不一樣的NoSQL數據庫時，一般使用功能之外其餘各類指標，如可擴展性、性能和一致性。因爲這些指標一般是使用NoSQL的初衷，因此不管從理論的角度仍是實踐的角度被深刻地研究了，而像CAP定理這樣的分佈式系統基礎結論也一樣適用於NoSQL系統。另外一方面，在NoSQL的數據模型領域，卻尚未很好地研究過，也缺少關係數據庫中那種系統性的理論。

我在這篇文章中從數據建模的角度對NoSQL家族系統作了比較簡單的比較，並簡要介紹幾種常見建模技術。

2.NoSQL數據模型視圖

要探索數據建模技術，必須先從系統性的NoSQL數據模型視圖着手，這多多少少能幫助咱們揭示其發展趨勢以及相互之間的關係。下圖描繪了主要NoSQL家族系統的虛擬「進化」過程，即鍵值存儲，BigTable類型的數據庫，文檔數據庫，全文搜索引擎，數據庫和圖形數據庫：

首先，咱們應該注意到，通常意義上講，SQL和關係型模型都是在好久之前就被設計出來，目的是爲最終用戶交互之用。這種面向用戶的性質有極深的影響：

最終用戶每每對彙總報表信息感興趣而不是單獨的數據項，於是SQL這方面作了大量的工做。

不能期望做爲天然人的用戶能顯式地控制併發性、完整性、一致性或者數據類型有效性。這就是爲何SQL竭力關注於事務保證、schema和參照完整性。

另外一方面，軟件應用程序每每對在數據庫內部作聚合沒有太大的興趣，並且至少在許多狀況下，程序可以本身控制完整性和有效性。除此以外，剔除這些功能對於性能和可擴展性存儲的影響極其重要。

新數據模型的演變開始了：

鍵-值存儲是一個很是簡單，但很是強大的模型。下面所描述的許多技術都徹底適用於這個模型。

鍵值模型最致命的缺點之一就是不適合按範圍處理主鍵的場景。有序的鍵-值模型突破了這一限制，並顯著提升了聚合能力。

有序的鍵-值模型很是強大，但它不提供任何針對值（value）的建模框架。在通常狀況下，值的建模能夠由應用程序完成，但BigTable風格的數據庫想得更加周到，它能夠將值按照映射的映射的映射（map-of-maps-of-maps）進行建模，說得明確點，分別是列簇（column family）、列（column）和時間戳化的版本。

文檔數據庫對BigTable模式提出兩個明顯的改善。第一，值能夠被聲明爲任意複雜的schema，而不只僅是一個映射的映射（map-of-maps）。第二，至少有一些產品實現了被數據庫管理的索引。就這個意義上來說，全文搜索引擎也能夠一樣被認爲提供了靈活的schema和自動化的索引。他們之間主要區別在於，文檔數據庫是根據字段名對索引進行編組，而搜索引擎是使用字段值對索引編組。值得注意的是像Oracle Coherence這樣的鍵-值存儲系統增長了索引和內嵌入口處理器的功能，正逐步向文件數據庫演進。

最後，圖形數據模型能夠被視爲有序的鍵-值模型朝另一個方向的進化。圖形數據庫容許對業務實體進行很是透明的建模（這個東西取決於那個東西），而分層建模技術在這方面用的是另外的數據模型，但也可與之媲美。圖形數據庫和文件數據庫息息相關，由於許多實現容許建模的值是映射或者文檔。

3.NoSQL數據建模的通常注意事項

與關係型建模不一樣，NoSQL數據建模每每是從特定查詢的應用開始：

關係型建模是典型地被手上可用數據的結構所驅動。設計主要圍繞着的是「我有什麼樣的答案？」

NoSQL數據建模一般由特定應用的訪問模式所驅動，好比須要支持的查詢類型。設計主要圍繞着的是「我有什麼問題？」

NoSQL數據建模每每比關係數據庫建模須要更加深刻地瞭解數據結構和算法。在這篇文章中，我介紹了幾個著名的數據結構，他們雖然非NoSQL所特有，但對於實際的NoSQL建模很是有用。

數據複製和去規範化是一等公民。

關係數據庫在對分層或圖形數據進行建模和處理時不是很方便。圖形數據庫顯然是這個領域的完美解決方案，但實際上大多數的NoSQL也都很是善於解決這樣的問題。這就是爲何這篇文章爲分層數據建模單獨寫了一個章節。

雖然數據建模技術基本上和具體實現無關，但我仍是列出了在寫這篇文章時我能想到的產品：

鍵值存儲：Oracle Coherence，Redis，Kyoto Cabinet

BigTable風格的數據庫： Apache HBase，Apache Cassandra

文檔數據庫： MongoDB，CouchDB

全文搜索引擎： Apache Lucene，Apache Solr

圖形數據庫：Neo4j，FlockDB

4.概念技術

本節專門介紹NoSQL數據建模的基本原則。

一、去規範化（Denormalization）

能夠將去規範化定義爲把相同的數據複製到多個文檔或數據表中，這樣能夠簡化/優化查詢處理，或者讓用戶數據能匹配一個特定的數據模型。在本文的大多數技術用到了這樣或那樣的去規範化。

通常來講，去規範化用於如下的折衷：

查詢的數據量或每次查詢IO**與總數據量的折衷。去規範化能夠將一個查詢所需的全部數據組合起來存放到同一個地方。這一般意味着對相同數據的不一樣的查詢會訪問不一樣的數據組合。所以，數據須要被複制多份，也就意味着增長了總數據量。

處理複雜性與總數據量的折衷。建模時的規範化和相應查詢的鏈接（join）明顯增長了查詢處理器的複雜度，在分佈式系統中尤其明顯。去規範化容許將數據按照查詢友好的方式存儲，從而簡化查詢的處理。

適用性：鍵值存儲，文檔數據庫， BigTable風格的數據庫

二、聚合（Aggregates）

全部主流NoSQL都提供了這樣或那樣的鬆散schema（soft schema）支持：

鍵值存儲和圖形數據庫一般不對值進行約束，因此值多是任意格式。另外，也能夠經過使用組合鍵將一個業務實體表示爲多條記錄。例如，能夠將一個用戶賬戶建模爲UserID_name，UserID_email，UserID_messages等組合鍵表示的一個實體集合。若是用戶沒有電子郵件或消息，而後相應的實體不會被記錄。

BigTable模式也支持鬆散schema，由於一個列簇是可變的列集合，一個單元格又能存儲不定數目的數據版本。

文檔數據庫天生就沒schema，雖然某些文檔數據庫容許在數據輸入時使用用戶定義的schema進行驗證。

鬆散schema容許使用複雜的內部結構（嵌套實體）構造實體的類，也容許改變特定實體的結構。這個更能帶來了兩個重要的便利：

經過嵌套的實體，最小化了一對多的關係，也所以減小了鏈接（join）。

異構業務實體的模型可使用一個文檔集合或者一個數據表。鬆散schema掩藏了這種建模和業務實體之間「技術」上的差別。

咱們用下面的圖來講明這些便利。該圖描繪了對電子商務領域中一個產品實體進行的建模。首先咱們能夠認爲全部的產品都有一個ID、價格（Price）和描述（Description）。進一步來看，咱們發現不一樣類型的產品有不一樣的屬性，如圖書包含做者信息，而牛仔褲有長度屬性。這些屬性中間的某些屬性天生就有一對多或這多對多的特性，好比音樂唱片中的曲目。

更進一步來看，可能有些實體不可能使用固定的類型進行建模。例如，不一樣品牌的牛仔褲的屬性是不固定的，而每一個製造商出產的牛仔褲的屬性也是不一致的。在規範化的關係型數據模型中雖然這些問題均可以解決，但方法很猥瑣。鬆散schema軟架構容許只使用一個聚合（Aggregation）（產品）就能對全部類型的產品及其屬性進行建模：

內嵌的去規範化會在性能和一致性上對更新操做形成很大的影響，因此要特別注意更新過程。

適用性：鍵值存儲，文檔數據庫， BigTable的風格數據庫

三、應用端鏈接（Application Side Joins）

不多有NoSQL解決方案支持鏈接。NoSQL「問題導向」性質的後果就是，一般在設計時處理join，而關係型模型是在執行查詢時處理join。查詢時處理join幾乎確定會帶來性能上的損失，但在許多狀況下，可以使用去規範化和聚合，即嵌入嵌套實體來避免join。固然，join在許多狀況下是不可避免的，並且應該由應用程序處理。主要的用例：

多對多關係每每是經過連接（link）建模的，這須要join。

聚合操做每每不適合內部實體會被頻繁修改的場景。一般更好的辦法是將發生的事情做爲一條新的記錄保留，並在查詢的時候將全部記錄作join，而不是去更改值。例如，對於一個信息系統而言，能夠用嵌套包含了Message實體的User實體來建模。可是，若是會常常地添加消息，更好的辦法多是把Message提取出來做爲獨立實體，並在查詢時再將其與User進行鏈接：

適用性：鍵值存儲，文檔數據庫， BigTable風格數據庫，圖形數據庫

5.通常建模技術

在本節中，咱們將討論適用於各類NoSQL實現的通常建模技術。

一、原子聚合（Atomic Aggregates）

許多NoSQL解決方案提供了有限的事務支持，雖然有些NoSQL不支持。在某些狀況下，人們還可使用分佈式鎖或應用程序管理的MVCC機制實現事務行爲，但常見的是使用聚合技術來對數據建模，以保證一些ACID特性。

強大的事務處理機制對於關係型數據庫而言是不可或缺的，其中緣由之一就是規範化的數據一般須要在多個地方進行更新。另外一方面，聚合容許一個單個業務實體存儲爲一個文件，行或鍵值對，從而能夠對其進行原子性的更新：

固然，作爲一種數據建模技術，原子聚合並非一個完善的事務型解決方案，但若是存儲能提供原子性、鎖或者TAS（test-and-set，測試並設置）指令上的一些擔保，那原子聚合就是可行的。

(譯者注：即將須要事務性操做的業務數據聚合放在一塊兒，存儲在一個NoQSQL提供或者應用能提供原子性操做的數據結構中。使用HBase時，將某個用戶某個業務的全部數據，如上圖，用一行存儲就是這種模式的應用。)

適用性：鍵值存儲，文檔數據庫， BigTable風格數據庫

二、可枚舉主鍵（Enumerable Keys）

也許無序鍵-值數據模型最大的好處就是能夠經過將主鍵哈希的辦法把實體數據分別存儲在多個服務器上。排序使事情變得更加複雜，可是即便存儲不提供這樣的功能，有時應用程序也能利用到有序主鍵的優點。讓咱們將對電子郵件建模做爲一個例子：

某些NoSQL存儲提供原子計數器，能生成一個順序化的ID。在這種狀況下，可使用userID_messageID做爲一個複合鍵來存儲消息。若是最新的消息ID是已知的，那就能夠遍歷之前的消息。另外，對於任何一個給定的消息ID，也能夠向前或向後進行遍歷。

也能夠將消息分桶（bucket），例如，天天的數據放到一個桶裏。這樣就容許從任何指定日期或當前日期開始，向前或向後遍歷一個郵箱。

適用性：鍵值存儲

(譯者注：能利用主鍵的一些天然或業務維度的特徵，將隨機讀寫轉換爲順序讀寫能提升遍歷性能，同時能方便應用邏輯編寫。但須要注意對分佈式部署時併發寫的影響以及對於業務的過分耦合。對於無序主鍵和有序主鍵的討論能夠參見《HBase權威指南》中Schema設計章節。)

三、降維（Dimensionality Reduction）

降維這種技術容許將一個多維數據模型映射到一個鍵-值模型或其餘非多維模型。

傳統的地理信息系統使用四叉樹（Quadtree）或R樹（R-tree）的某種變形來作索引。這些結構須要就地完成更新操做，所以在數據量很大時，維護開銷至關的大。另外一種方法是對這個二維結構進行遍歷，並將其扁平化爲一個普通的條目列表。使用這種技術的一個衆所周知的例子是Geohash。 Geohash使用相似Z形狀的路線來掃描整個二維空間，每次移動根據行進方向被編碼爲0或1。交錯位的經度和緯度上的變動移動以及移動。編碼過程在下圖中進行了說明，其中黑色和紅色位分別表明經度和緯度：

如圖所示，Geohash的一個重要特性是可以經過這種逐位編碼的近似程度來估計區域之間的距離。Geohash編碼容許使用簡單普通的數據模型來存儲地理信息，好比用有序鍵值保存空間上的聯繫。[6.1]講述了BigTable中的降維技術。更多有關Geohash及其相關技術的信息能夠在[6.2]和[6.3]中找到。

適用性：鍵值存儲，文檔數據庫， BigTable風格的數據庫

(譯者注：經過交織編碼方式來能將本來須要多維度標示的數據，如cube，存儲到一維的鍵值存儲系統中，這是一種很是重要的建模模式：提供了不一樣縮放等級下在多維空間中鄰接的數據仍然順序存儲，遍歷高效；同時不一樣主鍵從前向後的類似度和空間距離的遠近相一致，能經過鍵值的簡單順序比較判斷其位置「類似度」。

它的應用遠遠不僅地理信息的表示，有多個維度屬性不一樣粒度的數據表示都能用到這個技術，好比線下銷售交易數據一般都有時間和分支結構信息，用戶查詢銷售數據時一般先查詢一個大的區域，並且使用的時間段跨度也比較大，須要查詢更具體的信息時同時縮小地區和時間來逐步定位細節，這時分支機構和時間就比如是經度維度的兩個軸，經過交織時間和分支結構編碼的方式創建主鍵，能很好的知足這種場景。而單純的使用時間或分支機構作主鍵或索引卻都不能適應上述場景。)

四、索引表（Index Table）

索引表是一個很是簡單的技術，它在內部不支持索引的存儲上提供索引的支持。這類存儲中最重要的一類就是BigTable風格的數據庫。索引表的想法是按照訪問模式所須要的鍵來建立和維護一個特殊的表。例如，有一個主表，存儲了能夠經過用戶ID直接訪問的用戶賬戶。查詢指定城市的全部用戶能夠經過一個額外的用城市作主鍵的表來支持：

索引表能夠在每個主表記錄更新時更新或者使用批模式更新。不管哪一種方式，它會致使額外的性能損失，並帶來數據一致性上的問題。

能夠認爲索引表是一種對關係數據庫實例化視圖的模擬。

適用性： BigTable風格的數據庫

五、組合主鍵索引（Composite Key Index）

複合主鍵是一個很是通用的技術，但尤爲在主鍵有序存儲時極其有用。複合主鍵結合二次排序就能創建起一種多維索引，這和前面所述的降維技術在原理上是相似的。例如，假設咱們有一組記錄，每一個記錄是一個用戶統計數據。若是咱們要按用戶來自的地區來聚合這些統計資料，咱們可使用這樣的主鍵格式（State:City:UserId）。若是主鍵的存儲支持經過部分匹配來選取範圍（如BigTable風格的數據庫），那就能夠在特定的州（State）或者城市（City）的記錄上作遍歷：

適用性： BigTable風格的數據庫

(譯者注：在使用HBase這類BigTable風格的數據庫時，若是主鍵只使用一個字段/域的信息簡直是暴殄天物。使用多字段組合主鍵不只能解決主鍵值不能重複的問題，還能提升對於數據子集二次查找時的性能。）

六、組合主鍵的聚合

複合主鍵不只可用於做索引，還能夠爲不一樣類型分組。讓咱們來看一個例子。有一個巨大的日誌數組，記錄了互聯網用戶和他們訪問不一樣的網站（點擊流）的信息。咱們的目標是對於每一個惟一用戶計算出每一個站點的點擊數量。這相似於下面的SQL查詢：

咱們可使用將用戶名當前綴的組合主鍵來對這種狀況進行建模：

咱們的想法是將一個用戶的全部記錄放置在一塊兒，這樣就可能將其所有加載到內存中（一個用戶不會產生太多的事件），並使用哈希表或其餘方法消除掉重複的網站。另外一種技術是將用戶作爲主鍵，每次事件到達時將網站添加到這條數據的後部。然而，在大多數實現中，修改數據通常比插入數據的效率低。

適用性：有序鍵值存儲，BigTable風格的數據庫

七、倒排搜索-直接聚合

這種技術更像是數據處理模式，而不是數據建模。然而，數據模型也受這種模式使用的影響。這種技術的主要思想是使用索引來找到知足條件的數據，但聚合操做仍是使用原來的方式或者全表掃描。讓咱們來考慮一個例子。有一堆的日誌數據記錄了互聯網用戶和他們訪問不一樣的網站（點擊流，click stream）的信息。假設每條記錄都包括用戶ID、用戶所屬類別（男性、女性、博主（Blogger）等）、用戶來自的城市以及訪問的網址。咱們的目標是找出知足條件（網址、城市等）的觀衆，並將這堆觀衆（如符合標準的用戶集合）中出現的不一樣用戶按類別歸類。

很明顯，知足條件的用戶能夠經過像{類別->[用戶ID]}或{網站->[用戶ID]}這樣的倒排索引表很是高效地查找到。使用這樣的倒排索引，能夠獲得所要的用戶ID的交集或者並集（若是用戶ID被存儲爲排有序的列表或位圖，這就能夠很是高效地實現），從而得到目標用戶。但若是目標用戶是使用相似這樣的彙集查詢描述的：

那若是類別的數量很大，就不能用倒排索引作有效的處理。要解決這個問題，能夠用{用戶名->[分類集合]}的形式建立直接索引（Direct Index），而後遍歷它來創建最終報表。此架構示意以下圖：

最後須要提示的是，咱們須要知道若是隨機地訪問目標用戶中每個用戶ID所對應記錄，這樣作的效率可能很低。能夠經過利用批量查詢處理解決這個問題。這意味着，一些數量的用戶集能夠被預先計算（針對不一樣的報表條件），而後能夠經過對直接索引表或倒排索引表進行一次全表掃描從而計算出這批目標用戶的全部報告。

適用性：鍵值存儲，BigTable風格的數據庫，文檔數據庫

分層建模技術（Hierarchy Modeling Techniques）

(譯者注：若是須要經過屬性或者類別來快速查找對應的實體，這樣的索引比不可少。如今很火的用大數據分析用戶畫像不就須要像{用戶標籤->用戶羣}這樣的結構麼。）

八、樹聚合（Tree Aggregation）

能夠將一條單獨的記錄或者文件的模型建成樹，甚至是任意的圖（經過去規範化）。

在樹會被一次性訪問的場景中（例如，博客的整個評論樹會被讀取，並顯示在一篇文章的頁面中），這個技術很高效。

搜索和訪問任意條目可能有問題。

在大多數NoSQL的實現中，更新操做的效率低下（同相互獨立的節點相比）。

適用性：鍵值存儲，文檔數據庫

(譯者注：這是文檔型NoSQL的天下，對於無需跨樹join的場景，不只讀寫效率高，並且能很好的支持局部性的事務應用。）

九、鄰接列表（Adjacency Lists）

鄰接列表是一個簡單的圖型建模方法——每一個節點做爲一個單獨記錄建模，其中有包含直接祖先的數組或包含後代的數組。它容許經過其父母或子女的標識符來搜索一個節點，固然也能夠經過查詢一次前進一步的方式來遍歷一個圖。不管對於深度優先或廣度優先遍歷而言，要在整個子樹中找到一個給定的節點，這種方法的效率一般不高。

適用性：鍵值存儲，文檔數據庫

十、物化路徑

物化路徑是一種有助於避免在樹型結構上作遞歸遍歷的技術。也能夠認爲這是一種去規範化的技術。其設計思想是用一個節點全部的父節點或者子女節點來標識該節點，這樣就有能夠不用遍歷而獲得一個節點的全部祖先節點或者衍生節點：

由於這個技術能夠將層次結構轉換成扁平化的文檔，因此它對於全文搜索引擎特別地有用。從上圖中能夠看出，在男鞋（Men’s Shoes）類別下全部的產品或者子類別能夠簡單的經過查詢一個類別名稱而獲得。這個查詢很短。

物化路徑的存儲方式能夠是一個ID的集合，或者一個是包含級聯ID的字符串。後一種方式容許使用正則表達式，來查找那些指定部分的路徑符合某種條件的節點。此種方法如在下圖（路徑也包括了節點自身）所示：

適用性：鍵值存儲，文檔數據庫，搜索引擎

十一、嵌套集合（Nested Sets）

在對相似樹型結構進行建模時，嵌套集合是個標準的作法。它在關係數據庫中普遍被使用，然而它也徹底適用於鍵值存儲和文檔數據庫。其設計思想是在用數組來存儲樹的葉子節點（譯者：每一個葉子節點對應數組中的一個位置下標），並將每一個非葉結點映射爲一個葉子節點的範圍，這個範圍就是開始葉子節點和結束葉子節點在數組中的位置下標。以下圖所示：

這個結構對於不變數據來說很是有效，由於它佔用的內存小，而且能夠在不遍歷樹的狀況下獲得一個給定節點的全部葉子節點。然而，由於增長一個葉子節點會帶來位置下標的大量更新，因此插入和更新的操做代價是至關的高。

適用性：鍵值存儲，文檔數據庫

(譯者注：適用於字典表、按日期排序的歷史日誌數據表等。）

十二、扁平化嵌套文件：字段名稱編號

搜索引擎一般工做在扁平化的文檔之上，即每一個文檔由兩個扁平列表組成，這兩個列表分別記錄了字段的名稱和它對應的值。數據建模的目標是將業務實體映射爲簡單無結構的文檔，但若是實體內部的結構很複雜，這就難辦了。一個典型的困難就是層次結構模型，好比要將內部嵌套了文檔的文檔映射爲簡單無結構的文檔。讓咱們來考慮下面的例子：

這種方法實際上沒有可擴展性，由於隨着嵌套結構的數目的增加會迅速增長查詢的複雜度。

適用性：搜索引擎

(譯者注：若是你對於使用索引來加速查詢機關用盡，尤爲對用戶未來如何查詢數據一無所知，沒法在設計模型時進行優化時，這就是最後的稻草：使用全文搜索工具。它至少能在可接受的時間內能查出點東西來^o^。）

1三、扁平化嵌套文件：近似查詢

在[4.6]中還描述了另外一種能夠解決嵌套文件問題的技術。它的想法是使用近似的查詢，將文檔中單詞之間的距離限制在能夠接受的距離範圍之內。在下面的圖中，全部的技能和水平都被索引到了一個叫SkillAndLevel的域。使用「Excellent」和「Poetry」進行查詢表示的話，就會查找到這兩個單詞鄰接的條目：

[4.3]講述了在Solr之上使用這種技術的一個成功案例。

適用性：搜索引擎

(譯者注：同上，但查詢召回率高，會出現假匹配，有髒數據。）

1四、批量圖處理

在瀏覽一個指定節點的相鄰節點或瀏覽兩個或幾個節點之間的關係時，像Neo4j這樣的圖形數據庫的性能出奇的好。然而，通用圖形數據庫對大圖作全局性處理不是很高效，由於擴展性很差。分佈式圖形處理可使用MapReduce或者消息傳遞（Message Passing）模式來實現。我之前的一篇文章就介紹了一種這樣的模式。這種方法使用了鍵值存儲、文檔數據庫和BigTable風格的數據庫，能處理大型的圖形。

適用性：鍵值存儲，文檔數據庫，BigTable風格的數據庫

做者介紹：陳飈，Cloudera售前技術經理、行業領域顧問、資深方案架構師，原Intel Hadoop發行版核心開發人員。2006年加入Intel編譯器部門從事服務器中間件軟件開發，擅長服務器軟件調試與優化，曾帶領團隊開發出世界上性能領先的 XSLT 語言處理器。2010 年後開始Hadoop 產品開發及方案顧問，前後負責Hadoop 產品化、HBase 性能調優，以及行業解決方案顧問，已在交通、通訊等行業成功實施並支持多個上百節點Hadoop 集羣。