摘要：關(guān)于數(shù)據(jù)安全在早期的版本引發(fā)了很多爭(zhēng)論。端能確保收到了寫(xiě)入數(shù)據(jù)，但依然有短暫的日志落盤(pán)時(shí)差導(dǎo)致潛在的數(shù)據(jù)丟失可能。而每個(gè)分片上的數(shù)據(jù)又以的形式組織類(lèi)似于的概念，以便于集群內(nèi)部的數(shù)據(jù)遷移和再平衡。

在系統(tǒng)引入 MongoDB 也有幾年了，一開(kāi)始是因?yàn)?MySQL 中有單表記錄增長(zhǎng)太快（每天幾千萬(wàn)條吧）容易拖慢 MySQL 的主從復(fù)制。而這類(lèi)數(shù)據(jù)增長(zhǎng)迅速的流水表，對(duì)數(shù)據(jù)一致性也沒(méi)那么高要求，而且業(yè)務(wù)上也不需要關(guān)聯(lián)查詢(xún)它，就考慮分出去。為什么是 MongoDB？剛巧趕上公司 DBA 團(tuán)隊(duì)引入了這個(gè)數(shù)據(jù)庫(kù)，有人幫助運(yùn)維，對(duì)業(yè)務(wù)團(tuán)隊(duì)就成了一個(gè)自然的選擇。不過(guò)對(duì)于任何技術(shù)產(chǎn)品你如果要把它用在生產(chǎn)環(huán)境上，最好確定對(duì)它的架構(gòu)和運(yùn)作機(jī)理有個(gè)全面的理解。

MongoDB 是一種 NoSQL 數(shù)據(jù)庫(kù)，它在數(shù)據(jù)存儲(chǔ)的形態(tài)上和 MySQL 這類(lèi)關(guān)系數(shù)據(jù)庫(kù)有本質(zhì)區(qū)別。MongoDB 存儲(chǔ)的基本對(duì)象是 Document，所以我們把它稱(chēng)為一種文檔數(shù)據(jù)庫(kù)，而文檔的集合則組成了 Collection。與 SQL 的概念類(lèi)比，Collection 對(duì)應(yīng)于 Table 而 Document 對(duì)應(yīng)于 Row。Document 使用一種 BSON（Binary JSON）結(jié)構(gòu)來(lái)表達(dá)，JSON 大家都熟悉，像下面這樣。

Document 在內(nèi)部是如何存儲(chǔ)的？每個(gè) Document 被保存在一個(gè) Record 中。Record 相當(dāng)于 MongoDB 內(nèi)部分配的一塊空間，除了保存 Document 的內(nèi)容可能還會(huì)預(yù)留一些填充的額外空間。對(duì)于寫(xiě)入后的 Document 如果還會(huì)更新，可能導(dǎo)致 Document 長(zhǎng)度增加，就可以利用上額外的填充空間來(lái)。若業(yè)務(wù)對(duì)于寫(xiě)入后的 Document 不會(huì)再更新或刪除（像監(jiān)控日志、流水記錄等），可以指定無(wú)填充的 Record 分配策略，更節(jié)省空間。

了解了 Document 形態(tài)的基礎(chǔ)上，我們?cè)僬f(shuō)點(diǎn)針對(duì) Document 的訪問(wèn)操作。新的 WiredTiger 存儲(chǔ)引擎提供了 Document 級(jí)別的并發(fā)操作，所以并發(fā)性能有所改善。另外 MongoDB 僅對(duì)單一 Document 提供事務(wù)的 ACID 保障，如果一個(gè)操作涉及多個(gè) Document 則不能保證事務(wù)特性。不同的業(yè)務(wù)數(shù)據(jù)對(duì)事務(wù)一致性的要求不同，所以應(yīng)用開(kāi)發(fā)者需要知道將數(shù)據(jù)放在不同的 Document 中寫(xiě)入時(shí)在一致性方面可能的影響。詳細(xì)的操作 API 直接看官方文檔，不贅述了。

