MongoDB 初見指南

標籤：

技術若只如初見，那麼還會踩坑麼?

在系統引入 MongoDB 也有幾年了，一開始是因為 MySQL 中有單表記錄增長太快（每天幾千萬條吧）容易拖慢 MySQL 的主從複製。而這類資料增長迅速的流水表，對資料一致性也沒那麼高要求，而且業務上也不需要關聯查詢它，就考慮分出去。為什麼是 MongoDB？剛巧趕上公司 DBA 團隊引入了這個資料庫，有人協助營運，對業務團隊就成了一個自然的選擇。不過對於任何技術產品你如果要把它用在生產環境上，最好確定對它的架構和運作機理有個全面的理解。

形態

MongoDB 是一種 NoSQL 資料庫，它在資料存放區的形態上和 MySQL 這類別關係資料庫有本質區別。MongoDB 儲存的基本對象是 Document，所以我們把它稱為一種文檔資料庫，而文檔的集合則組成了 Collection。與 SQL 的概念類比，Collection 對應於 Table 而 Document 對應於 Row。Document 使用一種 BSON（Binary JSON）結構來表達，JSON 大家都熟悉，像下面這樣。

Document 在內部是如何儲存的？每個 Document 被儲存在一個 Record 中。Record 相當於 MongoDB 內部分配的一塊空間，除了儲存 Document 的內容可能還會預留一些填充的額外空間。對於寫入後的 Document 如果還會更新，可能導致 Document 長度增加，就可以利用上額外的填充空間來。若業務對於寫入後的 Document 不會再更新或刪除（像監控日誌、流水記錄等），可以指定無填充的 Record 分配策略，更節省空間的。

瞭解了 Document 形態的基礎上，我們再說點針對 Document 的訪問操作。新的 WiredTiger 儲存引擎提供了 Document 層級的並行作業，所以並發效能有所改善。另外 MongoDB 僅對單一 Document 提供事務的 ACID 保障，如果一個操作涉及多個 Document 則不能保證事務特性。不同的業務資料對事務一致性的要求不同，所以應用開發人員需要知道將資料放在不同的 Document 中寫入時在一致性方面可能的影響。詳細的操作 API 直接看官方文檔，不贅述了。

安全

這裡的安全指的資料安全，安全就是說資料被安全的儲存好了，不會丟失。關於 MongoDB 資料安全在早期的版本（1.x）引發了很多爭論。（可以看參考[2]）

安全和效率其實是相互制約的，越安全則效率越低，越高效則越不安全。MongoDB 的設計情境考慮的是應對大量的資料寫入和查詢，而資料的重要性相對沒那麼高。所以 MongoDB 的預設設定在安全和效率之間，更偏向效率。

我們先看下一個 Document 被寫入到 MongoDB 後它內部的處理方式。MongoDB 的 API 提供了不同安全層級的寫入選項來讓使用方根據其資料性質靈活的選擇。

Write To Buffer Without ACK

這個模式下 MongoDB 是不確認寫請求的，Client 端調用驅動寫入後若沒有網路錯誤就認為成功，實際到底寫入成功沒有是不確定的。即使網路沒有問題，資料到達 MongoDB 後它先儲存在記憶體 Buffer 中，再非同步寫入 Journaling 日誌，這中間有 100ms（預設值） 的落盤（寫入磁碟）時間視窗。一般資料庫的設計都是先寫 Journaling 的流水日誌，隨後非同步再寫真正的資料檔案到磁碟，這個隨後可能就比較長了，MongoDB 是 60 秒或者 Journaling 日誌達到 2G。

Write To Buffer With ACK

這個比上一種模式稍微好一點，MongoDB 收到寫入請求，先寫入記憶體 Buffer 後回傳 Ack 確認。Client 端能確保 MongoDB 收到了寫入資料，但依然有短暫的 Journaling 日誌落盤時差導致潛在的資料丟失可能。

Write To Journaling With ACK

這個模式確保至少寫入 Journaling 日誌後才回傳 Ack 確認，Client 端能確保資料至少寫入磁碟了，安全性較高。

Write To Replica Buffer With ACK

這個模式是針對多複本集的，為了提升資料安全性，除了及時寫入磁碟也可以通過寫多個副本來提升。在這個模式下，資料至少寫入 2 個副本的記憶體 Buffer 中才回傳 Ack 確認。雖然都在記憶體 Buffer 中，但兩個執行個體在落盤短暫的 100ms 時差中同時故障的機率很低，所以安全性有所提升。

明白了不同的寫入模式選項，我們才能更好的真對資料的性質選擇合適的安全層級。後面效率一節我們再分析不同寫入模式下的效率差異。

容量

