基于MongoDB的配置管理平臺(tái)應(yīng)用研究

葉思斯，林志達(dá)，郭獻(xiàn)彬，曹小明

（1.中國(guó)南方電網(wǎng)數(shù)字電網(wǎng)研究院有限公司，廣東廣州 510663；2.中國(guó)南方電網(wǎng)有限責(zé)任公司，廣東廣州 510670）

隨著互聯(lián)網(wǎng)行業(yè)的進(jìn)一步發(fā)展，數(shù)據(jù)呈爆炸式增長(zhǎng)趨勢(shì)。大數(shù)據(jù)已經(jīng)逐漸成為社會(huì)發(fā)展的重要組成部分，而社會(huì)也逐步邁入了大數(shù)據(jù)發(fā)展的時(shí)代［1］。但是隨著數(shù)據(jù)量的逐漸增多，傳統(tǒng)的儲(chǔ)存方式已經(jīng)無(wú)法適應(yīng)當(dāng)今的發(fā)展需求［2］。在此背景下，研究者開(kāi)始尋求新興的數(shù)據(jù)處理以及存儲(chǔ)技術(shù)，其中，云存儲(chǔ)技術(shù)作為一種通用型強(qiáng)、可靠性高等優(yōu)勢(shì)已經(jīng)逐漸成為了大規(guī)模數(shù)據(jù)存儲(chǔ)的重要技術(shù)之一［3］。所謂云存儲(chǔ)技術(shù)是指一種基于云計(jì)算技術(shù)的新興存儲(chǔ)技術(shù)，當(dāng)云計(jì)算技術(shù)可以和云存儲(chǔ)技術(shù)相互轉(zhuǎn)化，當(dāng)云計(jì)算系統(tǒng)需要進(jìn)行大量的數(shù)據(jù)存儲(chǔ)以及管理工作時(shí)，云計(jì)算系統(tǒng)就可以轉(zhuǎn)換為云存儲(chǔ)技術(shù)。云儲(chǔ)存技術(shù)也可以被看作為一種數(shù)據(jù)服務(wù)技術(shù)［4］。在實(shí)際應(yīng)用中，云存儲(chǔ)技術(shù)研究由于起步較晚，發(fā)展不夠成熟，在使用方面往往存在著安全性較差、帶寬限制以及數(shù)據(jù)管理等方面的問(wèn)題［5］。這些問(wèn)題嚴(yán)重制約了云儲(chǔ)存技術(shù)的發(fā)展。而現(xiàn)階段，針對(duì)云儲(chǔ)存相關(guān)技術(shù)的設(shè)計(jì)與優(yōu)化已經(jīng)成為了互聯(lián)網(wǎng)領(lǐng)域研究的熱點(diǎn)問(wèn)題，引發(fā)了研究者廣泛關(guān)注。

NoSQL是近年來(lái)發(fā)展較快的一種云存儲(chǔ)數(shù)據(jù)庫(kù)類(lèi)型，與傳統(tǒng)數(shù)據(jù)庫(kù)不同，NoSQL數(shù)據(jù)庫(kù)不需要遵循基本要求，其數(shù)據(jù)存儲(chǔ)方式也更加靈活［6］。其中MongoDB是NoSQL中功能最為豐富也是應(yīng)用最長(zhǎng)的數(shù)據(jù)庫(kù)之一。MongoDB主要是面向文檔的一種數(shù)據(jù)庫(kù)類(lèi)型，可以支持BSON格式的數(shù)據(jù)，數(shù)據(jù)存儲(chǔ)模式自由、結(jié)構(gòu)松散［7］。MongoDB應(yīng)用優(yōu)勢(shì)顯著，具有部署性強(qiáng)、性能高以及使用簡(jiǎn)便等優(yōu)點(diǎn)。其語(yǔ)言查詢功能強(qiáng)大，可實(shí)現(xiàn)關(guān)系數(shù)據(jù)庫(kù)中絕大部分的查詢功能，同時(shí)MongoDB也可以支持建立數(shù)據(jù)索引功能。

