N哦SQL技術與傳統的關系數據庫相比，最明顯的轉變是拋棄了關系模型。NoSQL主要有四種模型：
- 健值 - 面向聚合
- 文檔 - 面向聚合
- 列族 - 面向聚合
- 圖 - ？
前三種都是面向聚合的
2.1 聚合
關系模型：元組（行）是受限的結構：只能包含一系列的值，不能嵌套另外的元組和列表。
所有操作都以元組為目標，而且其返回值必須是元組。
面向聚合：是NoSQL操作數據時所用的單元，其結構比元組復雜，這種結構可以存放列表或嵌套其他記錄。
聚合是“領域驅動設計（DDD）”中的術語: 把一組相互關聯的對象視為一個整體單元來操作，這個單元叫聚合。一般通過原子操作更新聚合的值，並且在與數據存儲通信時，也以聚合為單位。以聚合為單位來復制和分片比較自然。
2.1.1 關系模型和聚合模型示例
客戶，訂單，收貨地址，賬單的關系模型如下：
如果用聚合的話，如下圖：主要有兩個聚合：客戶和訂單。
客戶與訂單之間的關聯不在某個聚合結構內部，它們算是兩個聚合之間的關系。
這里ID為77的地址出現三次，在關系型中，ID在三個地方用（如果要拿到地址的具體值，需要用JOIN，優點是，地址變了，好維護。）；在聚合中，地址的值被復制了三分（這樣就不用JOIN表了，但是缺點是：地址改的話，要改很多地方）。
聚合中，產品名稱直接寫入訂單項。這種做法在聚合模型中更常見，因為在數據交互的時候盡量減少所需訪問聚合的個數（個人覺得這個和數據庫中冗余列的設計思想類似，缺點是一樣的： 如果產品名稱發生變化了，如何去更新冗余列）。
其實還有另外一種方式畫出聚合的邊界，就是把客戶下的全部訂單放到客戶聚合中：這樣就只有一個聚合了。
對於如何划分聚合沒有標准答案，取決於你想如何處理數據：如果想一次性訪問客戶全部訂單，那就放到一個大的聚合里；反之，
2.1.2 面向聚合的影響
聚合的邊界很難划定。
某種聚合模型，在有些場景下，很合適，在另外的場景下可能不合適。
因此在操作數據時，如果沒有占主導地位的結構，采用聚合無知的關系型數據結構可能更適合。
聚合模型適合在集群上運行（聚合在理想情況下，代表一個對內高內聚，對外和其他聚合低耦合的結構，這樣，每一個聚合獨自部署在一個節點上，和其他節點的聚合不關聯，這樣可以降低分布式事務類的操作。）
一般，面向聚合的數據庫不支持跨越多個聚合的ACID事務。取而代之的是，它每次只能在一個聚合結構上執行原子操作。如果想按照原子的方式操作多個聚合，就必須自己組織應用程序的代碼。在實際中，大多數原子操作都可以局限於某個聚合結構內部。
2.2 健值數據模型與文檔數據模型
二者都面向聚合（面向聚合的實質就是可以嵌套包含，而SQL數據庫的列不能嵌套包含，也不能包含列表，所有SQL數據庫必須用外鍵去關聯，也就是用JOIN，面向聚合的數據庫的理想效果是沒有JOIN，在聚合內部包含所有的數據！）
兩種模型的區別是：健值的聚合不透明，文檔的聚合是透明的，其他的都很相似。健值的value可以是任意值，而文檔的結構相對要嚴格一些，文檔型的NoSQL可以訪問特定的列，而健值數據庫的value是個整體，不夠靈活。（也就是：健值數據庫，要訪問聚合內容，只能通過健來查找。而文檔型數據庫，則可以用聚合中的字段查詢，可以只獲取一部分聚合，而不用獲取全部內容。此外，數據庫還可以按照聚合內容創建索引）。
二者界限模糊：但是還是有區別的：健值數據庫，基本上都是通過健來搜索聚合內容；而文檔型數據庫中，我們提交的查詢關鍵詞往往是基於文檔的內部結構的。
2.3 列族存儲
"列存儲數據庫"：大部分數據庫以行為單元存儲數據，尤其是在需要提高寫入性能的場合更如此。然而，有些情況下寫入操作執行得很少，但是經常需要一次性讀取若干行中的很多列。這種情況下，將所有行的某一組列作為基本數據存儲單元，效果會更好。
“列族模型”： 可以看作是兩級聚合，第一級類似健值存儲，第二級可以包含更加詳細的信息。
列族數據庫將列組織為列族。每一列都必須是某個列族的一部分，而且訪問數據的單元也得是列。這樣設計的前提是，某個列族中的數據經常需要一起訪問。
列族可以包含超列，也就是列里面可以嵌套列。
2.4 總結
三種NoSQL的共同點是：都是用聚合這一概念。聚合都有一個索引鍵。集群上運行時，聚合是中心環節，數據庫保證聚合內的數據放在通過一個節點上。聚合還是更新操作的最小數據單元，對事務控制來說，以聚合為操作單元，正好合適。
三者差別：鍵值數據模型的聚合是不透明的整體；文檔模型的聚合是透明的，可以查詢獲得一部分數據。不過，文檔沒有模式，因此想優化存儲並獲取聚合中的部分內容時，數據庫不太好調整文檔結構。