一種MongoDB應用優化策略①

盧至彤,李 翀,柯 勇,孫健英

(中國科學院 計算機網絡信息中心,北京 100190)

一種MongoDB應用優化策略①

盧至彤,李 翀,柯 勇,孫健英

(中國科學院 計算機網絡信息中心,北京 100190)

為了解決不斷增長的文件存儲需求,和高流量高并發的訪問量,增強系統的響應性能,提出一種Web應用優化策略,通過MongoDB GridFS對網站文件存儲容量、可用性和可靠性進行擴展,并且通過Nginx和Keepalived,對后臺訪問進行負載均衡和雙機熱備,優化并發性能.實驗表明,當并發訪問數上升至80以上時,平均訪問響應時間縮短9%.文件通過Nginx Gridfs進行高并發上傳時非常穩定,在較大文件下載時比直接通過本地文件系統EXT4下載速度更高.

MongoDB;GridFS;Nginx;Keepalived;concurrency

Web應用通過文件服務器對圖片、視頻和文檔資源對文件進行管理,包括:文件存儲、文件同步和文件訪問.對于大多數應用而言,需要文件系統來存儲用戶上傳的文件.一般而言,用戶上傳的單個文件所占用的空間一般不大,但是上傳的文件數量是在不斷快速增長的.單機文件系統存儲容量可能會超過單機硬盤的擴容范圍而且其查詢性能在存儲量級過大時查找和插入性能都可能會遇到瓶頸.我們可以采用MongoDB GridFS[1]分布式文件系統來達到我們動態增加存儲容量的目的.

除此以外,MongoDB GridFS分布式文件系統能夠自動進行冗余備份,保證用戶的文件不會丟失;還有高可用性,也就是說當某個文件服務器出現故障的時候,自動切換到備份提供服務,使用戶感覺不到有什么異常.

隨著Web應用訪問量的提高,我們可以通過Nginx反向代理服務器的負載均衡來提升Web應用的響應性能.對于負載均衡集群架構系統,各服務器間需要共享session信息,我們可以通過Memcache[2]這個高性能的分布式的內存對象緩存系統來解決這個問題.

本文通過MongoDB GridFS分布式文件系統對網站文件存儲容量、可用性和讀取性能進行擴展.通過Nginx[3]代理服務器大量的并發訪問或數據流量分擔到多臺節點設備上分別處理,減少用戶等待響應的時間,優化并發性能.

1 系統設計

系統設計架構示意圖如圖1所示,系統通過Nginx代理服務器實現對于業務服務器和文件服務器集群的訪問,其中系統使用兩臺代理服務器采用雙機熱備技術確保系統的可靠性.通過設置負載均衡集群將訪問業務分攤到兩臺業務服務器上,降低了單個業務服務器的訪問壓力.主從代理服務器的負載均衡是使用Nginx作為反向代理服務器來實現的.

圖1 系統架構圖

分布式文件系統 MongoDB GridFS部署在MongoDB分布式數據庫上.數據庫分成三個分片[4]進行橫向擴展.每個分片由3臺Mongod Server副本集組成以保證可靠性.

1.1 負載均衡集群架構

系統使用2臺Nginx代理服務器作為系統的出口,通過一個虛擬IP對外提供服務,如下圖2所示.為保證系統的高可用性,采用雙機熱備模式.兩臺代理服務器同一時間只有一臺在提供服務.當提供服務的一臺出現故障的時候,另外一臺會馬上自動接管并且提供服務,進行無縫交接.雙機熱備是通過路由冗余協議在2臺代理服務器上分別安裝KeepAlive并進行配置實現的.

1.2 MongoDB副本集