這里的安全指的數(shù)據(jù)安全，安全就是說(shuō)數(shù)據(jù)被安全的保存好了，不會(huì)丟失。關(guān)于 MongoDB 數(shù)據(jù)安全在早期的版本（1.x）引發(fā)了很多爭(zhēng)論。（可以看參考[2]）

安全和效率其實(shí)是相互制約的，越安全則效率越低，越高效則越不安全。MongoDB 的設(shè)計(jì)場(chǎng)景考慮的是應(yīng)對(duì)大量的數(shù)據(jù)寫(xiě)入和查詢(xún)，而數(shù)據(jù)的重要性相對(duì)沒(méi)那么高。所以 MongoDB 的默認(rèn)設(shè)置在安全和效率之間，更偏向效率。

我們先看下一個(gè) Document 被寫(xiě)入到 MongoDB 后它內(nèi)部的處理方式。MongoDB 的 API 提供了不同安全級(jí)別的寫(xiě)入選項(xiàng)來(lái)讓使用方根據(jù)其數(shù)據(jù)性質(zhì)靈活的選擇。

Write To Buffer Without ACK

這個(gè)模式下 MongoDB 是不確認(rèn)寫(xiě)請(qǐng)求的，Client 端調(diào)用驅(qū)動(dòng)寫(xiě)入后若沒(méi)有網(wǎng)絡(luò)錯(cuò)誤就認(rèn)為成功，實(shí)際到底寫(xiě)入成功沒(méi)有是不確定的。即使網(wǎng)絡(luò)沒(méi)有問(wèn)題，數(shù)據(jù)到達(dá) MongoDB 后它先保存在內(nèi)存 Buffer 中，再異步寫(xiě)入 Journaling 日志，這中間有 100ms（默認(rèn)值） 的落盤(pán)（寫(xiě)入磁盤(pán)）時(shí)間窗口。一般數(shù)據(jù)庫(kù)的設(shè)計(jì)都是先寫(xiě) Journaling 的流水日志，隨后異步再寫(xiě)真正的數(shù)據(jù)文件到磁盤(pán)，這個(gè)隨后可能就比較長(zhǎng)了，MongoDB 是 60 秒或者 Journaling 日志達(dá)到 2G。

Write To Buffer With ACK

這個(gè)比上一種模式稍微好一點(diǎn)，MongoDB 收到寫(xiě)入請(qǐng)求，先寫(xiě)入內(nèi)存 Buffer 后回發(fā) Ack 確認(rèn)。Client 端能確保 MongoDB 收到了寫(xiě)入數(shù)據(jù)，但依然有短暫的 Journaling 日志落盤(pán)時(shí)差導(dǎo)致潛在的數(shù)據(jù)丟失可能。

Write To Journaling With ACK

這個(gè)模式確保至少寫(xiě)入 Journaling 日志后才回發(fā) Ack 確認(rèn)，Client 端能確保數(shù)據(jù)至少寫(xiě)入磁盤(pán)了，安全性較高。

Write To Replica Buffer With ACK

這個(gè)模式是針對(duì)多副本集的，為了提升數(shù)據(jù)安全性，除了及時(shí)寫(xiě)入磁盤(pán)也可以通過(guò)寫(xiě)多個(gè)副本來(lái)提升。在這個(gè)模式下，數(shù)據(jù)至少寫(xiě)入 2 個(gè)副本的內(nèi)存 Buffer 中才回發(fā) Ack 確認(rèn)。雖然都在內(nèi)存 Buffer 中，但兩個(gè)實(shí)例在落盤(pán)短暫的 100ms 時(shí)差中同時(shí)故障的概率很低，所以安全性有所提升。

明白了不同的寫(xiě)入模式選項(xiàng)，我們才能更好的真對(duì)數(shù)據(jù)的性質(zhì)選擇合適的安全級(jí)別。后面效率一節(jié)我們?cè)俜治霾煌瑢?xiě)入模式下的效率差異。

