《從零開始搭建MongoDB數據庫即服務》要點：
本文介紹了從零開始搭建MongoDB數據庫即服務，希望對您有用。如果有疑問，可以聯系我們。

相關主題：非關系型數據庫

講師介紹

鄭涔

阿里云數據庫技術專家

• 目前主要參與阿里云MongoDB云數據庫的研發,致力于讓開發者用上最好的MongoDB云服務；
• 主要關注分布式存儲、NoSQL等技術領域

分享大綱：

1. 什么是數據庫即服務
2. MongoDB
3. 如何搭建一個MongoDB數據庫即服務

一、什么是數據庫即服務(DBaaS)

 

首先介紹一下『數據庫即服務』.『數據庫即服務』其實是『Database-as-a-service』的中文翻譯,我們看看它在維基百科中的定義：

『數據庫即服務』是這樣一種服務模式,它使得應用開發者不再需要自己安裝和維護數據庫,而是由專門的數據庫服務提供商來做,應用開發者可以根據自己的需要去直接使用數據庫服務,并為使用量支付費用即可.我們知道,現在有很多的as-a-service,比如Infrastructure as a Service(IaaS)、Platform as a Service(Paas)還有Software as a Service(Saas).他們到底都是什么呢?有什么區別?

這張圖應該可以很好地解釋這些X-aaS.最左邊是傳統企業的IT,所有的活都要自己干,從數據中心服務器到操作系統數據庫再到上層業務系統.IaaS開始就進入云計算的范疇了,最基礎的是云服務器,不需要再關心機房啊硬件拉,直接就可以用.然后再往右客戶需要關注的越來越少,臟活累活都交給服務提供商來干.

那么『數據庫即服務』的情況是怎么樣呢?

數據庫即服務的優勢

數據庫即服務』其實可以認為是PaaS的一種變種,主要關注點在數據庫上,客戶不再需要去自己部署數據庫,而是只需要按需使用由服務提供商提供的數據庫即可,數據庫的維護都交給服務提供商來完成,這樣客戶只需關注應用本身即可.

我們來具體看一下使用『數據庫即服務』和原來有什么不同,這里除了列舉傳統全部DIY的方式之外,還對比了一種利用IaaS來自建數據庫的方式,這也是現在比較常見的一種做法.我們看到傳統方式,需要做很多事情,這當中還需要涉及多個團隊來協作,非常不容易.然后看看第二種方式,利用IaaS來自建,這里以阿里云的云服務器ECS為例,這種方式和剛剛相比,省了不少事,但是仍然是比較麻煩的,也可能還需要涉及跨團隊協作.

我們再來看看如果是使用『數據庫即服務』呢?只需要點下頁面上的部署按鈕,就可以等著用了,已經進化為完全自助服務了.從時間上來看,第一種方式可能需要花費數月,第二種可能需要花費數天,第三種則只需要數小時即可.可見『數據庫即服務』的優勢還是很明顯的.

為什么要即服務

所以說為什么要『即服務』,其實是一個進化的趨勢.我們經常說人不能太懶,但是懶這個字用在程序猿身上可能并不是不好的東西,因為懶,促使我們會去自動化.最早我們通過人肉操作,下載軟件,編譯部署,然后配置.有一天我們發現經常需要這么干很累很浪費時間,就開始寫腳本來完成這些操作,生產力開始提高.等到規模更大的時候,比如要同時管理數十臺數百臺機器,這時候可能分發腳本也嫌麻煩了,開始寫一些自動化的工具來做這個事情.到最高級階段,就是完全實現自助服務,這是懶的最高境界.

二、MongoDB簡介

說完了『即服務』以及其重要性,接下來我們看一下今天的另一個主角：MongoDB,因為有些同學可能對這個不了解,所以還是簡單介紹一下.

首先,MongoDB是什么呢,它是一個Document Store,文檔型數據庫,也是我們經常說的NoSQL.根據DB-Engines的數據庫排名,MongoDB長期霸占著NoSQL老大的地位,現在是數據庫界一位重量級選手.

事實上,MongoDB可以稱為是一種NewSQL,它融合了傳統關系型數據庫和NoSQL的一些優點.

最左邊的3個能力是來自于關系型數據庫：

• 首先,它具備豐富的查詢語句和二級索引.通過這點,用戶可以以足夠復雜的方式來訪問和組織數據.
• 第二點,強一致性.MongoDB支持一個靈活的一致性模型.你可以選擇使用強一致性,或最終一致性,取決于你的業務場景.
• 第三點,MongoDB能很好的集成到多企業現有技術架構中.

右邊3個能力來自NoSQL：

