葉思斯，林志達，郭獻彬，曹小明

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

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

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

本研究基于MongoDB的基本理論與概念，提出了基于片鍵類型優(yōu)化、數(shù)據(jù)查詢優(yōu)化以及數(shù)據(jù)存儲優(yōu)化3個方面的MongoDB分片集群系統(tǒng)優(yōu)化方案。為檢測優(yōu)化效果，研究分別檢測了在不同分片環(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是整個MongoDB分片集群中的路由服務(wù)器。通過Mongos可以使MongoDB分片集群中的客戶端以及服務(wù)端進行連接。用戶發(fā)送的請求將通過Mongos發(fā)送至不同的服務(wù)器中。為進一步提高MongoDB的穩(wěn)定性以及可靠性，在本研究中使用集群的方式對Mongos進行搭建。config server是存儲數(shù)據(jù)分片以及數(shù)據(jù)塊中具體信息的主要結(jié)構(gòu)，當(dāng)MongoDB運行時，config server負責(zé)將相關(guān)信息提供給Mongos，保證了Mongos的可靠性。同時，config server也可以擴展為集群。Mongod主要負責(zé)MongoDB的實際操作，包括數(shù)據(jù)塊的存儲、數(shù)據(jù)的查詢、數(shù)據(jù)的插入以及數(shù)據(jù)的實例化等操作。而monitor在MongoDB分片集群中主要起到數(shù)據(jù)監(jiān)控的作用。通過monitor可以監(jiān)控系統(tǒng)的負載均衡狀態(tài)、數(shù)據(jù)操作頻率以及讀寫基本耗時等內(nèi)容。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1.3 FODO算法

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

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

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

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

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

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

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

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

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

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

1.4 實驗測試環(huán)境

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

表1 實驗測試環(huán)境Tab.1 Experimental test environment

2 結(jié)果與討論

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

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

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

由圖3可知，在升序分片的環(huán)境下，數(shù)據(jù)插入后的分片差距過大，分布極不均衡。其中，Shard01的插入數(shù)據(jù)占比為81.94%，而Shard03的插入數(shù)據(jù)占比僅為18.06%，在Shard02區(qū)域甚至出現(xiàn)了沒有數(shù)據(jù)輸入的情況。而在Hash分片以及優(yōu)化分片的情況下均可使數(shù)據(jù)較為均勻地分布在各個區(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ù)據(jù)分布不均。而優(yōu)化分片擁有升序分片與Hash分片的優(yōu)點，在保證數(shù)據(jù)確定分布的情況下又可以避免數(shù)據(jù)過度集中。

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

2.1.2 插入方式測試

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

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

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

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

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

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

3 結(jié) 論

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