雲時代下的數據庫存儲——指揮若定的阿里雲數據庫MongoDB

本次直播視頻精彩回顧，戳這裏！

 

直播涉及到的PPT，戳這裏！

 

分享嘉賓：阿里雲高級產品經理 許鴻斌（花名：落宵）

           

本篇文章來自於阿里雲高級產品經理許鴻斌（落宵）在2018年《Redis、MongoDB、HBase大咖直播大講堂》技術直播峯會中的分享，該分享總體由三個部分構成：

 

一、雲數據庫MongoDB概述

 

二、雲數據庫MongoDB產品特性

 

三、典型場景

 

小荷才露尖尖角——初識MongoDB數據庫

 

 

在瞭解MongoDB數據庫以前首先介紹與MongoDB強相關的三個關鍵詞：Humongos、Scale Out和Document。

 

做爲MongoDB名稱的由來，Humongos中文意思爲極大的、巨大的，MongoDB從創辦的第一天起就是圍繞着對大數據量存儲支撐的願景來展開代碼開發的。

 

在數據庫產品的升級當中通常有兩個維度：第一個維度爲Scale Out向上升級，即隨着硬件的能力從兩核升級到四核再升級到八核向上升級的過程，可是機器終究是有上限的，此時數據庫很難突破物理機性能的瓶頸；第二個維度爲MongoDB自然支持的Scale Out橫向擴展能力，當一臺機器的性能達到上限時，能夠加入一臺機器組成一個新的集羣。這種橫向擴展的能力使得MongoDB的集羣能夠不斷地去提高自身的性能和存儲能力，從而達到大數據量所須要的性能要求，也成爲了MongoDB對大數據量支撐的佐證。

 

MongoDB是一個文檔型的數據庫，以文檔爲存儲單元，而傳統的MySQL等關係型數據庫是以行存爲單位的，相比行存的數據庫文檔型數據庫在存儲上更爲靈活，這也是在不少業務場景選擇使用文檔型數據庫來存儲業務數據的的重要緣由之一。

 

 

如上圖所示，假設咱們要存儲一輛汽車的數據，其中包括全部的部件信息。因爲每種部件所須要的信息不一樣，傳統的行存數據庫須要先將汽車全部的部件都拆開，分別存儲在不一樣的數據表中，例如發動機須要存儲的信息包括是否爲燃油機、柴油機、吸氣方式、燃油效率等字段，輪胎須要存儲的信息包括輪轂高度、胎壓範圍等字段。行存數據庫的數據結構須要多張表的支撐才能完整地組成一個所須要的部件信息。

 

 

文檔型數據庫不須要事先徹底設計好表同樣的結構來一一映射到每一個部件上，它支持動態結構，能夠把每個存儲項的項目名和值直接存儲在一個文檔當中，在數據結構上只須要簡單的幾行就能夠把多張數據表的信息彙總起來，文檔型數據庫自然支持的一些數據的聚合、嵌套和數組結構的特性，提供了一個更爲簡練的存儲結構、更爲靈活的存儲優點。

 

阿里雲數據庫MongoDB的產品架構

 

 

首先介紹的是MongoDB最爲基礎最爲常見的一個三副本架構，一旦建立三副本的實例，雲數據庫MongoDB會自動將三個節點部署在三臺不一樣的機器上，同時對外提供主節點寫入的支持以及其中一個備節點讀取的支持，兩個備節點自動從主節點獲取日誌進行數據同步。三副本架構的優點在於，當其中某個節點出現故障時，另一個備節點直接進行替換，系統會將以前的讀取流量切換到另一個正在運行的備節點上，從而保證當單點出現故障時整個應用的讀寫不會受到任何影響。但這樣的架構同時會暴露出一個問題，當每臺機器上的節點性能達到物理機的上限時，很難再去擴展能力，不管是在存儲能力，或者是處理能力包括在CPU、內存這些性能指標上都很難再去達到一個突破，因此阿里雲也支持了以下的MongoDB集羣架構。

 

 

