如何有效地進(jìn)行 MongoDB 的數(shù)據(jù)容量規(guī)劃？

時(shí)間：2023-10-18 01:30:01 | 來源：網(wǎng)站運(yùn)營(yíng)

時(shí)間：2023-10-18 01:30:01 來源：網(wǎng)站運(yùn)營(yíng)

如何有效地進(jìn)行 MongoDB 的數(shù)據(jù)容量規(guī)劃？：

二、JSON文檔模型設(shè)計(jì)

2.1、MongoDB文檔模型設(shè)計(jì)的三個(gè)誤區(qū)

• 不需要模型設(shè)計(jì)
• MongoDB應(yīng)該用一個(gè)超級(jí)大文檔來組織所有數(shù)據(jù)
• MongoDB不支持關(guān)聯(lián)或事物

以上這些說法全是錯(cuò)誤的。

2.2、關(guān)于JOSN文檔模型設(shè)計(jì)

文檔模型設(shè)計(jì)處于是物理模型設(shè)計(jì)階段 （PDM）

JSON 文檔模型通過內(nèi)嵌數(shù)組或引用字段來表示關(guān)系

文檔模型設(shè)計(jì)不遵從第三范式，允許冗余。

嚴(yán)格來說，MongoDB 同樣需要概念/邏輯建模

文檔模型設(shè)計(jì)的物理層結(jié)構(gòu)可以和邏輯層類似

2.3、邏輯模型 – JSON 模型

下面是一個(gè)JSON模型和邏輯模型的對(duì)比， 這里json文檔中的聯(lián)系人，列舉出了姓名、性別、創(chuàng)建日期、所屬組、和地址；

這樣一個(gè)物理關(guān)系模型中需要多張表，而這里可以直接通過一個(gè)json來表述出來。

2.4、文檔模式設(shè)計(jì)原則：性能和易用

在文檔模式設(shè)計(jì)中我們是沒有第三范式原則的，這是個(gè)好處也是個(gè)弊端，很多人不知道該如何設(shè)計(jì)這個(gè)模型。什么樣的模型好什么樣的模型壞。

我們是有兩個(gè)關(guān)鍵點(diǎn)，看你這個(gè)模型是否性能不錯(cuò)，能夠支撐高并發(fā)、低延遲的讀寫。另外一個(gè)角度在程序開發(fā)過程中是否簡(jiǎn)易。

這里沒有唯一的標(biāo)準(zhǔn)，這里更多的是經(jīng)驗(yàn)之談。我們后面給大家些建模的建議?？梢宰饛奈臋n模式設(shè)計(jì)三步走：

三、文檔模式設(shè)計(jì)：基礎(chǔ)建模

• 根據(jù)概念模型或者業(yè)務(wù)需求推導(dǎo)出邏輯模型 – 找到對(duì)象
  
• 列出實(shí)體之間的關(guān)系（及基數(shù)） - 明確關(guān)系
  
• 套用邏輯設(shè)計(jì)原則來決定內(nèi)嵌方式 – 進(jìn)行建模
  
• 完成基礎(chǔ)模型構(gòu)建
  

3.1、1:1關(guān)系建立

比如，一個(gè)聯(lián)系人只有一個(gè)頭像，

• 基本原則：一對(duì)一關(guān)系以內(nèi)嵌為主作為子文檔形式 或者直接在頂級(jí)不涉及到數(shù)據(jù)冗余；
• 例外情況：如果內(nèi)嵌后導(dǎo)致文檔大小超過16MB

{ "name": "TJ Tang", "company": "TAPDATA", "title": " CTO", "portraits": { "mimetype": "xxx", "data": "xxxx" }}

3.2、一對(duì)多關(guān)系建立

比如一個(gè)聯(lián)系人可以有多個(gè)地址：

