MongoDB  資料模型的設計模式及優缺點

在實際開發中，大多數效能問題都可以追溯到糟糕的模型設計。官方也提供分享過檔案模型設計的進階技巧，這裡簡單翻譯記錄一下。

簡介

官方文章的地址是 Building with Patterns: A Summary，其中彙總了 12 種設計模式及使用場景。

上述的圖表列舉了 12 種設計模式及應用場景，主要是以下這些：

• 近似值模式（Approximation Pattern）
• 屬性模式（Attribute Pattern）
• 桶模式（Bucket Pattern）
• 計算模式（Computed Pattern）
• 檔案版本控制模式（Document Versioning Pattern）
• 擴充套件參照模式（Extended Peference Pattern）
• 異常值模式（Outlier Pattern）
• 預分配模式（Preallocated Pattern）
• 多型模式（Polymorphic Pattern）
• 模式版本控制模式（Schema Versioning Pattern）
• 子集模式（Subset Pattern）
• 樹型模式（Tree and Graph Pattern）

近似值模式

範例描述

淘寶在往年“雙十一”都會有一個銷售額大屏展示，當銷售額小於 1 億時，可能展示的是實際的數量，當銷售額超過 1 億時，單位立即變成以“億”為單位，對於展示的大屏而言，”億“以下的單位這個時候並不是很重要了。

對於上述的場景，如果每次幾十、幾百都直接去更新資料庫中的實際值，則更新資料庫會變得非常頻繁，對於資料庫的壓力是非常大的。

實際上，並不需要每次都去更新資料庫，我們只需要將這個實際的精確值儲存在記憶體中，使用 1 億作為一個閾值，一旦超過這個閾值就精確值更新進資料庫中。

對於精度不是首要考慮因素時，那麼就可以使用近似值模式，尤其是消耗資源（時間、記憶體、CPU 週期）非常昂貴時效果會更佳。

近似值模式就是通過減少資料的寫入頻率，從而降低了架構的複雜度和資源開銷，進而提升了整體的效能與效率。

優缺點

近似值模式的優點如下：

• 由於是近似的資料，不必時時刻刻寫入，資料庫的寫操作量級更小

近似值模式的缺點如下：

• 儲存的是近似的資料，無法應對需要展示精確資料的場景
• 此模式需要在應用層實現

屬性模式

範例描述

屬性模式運用到了 MongoDB 多鍵索引的概念，支援對陣列中的巢狀子檔案中的某個屬性進行索引。

假設現在有一個關於電影的集合，其中檔案中會包含標題、導演、製片人、演員、上映時間等等資訊，對於跨地區上映的電影，有可能不同地區的上映時間是不一樣的。

如下展示是一條電影的檔案資料：

{
    "title": "Star Wars",
    "director": "George Lucas",
    // 不同地區有不同的上映時間
    "release_US": ISODate("1977-05-20T01:00:00+01:00"),
    "release_France": ISODate("1977-10-19T01:00:00+01:00"),
    "release_Italy": ISODate("1977-10-20T01:00:00+01:00"),
    "release_UK": ISODate("1977-12-27T01:00:00+01:00"),
}

為了支援對所有上映時間做一個快速搜尋，也許我們需要將所有的上映時間設定為單一索引，這個時候，索引的數量就會變得顯而易見的多。

使用屬性模式，我們通過將這些上映時間資訊移動到一個陣列中，然後再對這個陣列建立一個多鍵索引索引，以實現使用一個索引替代多個類似索引的功能。

如下是修改結構後的檔案資料：

{
    "title": "Star Wars",
    "director": "George Lucas",
    // 所有的地區的上映時間都放在同一個屬性內部
    "releaseList": [
        {
            "region": "US",
            "date": ISODate("1977-05-20T01:00:00+01:00")
        },
        {
            "region": "France",
            "date": ISODate("1977-10-19T01:00:00+01:00")
        },
        {
            "region": "Italy",
            "date": ISODate("1977-10-20T01:00:00+01:00")
        },
        {
            "region": "UK",
            "date": ISODate("1977-12-27T01:00:00+01:00")
        }
    ]
}

優缺點

屬性模式的優點如下：

• 需要更少的索引
• 查詢變得更容易編寫，而且通常更快

桶模式

範例描述

桶模式有點類似於水平分庫，常見的水平分庫是將一個集合按照某一個規則分佈到不同的資料庫上，桶模式是將一個集合中的檔案按照某一個規則合併起來。

假設現在有一個需要記錄使用者紀錄檔的需求，對於使用者的每一個動作，都需要將其更新到 MongoDB 當中，並且是記錄其動作、時間。

對於這樣的紀錄檔資料來說，如果將每一個動作都儲存成一個檔案，則將會佔用極大的儲存空間和記憶體。

使用桶模式的解決辦法就是，將一段時間的紀錄檔資料儲存成一個檔案，再將每一個動作紀錄檔的資料儲存到子檔案資料中。

當需要管理流式資料的時候，如時間序列、實時分析或物聯網應用程式，桶模式就是一個很好的解決方案。

