[[248398]] 

本文要點(diǎn)

即使MongoDB沒有強(qiáng)制要求，設(shè)計(jì)一個(gè)模式還是至關(guān)重要。

類似地，在設(shè)計(jì)模式及訪問模式時(shí)設(shè)計(jì)好索引。

避免大對(duì)象，尤其是大數(shù)組。

謹(jǐn)慎對(duì)待MongoDB的設(shè)置，尤其是關(guān)乎安全和穩(wěn)定性時(shí)。

MongoDB沒有查詢優(yōu)化器，因此，對(duì)于如何安排查詢操作的順序，你必須格外小心。

我從事數(shù)據(jù)庫相關(guān)工作已經(jīng)很長時(shí)間了，但是最近才開始使用MongoDB。在開始使用MongoDB之前，我希望有些事情我已經(jīng)知道。根據(jù)一般經(jīng)驗(yàn)，對(duì)于數(shù)據(jù)庫是什么以及它們能干什么，人們會(huì)有先入為主的認(rèn)識(shí)。為了給他人提供方便，本文列出了一些常見的錯(cuò)誤。

創(chuàng)建一個(gè)無需身份驗(yàn)證的MongoDB服務(wù)器

很遺憾，MongoDB在安裝時(shí)默認(rèn)不啟用身份驗(yàn)證。在只從本地訪問的工作站上，這沒什么不好。但是，由于MongoDB是一個(gè)多租戶系統(tǒng)，它會(huì)盡可能地占用內(nèi)存，因此最好是安裝在服務(wù)器上，最大限度地提供內(nèi)存，即使是開發(fā)工作。在服務(wù)器上使用默認(rèn)端口安裝而不啟用身份驗(yàn)證是在自找麻煩，尤其是可以在查詢中運(yùn)行任意JavaScript時(shí)(例如把$where作為注入攻擊的載體)。

身份驗(yàn)證方法有多種，但是用戶ID/密碼憑證最容易安裝和管理。當(dāng)你考慮基于LDAP的身份驗(yàn)證時(shí)，可以采用那個(gè)方法。在我們談?wù)摪踩珪r(shí)，MongoDB必須保持最新，而且，在日志里查找未授權(quán)訪問的跡象總是值得的。我不喜歡使用默認(rèn)端口。

忘記限制MongoDB的攻擊面

MongoDB的安全檢查清單為降低網(wǎng)絡(luò)滲透和數(shù)據(jù)泄露風(fēng)險(xiǎn)提供了很好的建議。我們很容易會(huì)認(rèn)為，開發(fā)服務(wù)器不需要高等級(jí)的安全。不是這樣的：安全對(duì)于所有MongoDB服務(wù)器都很重要。尤其是，除非有非常好的理由要使用mapReduce、group或$where，否則你應(yīng)該在配置文件中設(shè)置javascriptEnabled:false，禁用JavaScript。因?yàn)闃?biāo)準(zhǔn)MongoDB的數(shù)據(jù)文件是不加密的，另外，使用專門的用戶運(yùn)行MongoDB也是一個(gè)明智的做法，對(duì)數(shù)據(jù)文件的完全訪問僅限于那個(gè)用戶，這樣就可以使用操作系統(tǒng)自帶的文件訪問控制了。

沒有設(shè)計(jì)一個(gè)模式

對(duì)于模式，MongoDB沒有強(qiáng)制要求。這不是說它不需要模式。如果你真想保存文檔而又沒有一致的模式，那么你可以非?？焖?、簡單地保存它們，但是檢索會(huì)十分麻煩。

“MongoDB模式設(shè)計(jì)的六大經(jīng)驗(yàn)原則”是一篇值得一讀的經(jīng)典文章，而第三方工具(如Studio 3T)提供的類似“模式瀏覽器(Schema Explorer)”這樣可以執(zhí)行定期模式檢查的特性也是值得擁有的。

忘記排序規(guī)則(排序順序)

這比其他任何的配置錯(cuò)誤都會(huì)導(dǎo)致更多的挫折和時(shí)間浪費(fèi)。MongoDB默認(rèn)使用二進(jìn)制排序規(guī)則。這對(duì)任何地方的文化都是不利的。在80年代，大小寫敏感、重音敏感、二進(jìn)制排序規(guī)則，和念珠、土耳其長衫和卷胡子一起，被視為奇怪的時(shí)代錯(cuò)誤。現(xiàn)在，他們沒法辯解了。在現(xiàn)實(shí)生活中，motorbike和Motorbike就是一樣，而Britain和britain就是同一個(gè)地方。小寫字母和大寫字母只是書寫上的等價(jià)。就不要讓我再說重音字符排序規(guī)則了。當(dāng)你創(chuàng)建一個(gè)MongoDB數(shù)據(jù)庫時(shí)，使用一種合乎系統(tǒng)用戶語言和文化的重音敏感、大小寫敏感排序規(guī)則。這使得字符串?dāng)?shù)據(jù)的檢索容易許多。