在MongoDB集羣架構模式中，每個集羣下都由多個三副本節點構成，每一個Shard的節點依舊採用三副原本保障Shard節點的高可用，一個集羣能夠經過橫向擴展不斷地把Shard節點加入進來，目前最多支持32個Shard節點的添加。當一個Shard節點上面的機器性能達到上限時能夠不斷地添加新的Shard節點以達到一個橫向的擴展能力，也是MongoDB做爲水平橫向擴展一個很是重要的特性。不管是MongoDB三副本的架構保證一個高可用，仍是是集羣架構在高可用的基礎上兼容了橫向擴展的能力，因爲數據庫自己對於高可用、擴展性的考慮每個架構所對應到後端的數據庫硬件成本都有很是多個節點。

 

 

然而在一些實際的應用場景當中，不少用戶在一些開發、測試的平常場景使用MongoDB時，發現沒有必要使用那麼多的節點數去存儲，對於一些測試環境，咱們能夠容忍必定時間內的數據庫宕機，或者數據並不須要很是強的擴展性來進行支撐。阿里雲會在近期發佈一個MongoDB更爲基礎的架構，即MongoDB的單節點架構，這個架構徹底是針對整個MongoDB在測試、開發環境上的支撐所去構建的，它只有一個節點，一旦掛掉以後並不會有切換，而須要等待修復的過程。推薦用戶在一些微核性的場景，相似於測試、開發這樣的場景去使用，從而更好地顯示單節點架構高性價比的特性。

 

阿里雲數據庫MongoDB的售賣形態

 

 

阿里雲全部的MongoDB都是基於實例規格和存儲空間兩個訂價因子進行收費的，在包年包月的模式上有更爲折扣的價格，而按量付費更爲靈活，支持隨時啓動和釋放。在二月份到三月份，阿里雲將會提供支持用戶從按量付費的方式進行測試以後直接轉到包年包月的方式，無需從新開啓一個新的實例去修改應用的鏈接方式。同時在阿里雲目前所支持的包括三副本、集羣和單節點的多種架構中，例如購買了三副本模式，購買頁面中直接把三個節點的價格造成一個彙總顯示在頁面上而不須要用戶再去本身買多個節點。

 

精益求精——雲數據庫MongoDB產品優點

 

阿里雲上的MongoDB相比於一些用戶在機房自建部署的MongoDB上會有哪些方面的區別？

 

安全性：訪問控制和日誌審計

 

 

首先從安全性上看，從2016年末到2017年中期這段時間，全球爆發了很是嚴重的MongoDB配置的漏洞問題，據不徹底統計，全球大概有數十萬臺MongoDB，包括不少用戶在機房本身搭建的、在其它雲廠商上搭建的數據庫，都受到了不一樣程度的黑客攻擊，這些MongoDB集羣在被黑客攻擊以後，徹底地被黑客所控制，數據庫中的數據所有被黑客所加密，黑客在控制了這些集羣以後同時向這些MongoDB的用戶發起了勒索，在數據做爲安身立命重要支柱的企業當中，一旦被黑客所控制將產生嚴重的後果。在這樣一場很是嚴重的浩劫當中，阿里雲數據庫MongoDB上全部的實體都沒有被黑客所攻破。阿里雲在雲數據庫MongoDB上面對安全作了哪些方面的加持呢？

 

 

首先，在訪問控制方面，阿里雲上自然所支持的VPC專有網絡架構可以很好地將用戶所部署的一些應用、數據庫以及其它的一些雲產品所有放到一個隔離的網絡環境內部，這個網絡環境內部就至關於咱們本身在機房內所建的一個私有網絡，徹底隔離於外部，在此之上雲數據庫MongoDB支持IP白名單的功能，例如能夠在MongoDB的實例上去設置哪些服務器是能夠鏈接到MongoDB上的，而當機器的IP地址不在設置列表當中時，這臺機器是徹底沒法連通MongoDB實體的。即便整個帳號密碼徹底被竊取，也沒法將不在白名單內的機器鏈接到MongoDB這個實體上。

 

 