優缺點

桶模式的優點如下：

• 減少了集合中的檔案總數
• 提高了索引效能
• 可以通過預聚合簡化資料的存取

計算模式

範例描述

對於大型資料集，每一次計算都可能會佔用極大的 CPU、磁碟、記憶體等相關資源，甚至是影響到伺服器上的其他計算。

而對於需要重複計算、讀取比寫入多的場景，計算模式提供了一種優化的思路，以便降低伺服器資源的佔用。

拿一個電影觀看總人數的例子來說明：假設現在頁面上需要展示觀看電影的實際總人數，而且這個頁面會有成千上萬的人存取。

雖然，我們可以對電影的每一次放映都記錄起觀看人數，但是要獲取總人數，則需要拿出所有的放映場次的觀看人數之後計算其總和，這個計算就非常耗費資源和時間。

對於只有放映場次變化之後，總人數才會更新的情況，實際資料庫讀取的次數遠遠大於寫入的次數。

在這個場景中，計算模式的思路是：每一次更新放映場次資料的時候，將這個放映場次的人數彙總到一個檔案當中，這個檔案直接面向用戶的查詢。

優缺點

計算模式的優點如下：

• 對於頻繁的計算可以減少 CPU 的負載
• 查詢變得更容易編寫，而且通常更快

計算模式的缺點如下：

• 識別出需要使用此模式的的場景可能比較困難
• 除非必要，請勿過度使用此模式

檔案版本控制模式

範例描述

檔案版本控制模式在高度規範化的行業中非常有用，這些行業會要求資料的特定時間點版本。

假設現在有一個部落格系統，其中有一個記錄每次編輯部落格文章歷史的功能，這樣的功能就能應用檔案版本控制模式。

假設我們將所有的文章歷史都儲存在同一個集合當中，則需要考慮大部分與文章相關的功能都要過濾掉歷史版本、版本越多則集合檔案數量越多等等問題。

檔案版本控制模式的想法是：檔案中需要記錄一個檔案的版本，將最新的檔案儲存在一個 current 集合中，而那些舊版本的檔案儲存在 history 集合中。

為了最大化利用檔案版本控制模式的優勢，通常會假設資料存取模式儘量符合以下要求：

• 每個檔案不會有太多的修訂版本
• 需要做版本控制的檔案不會太多
• 大多數的查詢都是基於檔案的最新版本

優缺點

檔案版本控制模式的優點如下：

• 容易實現，對現有系統的影響小
• 在最新版本上進行請求時，沒有效能上的影響

檔案版本控制模式的缺點如下：

• 寫操作的數量會翻倍
• 請求需要被定位到正確的集合

擴充套件參照模式

範例描述

MongoDB 是一個不需要提前建模的 NoSQL，當不同檔案、不同集合之間存在關係的時候，通常會有嵌入和參照兩種方式。

嵌入就是將檔案資料嵌入到參照此資料的檔案中，存取時直接存取這一次檔案即可；參照就是隻在檔案中參照另一個檔案的標識，存取時需要存取兩次資料庫才能拿到完整的資料。

擴充套件參照模式是指僅複製經常存取並且不經常更改的欄位，而不是複製所有的資料，減少資訊的連線以提高效能。

這張圖的場景是：客戶和訂單是 1 對 N 的關係，通常查詢訂單列表的時候需要展示客戶的一些資訊，我們就需要考慮是否將客戶的資訊冗餘進訂單資訊中。

擴充套件參照模式認為，客戶的名稱和地址是不常做更新的，可以直接將這些資訊冗餘進訂單表中，以達到減少兩個集合連線查詢的要求。

優缺點

擴充套件參照模式的優點如下：

• 當有大量的 JOIN 操作時可以提升效能
• 讀操作會更快，並且可以減少 JOIN 操作的數量

擴充套件參照模式的缺點如下：

• 修改冗餘的這部分資料會比較複雜

異常值模式

範例描述

顧名思義，異常值模式主要用以解決超出應用程式正常模式的少數異常查詢情況。

假設你正在搭建一個出售圖書的電子商務網站，現在需要記錄一本書都有哪些使用者購買過，一個常見的做法的是將購買的使用者標識儲存在圖書檔案中，如下展示：

{
    "_id": ObjectId('6392cecd4dd9624424ad025d'),
    "title": "三國演義",
    "author": "羅貫中",
    "purchase_customers": [
        "user0",
        "user1",
        "user3",
        // ...
    ]
}

對於上述的檔案結構，大部分情況下是適用的。但是，對於銷量特別高的圖書，極可能導致圖書檔案的大小超過 16MB 的限制。

使用異常值模式的方式是：在圖書檔案中新增一個欄位來將其標記為異常值，超過一定大小的內容可以儲存在另一個檔案當中，在應用程式中對異常檔案做擴充套件查詢處理，減少異常檔案對正常檔案的影響。

優缺點

異常值模式的優點如下：

• 防止整個應用被某些異常的檔案或請求所影響
• 請求會針對那些典型的用例進行優化，而異常值仍將得到處理