在考慮 MongoDB 整體的存儲(chǔ)容量前，先考慮作為基本單元的 Document 的容量。Document 這種 JSON 形態(tài)天生會(huì)帶來(lái)數(shù)據(jù)存儲(chǔ)冗余，主要是 field 屬性每個(gè) Document 都會(huì)保存一遍。目前 3.2 版本的 MongoDB 已經(jīng)將新的 WiredTiger 作為默認(rèn)存儲(chǔ)引擎，它提供了壓縮功能，有兩種壓縮形式：

Snappy 默認(rèn)壓縮算法，在壓縮率和 CPU 開(kāi)銷(xiāo)之間取得平衡。

Zlib 更高的壓縮率，但也帶來(lái)更高的 CPU 開(kāi)銷(xiāo)。

而每個(gè) Document 依然有最大容量限制，不能無(wú)限增長(zhǎng)下去，這個(gè)限制目前是 16MB。那么我要存大于 16MB 的文件怎么辦，MongoDB 提供了 GridFS 來(lái)存儲(chǔ)超過(guò) 16MB 大小的文件。如下圖所示，一個(gè)大文件被拆分成小的 File Chunk，每個(gè) Chunk 大小 255KB，并存放在一個(gè) Document 中。GridFS 使用了 2 個(gè) Collection 來(lái)分別存放文件 Chunk 和文件元數(shù)據(jù)。

單機(jī)的容量總是受限于磁盤(pán)大小，而 MongoDB 解決方案依然是分片化。是用更多的機(jī)器來(lái)提供更大的容量，分片集群采用代理模式（《Redis 集群的合縱與連橫》一文中寫(xiě)過(guò)這類(lèi)模式），如下圖。

而每個(gè)分片上的數(shù)據(jù)又以 Chunk 的形式組織（類(lèi)似于 Redis Cluster 的 Slot 概念），以便于集群內(nèi)部的數(shù)據(jù)遷移和再平衡。比較容易混淆的是這里的 Chunk 不是前面 GridFS 里提到的 Chunk，它們的關(guān)系大概如下圖（吐槽下，干嘛要用同名的術(shù)語(yǔ)來(lái)表達(dá)完全不同的概念）。

支持水平擴(kuò)展和數(shù)據(jù)再平衡功能的 MongoDB Cluster 基本上數(shù)據(jù)容量就不再是個(gè)問(wèn)題了。

前面「安全」一節(jié)列舉了不同的寫(xiě)入模式，我們看下在這些不同模式下寫(xiě)入的效率如何。由于官方?jīng)]有提供基準(zhǔn)性能測(cè)試數(shù)據(jù)，下面的數(shù)據(jù)來(lái)自參考文獻(xiàn)[5]一個(gè)從 2009 年開(kāi)始使用 MongoDB 的專(zhuān)業(yè)技術(shù)公司博客分享的寫(xiě)入基準(zhǔn)測(cè)試數(shù)據(jù)。我這里根據(jù)數(shù)據(jù)結(jié)果做一些分析總結(jié)，下面是測(cè)試結(jié)果數(shù)據(jù)的表格和圖形展示。

w=0, Write To Buffer Without ACK

w=1, Write To Buffer With ACK

j=1, Write To Journaling With ACK

w=2, Write To Replica Buffer With ACK

測(cè)試類(lèi)型多了一項(xiàng)將 Journaling 日志放在 SSD 和機(jī)械硬盤(pán)上的差異，這讓我們可以直觀的感受 SSD 和機(jī)械硬盤(pán)在順序?qū)懬闆r下的性能差異。對(duì)于機(jī)械硬盤(pán)最大的性能制約是在磁頭移動(dòng)，所以 MongoDB 官方文檔也建議將 Journaling 日志和數(shù)據(jù)文件放在不同的磁盤(pán)上。保證順序?qū)?Journaling 日志的磁頭不會(huì)被隨機(jī)寫(xiě)數(shù)據(jù)文件影響，而數(shù)據(jù)文件的寫(xiě)入是通過(guò)內(nèi)存 buffer 緩沖的一個(gè)異步過(guò)程，對(duì)交互性能延遲的影響不大。