本研究基于MongoDB的基本理論與概念，提出了基于片鍵類(lèi)型優(yōu)化、數(shù)據(jù)查詢優(yōu)化以及數(shù)據(jù)存儲(chǔ)優(yōu)化3個(gè)方面的MongoDB分片集群系統(tǒng)優(yōu)化方案。為檢測(cè)優(yōu)化效果，研究分別檢測(cè)了在不同分片環(huán)境下的MongoDB數(shù)據(jù)插入性能以及數(shù)據(jù)查詢性能，明確了優(yōu)化效果。

1 方法

1.1 MongoDB分片集群部署構(gòu)成

本研究中的MongoDB分片集群部署構(gòu)成示意圖如圖1所示。

圖1 MongoDB分片集群部署示意圖Fig.1 Schematic diagram of MongoDB sharding cluster deployment

由圖1可知，在本研究中MongoDB分片集群主要由Mongos、config server、mongod以及monitor等主要模塊組成［8］。其中，Mongos是整個(gè)MongoDB分片集群中的路由服務(wù)器。通過(guò)Mongos可以使MongoDB分片集群中的客戶端以及服務(wù)端進(jìn)行連接。用戶發(fā)送的請(qǐng)求將通過(guò)Mongos發(fā)送至不同的服務(wù)器中。為進(jìn)一步提高M(jìn)ongoDB的穩(wěn)定性以及可靠性，在本研究中使用集群的方式對(duì)Mongos進(jìn)行搭建。config server是存儲(chǔ)數(shù)據(jù)分片以及數(shù)據(jù)塊中具體信息的主要結(jié)構(gòu)，當(dāng)MongoDB運(yùn)行時(shí)，config server負(fù)責(zé)將相關(guān)信息提供給Mongos，保證了Mongos的可靠性。同時(shí)，config server也可以擴(kuò)展為集群。Mongod主要負(fù)責(zé)MongoDB的實(shí)際操作，包括數(shù)據(jù)塊的存儲(chǔ)、數(shù)據(jù)的查詢、數(shù)據(jù)的插入以及數(shù)據(jù)的實(shí)例化等操作。而monitor在MongoDB分片集群中主要起到數(shù)據(jù)監(jiān)控的作用。通過(guò)monitor可以監(jiān)控系統(tǒng)的負(fù)載均衡狀態(tài)、數(shù)據(jù)操作頻率以及讀寫(xiě)基本耗時(shí)等內(nèi)容。

1.2 MongoDB數(shù)據(jù)庫(kù)優(yōu)化方案設(shè)計(jì)

本研究主要從片鍵類(lèi)型、數(shù)據(jù)查詢以及數(shù)據(jù)存儲(chǔ)3個(gè)方面對(duì)MongoDB進(jìn)行系統(tǒng)優(yōu)化分析。具體優(yōu)化內(nèi)容如下。

1.2.1 片鍵類(lèi)型優(yōu)化

片鍵是分片集群中最常用的索引，當(dāng)設(shè)定MongoDB中的某個(gè)索引為片鍵時(shí)，分片集群會(huì)根據(jù)片鍵的設(shè)定來(lái)對(duì)數(shù)據(jù)進(jìn)行劃分［9］。同時(shí)在進(jìn)行分片后，片鍵直接決定了數(shù)據(jù)的存放情況。因此片鍵的選擇十分重要，不恰當(dāng)?shù)钠I往往會(huì)使系統(tǒng)的性能降低，無(wú)法適應(yīng)較高的訪問(wèn)量；而恰當(dāng)?shù)钠I則可以進(jìn)一步提高系統(tǒng)的性能，確保系統(tǒng)良好運(yùn)行［10］。