• 首先是靈活的數據模型,MongoDB的文檔模型允許動態修改schema,不用擔心有任何的性能影響.
• 其次是高性能和高可擴展性,MongoDB可以輕松進行水平擴展,從而帶來更高的吞吐和更低的延遲.
• 最后,是全球部署,也就是高可用.接下來我們就來具體講下MongoDB的幾個關鍵特性.

MongoDB的關鍵特性

MongoDB的關鍵特性主要是3個,第一個就是靈活動態的文檔模型,第二個是高可用副本集,第三個是MongoDB的水平擴展,也就是sharding.

1、靈活動態的文檔模型

MongoDB以一種叫做BSON(二進制JSON)的存儲形式將數據作為文檔存儲.具有相似結構的文檔通常被組織成集合.可以把集合看成類似于關系數據庫中的的表：文檔對應的是行,字段對應的是列.

MongoDB將一條記錄的所有數據聚合在一個文檔中,而在關系數據庫中則傾向于將數據分布在多個表中.這樣做有幾個好處,一是由于數據聚集,減少了多表JOIN的需求,這樣只需要讀一次就可以讀到所有數據,在性能上會有很大優勢.

另外,這種模型更加接近我們平時編程語言中的對象結構,可以方便開發者進行數據映射.

最后就是這種模型是schema-less的,也就是在MongoDB中不需要像關系數據庫一樣去事先定義每個表的schema.MongoDB一個集合內的文檔之間可以擁有不同的結構,可以輕松為一個新的文檔添加和減少字段,不會有任何的性能影響.這個特性非常適合開發一些新產品,可以快速迭代.

當然,過于靈活就可能導致混亂.有時候我們想要求文檔必須要有某些字段,某些字段必須要有固定的類型.為此,MongoDB提供了一個文檔驗證功能來對文檔的格式進行約束.

2、高可用副本集

接下來說MongoDB的第二個關鍵特性,高可用副本集(也可以翻譯成復制集).

MongoDB副本集由一組Mongo實例(進程)組成,包含一個Primary節點和多個Secondary節點,Mongodb Driver(客戶端)的所有數據都寫入Primary,Secondary從Primary同步寫入的數據,以保持副本集內所有成員存儲相同的數據集,提供數據的高可用.

上圖是一個典型的MongDB副本集,包含一個Primary節點和2個Secondary節點.

副本集通過replSetInitiate命令(或mongo shell的rs.initiate())進行初始化,初始化后各個成員間開始發送心跳消息,并發起Primary選舉操作,獲得『大多數』成員投票支持的節點,會成為Primary,其余節點成為Secondary.

這里『大多數』的定義是副本集內可投票成員的一半以上,當副本集內存活成員數量不足大多數時,整個副本集將無法選舉出Primary,此時副本集將無法提供寫服務,處于只讀狀態.通常建議將副本集成員數量設置為奇數,因為偶數個節點能容忍的節點失效和比它少1個節點的奇數個節點是一樣的,但是可以節省一個節點的數據存儲成本.

除了初始化的時候會進行選舉,MongoDB副本集的高可用服務體現在,當副本集中沒有Primary節點時,選舉都會進行.比如當Primary節點宕機時,剩下的Secondary節點中會選舉出新的Primary(只需要滿足大多數成員存活的條件).選舉使用的算法是基于Raft協議,但是可以通過為節點配置選舉優先級對選舉結果進行控制.

此外需要提一下,有一些比較常見的特殊的Secondary.一個是Hidden,Hidden節點和普通的Secondary的區別是它是對Driver隱藏的節點,也就是客戶端無法訪問到Hidden,另外就是它的選舉優先級是0,也就是它不能被選舉為Primary.Hidden節點上擁有數據,因此通常會用來作一些運維任務,如數據備份、計算分析等.

另外還有一個是Arbiter,Arbiter是只參與投票,但是不存儲數據的節點,這可以用在對可用性有要求,又要嚴格控制成本的場景.

此外還有如Priority0節點、Delayed節點等.

3、MongoDB的水平擴展

MongoDB提供了一種水平擴展的方式,叫做sharding,通過這種方式對數據庫進行擴容,對應用是透明的.通過sharding,可以將一個集合的數據散到多個shard節點上.這里每個shard都可以是一組副本集.應用程序通過一個路由節點(mongos)來訪問sharding集群的數據.有了sharding,MongoDB就可以突破單機的限制,比如磁盤、內存和IOPS等,從而提供更強大的服務能力.

Sharded cluster由Shard、Mongos和Config server 3個組件構成.Mongos本身并不持久化數據,Sharded cluster所有的元數據都會存儲到Config Server,而用戶的數據則會分散存儲到各個shard.Mongos啟動后,會從config server加載元數據,開始提供服務,將用戶的請求正確路由到對應的Shard.