• 一對(duì)多關(guān)系同樣以內(nèi)嵌為主用數(shù)組來表示一對(duì)多不涉及到數(shù)據(jù)冗余；
• 例外情況：如果內(nèi)嵌后導(dǎo)致文檔大小超過16MB，數(shù)組長(zhǎng)度太大（數(shù)萬或更多），數(shù)組長(zhǎng)度不確定;

{ "name": "TJ Tang", "company": "TAPDATA", "title": " CTO", "portraits": { "mimetype": "xxx", "data": "xxxx" }, "addresses": [ { "type": "home", .... }, { "type": "work", .... } ]}

3.3、多對(duì)多關(guān)系建模

比如一個(gè)聯(lián)系人可以有多個(gè)地址：

• 一對(duì)多關(guān)系同樣以內(nèi)嵌為主用數(shù)組來表示一對(duì)多，通過冗余來實(shí)現(xiàn)N-N；
• 例外情況：如果內(nèi)嵌后導(dǎo)致文檔大小超過16MB，數(shù)組長(zhǎng)度太大（數(shù)萬或更多），數(shù)組長(zhǎng)度不確定;

{ "name": "TJ Tang", "company": "TAPDATA", "title": " CTO", "portraits": { "mimetype": "xxx", "data": "xxxx" }, "addresses": [ { "type": "home", .... }, { "type": "work", .... } ], "groups":[ {"name":"FRI"}, {"name":"DF"}, ]}

四、文檔模式設(shè)計(jì)：工況細(xì)化

在做工況細(xì)化過程中，我們需要根據(jù)技術(shù)需求對(duì)我們模型進(jìn)行調(diào)整，這是個(gè)技術(shù)導(dǎo)向，我們需要和業(yè)務(wù)方進(jìn)行詳細(xì)的溝通，了解到數(shù)據(jù)的使用方法，是根據(jù)什么來查詢的。如：?jiǎn)蝹€(gè)查詢，報(bào)表查詢，查詢參數(shù)是什么、數(shù)量有多大、讀寫比例有多少等等。針對(duì)不同需求，我們可以引入引用、關(guān)聯(lián)、或者冗余等手段來解決這些問題。

● 最頻繁的數(shù)據(jù)查詢模式

● 最常用的查詢參數(shù)

● 最頻繁的數(shù)據(jù)寫入模式

● 讀寫操作的比例

● 數(shù)據(jù)量的大小

比如：聯(lián)系人管理應(yīng)用的分組需求

4.1 解決方案：Group 使用單獨(dú)的集合

類似于關(guān)系型設(shè)計(jì)，使用 id 或者唯一鍵關(guān)聯(lián)，使用 $lookup 來提供一次查詢多表的能力（類似關(guān)聯(lián)）（3.2以上版本支持）。

4.2、聯(lián)系人的頭像： 引用模式

• 頭像使用高保真，大小在 5MB-10MB
• 頭像一旦上傳，一個(gè)月不可更換
• 基礎(chǔ)信息查詢（不含頭像）和 頭像查詢的比例為 9 ：1

建議： 使用引用方式，把頭像數(shù)據(jù)放到另外一個(gè)集合，可以顯著提升 90% 的查詢效率。

4.3、什么時(shí)候使用引用模式

• 內(nèi)嵌文檔太大，數(shù) MB 或者超過 16MB
• 內(nèi)嵌文檔或數(shù)組元素會(huì)頻繁修改
• 內(nèi)嵌數(shù)組元素會(huì)持續(xù)增長(zhǎng)并且沒有封頂

MongoDB 引用設(shè)計(jì)的限制

• MongoDB 對(duì)使用引用的集合之間并無主外鍵檢查
• MongoDB 使用聚合框架的 $lookup 來模仿關(guān)聯(lián)查詢
• $lookup 只支持 left outer join
• $lookup 的關(guān)聯(lián)目標(biāo)（from）不能是分片表

五、文檔設(shè)計(jì)模式：套用設(shè)計(jì)模式

文檔模型：無范式，無思維定式，充分發(fā)揮想象力；