在考慮 MongoDB 整體的儲存容量前，先考慮作為基本單元的 Document 的容量。Document 這種 JSON 形態天生會帶來資料存放區冗餘，主要是 field 屬性每個 Document 都會儲存一遍。目前 3.2 版本的 MongoDB 已經將新的 WiredTiger 作為預設儲存引擎，它提供了壓縮功能，有兩種壓縮形式：

• Snappy 預設壓縮演算法，在壓縮率和 CPU 開銷之間取得平衡。
• Zlib 更高的壓縮率，但也帶來更高的 CPU 開銷。

而每個 Document 依然有最大容量限制，不能無限增長下去，這個限制目前是 16MB。那麼我要存大於 16MB 的檔案怎麼辦，MongoDB 提供了 GridFS 來儲存超過 16MB 大小的檔案。如所示，一個大檔案被拆分成小的 File Chunk，每個 Chunk 大小 255KB，並存放在一個 Document 中。GridFS 使用了 2 個 Collection 來分別存放檔案 Chunk 和檔案中繼資料。

單機的容量總是受限於磁碟大小，而 MongoDB 解決方案依然是分區化。是用更多的機器來提供更大的容量，分區叢集採用代理模式（《Redis 叢集的合縱與連橫》一文中寫過這類模式），如。

而每個分區上的資料又以 Chunk 的形式組織（類似於 Redis Cluster 的 Slot 概念），以便於叢集內部的資料移轉和重新平衡。比較容易混淆的是這裡的 Chunk 不是前面 GridFS 裡提到的 Chunk，它們的關係大概如（吐槽下，幹嘛要用同名的術語來表達完全不同的概念）。

支援水平擴充和資料重新平衡功能的 MongoDB Cluster 基本上資料容量就不再是個問題了。

效率

前面「安全」一節列舉了不同的寫入模式，我們看下在這些不同模式下寫入的效率如何。由於官方沒有提供基準效能測試資料，下面的資料來自參考文獻[5]一個從 2009 年開始使用 MongoDB 的專業技術公司部落格分享的寫入基準測試資料。我這雷根據資料結果做一些分析總結，下面是測試結果資料的表格和圖形展示。

測試類型多了一項將 Journaling 日誌放在 SSD 和機械硬碟上的差異，這讓我們可以直觀的感受 SSD 和機械硬碟在順序寫情況下的效能差異。對於機械硬碟最大的效能制約是在磁頭移動，所以 MongoDB 官方文檔也建議將 Journaling 日誌和資料檔案放在不同的磁碟上。保證順序寫 Journaling 日誌的磁頭不會被隨機寫資料檔案影響，而資料檔案的寫入是通過記憶體 buffer 緩衝的一個非同步過程，對互動效能延遲的影響不大。

根據測試結果資料看，有無 Ack 之間響應延時相差一倍，基本就是多了一個網路傳輸的延時等待時間。開啟 Journaling 保證及時落盤，不論是 SSD 還是機械硬碟，這個延時都上升了 2 個數量級，翻了百倍，而 SSD 的順序寫比機械硬碟平均快 3 倍。而寫雙副本的平均延時比我預期高了不少，應該說延時的波動很大，不像寫磁碟延時最小、最大和平均的值非常接近。理論上寫雙副本不落盤的情況延時只應該比單一情況多一倍的網路開銷外加部份程式開銷，而實際測試資料顯示遠遠高於預期而且延時波動範圍大了很多。這種模式下 MongoDB 延時表現波動範圍太大，不夠穩定，具體到底是實現上的缺陷還是測試不夠準確，就不得而知。而且當時測試的版本是 2.4.1 不知道最新的 3.2 版本如何，如果採用這類寫入模式，可類比自己生產環境實測得出結論。

至於讀取效能是沒法做基準測試了，不同的文檔模型，選擇不同的查詢條件，效能都可能不同。雖然 MongoDB 是 Schemaless 的，但不意味著不需要對文檔的 Schema 進行設計，不同的 Schema 設計對效能的影響還是很大的。

總結

面臨一個新的技術產品或系統，「形態」是針對這個產品或系統最獨特部分的描述，屬於核心模型。而「安全」、「容量」、「效率」三個核心維度全面反應了一個技術產品或系統的不同設計和實現考慮，可類於比機械設計中的「三視圖」。對於初次面對一個新的技術產品或系統，這是一個適合的切入點來協助做初步的技術決策，然後跟著進一步的實踐測試來驗證思考和理解，這樣才能更好的理解和用好現有技術，做一個合格的技術拿來主義者。

參考

[1] MongoDB Doc. MongoDB Manual
[2] MongoDB White Paper. MongoDB Architecture Guide
[3] 陳皓. 千萬別用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

MongoDB 初見指南