Sharded cluster支持將單個集合的數據分散存儲在多個shard上,用戶可以指定根據集合內文檔的某個字段即shard key來分布數據,目前主要支持2種數據分布的策略,范圍分片(Range based sharding)或hash分片(Hash based sharding).

范圍分片下,文檔是根據其shard key的值進行分片.shard key的值相鄰近的文檔比較有可能會被放在同一個shard上,這種方式適用于需要使用范圍查詢的業務.

哈希分片下,文檔根據其shard key的hash值進行分片.這會保證數據分布比較均勻,但是不利于范圍查詢.

隨著數據量的增多,MongoDB也會自動在后臺對數據以chunk為單位進行負載均衡.

三、如何搭建MongoDB數據庫即服務

接下來介紹一下今天的重點內容,如何搭建一個MongoDB數據庫即服務.

首先,在我看來,數據庫即服務,應該具備這些特性：自動化、按需服務、彈性、安全、高可用和可量化：

• 第一個,自動化,這是非常關鍵的,是實現自助服務的基礎,所有可以被自動化操作的流程都應該被自動化,不需要人工干預.
• 第二個,按需服務,數據庫即服務應該是由用戶驅動的,后臺應該要有一個工作流的機制來對需求進行響應.
• 第三個,彈性,可以按需動態擴縮容.
• 第四個,安全,這是毋庸置疑的.
• 第五個,高可用,宕機自動切換.
• 第六個,可量化,服務的使用量可以被衡量、報告并且是可控的.

此圖為數據庫即服務應具備的功能大圖.主要包括生命周期管理、容災體系、監控報警、數據管理和增值服務：

• 生命周期管理包括數據庫實例的新建、釋放、擴縮容等,這是數據庫即服務最基礎的功能.
• 容災體系包括高可用、備份恢復,甚至更高級的如異地容災/多活等等.
• 監控報警一方面就是服務使用量的監控,另一方面則是報警,包括服務不可用的報警,以及一些監控數據異常的報警.
• 數據管理指的就是可以方便的對數據進行管理,如可以提供一些圖形化界面等.
• 增值服務包括審計、診斷服務等.其中審計是數據庫的一個非常重要的功能,一方面可以幫助查證問題,另一方面可以為一些數據分析或診斷提供數據源.診斷服務一方面跟蹤服務的資源使用量,為是否需要擴縮容提供決策依據,另一方面主要為慢查詢提供優化建議.

數據庫即服務的核心架構就是工作流引擎,這是實現自動化及按需服務的基礎.

1、生命周期管理

生命周期管理功能包括數據庫實例的新建、釋放、擴縮容以及遷移.新建一個數據庫實例包括分配資源(主要是主機資源)、安裝數據庫、初始化配置.對MongoDB來說,副本集涉及多個節點,涉及到資源的分配策略,Sharding更多.另外副本集還需要一些初始化工作,sharding需要有一個各組件的組合.釋放實例比較簡單,主要是資源的回收.擴縮容可以分為本地和跨機的擴縮容,其實跨機的擴縮容就是遷移.對于MongoDB來說,遷移可以直接利用MongoDB的添加節點自動同步的特性,還是比較方便的.

生命周期管理功能主要涉及這幾個組件,包括資源管理、規格及配置管理、軟件棧管理和負載均衡：

• 資源管理主要是指主機資源的管理,這里主機可以是物理機,也可以是虛擬機,如云主機等.資源管理主要負責資源的分配和回收,此外還包括如何實施資源隔離.
• 規格及配置管理一個是需要為數據庫實例制定一些規格,以方便擴容和縮容,另一方面是負責數據庫相關配置的維護.
• 軟件棧管理則包括數據庫軟件以及其依賴的軟件的安裝維護等,包括操作系統.
• 除了這些,還需要一個負載均衡組件來保證數據庫實例在資源上的分布的均衡,當有主機資源需要下線的時候,能夠做到自動對其上的數據庫實例進行遷移.

對于MongoDB來說,在實施資源分配策略時需要注意的一點是需要保證不要破壞副本集原本的高可用特性.雖然MongoDB副本集自帶了高可用,但是如果你把副本集的所有節點都分布在一臺物理機上,那如果這個物理機掛了,整個副本集都沒用了.所以一個起碼的原則是要保證MongoDB多副本的主機安全性,盡可能夠做到機架安全.

現在我們的MongoDB數據庫即服務的架構可以稍微擴充一下了,多了資源服務、規格及配置服務、軟件棧服務以及負載均衡服務這幾個組件.

2、容災體系

接下來看一下容災體系,這包括高可用、備份/恢復、異地容災/多活.高可用需要有一個負責健康檢查的巡檢服務,另外還需要有一個容災切換的組件.備份/恢復也是容災體系非常重要的一環,這里有一個很容易被忽視的事情是需要做備份的有效性驗證.如果備份不是有效的,那等于沒有備份.異地容災/多活是比較高級的容災能力,實施起來比較復雜,有興趣的同學可以參考我之前做過的一個分享《MongoDB異地容災多活實踐》.