設(shè)計(jì)模式：實(shí)戰(zhàn)過屢試不爽的設(shè)計(jì)技巧，快速應(yīng)用；

舉例：一個(gè)IoT場(chǎng)景的分桶設(shè)計(jì)模式，可以幫助把存儲(chǔ)空間降低10倍并且查詢效率提升數(shù)十倍。

問題：物聯(lián)網(wǎng)場(chǎng)景下的海量數(shù)據(jù)處理 - 設(shè)備監(jiān)控?cái)?shù)據(jù)

上報(bào)數(shù)據(jù)格式如下：

{ "_id":"10000000022200000222:CA2091", "icao":"CA2091", "ts":ISODate("2022-04-03T20:21:35.000+0000"), "events":{ "tem":35.3， "humidity":50.3, "lon":38.345, "lat":58.987, "open":"0", "b":"b" "p":[123,245], "s":91 }}我們假設(shè)有10萬個(gè)設(shè)備，每分鐘上報(bào)一條數(shù)據(jù)，一年的數(shù)據(jù)量大約52560*100W = 525億數(shù)據(jù)，約10TB;

	每分鐘1條
文檔條數(shù)	52.5B	10W * 365 * 24 * 60
索引大小	6364GB	10W * 365 * 24 * 60 * 130
_id index	1468GB
{ts:1,icao:1}	4895GB
文檔平均大小	92Bytes
數(shù)據(jù)大小	4503GB	10W * 365 * 24 * 60 * 92

5.2、解決方案-分桶設(shè)計(jì)

思路將之前每分鐘數(shù)據(jù)匯總到每小時(shí)一條，將每分鐘數(shù)據(jù)存放在events中，變更結(jié)構(gòu)如下：

{ "_id": "10000000022200000222:CA2091", "icao": "CA2091", "ts": ISODate("2022-04-03T20:00:00.000+0000"),//每小時(shí) "events": [//每小時(shí)60條數(shù)據(jù)，集合條數(shù)固定 { "tem": 35.3, "humidity": 50.3, "lon": 38.345, "lat": 58.987, "open": "0", "b": "b", "p": [ 123, 245 ], "s": 91, "ts": ISODate("2022-04-03T20:01:00.000+0000")//每分鐘 }, { "tem": 35.3, "humidity": 50.3, "lon": 38.345, "lat": 58.987, "open": "0", "b": "b", "p": [ 123, 245 ], "s": 91, "ts": ISODate("2022-04-03T20:02:00.000+0000") } ]}這里我們一個(gè)文檔可以存儲(chǔ)一個(gè)小時(shí)的設(shè)備數(shù)據(jù)，而events集合中的數(shù)據(jù)條數(shù)是固定的，每小時(shí)60條。

可視化表現(xiàn) 24 小時(shí)的設(shè)備數(shù)據(jù)，查詢1440 次讀操作即可。

指標(biāo)	每分鐘1條	每小時(shí)一個(gè)文檔
文檔條數(shù)	52.5B	876 M
索引大小	6364GB	106 GB
_id index	1468GB	24.5 GB
{ts:1,icao:1}	4895GB	81.6 GB
文檔平均大小	92Bytes	758 Bytes
數(shù)據(jù)大小	4503GB	618 GB

分桶方式總結(jié)：

場(chǎng)景	痛點(diǎn)	設(shè)計(jì)模式方案及優(yōu)點(diǎn)
時(shí)序數(shù)據(jù)	數(shù)據(jù)點(diǎn)采集頻繁，數(shù)據(jù)量太多	利用文檔內(nèi)嵌數(shù)組，將一個(gè)時(shí)間段的數(shù)據(jù)聚合到一個(gè)文檔里
物聯(lián)網(wǎng)		大量減少文檔數(shù)量
智慧城市		大量減少索引占用空間
智慧交通

六、設(shè)計(jì)模式集錦

6.1、列轉(zhuǎn)行模式

問題: 大文檔，很多字段，很多索引







解決方案：列轉(zhuǎn)行

• 列轉(zhuǎn)行總結(jié)：

場(chǎng)景	痛點(diǎn)	設(shè)計(jì)模式方案及優(yōu)點(diǎn)
產(chǎn)品屬性 ‘color’, ‘size’, ‘dimensions’, …物聯(lián)網(wǎng)，多語言（多國家）屬性	文檔中有很多類似的字段，會(huì)用于組合查詢搜索，需要建很多索引	轉(zhuǎn)化為數(shù)組，一個(gè)索引解決所有查詢問題

6.2、版本字段

問題：模型靈活了，如何管理文檔不同版本？

修改前版本：

{ "_id": ObjectId("5de26f197edd62c5d388babb"), "name": "TJ", "company": "Tapdata"}新增手機(jī)號(hào)后版本：

{ "_id": ObjectId("5de26f197edd62c5d388babb"), "name": "TJ", "company": "Tapdata", "phone":"182XXXX8888"}解決方案：增加一個(gè)版本字段：

{ "_id": ObjectId("5de26f197edd62c5d388babb"), "name": "TJ", "company": "Tapdata", "phone":"182XXXX8888", "schema_version": 2.0}

• 版本字段總結(jié)：

場(chǎng)景	痛點(diǎn)	設(shè)計(jì)模式方案及優(yōu)點(diǎn)
任何有版本衍變的數(shù)據(jù)庫	文檔模型格式多，無法知道其合理性,升級(jí)時(shí)候需要更新太多文檔	增加一個(gè)版本號(hào)字段;快速過濾掉不需要升級(jí)的文檔;升級(jí)時(shí)候?qū)Σ煌姹镜奈臋n做不同的處理