異常值模式的缺點如下：

• 通常會為特定的查詢而進行客製化，因此一些臨時產生的查詢可能效能不太理想
• 此模式的大部分工作是在應用程式程式碼中完成的

預分配模式

範例描述

在使用 MMAPv1 儲存引擎時，MongoDB 的一個常見優化是提前分配所需的記憶體，以滿足不斷增長的檔案未來會達到的大小。

MMAPv1 中不斷增長的檔案需要由伺服器端以相當昂貴的成本進行位置的遷移，而 WiredTiger 的無鎖機制（lock-free）和重寫（rewrite）更新演演算法不需要這種處理。

一個相對應的例子就是，直接儲存一個二維資料可以做到預分配記憶體，而儲存二維陣列轉換後的稀疏陣列則無法做到預分配記憶體。

因此，在 MMAPv1 中，更推薦使用預分配模式直接儲存原始的二維陣列。

優缺點

預分配模式的優點如下：

• 當預先知道檔案結構時，可以簡化設計

預分配模式的缺點如下：

• 簡單和效能之間的權衡

多型模式

範例描述

在物件導向中，多型指的是為不同資料型別的實體提供統一的介面，或使用一個單一的符號來表示多個不同的型別。

而 MongoDB 不強制要求集合的檔案擁有特定的結構，這裡的多型模式指的是，集合中的檔案具有更多的相似性而不是差異性，檔案結構都類似但又不完全相同。

其一種實現方案是將檔案分組在一起做查詢，而不是將其分散到多個集合中；另一種實現方案是使用嵌入式子檔案的模式彙總。

多型模式的一個典型用例是單一檢視應用程式：假設現在一家較大的公司收購了其他公司，這些公司的業務都是類似的，資料庫都以類似的方式儲存了資料。

這個時候就可以利用 MongoDB 和多型模式在短時間內構建好單一檢視應用程式。

除了單一檢視應用程式外，多型模式的其他典型用例還有以下幾種：

• 內容管理
• 移動應用程式
• 產品目錄

優缺點

多型模式的優點如下：

• 實現簡單
• 查詢可以在單個集合中執行

模式版本控制模式

範例描述

幾乎每個資料庫在其生命週期中的某個時刻都會產生變更，一旦資料庫中的資料模型發生變化，通常需要停止應用程式，遷移資料庫以支援新模式，然後重新啟動。

這種停機更新會導致糟糕的使用者體驗，而模式版本控制模式允許歷史版本和當前版本的檔案在集合中同時存在，以此保障使用者體驗。

通過使用 schema_version 欄位定義模式的版本，並將其儲存到資料庫中，每個新的模式版本都會增加 schema_version 欄位的值。

在應用程式內部，為每個模式版本建立相應的處理常式，這樣即可適應不同版本的資料。

優缺點

模式版本控制模式的優點如下：

• 不需要停機時間
• 模式遷移可控
• 減少未來的技術債務

模式版本控制模式的缺點如下：

• 在遷移過程中，對相同的欄位可能需要兩個索引

子集模式

範例描述

MongoDB 將頻繁存取的資料儲存在 RAM 中，當資料和索引的工作集超過分配的物理 RAM 時，隨著磁碟存取的發生以及資料從 RAM 中轉出，效能會開始下降。

為解決這個問題，一個方案是向伺服器新增更多的 RAM，不過擴充套件會有上限，而且非常昂貴；或者考慮對集合進行分片，但這會帶來額外的成本和複雜性。

子集模式就解決了有大量資料的大檔案沒有被應用程式使用而導致的工作集超過 RAM 容量的問題，比如說一個電商產品的評論可能有成千上萬條，但大部分情況下都只會存取最近 10 個評論。

其實現方法就是，將一個儲存大檔案的集合拆分成多個子集，每一個子集都能為單獨的功能提供資源，減少了工作集的總體大小。

優缺點

子集模式的優點如下：

• 在總體上減小了工作集的大小
• 縮短了最常用資料的磁碟存取時間

子集模式的缺點如下：

• 必須管理子集
• 請求附加的資料需要額外的資料庫存取

樹形模式

範例描述

對於 SQL 來說，可以通過外連子結點或父結點的方式表示樹形結構。

對於 MongoDB 而言，比較方便的就是通過儲存子結點陣列的方式實現，但是其缺點就是每次更新時都需要操作整個結構，不合適做頻繁更新，比如說家譜。

因此，當資料是分層結構並且經常被查詢時，樹形模式是比較優的一個選擇。並且可以通過給陣列中的屬性建立多鍵索引提高查詢效率。

優缺點

樹形模式的優點如下：

• 通過避免多次 JOIN 操作提高了效能

樹形模式的缺點如下：

• 需要在應用程式中管理樹結構的更新

到此這篇關於MongoDB  資料模型的設計模式的文章就介紹到這了,更多相關MongoDB  資料模型內容請搜尋it145.com以前的文章或繼續瀏覽下面的相關文章希望大家以後多多支援it145.com！