(鏈接：https://yq.aliyun.com/articles/96598)

MongoDB副本集自帶了高可用,我們還需要做什么工作呢?主要是需要保證容災切換的一個可控.以一個經典的3節點P/S/H副本集為例,一方面我們可以通過配置選舉優先級的方式來保持Primary和Secondary的角色穩定性.另一方面,我們希望在任意時刻,用戶都可以有兩個節點是可訪問的,因此我們需要對節點宕機后的副本集做一些reconfig操作,保證宕機節點最終都會變成Hidden,然后統一對Hidden進行處理,比如重搭等.

容災體系第二個比較重要的點就是備份恢復.備份主要需要做的是需要提供自動/手動的備份方式以及支持一些靈活的備份策略制定,如備份周期/備份保留時間等.恢復主要是看對恢復的形態做成什么樣,是覆蓋原來的實例還是克隆出一個新的實例來,還有就是恢復的粒度,這取決于備份能力,是只能恢復到某個全量備份,還是可以恢復到任意時間點.關于備份存儲,我們要求的最要 能力是高可靠性.另外就是剛剛提過的備份有效性驗證,不能等到火燒眉毛了才發現備份不可用,需要防范于未然.

關于MongoDB的備份方法,相關的文檔和分享已經有很多了,這里再簡單提一下.全量備份從實施方式上可以分為兩種,邏輯備份和物理備份.其中邏輯備份主要使用官方提供的mongodump/mongorestore工具.物理備份則可以在文件系統或是更底層的邏輯卷、塊設備這層去做.

從各個指標上對比邏輯備份和物理備份,在備份和恢復效率上,物理備份的優勢比較明顯,不過邏輯備份在兼容性上會比較好.

MongoDB的增量備份主要通過持續的抓取oplog來實現.有了全量備份加增量備份,就可以實現恢復到任意時間點.

至此,我們的MongoDB數據庫即服務的架構又可以得到一個比較大的擴充,主要增加了高可用以及備份相關的一些服務.

3、監控報警

接下來看下數據庫的監控報警,性能監控主要涉及性能數據的采集、存儲和展示.采集粒度越細越好,最好能做到秒級.報警則可以分為可用性的報警和性能數據的報警.

具備監控報警能力后的架構圖已經有點滿了,這里報警服務可以通過巡檢服務和性能數據存儲收集相關數據.

4、增值服務

來看最后一個增值服務,一個是審計,主要涉及審計日志的采集、存儲和分析.另一個是診斷服務,一個是資源使用量上的診斷,另外一個是慢查詢的診斷,可以做一些索引推薦等.

這就是我們的MongoDB數據庫即服務的完整架構,可以看到組件還是比較多的,做一個數據庫即服務還不是那么容易的.

總結

最后做一下總結,我認為數據庫即服務的核心特性有兩點,一個是資源池化,另外一個是服務可量化.

資源池化后才可以進行資源的自動管理,而我們需要的服務是要能夠被量化的,并且是可控的.現在回顧一下之前的一鍵安裝數據庫,其實背后有許多工作要做.當然,如果覺得自己搭建一個數據庫即服務太麻煩,可以考慮使用現成的云服務,比如阿里云MongoDB數據庫服務：)

Q&A

Q1：這些阿里云上都有嗎?還是內部再用?池化是多實例還是Docker ?

A1：這些服務,現在阿里云上的云數據庫MongoDB都做了,雖然有些功能可能還沒有暴露在控制臺上.多實例還是Docker,具體選擇的技術,其實都可以的.

Q2：想把MySQL的指定表數據存儲到阿里云的MONGODB有好的實現方式么?

A2：這個有一些工具可以干這個事情,可以關注阿里云的DTS服務,主要是在數據庫中進行數據遷移,另外還有一個datax可以做異構數據庫之間的導入導出.

Q3：Mongo單個collection數據達到億級別需要考慮拆分嗎

A3：億級別可以考慮使用sharding了.

Q4：它與Redis的區別主要是什么?

A4：Redis更多可能還是緩存場景吧,MongoDB支持二級索引,可以支持很復雜的查詢.

Q5：測試插入200W數據,為什么各個分片分配不均衡呢,其中一個分片占比非常高.shard key 是遞增的.

A5：shard key遞增就會導致在插入時都插入在一個shard上,發揮不了sharding的優勢,可以考慮再組合一個字段作為shard key.

https://m.qlchat.com/topic/details?topicId=270000444113427&isGuide=Y

密碼：221

原文來自微信公眾號：DBAplus社群

轉載請注明本頁網址：
http://www.snjht.com/jiaocheng/1952.html