其次，做爲對MongoDB目前所支持的一個很是重要的功能，即日誌審計的模式，能夠作到徹底地記錄用戶對於某一個MongoDB實例所作的一些更新、插入操做以及一些查詢時間超過100毫秒的慢查詢操做，這樣的一些操做範圍會有怎樣的做用呢？

 

一些企業在發生被外界所攻擊或者內部人員的數據竊取等安全事件以後，能夠在日誌審計中查找完整的操做記錄，包括操做的用戶是誰、操做時間是什麼以及對MongoDB的實例作了哪些破壞性竊取性操做，使得用戶有據可查、有證可依，同時在不少的金融領域尤爲是在金融監管需求下，日誌審計成爲一種必要的功能。

 

可用性：同城容災和異地容災

 

 

雲數據庫在MongoDB可用性上所作的一些突破，如一開始所介紹的，MongoDB目前最爲典型的三副本架構能夠比較好地避免單點故障問題，能夠保障有99.95%的SOA承諾，可是對於一些比較核心甚至敏感的業務場景仍是遠遠不夠的，若是整個部署三節點的機房徹底掛掉，例如出現一些斷電斷網的行爲時，整個三節點會在同一時間徹底地不可用，這個時間段內整個應用仍是會受到影響，因此目前阿里雲正在部署一套新的架構，很快將會在頁面上顯示，即支持將每個MongoDB的三副本實例的三個節點部署在同一個城市內的三個機房裏，三個節點之間經過網絡鏈接進行內網的通信，仍是和以前單機房的三副本架構同樣，另外兩個備節點依然從主節點上去同步數據，跟以前所不一樣的是一旦三個機房的其中一個出現了很是嚴重的天然災害致使整個機房掛掉以後，MongoDB目前所支持的一個HA高可用系統會直接將應用流量從掛掉的實例切換到另外兩個依舊正常運行的實例上，即便是整個機房受到天然災害的影響，整個業務依然沒有任何影響。

 

 

在同城容災的基礎上，不少的如一些證監會、銀監會對一些比較敏感的金融業務場景提出兩地三中心部署的架構需求，這樣的需求目前MongoDB已經支持上線，例如用戶在杭州的地域買到一個MongoDB的實例以後，能夠在北京也開啓一個這樣的實例，而阿里雲目前所支持的數據通道工具會將杭州的實例數據準實時地經過通道同步到北京這邊，一旦整個杭州地區出現比較嚴重的故障，整個業務流量能夠總體地從杭州切換到北京，避免業務流量受到城市級天然災害的影響，從而去確保整個應用的高可用保障。

 

輕運維：備份和恢復

 

 

在平常的一些運維操做當中，數據庫主要的一些故障會來自於兩個方面的緣由，第一種是硬件或天然災害的影響，咱們以前所介紹的三節點的高可用保障、同城容災、異地容災這些架構已經可以很好地規避這樣的硬件故障級別的一些問題，但與此同時數據庫容易遭受第二種更爲嚴重的影響，即人爲的一些操做失誤，其最根本最有效的解決方法是作一個數據的歸檔、數據的恢復，全部的雲數據和MongoDB實例目前已經在備份和恢復上面作了很大的改進，一方面在備份上全部的雲數據庫、MongoDB實例都會支持天天定時定點地進行自動備份的操做，徹底不須要人爲的介入。

 

 

此外相比於傳統的用戶經過開源版本自建的數據庫，雲數據庫MongoDB經過對內核的深度優化改良，作出一些很是重要的提高。第一點是流式備份，全部的備份直接經過網絡傳輸到雲存儲OSS上，而不在本地的機器上落地，這樣能夠避免在整個備份過程中對機器所在的IO產生影響，整個備份的速度會有10%左右的提高。第二點是物理備份，相比於官方的備份模式有更大的改進，官方目前支持的邏輯備份方式，在備份和恢復速度方面都比較慢，而在通過內核的改造以後目前已經在雲數據庫MongoDB上實現了物理備份方式的支持，效率上大體有10倍左右的性能提高。

 

 