6.3、近似計(jì)算

問題：統(tǒng)計(jì)網(wǎng)頁點(diǎn)擊流量

• 解決方案: 用近似計(jì)算

每隔10 (X)次寫一次，

• 近似計(jì)算總結(jié)：

場(chǎng)景	痛點(diǎn)	設(shè)計(jì)模式方案及優(yōu)點(diǎn)
網(wǎng)頁計(jì)數(shù)；各種結(jié)果不需要準(zhǔn)確的排名；	寫入太頻繁，消耗系統(tǒng)資源	間隔寫入，每隔10次或者100次，大量減少寫入需求

6.4、使用預(yù)聚合字段

問題: 業(yè)績(jī)排名，游戲排名，商品統(tǒng)計(jì)等精確統(tǒng)計(jì)

熱銷榜：某個(gè)商品今天賣了多少，這個(gè)星期賣了多少，這個(gè)月賣了多少？

電影排行：觀影者，場(chǎng)次統(tǒng)計(jì)

傳統(tǒng)解決方案：通過聚合計(jì)算

痛點(diǎn)：消耗資源多，聚合計(jì)算時(shí)間長(zhǎng)

• 解決方案: 用預(yù)聚合字段

在模型中新增預(yù)聚合字段，每次更新數(shù)據(jù)的時(shí)候同步更新統(tǒng)計(jì)值。

{ "product": "Bike", "sku": "abc123456", "quantitiy": 20394, "daily_sales": 40, "weekly_sales": 302, "monthly_sales": 1419}db.inventory.update({_id:123},{$inc: { quantity: -1, daily_sales: 1, weekly_sales: 1， monthly_sales: 1， } })

• 預(yù)聚合字段總結(jié)：

場(chǎng)景	痛點(diǎn)	設(shè)計(jì)模式方案及優(yōu)點(diǎn)
準(zhǔn)確排名,排行榜	統(tǒng)計(jì)計(jì)算耗時(shí)，計(jì)算時(shí)間長(zhǎng)	模型中直接增加統(tǒng)計(jì)字段;每次更新數(shù)據(jù)時(shí)候同時(shí)更新統(tǒng)計(jì)值

注：以上內(nèi)容參考《MongoDB 高手課》