常用的片鍵類(lèi)型主要分為小基數(shù)片鍵、升序片鍵以及Hash片鍵等。本研究中小基數(shù)片鍵的數(shù)量有限，在實(shí)際使用時(shí)往往會(huì)產(chǎn)生眾多體積較大且難以移動(dòng)的數(shù)據(jù)塊。升序片鍵則主要是以ID字段作為片鍵，在沒(méi)使用升序片鍵時(shí)可以將最新產(chǎn)生的數(shù)據(jù)集中起來(lái)，可以大幅度提高數(shù)據(jù)的讀取性能［11］。Hash片鍵是一種基于范圍的分片形式，其主要優(yōu)點(diǎn)為存儲(chǔ)和讀取的操作都均勻分布，并且消除了數(shù)據(jù)塊過(guò)大的問(wèn)題［12］。

基于實(shí)際需求和考慮，本研究選取了資源標(biāo)簽作為組合片鍵中的搜索鍵。同時(shí)，本文使用時(shí)段鍵來(lái)控制數(shù)據(jù)的局部化，時(shí)段鍵數(shù)目的取值需要保證在足夠大的同時(shí)又不超出系統(tǒng)所能承受的最佳處理范圍。本研究使用｛Month：1，Label：1｝的組合片鍵形式。其中Month字段作為主片鍵，表示資源上傳的時(shí)間，Labe字段作為第二片鍵，表示系統(tǒng)資源。在設(shè)定中，系統(tǒng)運(yùn)行超過(guò)兩年時(shí)，即n＞24，在這一范圍內(nèi)既可以保證數(shù)據(jù)的局部化又可以使每個(gè)時(shí)間段對(duì)應(yīng)多個(gè)數(shù)據(jù)塊。

1.2.2 數(shù)據(jù)查詢優(yōu)化

數(shù)據(jù)查詢優(yōu)化主要包括兩方面的內(nèi)容，分別是查詢數(shù)據(jù)優(yōu)化以及搜索鍵優(yōu)化。在某些情況下，MongoDB會(huì)將查詢后的結(jié)果分配到可能的幾個(gè)分片內(nèi)，隨后將執(zhí)行后的結(jié)果信息匯總起來(lái)反饋給客戶端［13］。這種工作模式極容易造成資源的消耗，同時(shí)也增加了操作的使用時(shí)間。在本研究中主要采用sort（）來(lái)排序查詢數(shù)據(jù)，以片鍵中的第一個(gè)字段為排序依據(jù)，隨后系統(tǒng)按照事先排序好的順序進(jìn)行查詢，再將執(zhí)行結(jié)果反饋給用戶，降低反應(yīng)時(shí)間以及資源占用程度。

搜索鍵的優(yōu)化主要以時(shí)段鍵以及搜索鍵作為片鍵，該組合方式可以使同類(lèi)型的數(shù)據(jù)集中在較少的分片上，有利于數(shù)據(jù)的查詢以及下載操作。同時(shí)，本文將用戶的ID作為搜索鍵的一部分，自動(dòng)添加進(jìn)搜索鍵的標(biāo)簽內(nèi)容中，解決了用戶在查詢和讀取本人的數(shù)據(jù)時(shí)系統(tǒng)查詢負(fù)荷過(guò)大的問(wèn)題。

1.2.3 數(shù)據(jù)存儲(chǔ)優(yōu)化

在MongoDB空間不足時(shí)需要自動(dòng)申請(qǐng)相應(yīng)的硬盤(pán)空間，申請(qǐng)空間的大小為64 M、128 M以及256 M并逐漸上升，最高申請(qǐng)上限為2G。但是在該種自動(dòng)分片的機(jī)制下容易導(dǎo)致內(nèi)存以及硬盤(pán)的占用。其示意圖如圖2所示。

圖2 數(shù)據(jù)存儲(chǔ)次序Fig.2 Data storage sequence

