標簽： MongoDB NoSQL
1. 存儲引擎
1.1 存儲引擎是什么
存儲引擎是位於持久化數據（通常是放在磁盤或者內存中）和數據庫之間的一個操作接口，它負責數據的存儲和讀取方式。MongoDB數據庫通過存儲引擎在磁盤中讀取數據，而假設我們的應用是ASP.NET MVC，我們可以使用官方的Mongo.Driver驅動，通過通信協議（如TCP）向MongoDB數據庫發送各種請求。以下是一個簡單的運行圖示
1.2 MongoDB中的默認存儲引擎
自MongoDB 3.2 Release版本起，MongoDB默認的存儲引擎就成了WiredTiger。而在之前的版本中，它還是MMAPv1。但由於MongoDB架構支持可插拔的存儲引擎，所以使用中即便要更換也是可以做到的。至於其他的功能比較大家可以參閱官方文檔，如不再是In-Place Update，新增Compression等。
我們可以在開啟mongod服務時輸入相關參數調整存儲引擎，如mongod --storageEngine MMAPv1|wiredTiger
我們也可以使用db.collections.stats()查看當前的引擎名稱
-
MMAPv1
MMAPv1 提供集合級別鎖（實際上稱為collection-level locking） -
WiredTiger
WiredTiger 對於寫操作提供文檔級別並發控制（實際上稱為document-level concurrency），因此，不同的客戶端請求可以在同一時間針對一個集合中的不同文檔進行修改
2. 數據模型設計
2.1 內嵌和引用
在MongoDB中，數據的表示方式有內嵌和引用兩種。
“引用”我們比較好理解，是指將不同實體的數據分散不到不同的集合中，而在關系型數據庫設計中就是將實體分別建立相應的模型表。如常見的“老師-學生”，“產品-標簽”關系，只要實體間存在關系，就可以使用“引用”思想。
“內嵌”是一種反范式化的設計，指的是將每個文檔所需的數據都嵌入到文檔內部，我想舉一個“用戶-賬戶”的關系。我們知道在領域驅動設計中，“用戶”是一個聚合根，每個用戶對應一個賬戶，所以是“1對1”的一種關系，在關系型數據庫設計中，大部分時候都會將這兩者嚴格區分開來。但是在MongoDB中，卻不然，我們可以直接選擇將“用戶”需要的“賬戶”數據內嵌到用戶文檔中，便於我們的增刪改查。這是一種反范式化的設計。
設計MongoDB數據模型的時候，我們需要轉變以往設計關系型數據模型時的思維。即便是針對一個關系中不同集合的數量規模，我們的模型也將有很大的不同。
2.2 設計原則
*
A. 1 - 1 或者 1 - （較少）
用戶與賬戶，以及用戶與收貨地址都是這樣情況，在這樣的情況下，顯而易見我們可以采取內嵌的方式來進行數據管理。
> db.person.findOne()
{
_id:ObjectId("cccc"),
name:"wddpct",
age:22,
location:"wenzhou",
addresses:[
{country:"china",city:"wenzhou",street:"chashan road"}
{country:"china",city:"wenzhou",street:"north center road"}
]
}
這也引伸出一個問題，除了“1”以外的另一端的實體是否有必要在數目較少的時候進行單獨集合的儲存。如用戶和任務模塊，任務是系統定期發布，分配給相應用戶完成，這意味着我們對任務的操作也將比較復雜。這樣的情況下，顯然是分開不同集合進行存儲，然后讓person集合引用task_id數組。
> db.person.findOne()
{
_id:ObjectId("cccc"),
name:"wddpct",
age:21,
location:"wenzhou",
tasks:[
ObjectId("xxxx"),
ObjectId("yyyy"),
……
]
}
所以針對剛才提到的情況，我們大可以借鑒領域驅動模式中的“實體”和“值對象”的部分概念，主要還是看這些數據模型在系統中是否有較大較復雜的操作可能。
*
B. 1 - （較多）
博主之前負責過一個市級地區中小學眼視光篩查系統，里面的簡化模型就比較適合拿來做例子。如學校與學生，數目多也不過數千。這樣的情況下，自然也是使用引用的方式更容易接受
> db.school.findOne()
{
_id:ObjectId("cccc"),
name:"middle1",
location:"wenzhou",
students:[
ObjectId("xxxx"),
ObjectId("yyyy"),
……
]
}
這里同樣也引伸出一個“冗余”的問題，我們知道大多時候我們需要查詢的數據屬性數目是比較少的，比如對於學生而言，我們可能只需要知道他的身高體重，所以我們可以使用“冗余”思想簡單修改剛才的集合成以下格式來應付
> db.school.findOne()
{
_id:ObjectId("cccc"),
name:"middle1",
location:"wenzhou",
students:[
{ObjectId("xxxx"),name:"wddpct",height:233,weight:233},
{ObjectId("yyyy"),name:"wddmd",height:233,weight:233}
……
]
}
不過也要注意的一點是，這樣每次更新student的信息時，不免又要對school中的冗余信息進行更新，所以也要結合具體場景使用
*
C. 1 - （非常多）
地區和車牌的關系勉強屬於此類，一個地區可能有幾十上百萬車牌，我們不可能再像剛才那樣在area中加入所有的license_id，不然可能光是單個文檔大小就超過MongoDB的16MB限制了，而且對於查詢也存在很大的負擔。
這里我們可以直接套用關系型數據庫中的外鍵思想，在license集合的末尾加入area_id就可以方便解決此類關系
> db.license.findOne()
{
_id:ObjectId("cccc"),
license:"middle1",
area:ObjectId("xxxx")
}
當然，我們也可以對area進行進一步冗余，所以就不額外說明了。
*
D. * -
對於多對多關系模型，可能又要祭出那句老話——“視具體情況而定”。不過一般情況下，它不過就是一對多關系的幾個變種。一個基本的原則是考慮兩邊統一引用對方的ObjectId，適當冗余部分信息。
除此以外，我們還可以從以下幾個原則去考慮
- 兩邊的數量比（較大方更適合引用）
- 兩邊的更新頻率比（較大方更適合引用）
- 兩邊的讀取頻率比（較大方更適合內嵌）
……
E. 通用建議
以下給出一張較通用的建議表，僅供參考
| 內嵌 | 引用 |
|---|---|
| 子文檔較小 | 子文檔較大 |
| 數據不會定期更改 | 數據經常改變 |
| 最終數據一致即可 | 中間階段數據也必須一致 |
| 文檔數據小額增加 | 文檔數據大幅增加 |
| 數據通常需要執行二次查詢 | 數據通常不包含在查詢結果中 |
| 快速讀取 | 快速寫入 |