戰(zhàn)：文檔模型、索引、執(zhí)行計(jì)劃與聚合管道)
很多人第一次接觸 MongoDB都是在項(xiàng)目里被字段老變、表結(jié)構(gòu)改不動(dòng)這件事逼過來的。我最開始也一樣拿著關(guān)系型數(shù)據(jù)庫的思維去用建了一堆看起來像表的集合寫出來的查詢?nèi)頀呙钄?shù)據(jù)量一上萬就開始卡。后來花了些時(shí)間把文檔模型、索引和執(zhí)行計(jì)劃這幾塊重新捋了一遍才發(fā)現(xiàn)這東西上手門檻確實(shí)低但想用得舒服完全是另一回事。這篇就按我自己帶人、自己踩坑的順序把 MongoDB 從裝好到能寫出一條像樣的查詢這條鏈路完整走一遍重點(diǎn)講清楚每個(gè)操作為什么這么寫而不是把官方文檔翻譯一遍。適合剛接手一個(gè) MongoDB 項(xiàng)目、或者準(zhǔn)備在下一個(gè)需求里引入它的朋友不管你是寫后端還是做數(shù)據(jù)分析跟著走一遍基本能跑通。1. 先把文檔模型這件事想明白別拿它當(dāng)關(guān)系庫用我在代碼評(píng)審里見過太多次這種情況一個(gè)集合里全是{_id, type, ...}這種結(jié)構(gòu)然后靠type字段去區(qū)分不同實(shí)體查的時(shí)候要寫一堆if type order。這就是典型的把關(guān)系型思維硬搬過來。文檔模型的核心價(jià)值在于把一次業(yè)務(wù)讀取需要的數(shù)據(jù)放在一起而不是把數(shù)據(jù)拆得越細(xì)越規(guī)范。1.1 一條文檔長什么樣和一行記錄差在哪里關(guān)系庫里一行記錄的所有字段都是扁平標(biāo)量復(fù)雜結(jié)構(gòu)必須拆表。MongoDB 的一條文檔本質(zhì)是一個(gè) BSON 對(duì)象字段值可以是字符串、數(shù)字、日期也可以直接是嵌套對(duì)象或者數(shù)組。舉個(gè)實(shí)際點(diǎn)的例子一個(gè)商品在關(guān)系庫里大概要拆成商品表、SKU 表、屬性表三張而在文檔模型里完全可以是一條{ _id: ObjectId(...), title: 某款機(jī)械鍵盤, price: 399, tags: [辦公, 無線, 靜音], specs: { switchType: 紅軸, layout: 87鍵, weight: 780 }, skus: [ { code: K87-W, color: 白, stock: 120 }, { code: K87-B, color: 黑, stock: 45 } ], createdAt: ISODate(2024-03-11T08:20:00Z) }讀一個(gè)商品詳情一條findOne就夠了不需要三次 join。這就是文檔模型最直接的收益讀路徑變短。代價(jià)是寫入時(shí)可能要更新整個(gè)文檔以及同一份數(shù)據(jù)在不同文檔里可能出現(xiàn)冗余。這個(gè)取舍后面第 6 節(jié)會(huì)展開講。這里有個(gè)細(xì)節(jié)容易被忽略_id默認(rèn)是ObjectId它不是一個(gè)隨機(jī)串結(jié)構(gòu)上包含 4 字節(jié)時(shí)間戳、5 字節(jié)隨機(jī)值、3 字節(jié)自增計(jì)數(shù)器。這意味著_id本身就帶創(chuàng)建時(shí)間信息你甚至可以用ObjectId(...).getTimestamp()反推文檔的創(chuàng)建時(shí)間。我在做數(shù)據(jù)排查的時(shí)候經(jīng)常用這招比額外加一個(gè)createdAt字段還快。1.2 什么場景適合什么場景別硬上不是所有項(xiàng)目都該上 MongoDB。我自己的判斷標(biāo)準(zhǔn)大概是這樣場景特征更適合的選擇原因字段結(jié)構(gòu)頻繁變化每個(gè)租戶字段還不一樣文檔模型不需要頻繁 DDL應(yīng)用層控制結(jié)構(gòu)讀多寫少一次讀取要拼好幾張表文檔模型內(nèi)嵌減少 join讀放大明顯強(qiáng)事務(wù)、多表強(qiáng)一致性轉(zhuǎn)賬類關(guān)系型跨文檔事務(wù)開銷大邏輯復(fù)雜大量多對(duì)多、需要靈活任意維度關(guān)聯(lián)查詢關(guān)系型文檔模型對(duì)多對(duì)多不友好日志、埋點(diǎn)、內(nèi)容、商品、配置文檔模型結(jié)構(gòu)松、寫入吞吐要求高報(bào)表類復(fù)雜聚合、窗口函數(shù)關(guān)系型或?qū)Ｓ梅治鰩炀酆瞎艿滥芰τ邢迯?fù)雜 SQL 更順手一句話總結(jié)讀模式相對(duì)固定、寫模式靈活多變的結(jié)構(gòu)適合文檔模型。如果你的查詢需求是任意維度隨便組合那關(guān)系庫的優(yōu)化器還是更靠譜。2. 環(huán)境從零跑起來安裝、啟動(dòng)到第一次握手裝 MongoDB 這件事本身不難難的是新手容易在幾個(gè)環(huán)節(jié)卡住服務(wù)沒起來、端口被占、認(rèn)證沒配好、連上了卻沒權(quán)限。我把這條鏈路拆細(xì)一點(diǎn)。2.1 本地起一個(gè)實(shí)例的幾種方式最省事的是容器方式一條命令搞定數(shù)據(jù)掛到本地目錄刪了容器數(shù)據(jù)還在docker run -d \ --name mongo-dev \ -p 27017:27017 \ -v /data/mongo:/data/db \ -e MONGO_INITDB_ROOT_USERNAMEadmin \ -e MONGO_INITDB_ROOT_PASSWORDdevpass123 \ mongo:7.0注意MONGO_INITDB_ROOT_USERNAME這個(gè)環(huán)境變量只有在數(shù)據(jù)目錄為空、首次初始化時(shí)才生效。我見過有人把數(shù)據(jù)目錄掛到已有數(shù)據(jù)的路徑然后發(fā)現(xiàn)環(huán)境變量里的賬號(hào)密碼根本沒建上連都連不進(jìn)去排查半天。要么用全新的空目錄要么手動(dòng)進(jìn)容器建用戶。如果用包管理器安裝Linux 上裝完之后默認(rèn)是mongod服務(wù)用systemctl start mongod啟動(dòng)配置文件一般在/etc/mongod.conf默認(rèn)只監(jiān)聽127.0.0.1。這個(gè)默認(rèn)值是有意為之的不要在沒配認(rèn)證的情況下把bindIp改成0.0.0.0我在一些內(nèi)網(wǎng)環(huán)境里見過裸奔的實(shí)例任何人都能連上去刪庫。配置文件里幾個(gè)值得改的點(diǎn)net: port: 27017 bindIp: 127.0.0.1 storage: dbPath: /var/lib/mongo wiredTiger: engineConfig: cacheSizeGB: 2cacheSizeGB默認(rèn)會(huì)吃掉可用內(nèi)存的一半減 1G。在容器里如果沒設(shè)內(nèi)存限制它可能按宿主機(jī)的內(nèi)存來算結(jié)果被 OOM kill。容器部署時(shí)建議顯式設(shè)置這個(gè)值一般給容器內(nèi)存的 50% 到 60%。2.2 連接串里的每個(gè)參數(shù)都值得看一遍連接串看著簡單但每個(gè)參數(shù)背后都有含義mongodb://admin:devpass123localhost:27017/appdb?authSourceadminmaxPoolSize50retryWritestrueauthSourceadmin認(rèn)證庫。用戶建在哪個(gè)庫這里就寫哪個(gè)。建在admin庫卻連業(yè)務(wù)庫時(shí)忘了加這個(gè)參數(shù)報(bào)的錯(cuò)是Authentication failed很容易誤判成密碼錯(cuò)。maxPoolSize連接池上限默認(rèn) 100。小服務(wù)給 20 到 50 就夠給太大會(huì)把數(shù)據(jù)庫連接數(shù)打滿。retryWritestrue遇到網(wǎng)絡(luò)抖動(dòng)或主節(jié)點(diǎn)切換時(shí)自動(dòng)重試一次。副本集環(huán)境建議開著單機(jī)開了也無害。要注意retryWrites不是萬能的它只對(duì)冪等或可重試的寫操作生效而且是在驅(qū)動(dòng)層重試如果第一次寫其實(shí)成功了只是響應(yīng)丟了重試可能造成重復(fù)寫入。所以業(yè)務(wù)上需要唯一性的字段索引該建還是要建。2.3 用 mongosh 還是圖形工具mongosh是官方現(xiàn)在的命令行客戶端語法上是 JS 環(huán)境可以寫循環(huán)、可以定義變量調(diào)試的時(shí)候非常順手。圖形工具比如一些可視化客戶端適合看數(shù)據(jù)和臨時(shí)改兩條記錄但復(fù)雜查詢還是命令行快。一個(gè)我常用的技巧是在 mongosh 里定義幾個(gè)快捷函數(shù)// 查看當(dāng)前庫所有集合及大小 db.getCollectionNames().forEach(function(c) { var s db.getCollection(c).stats(); print(c \t s.count \t (s.size / 1024 / 1024).toFixed(2) MB); });排查哪個(gè)集合在瘋漲的時(shí)候這行比翻監(jiān)控面板快多了。3. 把增刪改查寫成肌肉記憶操作符才是重點(diǎn)CRUD 誰都會(huì)寫但寫得好不好差別全在對(duì)操作符的理解上。我見過太多人把讀出來、在應(yīng)用里改、再整體寫回去當(dāng)成標(biāo)準(zhǔn)做法結(jié)果并發(fā)一上來就丟更新。3.1 插入單條、批量與順序的取舍db.orders.insertOne({ orderNo: A1001, amount: 199, status: paid }); db.orders.insertMany([ { orderNo: A1002, amount: 88, status: paid }, { orderNo: A1003, amount: 320, status: unpaid } ], { ordered: false });ordered: false這個(gè)參數(shù)很關(guān)鍵。默認(rèn)是有序插入一旦中間某條失敗比如唯一索引沖突后面的全部不執(zhí)行。設(shè)為false之后失敗的跳過成功的照常寫入返回值里會(huì)帶上失敗的索引列表。批量導(dǎo)入數(shù)據(jù)的場景基本都應(yīng)該關(guān)掉有序否則一條臟數(shù)據(jù)能讓整批任務(wù)中斷。但要注意ordered: false下驅(qū)動(dòng)可能會(huì)并發(fā)寫多個(gè)分片或節(jié)點(diǎn)失敗的那條不會(huì)自動(dòng)重試你的代碼需要自己處理返回值里的writeErrors。3.2 查詢條件、投影和游標(biāo)db.orders.find( { status: paid, amount: { $gte: 100 } }, { orderNo: 1, amount: 1, _id: 0 } ).sort({ amount: -1 }).limit(20);投影里_id: 0是為了省字節(jié)。數(shù)據(jù)量大、字段多的時(shí)候只取需要的字段能讓網(wǎng)絡(luò)傳輸量降一個(gè)數(shù)量級(jí)。我做過一個(gè)對(duì)比一個(gè)文檔平均 4KB只投影出 3 個(gè)字段之后只有 200 字節(jié)左右20 倍差距。游標(biāo)這塊有個(gè)新手常犯的問題遍歷大數(shù)據(jù)集時(shí)直接find()然后toArray()內(nèi)存直接爆。正確做法是用游標(biāo)迭代const cursor db.orders.find({ status: paid }).batchSize(500); while (cursor.hasNext()) { /* 逐條處理 */ }batchSize控制每次從服務(wù)端拉多少條默認(rèn) 101 條第一批發(fā)完后就按 16MB 限制取。對(duì)于導(dǎo)出類任務(wù)把它設(shè)成幾百到一千比較均衡。3.3 更新操作符才是核心這是我見過最多問題的地方。下面這種寫法在并發(fā)下必丟更新// 錯(cuò)誤示范讀-改-寫 const doc db.accounts.findOne({ _id: 1 }); db.accounts.updateOne({ _id: 1 }, { $set: { balance: doc.balance - 100 } });兩個(gè)人同時(shí)讀到balance 500各自減 100 寫回最后是 400 而不是 300。正確姿勢是用$inc讓數(shù)據(jù)庫做原子運(yùn)算db.accounts.updateOne( { _id: 1, balance: { $gte: 100 } }, { $inc: { balance: -100 }, $set: { updatedAt: new Date() } } );條件里帶上balance: { $gte: 100 }是樂觀鎖的思路余額不足時(shí)matchedCount為 0業(yè)務(wù)層就知道扣款失敗。這樣既保證了原子性又避免了超扣。幾個(gè)高頻操作符的語義要分清操作符作用注意點(diǎn)$set設(shè)置字段值字段不存在會(huì)創(chuàng)建$unset刪除字段值是占位符寫什么都行$inc數(shù)值增減字段必須存在或是數(shù)字否則報(bào)錯(cuò)$push數(shù)組末尾追加可配合$each批量加$addToSet數(shù)組去重追加元素多時(shí)性能下降明顯$pull按條件移除數(shù)組元素支持條件表達(dá)式$setOnInsert僅插入時(shí)設(shè)置必須配合upsert: trueupsert: true是個(gè)好幫手先查后插的兩步操作可以合并成一步db.users.updateOne( { openId: u_123 }, { $set: { nickname: 老王 }, $setOnInsert: { createdAt: new Date() } }, { upsert: true } );注意$set和$setOnInsert不能作用于同一個(gè)字段否則會(huì)報(bào)沖突。3.4 刪除要謹(jǐn)慎軟刪除更常見物理刪除deleteMany在線上環(huán)境我建議慎用尤其是沒有備份的情況下。大多數(shù)業(yè)務(wù)場景用軟刪除更穩(wěn)加一個(gè)deletedAt字段查詢時(shí)帶上deletedAt: null。如果確實(shí)要物理刪除先查一遍確認(rèn)范圍// 先看會(huì)刪掉多少條 db.logs.countDocuments({ createdAt: { $lt: new Date(2024-01-01) } }); // 確認(rèn)無誤再刪分批刪避免長鎖 db.logs.deleteMany({ createdAt: { $lt: new Date(2024-01-01) } });單次刪幾十萬條會(huì)長時(shí)間占用寫鎖更好的方式是分批每次刪 5000 條循環(huán)執(zhí)行中間 sleep 一小會(huì)。4. 索引和執(zhí)行計(jì)劃數(shù)據(jù)漲到百萬級(jí)之后的分水嶺前面那些操作在幾千條數(shù)據(jù)的時(shí)候都飛快任何寫法都能跑。等到集合上百萬差別就出現(xiàn)了有的查詢 5 毫秒有的一分半。分水嶺就是索引。4.1 復(fù)合索引的最左前綴原則db.orders.createIndex({ status: 1, createdAt: -1 });這條復(fù)合索引能支持的查詢是status單獨(dú)查、status createdAt組合查。但單獨(dú)用createdAt查走不了因?yàn)閟tatus在最左邊跳不過去。這就是最左前綴原則和關(guān)系庫一樣。字段順序怎么定我一般按 ESR 原則Equality等值在前Sort排序在中Range范圍在后。比如查已支付訂單、按時(shí)間倒序、金額大于 100db.orders.find({ status: paid, amount: { $gt: 100 } }).sort({ createdAt: -1 });理論上最理想的是{ status: 1, createdAt: -1, amount: 1 }。為什么把范圍條件放最后因?yàn)榉秶鷹l件一旦匹配后面的字段就無法再用索引做精確跳轉(zhuǎn)了。當(dāng)然實(shí)際場景里排序字段和范圍字段的順序還要結(jié)合數(shù)據(jù)分布測試不要迷信理論。4.2 用 explain 看它到底走了哪條路索引建完不代表用上了。驗(yàn)證方式是explaindb.orders.find({ status: paid }).sort({ createdAt: -1 }) .explain(executionStats);重點(diǎn)看幾個(gè)字段winningPlan.stageCOLLSCAN表示全表掃描IXSCAN表示走了索引FETCH表示還要回表取文檔。totalDocsExamined掃描文檔數(shù)。如果遠(yuǎn)大于返回條數(shù)索引效果很差。totalKeysExamined掃描索引鍵數(shù)。executionTimeMillis執(zhí)行耗時(shí)。一個(gè)健康的查詢totalDocsExamined應(yīng)該接近返回條數(shù)。如果看到nReturned: 20但totalDocsExamined: 200000說明索引方向不對(duì)或者查詢條件本身不具選擇性。4.3 幾個(gè)讓索引失效的典型寫法寫法問題改法{ name: /abc/ }前置通配無法走索引改成前綴匹配/^abc/或上全文索引{ age: { $ne: 30 } }不等條件選擇性差盡量用等值 范圍組合查詢字段做了運(yùn)算索引鍵無法參與匹配把運(yùn)算挪到應(yīng)用層或建表達(dá)式索引數(shù)組字段上建普通索引后按元素?cái)?shù)查索引覆蓋不到需要$size的場景考慮冗余計(jì)數(shù)字段索引字段類型混用字符串和數(shù)字類型不匹配不命中統(tǒng)一寫入類型必要時(shí)加校驗(yàn)還有一個(gè)坑是索引建太多。每加一個(gè)索引寫入時(shí)就要多維護(hù)一棵 B 樹。我見過一個(gè)集合上建了十幾個(gè)索引寫入 QPS 直接腰斬。原則是先看慢查詢?nèi)罩菊页稣嬲哳l的查詢模式再針對(duì)性建索引定期用$indexStats檢查索引使用次數(shù)長期為 0 的果斷刪掉。db.orders.aggregate([{ $indexStats: {} }]);這個(gè)命令會(huì)返回每個(gè)索引的accesses.ops一目了然。5. 聚合管道把統(tǒng)計(jì)邏輯從應(yīng)用層搬回來以前我特別愛在應(yīng)用層做統(tǒng)計(jì)查出一堆文檔然后 for 循環(huán)累加。后來發(fā)現(xiàn)數(shù)據(jù)量一上來網(wǎng)絡(luò)傳輸和內(nèi)存占用都受不了而且代碼又長又難維護(hù)。聚合管道就是把這類邏輯下推到數(shù)據(jù)庫側(cè)。5.1 管道的執(zhí)行順序決定了性能聚合管道是一串 stage 依次執(zhí)行每個(gè) stage 的輸出是下一個(gè)的輸入。順序至關(guān)重要$match和$limit一定要盡早db.orders.aggregate([ { $match: { status: paid, createdAt: { $gte: ISODate(2024-01-01) } } }, { $group: { _id: $userId, total: { $sum: $amount }, cnt: { $sum: 1 } } }, { $match: { total: { $gte: 1000 } } }, { $sort: { total: -1 } }, { $limit: 50 } ]);如果把$match放在$group后面前面就要對(duì)全量數(shù)據(jù)處理一遍可能慢幾十倍。能過濾的先過濾能少的先少這是寫聚合管道的第一原則。另外第一個(gè)$match如果命中了索引整個(gè)管道都會(huì)受益。所以聚合查詢的入口過濾條件要和索引對(duì)齊寫完記得用explain看一下。5.2 分組、展開和關(guān)聯(lián)$group里最常用的是$sum、$avg、$max、$min還可以用$push把分組內(nèi)的值收集成數(shù)組{ $group: { _id: $category, prices: { $push: $price } } }$unwind用來把數(shù)組拆成多條處理一條訂單多個(gè)商品這種結(jié)構(gòu)特別方便db.orders.aggregate([ { $unwind: $items }, { $group: { _id: $items.sku, sold: { $sum: $items.qty } } }, { $sort: { sold: -1 } } ]);$lookup相當(dāng)于左連接但它在大數(shù)據(jù)量下是性能殺手因?yàn)槊總€(gè)輸入文檔都要去目標(biāo)集合查一次。如果目標(biāo)集合的關(guān)聯(lián)字段上有索引還好沒有索引就是災(zāi)難。我的建議是能靠內(nèi)嵌解決的關(guān)聯(lián)就別用$lookup。5.3 聚合的內(nèi)存限制和落盤聚合管道默認(rèn)每個(gè) stage 最多用 100MB 內(nèi)存超了直接報(bào)錯(cuò)。大數(shù)據(jù)量分組要開啟落盤db.orders.aggregate(pipeline, { allowDiskUse: true });開啟之后會(huì)寫臨時(shí)文件速度慢一些但不會(huì)失敗。生產(chǎn)環(huán)境跑報(bào)表類聚合這個(gè)參數(shù)基本是必開的。還有一點(diǎn)$group的_id如果基數(shù)特別大比如按用戶 ID 分組幾千萬用戶內(nèi)存和臨時(shí)文件都會(huì)吃緊。這種場景我一般會(huì)先按時(shí)間窗口切分分批聚合再合并結(jié)果比一次性硬跑靠譜。6. 數(shù)據(jù)建模和幾個(gè)新手最容易翻車的地方前面都是操作層面的事真正決定項(xiàng)目后期好不好維護(hù)的是數(shù)據(jù)建模。這塊沒有標(biāo)準(zhǔn)答案但有些坑是共通的。6.1 內(nèi)嵌還是引用看讀寫比例這是文檔建模最核心的決策。判斷依據(jù)其實(shí)就一句話這份子數(shù)據(jù)是不是總跟著主數(shù)據(jù)一起讀而且數(shù)量有上限。適合內(nèi)嵌的情況訂單里的商品明細(xì)、文章里的標(biāo)簽、用戶設(shè)置里的偏好項(xiàng)。這些數(shù)據(jù)量有限幾十條以內(nèi)且讀主數(shù)據(jù)時(shí)基本都要一起讀。適合引用的情況用戶和訂單、商品和評(píng)論。這類數(shù)據(jù)會(huì)無限增長或者需要獨(dú)立查詢內(nèi)嵌進(jìn)去會(huì)導(dǎo)致文檔不斷變大最終撞上 16MB 的單文檔上限。一個(gè)真實(shí)踩過的坑某項(xiàng)目把用戶的所有操作日志內(nèi)嵌到用戶文檔里一開始沒問題跑了一年之后單個(gè)文檔漲到十幾 MB更新開始報(bào)錯(cuò)查詢也越來越慢。后來拆成獨(dú)立集合按userId索引才解決。數(shù)組字段一定要問自己這個(gè)數(shù)組會(huì)不會(huì)無限增長。會(huì)就必須拆出去。6.2 無模式不等于不用設(shè)計(jì)MongoDB 不強(qiáng)制 schema不代表可以隨便寫。同一個(gè)集合里字段名一會(huì)兒userId一會(huì)兒user_id一會(huì)兒字符串一會(huì)兒數(shù)字后期查詢能把你逼瘋。我的做法是在應(yīng)用層用統(tǒng)一的模型定義很多語言的驅(qū)動(dòng)都支持 schema 校驗(yàn)同時(shí)在集合上開 validatordb.createCollection(orders, { validator: { $jsonSchema: { bsonType: object, required: [orderNo, amount, status], properties: { orderNo: { bsonType: string }, amount: { bsonType: decimal }, status: { enum: [paid, unpaid, refunded] } } } }, validationLevel: moderate });validationLevel: moderate表示已有文檔不校驗(yàn)、新寫入才校驗(yàn)避免上線時(shí)被歷史數(shù)據(jù)卡住。這個(gè)約束看起來麻煩但能擋掉大量低級(jí)錯(cuò)誤。金額字段我特別建議用Decimal128而不是 double浮點(diǎn)數(shù)累加會(huì)出現(xiàn)0.1 0.2 0.30000000000000004這種問題財(cái)務(wù)場景絕對(duì)不能接受。6.3 幾個(gè)高頻坑的快速清單坑表現(xiàn)處理方式單文檔超 16MB寫入報(bào)錯(cuò)object to insert too large拆集合或改用 GridFS 存大文件正則沒加錨點(diǎn)查詢越來越慢前綴匹配加^或建文本索引時(shí)間字段存字符串范圍查詢和排序都不準(zhǔn)統(tǒng)一存Date類型skip翻大頁越翻越慢改成基于上一頁最后一條的_id游標(biāo)翻頁數(shù)組元素?zé)o上限文檔膨脹拆子集合主文檔存摘要唯一索引在數(shù)組字段上語義和預(yù)期不符想清楚是全數(shù)組唯一還是元素唯一skip翻頁這個(gè)坑值得單獨(dú)說一下。skip(100000).limit(20)并不是直接跳到第 10 萬條而是先把前面 10 萬條掃一遍再丟掉越往后越慢。正確做法是記住上一頁最后一條的排序字段值下一頁用 lastValue來查db.articles.find({ createdAt: { $lt: lastCreatedAt } }) .sort({ createdAt: -1 }).limit(20);這種方式在任何頁數(shù)下耗時(shí)都穩(wěn)定前提是排序字段上有索引。6.4 備份和變更這兩件事別等出事再想最后提兩個(gè)運(yùn)維層面的事。第一是備份mongodump簡單夠用但要注意它是邏輯備份大庫導(dǎo)出很慢而且導(dǎo)出期間的數(shù)據(jù)一致性要靠--oplog保證。數(shù)據(jù)量大的話快照方式更穩(wěn)。第二是索引和字段的變更。給一個(gè)千萬級(jí)集合加索引如果沒有指定后臺(tái)構(gòu)建會(huì)阻塞寫入。新版本雖然默認(rèn)行為已經(jīng)優(yōu)化但上線前還是應(yīng)該在預(yù)發(fā)環(huán)境用同等數(shù)據(jù)量壓一遍記錄耗時(shí)。我吃過一次虧預(yù)發(fā)只有十萬條數(shù)據(jù)加索引兩秒完成生產(chǎn)一千多萬條加了四十多分鐘期間接口大面積超時(shí)。自此之后任何涉及大集合的變更我都會(huì)先拿生產(chǎn)數(shù)據(jù)的抽樣副本跑一遍估算耗時(shí)再挑低峰期執(zhí)行。寫了這么多其實(shí) MongoDB 入門真正的門檻不在語法而在兩個(gè)思維轉(zhuǎn)變一是從表結(jié)構(gòu)先行轉(zhuǎn)到讀取模式先行建模時(shí)先想清楚數(shù)據(jù)怎么被讀二是從應(yīng)用層拼裝轉(zhuǎn)到數(shù)據(jù)庫側(cè)完成索引、聚合、投影這些能力用好了很多邏輯根本不用搬到代碼里。我自己在實(shí)際項(xiàng)目里的體會(huì)是但凡一個(gè)查詢開始變慢第一反應(yīng)應(yīng)該是去看explain而不是急著加緩存。緩存能蓋住問題但索引沒建對(duì)緩存一失效問題還是原樣回來。 MongoDB 實(shí)戰(zhàn)：文檔模型、索引、執(zhí)行計(jì)劃與聚合管道
很多人第一次接觸 MongoDB都是在項(xiàng)目里被字段老變、表結(jié)構(gòu)改不動(dòng)這件事逼過來的。我最開始也一樣拿著關(guān)系型數(shù)據(jù)庫的思維去用建了一堆看起來像表的集合寫出來的查詢?nèi)頀呙钄?shù)據(jù)量一上萬就開始卡。后來花了些時(shí)間把文檔模型、索引和執(zhí)行計(jì)劃這幾塊重新捋了一遍才發(fā)現(xiàn)這東西上手門檻確實(shí)低但想用得舒服完全是另一回事。這篇就按我自己帶人、自己踩坑的順序把 MongoDB 從裝好到能寫出一條像樣的查詢這條鏈路完整走一遍重點(diǎn)講清楚每個(gè)操作為什么這么寫而不是把官方文檔翻譯一遍。適合剛接手一個(gè) MongoDB 項(xiàng)目、或者準(zhǔn)備在下一個(gè)需求里引入它的朋友不管你是寫后端還是做數(shù)據(jù)分析跟著走一遍基本能跑通。1. 先把文檔模型這件事想明白別拿它當(dāng)關(guān)系庫用我在代碼評(píng)審里見過太多次這種情況一個(gè)集合里全是{_id, type, ...}這種結(jié)構(gòu)然后靠type字段去區(qū)分不同實(shí)體查的時(shí)候要寫一堆if type order。這就是典型的把關(guān)系型思維硬搬過來。文檔模型的核心價(jià)值在于把一次業(yè)務(wù)讀取需要的數(shù)據(jù)放在一起而不是把數(shù)據(jù)拆得越細(xì)越規(guī)范。1.1 一條文檔長什么樣和一行記錄差在哪里關(guān)系庫里一行記錄的所有字段都是扁平標(biāo)量復(fù)雜結(jié)構(gòu)必須拆表。MongoDB 的一條文檔本質(zhì)是一個(gè) BSON 對(duì)象字段值可以是字符串、數(shù)字、日期也可以直接是嵌套對(duì)象或者數(shù)組。舉個(gè)實(shí)際點(diǎn)的例子一個(gè)商品在關(guān)系庫里大概要拆成商品表、SKU 表、屬性表三張而在文檔模型里完全可以是一條{ _id: ObjectId(...), title: 某款機(jī)械鍵盤, price: 399, tags: [辦公, 無線, 靜音], specs: { switchType: 紅軸, layout: 87鍵, weight: 780 }, skus: [ { code: K87-W, color: 白, stock: 120 }, { code: K87-B, color: 黑, stock: 45 } ], createdAt: ISODate(2024-03-11T08:20:00Z) }讀一個(gè)商品詳情一條findOne就夠了不需要三次 join。這就是文檔模型最直接的收益讀路徑變短。代價(jià)是寫入時(shí)可能要更新整個(gè)文檔以及同一份數(shù)據(jù)在不同文檔里可能出現(xiàn)冗余。這個(gè)取舍后面第 6 節(jié)會(huì)展開講。這里有個(gè)細(xì)節(jié)容易被忽略_id默認(rèn)是ObjectId它不是一個(gè)隨機(jī)串結(jié)構(gòu)上包含 4 字節(jié)時(shí)間戳、5 字節(jié)隨機(jī)值、3 字節(jié)自增計(jì)數(shù)器。這意味著_id本身就帶創(chuàng)建時(shí)間信息你甚至可以用ObjectId(...).getTimestamp()反推文檔的創(chuàng)建時(shí)間。我在做數(shù)據(jù)排查的時(shí)候經(jīng)常用這招比額外加一個(gè)createdAt字段還快。1.2 什么場景適合什么場景別硬上不是所有項(xiàng)目都該上 MongoDB。我自己的判斷標(biāo)準(zhǔn)大概是這樣場景特征更適合的選擇原因字段結(jié)構(gòu)頻繁變化每個(gè)租戶字段還不一樣文檔模型不需要頻繁 DDL應(yīng)用層控制結(jié)構(gòu)讀多寫少一次讀取要拼好幾張表文檔模型內(nèi)嵌減少 join讀放大明顯強(qiáng)事務(wù)、多表強(qiáng)一致性轉(zhuǎn)賬類關(guān)系型跨文檔事務(wù)開銷大邏輯復(fù)雜大量多對(duì)多、需要靈活任意維度關(guān)聯(lián)查詢關(guān)系型文檔模型對(duì)多對(duì)多不友好日志、埋點(diǎn)、內(nèi)容、商品、配置文檔模型結(jié)構(gòu)松、寫入吞吐要求高報(bào)表類復(fù)雜聚合、窗口函數(shù)關(guān)系型或?qū)Ｓ梅治鰩炀酆瞎艿滥芰τ邢迯?fù)雜 SQL 更順手一句話總結(jié)讀模式相對(duì)固定、寫模式靈活多變的結(jié)構(gòu)適合文檔模型。如果你的查詢需求是任意維度隨便組合那關(guān)系庫的優(yōu)化器還是更靠譜。2. 環(huán)境從零跑起來安裝、啟動(dòng)到第一次握手裝 MongoDB 這件事本身不難難的是新手容易在幾個(gè)環(huán)節(jié)卡住服務(wù)沒起來、端口被占、認(rèn)證沒配好、連上了卻沒權(quán)限。我把這條鏈路拆細(xì)一點(diǎn)。2.1 本地起一個(gè)實(shí)例的幾種方式最省事的是容器方式一條命令搞定數(shù)據(jù)掛到本地目錄刪了容器數(shù)據(jù)還在docker run -d \ --name mongo-dev \ -p 27017:27017 \ -v /data/mongo:/data/db \ -e MONGO_INITDB_ROOT_USERNAMEadmin \ -e MONGO_INITDB_ROOT_PASSWORDdevpass123 \ mongo:7.0注意MONGO_INITDB_ROOT_USERNAME這個(gè)環(huán)境變量只有在數(shù)據(jù)目錄為空、首次初始化時(shí)才生效。我見過有人把數(shù)據(jù)目錄掛到已有數(shù)據(jù)的路徑然后發(fā)現(xiàn)環(huán)境變量里的賬號(hào)密碼根本沒建上連都連不進(jìn)去排查半天。要么用全新的空目錄要么手動(dòng)進(jìn)容器建用戶。如果用包管理器安裝Linux 上裝完之后默認(rèn)是mongod服務(wù)用systemctl start mongod啟動(dòng)配置文件一般在/etc/mongod.conf默認(rèn)只監(jiān)聽127.0.0.1。這個(gè)默認(rèn)值是有意為之的不要在沒配認(rèn)證的情況下把bindIp改成0.0.0.0我在一些內(nèi)網(wǎng)環(huán)境里見過裸奔的實(shí)例任何人都能連上去刪庫。配置文件里幾個(gè)值得改的點(diǎn)net: port: 27017 bindIp: 127.0.0.1 storage: dbPath: /var/lib/mongo wiredTiger: engineConfig: cacheSizeGB: 2cacheSizeGB默認(rèn)會(huì)吃掉可用內(nèi)存的一半減 1G。在容器里如果沒設(shè)內(nèi)存限制它可能按宿主機(jī)的內(nèi)存來算結(jié)果被 OOM kill。容器部署時(shí)建議顯式設(shè)置這個(gè)值一般給容器內(nèi)存的 50% 到 60%。2.2 連接串里的每個(gè)參數(shù)都值得看一遍連接串看著簡單但每個(gè)參數(shù)背后都有含義mongodb://admin:devpass123localhost:27017/appdb?authSourceadminmaxPoolSize50retryWritestrueauthSourceadmin認(rèn)證庫。用戶建在哪個(gè)庫這里就寫哪個(gè)。建在admin庫卻連業(yè)務(wù)庫時(shí)忘了加這個(gè)參數(shù)報(bào)的錯(cuò)是Authentication failed很容易誤判成密碼錯(cuò)。maxPoolSize連接池上限默認(rèn) 100。小服務(wù)給 20 到 50 就夠給太大會(huì)把數(shù)據(jù)庫連接數(shù)打滿。retryWritestrue遇到網(wǎng)絡(luò)抖動(dòng)或主節(jié)點(diǎn)切換時(shí)自動(dòng)重試一次。副本集環(huán)境建議開著單機(jī)開了也無害。要注意retryWrites不是萬能的它只對(duì)冪等或可重試的寫操作生效而且是在驅(qū)動(dòng)層重試如果第一次寫其實(shí)成功了只是響應(yīng)丟了重試可能造成重復(fù)寫入。所以業(yè)務(wù)上需要唯一性的字段索引該建還是要建。2.3 用 mongosh 還是圖形工具mongosh是官方現(xiàn)在的命令行客戶端語法上是 JS 環(huán)境可以寫循環(huán)、可以定義變量調(diào)試的時(shí)候非常順手。圖形工具比如一些可視化客戶端適合看數(shù)據(jù)和臨時(shí)改兩條記錄但復(fù)雜查詢還是命令行快。一個(gè)我常用的技巧是在 mongosh 里定義幾個(gè)快捷函數(shù)// 查看當(dāng)前庫所有集合及大小 db.getCollectionNames().forEach(function(c) { var s db.getCollection(c).stats(); print(c \t s.count \t (s.size / 1024 / 1024).toFixed(2) MB); });排查哪個(gè)集合在瘋漲的時(shí)候這行比翻監(jiān)控面板快多了。3. 把增刪改查寫成肌肉記憶操作符才是重點(diǎn)CRUD 誰都會(huì)寫但寫得好不好差別全在對(duì)操作符的理解上。我見過太多人把讀出來、在應(yīng)用里改、再整體寫回去當(dāng)成標(biāo)準(zhǔn)做法結(jié)果并發(fā)一上來就丟更新。3.1 插入單條、批量與順序的取舍db.orders.insertOne({ orderNo: A1001, amount: 199, status: paid }); db.orders.insertMany([ { orderNo: A1002, amount: 88, status: paid }, { orderNo: A1003, amount: 320, status: unpaid } ], { ordered: false });ordered: false這個(gè)參數(shù)很關(guān)鍵。默認(rèn)是有序插入一旦中間某條失敗比如唯一索引沖突后面的全部不執(zhí)行。設(shè)為false之后失敗的跳過成功的照常寫入返回值里會(huì)帶上失敗的索引列表。批量導(dǎo)入數(shù)據(jù)的場景基本都應(yīng)該關(guān)掉有序否則一條臟數(shù)據(jù)能讓整批任務(wù)中斷。但要注意ordered: false下驅(qū)動(dòng)可能會(huì)并發(fā)寫多個(gè)分片或節(jié)點(diǎn)失敗的那條不會(huì)自動(dòng)重試你的代碼需要自己處理返回值里的writeErrors。3.2 查詢條件、投影和游標(biāo)db.orders.find( { status: paid, amount: { $gte: 100 } }, { orderNo: 1, amount: 1, _id: 0 } ).sort({ amount: -1 }).limit(20);投影里_id: 0是為了省字節(jié)。數(shù)據(jù)量大、字段多的時(shí)候只取需要的字段能讓網(wǎng)絡(luò)傳輸量降一個(gè)數(shù)量級(jí)。我做過一個(gè)對(duì)比一個(gè)文檔平均 4KB只投影出 3 個(gè)字段之后只有 200 字節(jié)左右20 倍差距。游標(biāo)這塊有個(gè)新手常犯的問題遍歷大數(shù)據(jù)集時(shí)直接find()然后toArray()內(nèi)存直接爆。正確做法是用游標(biāo)迭代const cursor db.orders.find({ status: paid }).batchSize(500); while (cursor.hasNext()) { /* 逐條處理 */ }batchSize控制每次從服務(wù)端拉多少條默認(rèn) 101 條第一批發(fā)完后就按 16MB 限制取。對(duì)于導(dǎo)出類任務(wù)把它設(shè)成幾百到一千比較均衡。3.3 更新操作符才是核心這是我見過最多問題的地方。下面這種寫法在并發(fā)下必丟更新// 錯(cuò)誤示范讀-改-寫 const doc db.accounts.findOne({ _id: 1 }); db.accounts.updateOne({ _id: 1 }, { $set: { balance: doc.balance - 100 } });兩個(gè)人同時(shí)讀到balance 500各自減 100 寫回最后是 400 而不是 300。正確姿勢是用$inc讓數(shù)據(jù)庫做原子運(yùn)算db.accounts.updateOne( { _id: 1, balance: { $gte: 100 } }, { $inc: { balance: -100 }, $set: { updatedAt: new Date() } } );條件里帶上balance: { $gte: 100 }是樂觀鎖的思路余額不足時(shí)matchedCount為 0業(yè)務(wù)層就知道扣款失敗。這樣既保證了原子性又避免了超扣。幾個(gè)高頻操作符的語義要分清操作符作用注意點(diǎn)$set設(shè)置字段值字段不存在會(huì)創(chuàng)建$unset刪除字段值是占位符寫什么都行$inc數(shù)值增減字段必須存在或是數(shù)字否則報(bào)錯(cuò)$push數(shù)組末尾追加可配合$each批量加$addToSet數(shù)組去重追加元素多時(shí)性能下降明顯$pull按條件移除數(shù)組元素支持條件表達(dá)式$setOnInsert僅插入時(shí)設(shè)置必須配合upsert: trueupsert: true是個(gè)好幫手先查后插的兩步操作可以合并成一步db.users.updateOne( { openId: u_123 }, { $set: { nickname: 老王 }, $setOnInsert: { createdAt: new Date() } }, { upsert: true } );注意$set和$setOnInsert不能作用于同一個(gè)字段否則會(huì)報(bào)沖突。3.4 刪除要謹(jǐn)慎軟刪除更常見物理刪除deleteMany在線上環(huán)境我建議慎用尤其是沒有備份的情況下。大多數(shù)業(yè)務(wù)場景用軟刪除更穩(wěn)加一個(gè)deletedAt字段查詢時(shí)帶上deletedAt: null。如果確實(shí)要物理刪除先查一遍確認(rèn)范圍// 先看會(huì)刪掉多少條 db.logs.countDocuments({ createdAt: { $lt: new Date(2024-01-01) } }); // 確認(rèn)無誤再刪分批刪避免長鎖 db.logs.deleteMany({ createdAt: { $lt: new Date(2024-01-01) } });單次刪幾十萬條會(huì)長時(shí)間占用寫鎖更好的方式是分批每次刪 5000 條循環(huán)執(zhí)行中間 sleep 一小會(huì)。4. 索引和執(zhí)行計(jì)劃數(shù)據(jù)漲到百萬級(jí)之后的分水嶺前面那些操作在幾千條數(shù)據(jù)的時(shí)候都飛快任何寫法都能跑。等到集合上百萬差別就出現(xiàn)了有的查詢 5 毫秒有的一分半。分水嶺就是索引。4.1 復(fù)合索引的最左前綴原則db.orders.createIndex({ status: 1, createdAt: -1 });這條復(fù)合索引能支持的查詢是status單獨(dú)查、status createdAt組合查。但單獨(dú)用createdAt查走不了因?yàn)閟tatus在最左邊跳不過去。這就是最左前綴原則和關(guān)系庫一樣。字段順序怎么定我一般按 ESR 原則Equality等值在前Sort排序在中Range范圍在后。比如查已支付訂單、按時(shí)間倒序、金額大于 100db.orders.find({ status: paid, amount: { $gt: 100 } }).sort({ createdAt: -1 });理論上最理想的是{ status: 1, createdAt: -1, amount: 1 }。為什么把范圍條件放最后因?yàn)榉秶鷹l件一旦匹配后面的字段就無法再用索引做精確跳轉(zhuǎn)了。當(dāng)然實(shí)際場景里排序字段和范圍字段的順序還要結(jié)合數(shù)據(jù)分布測試不要迷信理論。4.2 用 explain 看它到底走了哪條路索引建完不代表用上了。驗(yàn)證方式是explaindb.orders.find({ status: paid }).sort({ createdAt: -1 }) .explain(executionStats);重點(diǎn)看幾個(gè)字段winningPlan.stageCOLLSCAN表示全表掃描IXSCAN表示走了索引FETCH表示還要回表取文檔。totalDocsExamined掃描文檔數(shù)。如果遠(yuǎn)大于返回條數(shù)索引效果很差。totalKeysExamined掃描索引鍵數(shù)。executionTimeMillis執(zhí)行耗時(shí)。一個(gè)健康的查詢totalDocsExamined應(yīng)該接近返回條數(shù)。如果看到nReturned: 20但totalDocsExamined: 200000說明索引方向不對(duì)或者查詢條件本身不具選擇性。4.3 幾個(gè)讓索引失效的典型寫法寫法問題改法{ name: /abc/ }前置通配無法走索引改成前綴匹配/^abc/或上全文索引{ age: { $ne: 30 } }不等條件選擇性差盡量用等值 范圍組合查詢字段做了運(yùn)算索引鍵無法參與匹配把運(yùn)算挪到應(yīng)用層或建表達(dá)式索引數(shù)組字段上建普通索引后按元素?cái)?shù)查索引覆蓋不到需要$size的場景考慮冗余計(jì)數(shù)字段索引字段類型混用字符串和數(shù)字類型不匹配不命中統(tǒng)一寫入類型必要時(shí)加校驗(yàn)還有一個(gè)坑是索引建太多。每加一個(gè)索引寫入時(shí)就要多維護(hù)一棵 B 樹。我見過一個(gè)集合上建了十幾個(gè)索引寫入 QPS 直接腰斬。原則是先看慢查詢?nèi)罩菊页稣嬲哳l的查詢模式再針對(duì)性建索引定期用$indexStats檢查索引使用次數(shù)長期為 0 的果斷刪掉。db.orders.aggregate([{ $indexStats: {} }]);這個(gè)命令會(huì)返回每個(gè)索引的accesses.ops一目了然。5. 聚合管道把統(tǒng)計(jì)邏輯從應(yīng)用層搬回來以前我特別愛在應(yīng)用層做統(tǒng)計(jì)查出一堆文檔然后 for 循環(huán)累加。后來發(fā)現(xiàn)數(shù)據(jù)量一上來網(wǎng)絡(luò)傳輸和內(nèi)存占用都受不了而且代碼又長又難維護(hù)。聚合管道就是把這類邏輯下推到數(shù)據(jù)庫側(cè)。5.1 管道的執(zhí)行順序決定了性能聚合管道是一串 stage 依次執(zhí)行每個(gè) stage 的輸出是下一個(gè)的輸入。順序至關(guān)重要$match和$limit一定要盡早db.orders.aggregate([ { $match: { status: paid, createdAt: { $gte: ISODate(2024-01-01) } } }, { $group: { _id: $userId, total: { $sum: $amount }, cnt: { $sum: 1 } } }, { $match: { total: { $gte: 1000 } } }, { $sort: { total: -1 } }, { $limit: 50 } ]);如果把$match放在$group后面前面就要對(duì)全量數(shù)據(jù)處理一遍可能慢幾十倍。能過濾的先過濾能少的先少這是寫聚合管道的第一原則。另外第一個(gè)$match如果命中了索引整個(gè)管道都會(huì)受益。所以聚合查詢的入口過濾條件要和索引對(duì)齊寫完記得用explain看一下。5.2 分組、展開和關(guān)聯(lián)$group里最常用的是$sum、$avg、$max、$min還可以用$push把分組內(nèi)的值收集成數(shù)組{ $group: { _id: $category, prices: { $push: $price } } }$unwind用來把數(shù)組拆成多條處理一條訂單多個(gè)商品這種結(jié)構(gòu)特別方便db.orders.aggregate([ { $unwind: $items }, { $group: { _id: $items.sku, sold: { $sum: $items.qty } } }, { $sort: { sold: -1 } } ]);$lookup相當(dāng)于左連接但它在大數(shù)據(jù)量下是性能殺手因?yàn)槊總€(gè)輸入文檔都要去目標(biāo)集合查一次。如果目標(biāo)集合的關(guān)聯(lián)字段上有索引還好沒有索引就是災(zāi)難。我的建議是能靠內(nèi)嵌解決的關(guān)聯(lián)就別用$lookup。5.3 聚合的內(nèi)存限制和落盤聚合管道默認(rèn)每個(gè) stage 最多用 100MB 內(nèi)存超了直接報(bào)錯(cuò)。大數(shù)據(jù)量分組要開啟落盤db.orders.aggregate(pipeline, { allowDiskUse: true });開啟之后會(huì)寫臨時(shí)文件速度慢一些但不會(huì)失敗。生產(chǎn)環(huán)境跑報(bào)表類聚合這個(gè)參數(shù)基本是必開的。還有一點(diǎn)$group的_id如果基數(shù)特別大比如按用戶 ID 分組幾千萬用戶內(nèi)存和臨時(shí)文件都會(huì)吃緊。這種場景我一般會(huì)先按時(shí)間窗口切分分批聚合再合并結(jié)果比一次性硬跑靠譜。6. 數(shù)據(jù)建模和幾個(gè)新手最容易翻車的地方前面都是操作層面的事真正決定項(xiàng)目后期好不好維護(hù)的是數(shù)據(jù)建模。這塊沒有標(biāo)準(zhǔn)答案但有些坑是共通的。6.1 內(nèi)嵌還是引用看讀寫比例這是文檔建模最核心的決策。判斷依據(jù)其實(shí)就一句話這份子數(shù)據(jù)是不是總跟著主數(shù)據(jù)一起讀而且數(shù)量有上限。適合內(nèi)嵌的情況訂單里的商品明細(xì)、文章里的標(biāo)簽、用戶設(shè)置里的偏好項(xiàng)。這些數(shù)據(jù)量有限幾十條以內(nèi)且讀主數(shù)據(jù)時(shí)基本都要一起讀。適合引用的情況用戶和訂單、商品和評(píng)論。這類數(shù)據(jù)會(huì)無限增長或者需要獨(dú)立查詢內(nèi)嵌進(jìn)去會(huì)導(dǎo)致文檔不斷變大最終撞上 16MB 的單文檔上限。一個(gè)真實(shí)踩過的坑某項(xiàng)目把用戶的所有操作日志內(nèi)嵌到用戶文檔里一開始沒問題跑了一年之后單個(gè)文檔漲到十幾 MB更新開始報(bào)錯(cuò)查詢也越來越慢。后來拆成獨(dú)立集合按userId索引才解決。數(shù)組字段一定要問自己這個(gè)數(shù)組會(huì)不會(huì)無限增長。會(huì)就必須拆出去。6.2 無模式不等于不用設(shè)計(jì)MongoDB 不強(qiáng)制 schema不代表可以隨便寫。同一個(gè)集合里字段名一會(huì)兒userId一會(huì)兒user_id一會(huì)兒字符串一會(huì)兒數(shù)字后期查詢能把你逼瘋。我的做法是在應(yīng)用層用統(tǒng)一的模型定義很多語言的驅(qū)動(dòng)都支持 schema 校驗(yàn)同時(shí)在集合上開 validatordb.createCollection(orders, { validator: { $jsonSchema: { bsonType: object, required: [orderNo, amount, status], properties: { orderNo: { bsonType: string }, amount: { bsonType: decimal }, status: { enum: [paid, unpaid, refunded] } } } }, validationLevel: moderate });validationLevel: moderate表示已有文檔不校驗(yàn)、新寫入才校驗(yàn)避免上線時(shí)被歷史數(shù)據(jù)卡住。這個(gè)約束看起來麻煩但能擋掉大量低級(jí)錯(cuò)誤。金額字段我特別建議用Decimal128而不是 double浮點(diǎn)數(shù)累加會(huì)出現(xiàn)0.1 0.2 0.30000000000000004這種問題財(cái)務(wù)場景絕對(duì)不能接受。6.3 幾個(gè)高頻坑的快速清單坑表現(xiàn)處理方式單文檔超 16MB寫入報(bào)錯(cuò)object to insert too large拆集合或改用 GridFS 存大文件正則沒加錨點(diǎn)查詢越來越慢前綴匹配加^或建文本索引時(shí)間字段存字符串范圍查詢和排序都不準(zhǔn)統(tǒng)一存Date類型skip翻大頁越翻越慢改成基于上一頁最后一條的_id游標(biāo)翻頁數(shù)組元素?zé)o上限文檔膨脹拆子集合主文檔存摘要唯一索引在數(shù)組字段上語義和預(yù)期不符想清楚是全數(shù)組唯一還是元素唯一skip翻頁這個(gè)坑值得單獨(dú)說一下。skip(100000).limit(20)并不是直接跳到第 10 萬條而是先把前面 10 萬條掃一遍再丟掉越往后越慢。正確做法是記住上一頁最后一條的排序字段值下一頁用 lastValue來查db.articles.find({ createdAt: { $lt: lastCreatedAt } }) .sort({ createdAt: -1 }).limit(20);這種方式在任何頁數(shù)下耗時(shí)都穩(wěn)定前提是排序字段上有索引。6.4 備份和變更這兩件事別等出事再想最后提兩個(gè)運(yùn)維層面的事。第一是備份mongodump簡單夠用但要注意它是邏輯備份大庫導(dǎo)出很慢而且導(dǎo)出期間的數(shù)據(jù)一致性要靠--oplog保證。數(shù)據(jù)量大的話快照方式更穩(wěn)。第二是索引和字段的變更。給一個(gè)千萬級(jí)集合加索引如果沒有指定后臺(tái)構(gòu)建會(huì)阻塞寫入。新版本雖然默認(rèn)行為已經(jīng)優(yōu)化但上線前還是應(yīng)該在預(yù)發(fā)環(huán)境用同等數(shù)據(jù)量壓一遍記錄耗時(shí)。我吃過一次虧預(yù)發(fā)只有十萬條數(shù)據(jù)加索引兩秒完成生產(chǎn)一千多萬條加了四十多分鐘期間接口大面積超時(shí)。自此之后任何涉及大集合的變更我都會(huì)先拿生產(chǎn)數(shù)據(jù)的抽樣副本跑一遍估算耗時(shí)再挑低峰期執(zhí)行。寫了這么多其實(shí) MongoDB 入門真正的門檻不在語法而在兩個(gè)思維轉(zhuǎn)變一是從表結(jié)構(gòu)先行轉(zhuǎn)到讀取模式先行建模時(shí)先想清楚數(shù)據(jù)怎么被讀二是從應(yīng)用層拼裝轉(zhuǎn)到數(shù)據(jù)庫側(cè)完成索引、聚合、投影這些能力用好了很多邏輯根本不用搬到代碼里。我自己在實(shí)際項(xiàng)目里的體會(huì)是但凡一個(gè)查詢開始變慢第一反應(yīng)應(yīng)該是去看explain而不是急著加緩存。緩存能蓋住問題但索引沒建對(duì)緩存一失效問題還是原樣回來。