副本集架構如下圖3所示,系統中一共包含4個副本集,每個副本集包含3個副本,分別是一個Primary,2個Secondary.3個副本在同步之后存儲的是同一份數據.其中,主節點負責整個副本集的數據寫入,從節點定期從主節點通過Oplog同步數據備份,通過配置可從距離最近節點讀取數據,實現讀寫分離.副本集之間通過心跳維持聯系,一但主節點掛掉失去聯系,從節點就會選舉一個新的主節點,選舉過程對客戶端是透明的.副本集提供了數據的冗余備份,并因在多個服務器上可讀取存儲的數據副本,提高了數據的可用性和故障容忍性.

圖3 副本集架構圖

1.3 MongoDB分片架構

為提高存儲空間,分擔請求負載,采用MongoDB集群的分片配置[5],如下圖4所示.整個分片集群不同服務器分別承擔以下不同角色:

①Mongos Server,路由服務器,數據庫集群請求的入口,負責把對應的數據請求請求轉發到對應的分片服務器上.管理操作、讀寫操作都通過mongos server來完成,以保證集群多個組件處于一致的狀態.

②Config Server,配置服務器,存儲所有數據庫元信息的配置,即各個chunk與分片服務器的映射關系.如下圖所示,將配置服務器配置成一個副本集防止系統單點故障.

③Shard Server,分片服務器,存儲數據庫中具體的的數據.其中,每一個分片服務器是一個副本集保證數據可用性.如下圖所示,集群有3個分片服務器,必要時還可進行擴展.

在分片服務器里,MongoDB會把數據根據片鍵分為chunks,如圖5所示.當一個chunk的大小超過配置中的chunk size時,MongoDB的后臺進程會把這個chunk切分成更小的chunk.除此之外,MongDB的后臺進程Balancer負責chunk的遷移,從而均衡各個分片服務器的負載.這些過程對客戶端都是透明的.

圖4 MongoDB分片架構圖

圖5 MongoDB chunk分布圖

1.4 GridFS

GridFS[6]是MongoDB之上的分布式文件系統,通過MongoDB的復制,分片等機制來存儲文件數據和文件元數據并進行管理與分析.GridFS將二進制數據大文件分成很多塊,每一塊作為一個單獨的文檔存儲.

GridFS使用兩個文檔來存儲二進制數據文件,一個用來存儲文件本身的塊,另外一個用來存儲分塊的信息和文件的元數據,默認對應的集合分別為fs.chunks和fs.files,其結構如圖6所示.

fs.files這個集合Collection存儲文件元數據,一般比較小,不需要分片存儲.fs.chunks這個集合Collection存儲了文件數據,比較大,根據files_id,n作為片鍵將不同chunk通過哈希分布到不同分片服務器上.

圖6 GridFS文件存儲

2 系統實現

2.1 運行環境

運行環境集群中有7臺服務器,其環境如表2所示,其中每臺服務器的配置環境如表1所示.

表1 服務器配置信息

2.2 配置

2.2.1 MongoDB和GridFS配置

MongoDB的配置[7]示意圖如下圖所示.在如下的配置中,任何一臺機器因故障不能提供服務,都能保證MongoDB繼續提供正常的服務,數據不丟失,保證容災性.并且在相應的配置后,能增加和減少節點,有良好的可擴展性.

在四個服務器上開啟Mongod服務,然后對Shard1、Shard2、Shard3和configReplSet副本集用mongo命令進行連接,然后在Mongo Shell中配置副本集信息,如下所示.

表2 服務器集群環境

添加分片用命令mongo進行連接mongos服務器端口,然后在MongoShell中配置分片信息,如下所示.

在新建數據庫test之后,對數據庫test開啟分片. GridFS默認使用兩種集合 Collection:fs.files和fs.chunks來存儲數據,對集合fs.chunks開啟分片和索引.在Mongo Shell中的配置如下所示:

2.2.2 Tomcat和Mysql安裝配置

Tomcat業務服務器集群結構如圖7所示.

圖7 Tomcat服務器集群結構

表3 Mongo服務器配置

在服務器 06、07,也就是 10.10.1.139和10.10.1.144上下載并安裝Tomcat 8.并將Java Web應用打包成 war包,然后發布到 Tomcat服務器的webapps目錄下.并在服務器06上安裝和啟動Mysql. Web應用使用其作為數據庫服務器.

