資訊專欄INFORMATION COLUMN
摘要：關于數據安全在早期的版本引發了很多爭論。端能確保收到了寫入數據，但依然有短暫的日志落盤時差導致潛在的數據丟失可能。而每個分片上的數據又以的形式組織類似于的概念，以便于集群內部的數據遷移和再平衡。
在系統引入 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 的專業技術公司博客分享的寫入基準測試數據。我這里根據數據結果做一些分析總結，下面是測試結果數據的表格和圖形展示。
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
測試類型多了一項將 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
寫點文字，畫點畫兒，「瞬息之間」一切都變了。覺得不錯，可長按或掃描二維碼關注。
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/18860.html
摘要：段落標簽中段落標簽是，表示一段文字，是否換行取決于視圖窗口的大小。字體裝飾加粗字體建議使用，不要使用標簽，同樣傾斜字體應該使用標簽而不建議使用標簽，之所以這樣做主要是為了保證代碼的語義良好。相信大家常常會打開瀏覽器搜索一些內容或者瀏覽一些網站，在瀏覽器的頁面上會呈現很多內容，但是具體的形式無非就是圖片、文字以及鏈接（可以點擊進入另一個頁面的特殊文字），其中文字承載著巨大的作用，傳遞著各種各樣...
摘要：這一概念和相對，認為可以在進程函數外部對其終止運行。對于從其他語言轉向的人來說，它看起來很像函數返回值指針。 本文翻譯自：The Basics Of ES6 Generators 由于個人能力有限，翻譯中難免有紕漏和錯誤，望不吝指正issue JavaScript ES6(譯者注：ECMAScript 2015)中最令人興奮的特性之一莫過于Generator函數，它是一種全新的函數...
摘要：不采用關系模型主要是為了獲得更好的擴展性。易于擴展應用程序數據集的大小正在以不可思議的速度增長。過去非常罕見的級別數據，現在已是司空見慣了。這種精簡方式的設計是能夠實現如此高性能的原因之一。下一篇文章指南基礎知識文檔集合數據庫客戶端 下一篇文章：MongoDB指南---2、MongoDB基礎知識-文檔、集合、數據庫、客戶端 MongoDB是一款強大、靈活，且易于擴展的通用型數據庫。它...
摘要：不采用關系模型主要是為了獲得更好的擴展性。易于擴展應用程序數據集的大小正在以不可思議的速度增長。過去非常罕見的級別數據，現在已是司空見慣了。這種精簡方式的設計是能夠實現如此高性能的原因之一。下一篇文章指南基礎知識文檔集合數據庫客戶端 下一篇文章：MongoDB指南---2、MongoDB基礎知識-文檔、集合、數據庫、客戶端 MongoDB是一款強大、靈活，且易于擴展的通用型數據庫。它...
摘要：例如，假設要刪除集合中所有為的人刪除數據是永久性的，不能撤銷，也不能恢復。刪除速度刪除文檔通常很快，但是如果要清空整個集合，那么使用直接刪除集合會更快然后在這個空集合上重建各項索引。上一篇文章指南基礎知識使用下一篇文章指南更新文檔 上一篇文章：MongoDB指南---4、MongoDB基礎知識-使用MongoDB Shell下一篇文章：MongoDB指南---6、更新文檔 本章會介紹...
閱讀 2986·2021-11-23 09:51
閱讀 2798·2021-11-11 16:55
閱讀 2907·2021-10-14 09:43
閱讀 1394·2021-09-23 11:22
閱讀 1035·2019-08-30 11:04
閱讀 1663·2019-08-29 11:10
閱讀 956·2019-08-27 10:56
閱讀 3102·2019-08-26 12:01