根據(jù)測(cè)試結(jié)果數(shù)據(jù)看，有無(wú) Ack 之間響應(yīng)延時(shí)相差一倍，基本就是多了一個(gè)網(wǎng)絡(luò)傳輸?shù)难訒r(shí)等待時(shí)間。開(kāi)啟 Journaling 保證及時(shí)落盤(pán)，不論是 SSD 還是機(jī)械硬盤(pán)，這個(gè)延時(shí)都上升了 2 個(gè)數(shù)量級(jí)，翻了百倍，而 SSD 的順序?qū)懕葯C(jī)械硬盤(pán)平均快 3 倍。而寫(xiě)雙副本的平均延時(shí)比我預(yù)期高了不少，應(yīng)該說(shuō)延時(shí)的波動(dòng)很大，不像寫(xiě)磁盤(pán)延時(shí)最小、最大和平均的值非常接近。理論上寫(xiě)雙副本不落盤(pán)的情況延時(shí)只應(yīng)該比單一情況多一倍的網(wǎng)絡(luò)開(kāi)銷(xiāo)外加部份程序開(kāi)銷(xiāo)，而實(shí)際測(cè)試數(shù)據(jù)顯示遠(yuǎn)遠(yuǎn)高于預(yù)期而且延時(shí)波動(dòng)范圍大了很多。這種模式下 MongoDB 延時(shí)表現(xiàn)波動(dòng)范圍太大，不夠穩(wěn)定，具體到底是實(shí)現(xiàn)上的缺陷還是測(cè)試不夠準(zhǔn)確，就不得而知。而且當(dāng)時(shí)測(cè)試的版本是 2.4.1 不知道最新的 3.2 版本如何，如果采用這類(lèi)寫(xiě)模式，可模擬自己生產(chǎn)環(huán)境實(shí)測(cè)得出結(jié)論。

至于讀取性能是沒(méi)法做基準(zhǔn)測(cè)試了，不同的文檔模型，選擇不同的查詢(xún)條件，性能都可能不同。雖然 MongoDB 是 Schemaless 的，但不意味著不需要對(duì)文檔的 Schema 進(jìn)行設(shè)計(jì)，不同的 Schema 設(shè)計(jì)對(duì)性能的影響還是很大的。

面臨一個(gè)新的技術(shù)產(chǎn)品或系統(tǒng)，「形態(tài)」是針對(duì)這個(gè)產(chǎn)品或系統(tǒng)最獨(dú)特部分的描述，屬于核心模型。而「安全」、「容量」、「效率」三個(gè)核心維度全面反應(yīng)了一個(gè)技術(shù)產(chǎn)品或系統(tǒng)的不同設(shè)計(jì)和實(shí)現(xiàn)考慮，可類(lèi)于比機(jī)械設(shè)計(jì)中的「三視圖」。對(duì)于初次面對(duì)一個(gè)新的技術(shù)產(chǎn)品或系統(tǒng)，這是一個(gè)適合的切入點(diǎn)來(lái)幫助做初步的技術(shù)決策，然后跟著進(jìn)一步的實(shí)踐測(cè)試來(lái)驗(yàn)證思考和理解，這樣才能更好的理解和用好現(xiàn)有技術(shù)，做一個(gè)合格的技術(shù)拿來(lái)主義者。

1] MongoDB Doc. [MongoDB Manual
2] MongoDB White Paper. [MongoDB Architecture Guide
3] 陳皓. [千萬(wàn)別用MongoDB？真的嗎？. 2011.11
4] David Mytton. [Does everyone hate MongoDB?. 2012.09
5] David Mytton. [MongoDB Benchmarks. 2012.08
6] David Mytton. [MongoDB Schema Design Pitfalls. 2013.02

寫(xiě)點(diǎn)文字，畫(huà)點(diǎn)畫(huà)兒，「瞬息之間」一切都變了。覺(jué)得不錯(cuò)，可長(zhǎng)按或掃描二維碼關(guān)注。