2.2.3 Nginx、Memcached和Keepalived配置安裝

在服務器07上用git下載nginx-gridfs插件,并安裝和編譯,命令如下所示:

在nginx配置文件中配置負載均衡業務服務器與MongoDB Mongos IP地址與端口,如下所示.

Mencached是一個高性能的分布式的內存對象緩存系統,負責業務服務器間共享session對象信息,在服務器07上安裝和啟動.然后在服務器06和07的Tomcat里配置支持Mencached的session管理,即修改文件server.xml,添加Mencached服務器配置信息.

在服務器05和服務器06上,下載安裝Keepalived,并對Keepalived的配置文件keepalived.conf進行配置,在其中設置服務器05是主服務器,而06是備服務器.然后,在這2臺服務器上啟用Keepalived服務.為了使主服務器Keepalived正常運行而Nginx出現故障時,關閉服務,能夠順利切換,創建監控腳本,并在Keepalived配置文件中實現監控.

3 系統測試

3.1 響應性能測試

對部署在系統中Web應用的響應性能用Jmeter進行測試,其中采用的Web測試應用的后臺技術架構是SpringMVC3.對部署在單個服務器上的同一Web應用響應性能對比.分別模擬30,50,80,100,120個用戶在1秒內發出HTTP請求以測試其并發性能,測量值分別如下表3所示.其中,Samples表示一共完成了多少個線程,Average表示平均響應時間,單位是毫秒, Median表示統計意義上面的響應時間的中值,單位是毫秒,99%Line表示所有線程中99%的線程的響應時間都小于或大于當前數值,單位是毫秒,Min表示最小響應時間,單位是毫秒,Max表示最大響應時間,單位是毫秒.

可看到,隨著并發訪問數的提高,優化后的系統的響應時間越少,吞吐量越大.然而,并發訪問數提高,漸漸超過系統的承受能力,錯誤率也開始提高.在并發訪問為80及80以下時,單服務器響應性能均比優化后的系統表現要好,這可能是因為還沒達到單服務器并發性能極限,而且,通過Nginx請求轉發還需要相應的時間消耗.在并發訪問為80左右時,平均響應時間縮短9%,其趨勢如下圖8所示.這可能是因為,隨著并發訪問數的提高,單服務器響應性能逐漸降低,而通過Nginx的分發和兩臺服務器分擔請求,單個服務器所需承擔的并發數下降,其服務器響應性能也維持在較高的狀態.而在并發訪問數達到100時,單服務器開始出錯,說明已經達到它的并發極限.而優化后的系統運行良好.直到并發訪問數達到120,才達到優化后的系統的并發極限.

表4 并發訪問數據對比

圖7 平均響應時間增長趨勢圖

3.2 GridFS文件并發讀寫性能

3.2.1 GridFS文件并發寫性能

通過GridFS Java驅動,編寫Java測試應用程序,在其中創建并發訪問線程進行測試,模擬并發訪問十次的平均值,以減少誤差.然后與Linux EXT4文件系統在500K和20M大小的文件寫文件效率進行對比,并記錄其響應時間,如下圖所示.其中文件都是保存在同一個目錄下.可以看出,無論是在大文件還是小文件, GridFS文件上傳時間雖然比EXT4要慢.但是,隨著并發數的上升,文件上傳的最大時間是比較穩定的.

上傳時間較慢原因有以下幾個:第一,在寫文件時,觀察GridFS數據庫分片狀態的變化,發現文件寫入總是在同一個節點上.這是因為集合fs.chunks的分片片鍵是(files_id,n),而其中files_id是自動生成的.在這種情況下,插入總是在一個分片上操作.第二,由于Balancer的Chunks均衡時要鎖定資源,速度較慢,來不及將新插入的Chunks遷移.第三,在集合fs.files和fs.chunks上建立了索引,對插入速度也有影響.第四,其他因素的影響可能導致結果有誤差,如CPU資源,緩存資源的占用等.