創(chuàng)建大文檔集合

MongoDB樂于把最大16MB的文檔置于集合中，而GridFS設(shè)計(jì)用于超過16MB的大文檔。但是，可以容納大文檔并不意味著那是一個(gè)好主意。MongoDB在單個(gè)文檔的大小為幾KB時(shí)表現(xiàn)最好，處理它們的方式更像寬SQL表的行。大文檔會(huì)導(dǎo)致多種性能問題。

使用大數(shù)組創(chuàng)建文檔

文檔可以包含數(shù)組。最好是把數(shù)組元素的數(shù)量保持在四位數(shù)以下。如果數(shù)組頻繁添加，會(huì)使得包含它的文檔過大，那樣，它在磁盤上的位置就需要移動(dòng)，反過來，這意味著每個(gè)索引都必須更新。當(dāng)一個(gè)包含大數(shù)組的文檔重新索引時(shí)，由于每個(gè)數(shù)組元素都有一個(gè)單獨(dú)的索引條目，所以會(huì)發(fā)生大量的索引重寫。此外，這種重新索引在這類文檔插入或刪除時(shí)也會(huì)發(fā)生。

為了最小化這個(gè)問題，MongoDB有一個(gè)“填充因子(padding factor)”，為文檔增長提供空間。

你也許會(huì)想，你可以通過不建立數(shù)組索引來繞開這個(gè)問題。遺憾的是，沒有索引，你會(huì)遇到其他問題。因?yàn)槲臋n會(huì)從頭到尾掃描，找到一個(gè)接近數(shù)組尾部的元素需要花更多的時(shí)間，大部分處理這個(gè)文檔的操作都會(huì)變慢。

忘記聚合情況下的階段排序

在有查詢優(yōu)化器的數(shù)據(jù)庫系統(tǒng)中，你編寫的查詢是說明你想要什么而不是如何獲取它。這就像在餐館中點(diǎn)餐;你通常只需要點(diǎn)菜，而不必對(duì)廚師發(fā)出詳細(xì)的指令。

在MongoDB中，你是對(duì)廚師發(fā)指令。例如，你需要通過$match和$project確保管道中的數(shù)據(jù)盡早減少，排序只在數(shù)據(jù)減少時(shí)發(fā)生一次，查找按照你希望的順序執(zhí)行。查詢優(yōu)化器省去了不必要的工作，優(yōu)化階段順序，選擇連接類型，這會(huì)把你寵壞。MongoDB給了你更多的控制，但這種便利是有成本的。

像Studio 3T這樣的工具使構(gòu)建準(zhǔn)確的MongoDB聚合查詢變得更容易。它的聚合編輯器特性使你可以一次對(duì)一個(gè)階段應(yīng)用管道操作符，你可以在每個(gè)階段驗(yàn)證輸入和輸出，更便于調(diào)試。

使用快速寫

永遠(yuǎn)不要把MongoDB設(shè)為低穩(wěn)定性的高速寫?？瓷先ィ?ldquo;file-and-forget”模式使得寫入速度變快了，因?yàn)槊钤趯?shí)際寫入任何東西前就返回了。如果系統(tǒng)在數(shù)據(jù)寫入磁盤之前崩潰了，就會(huì)丟失，存在出現(xiàn)不一致狀態(tài)的風(fēng)險(xiǎn)。所幸，64位的MongoDB啟用了“日志(Journaling)”。

MMAPv1和WiredTiger存儲(chǔ)引擎都使用日志預(yù)防上述情況，不過，在日志關(guān)閉的情況下，WiredTiger也可以在還原過程中恢復(fù)到最后一致的檢查點(diǎn)。

日志可以確保數(shù)據(jù)庫在恢復(fù)時(shí)處于一致狀態(tài)，它會(huì)保存日志寫入時(shí)的所有數(shù)據(jù)。日志寫入的時(shí)間間隔可以使用運(yùn)行時(shí)選項(xiàng)commitIntervalMs來配置。

為了確保寫入，就要確保在配置文件中啟用日志(storage.journal.enabled)，而且提交間隔要和你能夠承擔(dān)的數(shù)據(jù)丟失相對(duì)應(yīng)。

無索引排序