已知共有Shard01、Shard02以及Shard03 3個(gè)片，其負(fù)載分別為400、300以及700。假設(shè)此時(shí)需要插入一組新的數(shù)據(jù)，由于其數(shù)據(jù)儲(chǔ)存是按照時(shí)間順序進(jìn)行排列的，因此當(dāng)寫(xiě)入新數(shù)據(jù)時(shí)首先會(huì)寫(xiě)入到Shard03片中，此時(shí)則會(huì)導(dǎo)致shard03負(fù)載過(guò)高，而Shard01和Shard02負(fù)載過(guò)低，造成資源的浪費(fèi)。因此在實(shí)際應(yīng)用中常常需要使用數(shù)據(jù)均衡算法進(jìn)行優(yōu)化。而在MongoDB的優(yōu)化算法中常常根據(jù)數(shù)據(jù)量的大小來(lái)統(tǒng)計(jì)負(fù)載的方式。此種方法在實(shí)際運(yùn)行過(guò)程中存在諸多問(wèn)題，實(shí)際應(yīng)用效果較差。

為解決此問(wèn)題，基于數(shù)據(jù)被查詢的概率來(lái)進(jìn)行系統(tǒng)的數(shù)據(jù)存儲(chǔ)優(yōu)化。該方案利用FODO算法思想進(jìn)行實(shí)驗(yàn)數(shù)據(jù)存儲(chǔ)優(yōu)化，首先利用數(shù)據(jù)被查詢的概率來(lái)計(jì)算查詢負(fù)載，隨后將所有存儲(chǔ)對(duì)象按照查詢負(fù)載由小到大派別，假設(shè)集群中的某一分片被刪除，該片中的數(shù)據(jù)塊就會(huì)以被查詢的概率來(lái)決定存儲(chǔ)的位置，進(jìn)而提高查詢的速度。

1.3 FODO算法

本研究利用FODO算法進(jìn)行優(yōu)化的步驟如下。

首先，計(jì)算出第i個(gè)數(shù)據(jù)塊被訪問(wèn)的概率，公式如下所示：

其中，P為第i個(gè)數(shù)據(jù)塊被查詢的次數(shù)和全體數(shù)據(jù)被查詢的次數(shù)的比值。由式（1）可以看出，對(duì)所有數(shù)據(jù)塊而言，其分母均相同。因此P可以通過(guò)單位時(shí)間內(nèi)數(shù)據(jù)塊的查詢次數(shù)排序來(lái)代替。

因此，在數(shù)據(jù)文檔中添加查詢的頻率鍵F，其表達(dá)式為

其中，F(xiàn)表示第i個(gè)數(shù)據(jù)塊被查詢的頻率。

在實(shí)際應(yīng)用中發(fā)現(xiàn)，部分?jǐn)?shù)據(jù)在不同的時(shí)間段查詢的頻率也不盡相同，為確保數(shù)據(jù)查詢的時(shí)效性，需要統(tǒng)計(jì)最近一段時(shí)間的查詢頻率，而本研究通過(guò)調(diào)整資源可知，將時(shí)間段的長(zhǎng)度設(shè)置為一個(gè)月是最佳的選擇，因此將式（2）中的時(shí)間段長(zhǎng)度設(shè)置為1個(gè)月，則該公式可以被改寫(xiě)為

又因?yàn)槭剑?）中的t為固定值，因此可以進(jìn)一步簡(jiǎn)化式（3），即可得出一個(gè)月內(nèi)的查詢次數(shù)C，公式如下所示：

其中，F(xiàn)it為第i個(gè)數(shù)據(jù)塊在t時(shí)間段內(nèi)的查詢總數(shù)。

所有數(shù)據(jù)塊的值的總和如下所示：

