NoSQL 數據建模技術(2)

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

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

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

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

　　(2) 聚合 Aggregates

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

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

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

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

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

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

　　可以讓內部技術上的數據存儲更接近于業務實體，特別是那種混合式的業務實體?？赡艽嬗谝粋€文檔集或是一張表中。

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

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

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

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

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

　　Entity Aggregation

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

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

　　(3) 應用層聯結 Application Side Joins

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

　　多對多的數據實體關系——經常需要被連接或聯結。

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

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

　　通用建模技術 General Modeling Techniques

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

　　(4) 原子聚合 Atomic Aggregates

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

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

原文轉自：http://www.anti-gravitydesign.com