在恢復方式上，目前所支持的在控制檯上的一個恢復方式稱之爲克隆實例，即將用戶在設置好的備份時間點內所備份的數據文件和日誌文件自動地存儲到一個雲存儲OSS上。當用戶須要作一些恢復操做時，並非單純地直接把以前的一個數據庫備份文件直接恢復成咱們所須要的數據，因爲一些時間點並無產生數據備份，MongoDB支持當用戶指定一個存儲週期內的時間點後，系統會自動地尋找離這個時間點最近的一個備份文件，先將備份恢復出來，而後再經過這份備份文件所存儲的一些日誌文件將整個用戶所須要的數據追溯到用戶所指定的時間點，這個時間點目前能夠支持到7天以內的任意秒級別。同時數據備份並不僅僅直接將恢復作到原來的實際上面，由於一旦恢復以後發現整個恢復的過程、恢復的選項是錯誤的時，數據備份將會受到很是大的影響，因此克隆實例會先將數據恢復到一個全新的實例上面，在恢復完成以後用戶能夠登到全新的實例上去作一些數據的仿真校驗，確認無誤以後，再將咱們須要恢復的部分或所有的數據直接導入到原來的數據庫實例上面，在這個數據恢復的過程中，既能夠確保整個系統恢復安全性的保障，同時整個恢復的過程又不會影響原來數據庫的正常運行。

 

 

在監控方面的改良上，數據監控是數據庫運維很是核心的一個功能，目前在雲數據庫MongoDB上的控制檯會支持用戶查看很是多的包括機器自己的、引擎自己的一些監控數據，同時這些監控數據也會彙總一份到雲監控的產品上，去作一個數據更長期的存儲以及用戶針對這些數據去作一個像報警的預值設置。

 

同時，阿里雲將會在近期支持一個很是獨家的功能，雲數據庫MongoDB版將會支持到整個監控數據的採集力度，從現有的5分鐘級別直接優化到秒級別，即每一秒都會有一個點，這樣採集力度的優化，在平時的運維當中會產生哪些比較大的影響呢？

 

 

以上兩張圖都是對同一個實例在同一個時間段內的採集，上面的圖是分鐘級的採集，下面的圖是秒級別的採集，從中咱們能夠看出，在秒級別中每個數據每個時間段內都有波峯波谷，而在分鐘級的監控圖中，整個監控過程很是的平滑，很難去發現一些問題。在日常的一些運維管理當中會發現，某一段時間內的數據庫或者是整個應用出現的一些比較大的例如應用卡頓等一些方面的影響，可是從監控數據上看整個過程又很是的平滑，很難去發現問題的所在，當切換到秒級別的監控力度上去以後，是能夠很清楚很濃密地看到，在哪一個時間段內性能出現了抖動，哪個監控下出現了問題。基於這樣的數據纔可以更快地去定位到問題所產生的一些緣由，更深一步地去優化這個問題對應用和整個架構所帶來的一些影響，例如一些慢查詢的優化、創建新的索引之類的優化操做。

 

索引推薦：多存儲引擎

 

 

最後是對整個雲數據庫MongoDB上所支持的一個比較獨家特性的介紹，即多存儲引擎的功能，MongoDB官方目前支持的默認存儲引擎是WiredTiger，它的綜合性能很是穩定，一旦用戶使用MongoDB開源的版本去生成數據庫時，默認採用這樣的存儲引擎去支持整個數據的存儲過程，而阿里雲數據庫MongoDB在WiredTiger的基礎上又獨家支持了TerarkDB和RocksDB這兩款存儲引擎，不少用戶根據業務的特性去選擇存儲引擎來達到性能優化、成本縮減的目的。

 

TerarkDB是非支持全局高壓縮技術的存儲引擎，可以大幅度地提升一些隨機查詢的性能，在一些大數據存儲的場景中可以有效地減小整個存儲的成本。而RocksDB存儲引擎支持大數據量持續寫入的場景，在一些官方的文檔上會有比較詳細的介紹。在相同的一些持續大數據寫入的場景測試下，經過第三方的測試工具會發現，RocksDB在該條件下依舊可以保持長時間的很是高的穩定性寫入，推薦用戶若是有大數據量寫入或者大數據量存儲場景能夠經過咱們官方的文檔去了解一下咱們目前所支持的這兩款存儲引擎。

 

 

