• 1
  • 2
  • 3
  • 4
  • 5
mysql數據庫問題 首 頁  ?  幫助中心  »  數據庫  »  mysql數據庫問題
MongoDB 的指南
發布日期:2016-5-2 21:5:50

  

  圖1

  現在系統引入 MongoDB 也有幾年了,一開始是由于 MySQL 中有單表記錄增長太快(每天有幾千萬條吧)容易拖慢 MySQL 的主從復制。 而且這類數據增長迅速的流水表,對數據一致性也沒那么高要求,且業務上也不需要關聯查詢它,就考慮分出去。 那么為什么是 MongoDB?剛巧趕上公司 DBA 團隊引入了這個數據庫,有人幫助運維,對業務團隊就成了一個自然的選擇。 不過對于任何技術產品你若要把它用在生產環境上,最好確定對它的架構和運作機理有個全面的理解。

  一、形態

  MongoDB 是一種 NoSQL 數據庫,在數據存儲的形態上與 MySQL 這類關系數據庫有本質區別。 它存儲的基本對象是 Document,因此我們把它稱為一種文檔數據庫,而文檔的集合則組成了 Collection。 與 SQL 的概念類相比,Collection 對應于 Table 而 Document 對應于 Row。 Document 使用一種 BSON(Binary JSON)結構來表達,JSON 大家都熟悉,像下面這樣。如圖2所示:


  圖2

  Document 在內部是如何存儲的?每個 Document 被保存在一個 Record 中。 Record 相當于 MongoDB 內部分配的一塊空間,除了保存 Document 的內容外,可能還會預留一些填充的額外空間。 對于寫入后的 Document 如果還會更新,這可能導致 Document 長度增加,就可利用上額外的填充空間來。 如果業務對于寫入后的 Document 不會再更新或者刪除(像監控日志、流水記錄等),可以指定無填充的 Record 分配策略,更節省空間。如圖3所示:


  圖3

  在了解了 Document 形態的基礎上,我們再來說點針對 Document 的訪問操作。 新的 WiredTiger 存儲引擎提供了 Document 級別的并發操作,所以并發性能有所改善。 另外 MongoDB 僅對單一 Document 提供事務的 ACID 保障,如果一個操作涉及多個 Document 則不能保證事務特性。 不同的業務數據對事務一致性的要求不同,因此應用開發者需要知道將數據放在不同的 Document 中寫入時在一致性方面可能的影響。 詳細的操作可以參考 API官方文檔,在這里不贅述了。

  二、安全

  這里的安全指的數據安全,安全就是說數據被安全的保存好了,數據不會丟失。 關于 MongoDB 數據安全在早期的版本(1.x)引發了很多爭論。(可以看參考[2])

  安全與效率其實是相互制約的,越安全則效率越低,越高效則越不安全。 MongoDB 的設計場景考慮的是應對大量的數據寫入與查詢,而數據的重要性相對沒那么高。 因此 MongoDB 的默認設置在安全與率之間,更偏向效率。

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

  1.Write To Buffer Without ACK

  如圖4所示:


  圖4

  圖4的這個模式下 MongoDB 是不確認寫請求的,Client 端調用驅動寫入后若沒有網絡錯誤就認為成功,實際到底寫入成功沒有是不確定的。 即使網絡沒有問題,數據到達 MongoDB 后它先保存在內存 Buffer 中,再異步寫入 Journaling 日志,這中間有 100ms(默認值) 的落盤(寫入磁盤)時間窗口。 一般數據庫的設計都是先寫 Journaling 的流水日志,隨后異步再寫真正的數據文件到磁盤,這個隨后可能就比較長了,MongoDB 是 60 秒或 Journaling 日志達到 2G。

  2.Write To Buffer With ACK

  如圖5所示:


  圖5

  圖5的這個比上一種模式稍微好一點,MongoDB 收到寫入請求,先寫入內存 Buffer 后回發 Ack 確認。 Client 端能確保 MongoDB 收到了寫入數據,但是依然有短暫的 Journaling 日志落盤時差導致潛在的數據丟失可能。

  3.Write To Journaling With ACK

  如圖6所示:


  圖6

  圖6的這個模式確保至少寫入 Journaling 日志后才回發 Ack 確認,Client 端能確保數據至少寫入磁盤了,安全性較高。

  4.Write To Replica Buffer With ACK

  如圖7所示:


  圖7

  圖7的這個模式是針對多副本集的,為了提升數據安全性,除了及時寫入磁盤也可以通過寫多個副本來提升。 在這個模式下,數據至少寫入 2 個副本的內存 Buffer 中才回發 Ack 確認。 雖然都在內存 Buffer 中,但兩個實例在落盤短暫的 100ms 時差中同時故障的概率很低,所以安全性有所提升。

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

  三、容量

  在考慮 MongoDB 整體的存儲容量前,先考慮作為基本單元的 Document 的容量。Document 這種 JSON 形態天生會帶來數據存儲冗余,主要是 field 屬性每個 Document 都會保存一遍。 目前 MongoDB 3.2 版本已經將新的 WiredTiger 作為默認存儲引擎,它提供了壓縮功能,有以下兩種壓縮形式:

  (1)Snappy 默認壓縮算法,在壓縮率和 CPU 開銷之間取得平衡。

  (2)Zlib 更高的壓縮率,但也帶來更高的 CPU 開銷。

  而每個 Document 依然有最大容量限制,不能無限增長下去,這個限制目前是 16MB。 那么我要存大于 16MB 的文件怎么辦,MongoDB 提供了 GridFS 來存儲超過 16MB 大小的文件。 如下圖所示,一個大文件被拆分成小的 File Chunk,每個 Chunk 大小 255KB,并存放在一個 Document 中。 GridFS 使用了 2 個 Collection 來分別存放文件 Chunk 和文件元數據。如圖8所示:


  圖8

  單機的容量總是受限于磁盤大小,而 MongoDB 解決方案依然是分片化。 是用更多的機器來提供更大的容量,分片集群采用代理模式(《Redis 集群的合縱與連橫》一文中寫過這類模式),如圖9所示。


  圖9

  而每個分片上的數據又以 Chunk 的形式組織(類似于 Redis Cluster 的 Slot 概念),以便于集群內部的數據遷移和再平衡。 比較容易混淆的是這里的 Chunk 不是前面 GridFS 里提到的 Chunk,它們的關系大概如下圖所示:


  圖10

  支持水平擴展和數據再平衡功能的 MongoDB Cluster 基本上數據容量就不再是個問題了。

  四、效率

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


  圖11


  圖12

  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](https://docs.mongodb.org/manual/)

  [2]. MongoDB White Paper. [MongoDB Architecture Guide](http://s3.amazonaws.com/info-mongodb-com/MongoDB_Architecture_Guide.pdf)

  [3]. 陳皓. [千萬別用MongoDB?真的嗎?](http://coolshell.cn/articles/5826.html). 2011.11

  [4]. David Mytton. [Does everyone hate MongoDB?](https://blog.serverdensity.com/does-everyone-hate-mongodb/). 2012.09

  [5]. David Mytton. [MongoDB Benchmarks](https://blog.serverdensity.com/mongodb-benchmarks/). 2012.08

  [6]. David Mytton. [MongoDB Schema Design Pitfalls](https://blog.serverdensity.com/mongodb-schema-design-pitfalls/). 2013.02

什么行业的讲师最赚钱 北京pk赛车软件下载 双人急速赛车 浙江体彩20选5开奖 股票软件开发 平特肖公式大全官方 澳门皇家游戏下载 河北福利彩票排列7 模拟炒股的app 白小姐四肖必选一有 棋牌下载?