在搜索和聚合中，你經(jīng)常希望排序數(shù)據(jù)。但愿那是在最后階段完成的，在結(jié)果過濾之后，從而減少需要排序的數(shù)據(jù)量。即使在那個(gè)時(shí)候，你需要一個(gè)可以覆蓋排序的索引。單鍵索引或混合索引都可以。

當(dāng)沒有合適的索引可用時(shí)，MongoDB就不得不在沒有索引的情況下排序。對(duì)于排序操作中所有文檔的總大小，有32MB的內(nèi)存限制，如果MongoDB達(dá)到了這個(gè)限值，它就會(huì)產(chǎn)生錯(cuò)誤，或者有時(shí)候僅僅返回一個(gè)空的記錄集。

Lookup而沒有索引支持

Lookup的功能和SQL聯(lián)合查詢類似。為了獲得良好的性能，作為外鍵的鍵值上需要有索引。這并不明顯，因?yàn)槠涫褂貌]有在explain()中報(bào)告。這些索引并不包含在explain()記錄的索引里，那些索引是供管道操作符$match、$sort出現(xiàn)在管道開始時(shí)使用的。現(xiàn)在，索引可以覆蓋聚合管道的任何階段。

不使用多條更新

db.collection.update()方法用于修改一個(gè)已存在文檔的一部分或全部，或者是整個(gè)替換一個(gè)已存在的文檔，這取決于你提供的更新參數(shù)。除非你設(shè)置multi參數(shù)，更新匹配查詢條件的所有文檔，否則它不會(huì)更新集合里的所有文檔。這一點(diǎn)不是那么明顯。

忘記哈希對(duì)象中鍵序的意義

在JSON中，一個(gè)對(duì)象包含一個(gè)無序集合，而該集合中有零個(gè)或多個(gè)名/值對(duì)，其中名是一個(gè)字符串，而值是一個(gè)字符串、數(shù)值、布爾值、空、對(duì)象或數(shù)組。

遺憾的是，BSON在做搜索時(shí)給順序賦予了意義。在MongoDB中，嵌入對(duì)象中鍵的順序很重要，也就是說，{ firstname: "Phil", surname: "factor" }和{ surname: "factor", firstname: "Phil" }就不匹配。這意味著，你必須保留文檔中名/值對(duì)的順序，如果你想確?？梢哉业剿鼈兊脑?。

混淆“null”和“undefined”

根據(jù)正式的JSON標(biāo)準(zhǔn)(ECMA-404第5節(jié))，“undefined”值在JSON中從來就是不合法的，雖然它事實(shí)上已經(jīng)在JavaScript中使用。而且，它在BSON中是“deprecated”，會(huì)轉(zhuǎn)換成$null，這并不是一個(gè)總令人滿意的解決方案。在MongoDB中，要避免使用“undefined”。

使用$limit()而未用$sort()

通常，當(dāng)你在MongoDB中開發(fā)時(shí)，僅僅查看查詢或聚合返回的結(jié)果的樣例會(huì)很有用。 $limit()就是為了滿足這個(gè)要求，但是，它永遠(yuǎn)不應(yīng)該出現(xiàn)在最終版本的代碼中，除非你首先使用了$sort。這是因?yàn)?，不這樣的話，你就無法保證結(jié)果的順序，你就無法可靠地“按頁瀏覽”數(shù)據(jù)。為了確保可靠性，查詢或聚合必須是“確定的”，就是說，它們每次執(zhí)行都會(huì)給出相同的結(jié)果。包含$limit而不包含$sort的代碼不是確定的，后續(xù)會(huì)導(dǎo)致難以跟蹤的Bug。

小結(jié)

對(duì)于MongoDB，讓你最終感到失望的唯一方式是把它直接和另一種類型的數(shù)據(jù)庫如RDBMS比較，或者對(duì)它有特別的期待。這就像把桔子和叉子比較。數(shù)據(jù)庫系統(tǒng)有它們的用途。最好是理解并領(lǐng)會(huì)這些差別。強(qiáng)迫MongoDB開發(fā)人員按照RDBMS的方式做事就太遺憾了，我希望繼續(xù)看到解決舊問題的有趣的新方法，如確保數(shù)據(jù)完整性、使數(shù)據(jù)系統(tǒng)具有從故障和惡意破壞中恢復(fù)的能力。

在4.0版本中，MongoDB引入了ACID事務(wù)處理，這是以創(chuàng)新方式引入重大改善的一個(gè)很好的例子。多文檔、多語句事務(wù)現(xiàn)在是原子的了，它允許開發(fā)人員調(diào)整用于獲取鎖的時(shí)間，過期掛起事務(wù)以及修改隔離級(jí)別。