標簽： MongoDB NoSQL

• MongoDB 存儲引擎和數據模型設計
• 1. 存儲引擎
  • 1.1 存儲引擎是什麼
  • 1.2 MongoDB中的預設存儲引擎
• 2. 數據模型設計
  • 2.1 內嵌和引用
  • 2.2 設計原則
    • A. 1 - 1 或者 1 - *（較少）
    • B. 1 - *（較多）
    • C. 1 - *（非常多）
    • D. * - *
    • E. 通用建議

1. 存儲引擎

1.1 存儲引擎是什麼

存儲引擎是位於持久化數據（通常是放在磁碟或者記憶體中）和資料庫之間的一個操作介面，它負責數據的存儲和讀取方式。MongoDB資料庫通過存儲引擎在磁碟中讀取數據，而假設我們的應用是ASP.NET MVC，我們可以使用官方的Mongo.Driver驅動，通過通信協議（如TCP）向MongoDB資料庫發送各種請求。以下是一個簡單的運行圖示

1.2 MongoDB中的預設存儲引擎

自MongoDB 3.2 Release版本起，MongoDB預設的存儲引擎就成了WiredTiger。而在之前的版本中，它還是MMAPv1。但由於,ongoDB架構支持可插拔的存儲引擎，所以使用中即便要更換也是可以做到的。至於其他的功能比較大家可以參閱官方文檔，如不再是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，適當冗餘部分信息。

除此以外，我們還可以從以下幾個原則去考慮

1. 兩邊的數量比（較大方更適合引用）
2. 兩邊的更新頻率比（較大方更適合引用）
3. 兩邊的讀取頻率比（較大方更適合內嵌）
   ……

E. 通用建議

以下給出一張較通用的建議表，僅供參考