3.2.2 GridFS文件并發讀性能

通過MongoDB GridFS的JavaAPI測試文件的下載效率.GridFS下載測試是通過Nginx GridFS模塊在Nginx上下載,而對比的是通過TomcatWeb服務器在EXT4本地文件系統上下載,在這里搭建了NFS文件共享系統方便進行對比.500K和500M空間大小的文件下載時間如下圖8所示,其中文件都是保存在同一個目錄下.

圖8 500K和20M文件并發上傳時間

GridFS的并發查詢優勢在于通過Balancer的策略將數據塊chunks的查詢均勻的分布在各個分片上,訪問負載也隨著分散到各個分片上,從而提高并發性能.事實上,當存儲的文件數據量少,由于路由查詢等消耗,GridFS的優勢并不明顯.除此之外,相對于Linux EXT4文件系統的單個目錄下能存放的文件和文件夾數目有限而且過多的文件數目會導致文件搜索時間過長的問題而言,GridFS將文件名和路徑信息存放在fs.files里面則沒有這些問題.

文件下載速度與當前網絡帶寬關系密切,而網絡帶寬是隨著時間動態變化的.測試雖然采取多次測量取平均值,仍然可能導致數據測量有一定偏差.

4 總結

針對不斷提高的文件存儲需求以及高流量高并發的Web應用訪問有延遲的問題,本文提出了一種Web優化策略對網站響應性能、文件存儲容量、可用性、可靠性和并發讀取性能等方面進行提升.對這種優化的部署架構的響應性能和文件下載速率做了實驗和測試發現,通過Nginx系統在高并發情況下有9%的性能提升.而且MongoDB Gridfs集群的文件上傳速率穩定,下載速率在文件較大的情況下性能較好.

1 Chodorow K.MongoDB:The Definitive Guide.O’Reilly Media,Inc.2013.

2 Fitzpatrick B.Distributed caching with memcached.Linux Journal,2004,(124):72–76.

3 Chi X,Liu B,Niu Q,et al.Web load balance and cache optimization design based nginx under high-concurrency environment.2012 Third International Conference on Digital Manufacturing and Automation(ICDMA).IEEE.2012. 1029–1032.

4 Liu Y,Wang Y,Jin Y.Research on the improvement of MongoDB auto-sharding in cloud environment.2012 7th International Conference on Computer Science&Education (ICCSE).IEEE.2012.851–854.

5 Jiang W,Zhang L,Liao X,et al.A novel clustered MongoDB-based storage system for unstructured data with high availability.Computing,2014,96(6):455–478.

6 Gu Y,Wang X,Shen S,et al.Analysis of data storage mechanism in NoSQL database MongoDB.2015 IEEE International Conference on Consumer Electronics-Taiwan (ICCE-TW).IEEE.2015.70–71.

7劉一夢.基于MongoDB的云數據管理技術的研究與應用[碩士學位論文].北京:北京交通大學,2012.

Optimisation Strategy for WebApplications Based on MongoDB

LU Zhi-Tong,LI Zhong,KE Yong,SUN Jian-Ying

(Computer Network Information Center,ChineseAcademy of Sciences,Beijing 100190,China)

With the growing demand for massive file storage and high number of concurrent accesses to enhance performance of the system.In this paper,we propose an optimization strategy of web applications,which can expand the storage capacity,availability and reliability with MongoDB GridFS,and also can support load balancing and hot standby with Nginx and Keepalived,optimizing concurrent performance.We test the concurrent performances of the web application and the experimental results show that the average response time could be reduce by 9%when the number of concurrent accesses increases to more than 80.When files are uploaded concurrently through Nginx Gridfs,the performance is stable.The file-download speeds of larger files are faster than those through local file system EXT4.

MongoDB;GridFS;Nginx;Keepalived;concurrency

2016-09-05;收到修改稿時間:2016-10-17

10.15888/j.cnki.csa.005767