當(dāng)開(kāi)啟新節(jié)點(diǎn)時(shí)，可以與鏈表中的其他對(duì)象所對(duì)應(yīng)的C值進(jìn)行對(duì)比，從而實(shí)現(xiàn)排序操作。在均衡器進(jìn)行數(shù)據(jù)遷移時(shí)也可以根據(jù)數(shù)據(jù)塊中對(duì)應(yīng)的C值進(jìn)行統(tǒng)計(jì)，分析存儲(chǔ)對(duì)象的查詢負(fù)載，決定數(shù)據(jù)點(diǎn)存儲(chǔ)次序，從而實(shí)現(xiàn)數(shù)據(jù)的存儲(chǔ)優(yōu)化。

1.4 實(shí)驗(yàn)測(cè)試環(huán)境

本研究主要測(cè)試環(huán)境如表1所示。

表1 實(shí)驗(yàn)測(cè)試環(huán)境Tab.1 Experimental test environment

2 結(jié)果與討論

2.1 MongoDB數(shù)據(jù)庫(kù)插入操作分析

2.1.1 3個(gè)不同分片環(huán)境下的插入分析

本研究主要討論了升序片鍵、Hash片鍵以及優(yōu)化片鍵這3種分片環(huán)境下MongoDB數(shù)據(jù)庫(kù)的相關(guān)性能，具體討論了在150萬(wàn)條數(shù)據(jù)插入時(shí)，數(shù)據(jù)的分布規(guī)律以及數(shù)據(jù)的寫(xiě)入速度，具體內(nèi)容如圖3-5所示。

由圖3可知，在升序分片的環(huán)境下，數(shù)據(jù)插入后的分片差距過(guò)大，分布極不均衡。其中，Shard01的插入數(shù)據(jù)占比為81.94%，而Shard03的插入數(shù)據(jù)占比僅為18.06%，在Shard02區(qū)域甚至出現(xiàn)了沒(méi)有數(shù)據(jù)輸入的情況。而在Hash分片以及優(yōu)化分片的情況下均可使數(shù)據(jù)較為均勻地分布在各個(gè)區(qū)域內(nèi)。其中，在Hash片鍵的環(huán)境下，Shard01-Shard03的插入數(shù)據(jù)分布占比分別為30.42%、37.94%以及31.64%；而在優(yōu)化片鍵的環(huán)境下Shard01-Shard03的插入數(shù)據(jù)分布占比分別為32.45%、35.34%以及32.21%；優(yōu)化分片的效果略好于Hash分片。產(chǎn)生這種現(xiàn)象的主要原因是在升序分片中，當(dāng)數(shù)據(jù)插入時(shí)往往會(huì)在最新的片上進(jìn)行，造成數(shù)據(jù)分布不均。而優(yōu)化分片擁有升序分片與Hash分片的優(yōu)點(diǎn)，在保證數(shù)據(jù)確定分布的情況下又可以避免數(shù)據(jù)過(guò)度集中。

圖3 升序片鍵數(shù)據(jù)插入性能分析Fig.3 Performance analysis of ascending slice key data insertion

圖4 Hash片鍵數(shù)據(jù)插入性能分析Fig.4 Hash key data insertion performance analysis

圖5 優(yōu)化片鍵數(shù)據(jù)插入性能分析Fig.5 Optimized slice key data insertion performance analysis

在3種分片環(huán)境下，數(shù)據(jù)寫(xiě)入速度也有著較大的區(qū)別，當(dāng)數(shù)據(jù)量分別在100萬(wàn)-700萬(wàn)條時(shí)，在升序片鍵環(huán)境下，數(shù)據(jù)寫(xiě)入速度為7000條/秒至9000條/秒。而在Hash片鍵以及優(yōu)化片鍵的環(huán)境下，插入速度則在3000條/秒至4000條/秒之間。結(jié)果顯示在升序分片的環(huán)境下，數(shù)據(jù)插入的速度最快。

2.1.2 插入方式測(cè)試

同時(shí)，本研究還分析了在優(yōu)化片鍵分片的條件下，不同數(shù)據(jù)插入方式對(duì)MongoDB性能的影響，以插入所需時(shí)間作為評(píng)判依據(jù)，主要分析了批量插入以及逐條插入這兩種數(shù)據(jù)插入方式的影響。具體結(jié)果如圖6所示。