經過上述的一些介紹，咱們能夠發現相比於用戶自建的MongoDB實例，雲數據庫MongoDB不管是在可用性、擴展性、整個安全上的如訪問控制、審計日誌這樣一些獨家的功能、自動備份、克隆恢復、以及即將獨家支持的秒級監控、索引推薦優化等功能上都存在很是大的優點，若是用戶自建數據庫的話將會投入很是大的開發力量。

 

實踐是檢驗真理的惟一標準——MongoDB的典型場景

 

 

物聯網行業中，因爲許多物聯網設備每時每刻都在經過傳感器向服務端寫入一些數據，因此物聯網第一個特性就是總體的數據量很是大，在這種狀況下MongoDB的集羣版所支持的橫向擴展的能力可以很好地支撐數據量不斷地寫入，而沒必要像一些單機的數據庫那樣一旦達到整個機器上限時還須要另外作鏈接地址、數據庫更換性能的優化操做，Sharding模式能夠持續地實現一個水平能力的擴展。物聯網第二個特性就是數據結構很是靈活，例如可穿戴設備，它所採集的一些數據的特徵都是各不相同的，在這種狀況下咱們一開始所介紹的MongoDB很靈活的文檔型結構就能夠很好地去支撐這種豐富的結構數據擴展。整個物聯網最終訴求就是基於如此大量的數據存儲以後，還須要在這些存儲的數據上面作一個分析最後彙總成一個結果反饋到每個客戶端或服務端上造成一些結果的展現和數據的決策，在這種狀況下MongoDB自身所支持的一些低壓條件能夠很好地去作大數據分析的支持，因此在物聯網這個行業上面不管是從數據的存儲、大數據的支撐以及數據分析的支持上MongoDB各方面的特性均可以獲得很是淋漓盡致的展現。

 

 

遊戲行業中，首先MongoDB Document這樣一個很是靈活的架構支持，能夠支撐遊戲應用上很是多的功能擴展，其次一旦整個遊戲開始進入推廣期以後，它須要不斷地去作一些開服的操做來支撐大量的用戶量，這些開服操做在以前不少的運維的順序是，須要先去建一個服務器，再去建一個一樣的MongoDB數據庫，再經過數據拉取導入等方式將原本數據庫裏的數據轉移到新的數據庫當中，由於遊戲開服之後兩邊的數據庫結構差異不是很大，這樣的一套操做須要消耗運維很是多的時間和精力，因此在這樣的場景之下克隆實例可以很好地發揮這樣的功能，當用戶須要作一個開服操做時，只須要在原先的數據庫實例（稱爲母實例）上面直接經過克隆實例的功能選擇它所須要克隆實例的數量以及它克隆的整個數據須要基於哪一個備份文件和指定一個克隆時間點能夠是當前的時間點，在作完這幾步操做以後，系統會自動根據用戶的訴求生成多個如出一轍的數據庫實例，這些數據庫實例不只能夠在規格和性能上保持一致，同時在裏面的數據上也能夠跟用戶以前的數據庫保持一致，能夠幫助遊戲行業在開服這個操做上提升效率。

 

 

地理信息行業中，首先MongoDB自身自然地支持像地理信息數據索引的一些操做，能夠很方便地應用於一些應用場景，如經緯度的查詢、座標的精確查詢等數據操做的支持，這是MongoDB自己就支持的一些特性。同時地理信息的行業會常常須要從各地採集數據彙總到某個中心庫上造成一個信息的彙總，目前雲數據庫MongoDB已經支持了這樣一個數據通道的功能，能夠幫助用戶很輕鬆地構建這樣一個數據彙總操做，幫助用戶將各地分佈的分佈節點上所存儲的數據自動同步到一箇中心庫上，從而永久性地確保中心庫上的數據永遠是最全面的，同時能夠幫助用戶節省不少像數據同步、數據更新的一些自動同步操做。

閱讀原文http://click.aliyun.com/m/41119/