MongoDB 模式設(shè)計詳解
注意事項
模式設(shè)計，即在文檔中表示數(shù)據(jù)的方式，對于數(shù)據(jù)表示來說時非常關(guān)鍵的。
為 MongoDB 做模式設(shè)計時，在性能、可伸縮性和簡單性方面是重中之重，也需要考慮一些特別的注意事項。
限制條件
與常見的 SQL 相比而言，MongoDB 有自己的限制條件：
- 文檔最大限制為 16M 大小
- 從磁盤讀寫完整文檔
- 更新會重寫整個文檔
- 在文檔級別進(jìn)行原子更新
訪問模式
設(shè)計模式時最需要關(guān)注的就是數(shù)據(jù)庫的讀操作，在數(shù)據(jù)庫運行過程中，應(yīng)盡量減少查詢的數(shù)量，這就需要在設(shè)計時確保一起查詢的數(shù)據(jù)存儲在同一個文檔中。
其實，就是考慮是否是否可以將動態(tài)（讀/寫）數(shù)據(jù)和靜態(tài)（主要是讀）數(shù)據(jù)分離開，如未經(jīng)常使用的數(shù)據(jù)應(yīng)該移到不同的集合中。
在進(jìn)行模式設(shè)計時，提高最常見查詢的優(yōu)先級會獲得最佳的性能。
關(guān)系類型
數(shù)據(jù)之間的關(guān)系影響著文檔之間應(yīng)該是內(nèi)嵌還是引用。
比如說，需要弄清楚如何在不執(zhí)行其他查詢的情況下引用文檔，以及當(dāng)關(guān)系發(fā)生變化時需要更新多少文檔。
關(guān)系基數(shù)對于文檔之間的關(guān)系非常重要，如一對一、一對多、多對多、一對百萬、多對百萬等等關(guān)系基礎(chǔ)，影響的程度差距非常大，應(yīng)選取最佳格式去做建模。
在關(guān)系基數(shù)的基礎(chǔ)上，還需關(guān)注訪問的情況、重要數(shù)據(jù)更新與讀取的比例，這些充分考慮之后，將有助于確定應(yīng)采用內(nèi)嵌文檔還是引用文檔。
范式化和反范式化
基本概念
通常來說，多文檔之間的關(guān)系可以使用反范式化（內(nèi)嵌）或范式化（引用）。
范式化是指在文檔中引用外部數(shù)據(jù)的標(biāo)識，同一份數(shù)據(jù)只存在一個地方。
在查詢時，查詢完整的數(shù)據(jù)需要做 JOIN 的操作，需要查詢多次才可能獲取到所需內(nèi)容；但是在更改時僅需修改一處地方，不需要擔(dān)心破壞數(shù)據(jù)的完整性。
反范式化是指將外部數(shù)據(jù)復(fù)制一份存儲在文檔中，也就是說同一份數(shù)據(jù)存在多處地方。
在查詢時，只需查詢一次即可得到所需內(nèi)容，查詢效率比較可觀；而在更改時，需要更新多處地方，可能會出現(xiàn)數(shù)據(jù)不一致的情況，不能保證完整性。
范式化選擇
決定何時采用范式化以及何時采用反范式化是比較困難的：通常，范式化的寫入速度更快，而反范式化的讀取速度更快。
通過判斷以下因素可決策選擇使用范式化還是反范式化：
| 更適合范式化 | 更適合反范式化 |
|---|---|
| 較大子文檔 | 較小子文檔 |
| 數(shù)據(jù)經(jīng)常變更 | 數(shù)據(jù)不經(jīng)常變更 |
| 數(shù)據(jù)要強(qiáng)一致 | 數(shù)據(jù)最終一致即可 |
| 文檔數(shù)據(jù)大幅增加 | 文檔數(shù)據(jù)小幅增加 |
| 數(shù)據(jù)通常不包含在結(jié)果中 | 數(shù)據(jù)通常需要執(zhí)行二次查詢才能獲得 |
| 快速寫入 | 快速讀取 |
模型設(shè)計小技巧
指導(dǎo)原則
通常來說，具有類似模式的文檔應(yīng)該保存在同一個集合中。
對于集合來說，需要考慮的一個大問題是鎖機(jī)制（每個文檔都有一個讀/寫鎖）和存儲。
當(dāng)使用 --directoryperdb 選項時，每個數(shù)據(jù)庫都可以保留在自己的目錄中，這允許你將不同的數(shù)據(jù)庫掛載到不同的卷中。
同一個應(yīng)用程序連接的數(shù)據(jù)庫可以根據(jù)業(yè)務(wù)進(jìn)行劃分，也許可以將高價值的業(yè)務(wù)數(shù)據(jù)存儲在 SSD 上，或者是使用 RAID10 進(jìn)行存儲，而低價值的數(shù)據(jù)可以存儲在 RAID0 上。
刪除舊數(shù)據(jù)
有些數(shù)據(jù)只在短時間內(nèi)比較重要，過了這段時間，保存這些數(shù)據(jù)只是再浪費存儲空間。
刪除舊數(shù)據(jù)有 3 種常見的方式：使用固定集合、使用 TTL 索引、使用多個集合。
最簡單的方式是使用固定集合：將集合大小設(shè)置成一個較大的值，并讓舊數(shù)據(jù)從固定集合的末尾被“刪除”。
第二種方式是使用 TTL 集合：TTL 集合可以更精確地控制刪除文檔的時間，但其在寫入量過大的集合中操作速度不夠快。
最后一種方式是使用多個集合：例如每個月的文檔都單獨使用一個集合。
一致性管理
MongoDB 支持多種一致性級別，從總是能夠讀取自己所寫的數(shù)據(jù)到讀取不確定的舊數(shù)據(jù)。
其內(nèi)部實現(xiàn)是服務(wù)器端為每一個數(shù)據(jù)庫連接都維護(hù)了請求隊列，同一個連接發(fā)來的請求都會被添加到隊列的末尾，連接中的任何后續(xù)請求都將依次得到處理。
這個管理方式涉及到多個客戶端連接會出現(xiàn)并發(fā)問題，在一個連接中插入文檔后，在另一個連接的后續(xù)查詢卻不一定會返回這個文檔（實際上已經(jīng)插入成功）。
同樣的一致性問題在 MongoDB 擁有副本集時也會出現(xiàn)，副本節(jié)點的數(shù)據(jù)與主節(jié)點的數(shù)據(jù)總是會有時間差，高并發(fā)的請求同樣存在讀取到舊數(shù)據(jù)的風(fēng)險。
MongoDB 提供了 readConcern 選項來控制被讀取數(shù)據(jù)的一致性和隔離性。它通常與 writerConcern 組合使用，以控制為應(yīng)用程序提供的一致性和可用性保證：
如果 readConcern=local，從當(dāng)前實例查詢并返回結(jié)果，不能保證數(shù)據(jù)已經(jīng)寫入大多數(shù)副本集成員。默認(rèn)在主庫讀，如果本次讀取使用了 causally consistent 則在從庫讀。
如果 readConcern=available，從當(dāng)前實例查詢并返回結(jié)果，不能保證數(shù)據(jù)已經(jīng)寫入大多數(shù)副本集成員。默認(rèn)在從庫讀，并且此選項與 causally consistent 不能同時使用。
如果 readConcern=majority，查詢結(jié)果返回被副本集的大多數(shù)成員確認(rèn)的數(shù)據(jù)，讀操作返回的文檔是持久化的。前提是 MongoDB 必須是 WiredTiger 存儲引擎。
如果 readConcern=linearizable，查詢可能會等待并發(fā)執(zhí)行的寫操作傳播到大多數(shù)副本集成員，然后再返回結(jié)果。
如果 readConcern=snapshot，這是適用于多文檔事務(wù)中的操作，通常情況下使用較少。
模式遷移
隨著應(yīng)用程序的增長和需求的變化，數(shù)據(jù)庫模式也可能需要隨之增長和改變。理想情況下，如果可以的話，應(yīng)該考慮使用文檔版本控制模式。
最簡單的方式是根據(jù)應(yīng)用程序的需要改進(jìn)數(shù)據(jù)庫模式，以確保應(yīng)用程序支持所有的舊版模式。但是這種方式可能會導(dǎo)致混亂，特別是當(dāng)不同版本的模式存在沖突時。
為了以一種更結(jié)構(gòu)化的方式處理不斷變化的需求，可以在每個文檔中包含一個 version 字段，并使用它來確定應(yīng)用程序?qū)⒔邮艿奈臋n結(jié)構(gòu)。
最后一種方式是在模式變更時遷移所有數(shù)據(jù)。但這通常不是一個好主意：會給系統(tǒng)帶來壓力，還必須確保所有文檔都被更新成功。
模式管理
MongoDB 3.2 引入了模式驗證，其可以在更新和插入操作期間對數(shù)據(jù)進(jìn)行驗證。
MongoDB 3.6 又通過 $jsonSchema 運算符添加了 JSON 模式驗證，現(xiàn)在這是 MongoDB 中所有模式驗證的推薦方法。
只有當(dāng)文檔被更改時，驗證功能才會檢查這些文檔，并且此功能是每個集合都需要單獨配置的。
要向現(xiàn)有集合添加驗證功能，可以在 collMod 命令中使用 validator 選項。在使用 db.createCollection() 時，可以通過指定 validator 選項將驗證添加到新集合中。
MongoDB 還提供了兩個額外的選項：
validationLevel: 決定了在更新過程中驗證規(guī)則對現(xiàn)有文檔檢查的嚴(yán)格程度validationAction: 決定了是應(yīng)該在發(fā)生錯誤時拒絕請求，還是允許請求并發(fā)出警告
當(dāng)然，更詳細(xì)的相關(guān)內(nèi)容可以查看 官方文檔。
編寫代碼來處理數(shù)據(jù)完整性問題
為保證 MongoDB 數(shù)據(jù)的完整性，有可能需要在應(yīng)用程序中增加必要的邏輯代碼進(jìn)行處理，也需要增加定時任務(wù)來保持?jǐn)?shù)據(jù)的一致性。
有可能需要有以下的任務(wù)：
- 一致性修復(fù)程序：檢查計算和重復(fù)數(shù)據(jù)以確保每個人都具有一致的值
- 預(yù)填充器：創(chuàng)建將來需要的文檔
- 聚合：保持內(nèi)聯(lián)聚合為最新
- 架構(gòu)檢查器：確保當(dāng)前使用的文檔集都具有一組字段，可以自動更正它們
- 定時備份：定期鎖定和轉(zhuǎn)儲數(shù)據(jù)庫
到此這篇關(guān)于MongoDB 模式設(shè)計詳解的文章就介紹到這了,更多相關(guān)MongoDB模式設(shè)計內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！
相關(guān)文章
關(guān)于MongoTemplate通過id查詢?yōu)閚ull的問題
這篇文章主要介紹了關(guān)于MongoTemplate通過id查詢?yōu)閚ull的問題,本文給大家介紹的非常詳細(xì)，對大家的學(xué)習(xí)或工作具有一定的參考借鑒價值，需要的朋友可以參考下2021-01-01
這篇文章主要介紹了mongo復(fù)制集同步驗證的實例詳解的相關(guān)資料,這里提供實現(xiàn)的方法及示例代碼，幫助大家學(xué)習(xí)理解，需要的朋友可以參考下2017-07-07
剖析后OpLog訂閱MongoDB的數(shù)據(jù)變更就沒那么難了
這篇文章主要為介紹了OpLog訂閱MongoDB的數(shù)據(jù)變更，希望讀完本文后讓你對OpLog訂閱MongoDB的數(shù)據(jù)變更不在頭疼，有需要的朋友可以借鑒參考下，希望能夠有所幫助2022-02-02
$divide聚合運算符返回兩個表達(dá)式相除的結(jié)果,參數(shù)通過數(shù)組傳遞給$divide運算符,這篇文章介紹了MongoDB聚合運算符$divide的相關(guān)知識,感興趣的朋友跟隨小編一起看看吧2024-03-03
mongoDB是一個非常不錯的數(shù)據(jù)庫，最近也正在學(xué)習(xí)mongoDB，在使用一個數(shù)據(jù)庫前必不可少的就是安裝和卸載，所以下面這篇文章主要給大家介紹了關(guān)于Mac系統(tǒng)中mongoDB安裝與卸載的相關(guān)資料，需要的朋友可以參考借鑒，下面來一起看看吧。2017-10-10
這篇文章主要介紹了 MongoDB 游標(biāo)詳解及實例代碼的相關(guān)資料,需要的朋友可以參考下2017-04-04
這篇文章主要介紹了MongoDB中連接池、索引、事務(wù)的相關(guān)資料,需要的朋友可以參考下2023-01-01
MongoDB中的主從同步配置和mongod相關(guān)啟動命令講解
這篇文章主要介紹了MongoDB中的主從同步配置和mongod相關(guān)啟動命令講解,文中也羅列了很多其他常用的mongod命令參數(shù),需要的朋友可以參考下2016-03-03
mongodb數(shù)據(jù)庫游標(biāo)的使用淺析
這篇文章主要介紹了mongodb數(shù)據(jù)庫游標(biāo)的使用,需要的朋友可以參考下2014-07-07
如何去掉保存mongodb數(shù)據(jù)時出現(xiàn)的_class字段
這篇文章主要給大家介紹了如何去掉保存mongodb數(shù)據(jù)時出現(xiàn)的_class字段,文中通過代碼示例給大家介紹的非常詳細(xì),對大家的學(xué)習(xí)或工作有一定的幫助,需要的朋友可以參考下2024-02-02