由圖6可知，在數(shù)據(jù)量分別為100萬(wàn)條至700萬(wàn)條時(shí)，數(shù)據(jù)逐條插入以及數(shù)據(jù)批量插入時(shí)所需的時(shí)間基本相同，差距不大。結(jié)果表明，在該條件下插入方式的不同并不會(huì)影響MongoDB數(shù)據(jù)庫(kù)的相關(guān)性能。

圖6 逐條插入與批量插入的性能分析Fig.6 Performance analysis of strip insert and batch insert

2.2 MongoDB數(shù)據(jù)庫(kù)查詢操作分析

本研究同時(shí)分析了在3種不同分片環(huán)境下數(shù)據(jù)查詢的相關(guān)性能，本文以查詢速度作為查詢?cè)u(píng)價(jià)指標(biāo)。具體結(jié)果如圖7所示，其中圖7（a）-7（c）分別為升序片鍵、Hash片鍵以及優(yōu)化片鍵的數(shù)據(jù)查詢速度結(jié)果。

由圖7可知，當(dāng)數(shù)據(jù)量分別為100萬(wàn)-700萬(wàn)條時(shí)，在升序片鍵的環(huán)境下，數(shù)據(jù)查詢速度在4000條/秒至6000條/秒之間；在Hash片鍵的環(huán)境下，數(shù)據(jù)查詢速度最小，基本維持在1000條/秒左右。而在優(yōu)化片鍵的環(huán)境下，數(shù)據(jù)查詢速度最大，在1萬(wàn)條/秒至1.2萬(wàn)條/秒之間。結(jié)果表明，在優(yōu)化片鍵的環(huán)境下，MongoDB的查詢性能最好。

3 結(jié) 論

本研究主要探討了MongoDB集群的系統(tǒng)優(yōu)化以及相關(guān)的測(cè)試研究。主要分析了在升序片鍵、Hash片鍵以及優(yōu)化片鍵3種不同分片條件下數(shù)據(jù)的插入性能以及數(shù)據(jù)的查詢性能?？傻贸鋈缦陆Y(jié)論：（1）在插入數(shù)據(jù)分布規(guī)律測(cè)試中，升序分片中數(shù)據(jù)分布差距較大，Shard01插入數(shù)據(jù)占比為81.94%，Shard03的插入數(shù)據(jù)占比僅為18.06%，而在Shard02區(qū)域無(wú)數(shù)據(jù)插入。（2）在Hash分片以及優(yōu)化分片環(huán)境下數(shù)據(jù)分布較為均勻，其中，優(yōu)化分片環(huán)境下速度分布最為均勻，3個(gè)區(qū)域的數(shù)據(jù)分布占比均在33%左右。（3）數(shù)據(jù)插入速度則是升序分片下速度最快，Hash分片以及優(yōu)化分片的數(shù)據(jù)插入速度基本一致。同時(shí)，研究還表明，逐條插入以及批量插入這兩種插入方式對(duì)MongoDB的數(shù)據(jù)插入所需時(shí)間并無(wú)明顯影響。數(shù)據(jù)查詢結(jié)果表明，在數(shù)據(jù)量分別為100萬(wàn)-700萬(wàn)條時(shí)，在優(yōu)化片鍵的環(huán)境下，數(shù)據(jù)查詢速度范圍為1萬(wàn)條/秒至1.2萬(wàn)條/秒之間。在優(yōu)化片鍵環(huán)境下查詢速度最大，查詢性能最好。綜合上述結(jié)果可知，在優(yōu)化后的分片環(huán)境下數(shù)據(jù)插入性能以及數(shù)據(jù)查詢性能較高，使用本研究的優(yōu)化方案可以有效地提高M(jìn)ongoDB集群的相關(guān)性能，從而提高M(jìn)ongoDB集群的使用效果。