MongoDB資料庫的海量資料儲存應用
3 過程分析與測試
3.1 GridFS概述
由於MongoDB中的Bson物件大小是有限制的，在1.7版本以前單個Bson物件最大容量為4M，1.7版本以後單個Bson物件最大容量為16M[5]。對於一般的檔案儲存，單個物件的4到16M的儲存容量能夠滿足需求，但無法滿足對於一些大檔案的儲存，如高清圖片、設計圖紙、視訊等，因此在海量資料儲存方面，MongoDB提供了內建的Grid
FS，可以將一個大檔案分割成為多個較小的文件，可以指定檔案分塊標準，對使用者是透明的。GridFS使用兩個資料結構來儲存資料：files（包含元資料物件）、chunks（包含其他一些相關資訊的二進位制塊）。為了使多個GridFS命名為一個單一的資料庫，檔案和塊都有一個字首，預設字首為fs，使用者有權改變這個字首。
GridFS對Java、C#、Perl、PHP、Python、Ruby等程式言語均支援，且提供了良好的API介面。
3.2 基於GridFS的海量資料儲存測試
本文主要採用MongoDB最新版2.0及官方提供的C#語言驅動進行測試，C#驅動下載地址：https://github.com/mongodb/Mongo-csharp-driver。
MongoDB在bin目錄下提供了一系列有用的工具，可以很方便的進行運維管理：
（1）bsondump：將Bson格式的檔案轉儲為Json格式的資料。
（2）mongo：客戶端命令列工具，支援js語法。
（3）mongod：資料庫服務端，每個例項啟動一個程序，可以fork為後臺執行。
（4）mongodump：資料庫備份工具。
（5）mongorestore：資料庫恢復工具。
（6）mongoexport：資料匯出工具。
（7）mongoimport：資料匯入工具。
（8）mongofiles：GridFS管理工具，可實現二進位制檔案的存取。
（9）mongos:分片路由，如果使用了sharding功能，則應用程式連線的是mongos，而非mongod。
（10）mongosniff：這一工具的作用類似於tcpdump，不同的是他只監控MongoDB相關包請求，並且是以指定的可讀性的形式輸出。
（11）mongostat：實時效能監控工具。
同時有好幾個第三方提供的客戶端圖形工具，如MongoVUE、RockMongo、MongoHub等，方便管理和維護。
GridFS結合自動分片及自動複製技術，可以實現高效能的分散式資料庫叢集架構，從而進行海量資料儲存，如下圖2所示。
圖2 高效能的分散式資料庫叢集架構
MongoDB Sharding Cluster需要三種角色：
（1）Shard Server：即儲存實際資料的分片，每個Shard可以是一個mongod例項，也可以是一組mongod例項構成的Replica Set。
（2）Config Server：用來儲存所有shard節點的配置資訊、每個chunk的shard key範圍、chunk在各shard的分佈情況、該叢集中所有DB和collection的sharding配置資訊。
（3）Route Process：這是一個前端路由，客戶端由此接入，然後詢問Config Servers需要到哪個shard上查詢或儲存記錄，再連線相應的shard進行操作，最後將結果返回給客戶端，而這一切對客戶端是透明的，客戶端不用關心所操作的記錄儲存在哪個shard上。
為了測試方便，下面在同一臺物理機器上構建一個簡單的Sharding Cluster，如下圖3所示。
圖3 簡單的Sharding Cluster架構圖
配置測試環境如下：
模擬2個Shard伺服器和1個Config伺服器，均執行在本機127.0.0.1上，只是埠不同：
（1）Shard Server1：127.0.0.1：27020。
（2）Shard Server2：127.0.0.1：27021。
（3）Config Server：127.0.0.1：27022。
（4）Route Process：127.0.0.1：27017。
啟動相關服務程序：
c:\mongodb 2.0.0\bin>mongod --shardsvr --dbpath "c:\mongodb 2.0.0\db" --port 27020
d:\mongodb 2.0.0\bin>mongod --shardsvr --dbpath "d:\mongodb 2.0.0\db" --port 27021
e:\mongodb 2.0.0\bin>mongod --configsvr --dbpath "e:\mongodb 2.0.0\db" --port 27022
e:\mongodb 2.0.0\bin>mongos --configdb 127.0.0.1:27022
配置Sharding：
(1)e:\mongodb 2.0.0\bin>mongo
(2)use admin
(3)db.runCommand( { addshard : "127.0.0.1:27020", allowLocal : 1,
maxSize:2 , minKey:1, maxKey:10 } )
(4)db.runCommand( { addshard : "127.0.0.1:27021", allowLocal : 1, minKey:100 } )
(5)config =connect("127.0.0.1:27022")
(6)config = config.getSisterDB("config")
(7)ecDocs=db.getSisterDB("ecDocs")
(8)db.runCommand({enablesharding:"ecDocs"})
(9)db.runCommand( { shardcollection : "ecDocs.filedocs.chunks", key : { files_id : 1 } } )
(10)db.runCommand( { shardcollection : "ecDocs.filedocs.files", key : { _id : 1 } } )
以上的ecDocs是指資料庫名，filedocs是指使用者自定義的GridFS的檔案集合名，系統預設檔案集合名為fs。
使用官方提供的C#驅動,需要在程式中引用MongoDB.Driver.dllMongoDB.Bson.dll，迴圈新增同一檔案到GridFS示例程式碼，如下圖4所示。
圖4 迴圈新增同一檔案到GridFS程式碼
測試配置環境如下：
作業系統：WindowsXP專業版32位SP3。
處理器(CPU)：英特爾Xeon(至強)[email protected]。
記憶體：3567MB(DDR31333MHz/FLASH)。
硬碟：希捷ST3250318AS(250GB/7200轉/分)。
由於本機是32位作業系統，因此單個服務例項只支援GridFS的檔案容量大小為0.9G左右，由於採用了兩臺Shard服務例項，可以支援儲存的檔案總容量大小為1.8G左右，如果是64位作業系統就沒有此限制。
本文主要測試GridFS採用迴圈插入大容量檔案的效能和分片容量大小,測試結果，如下圖5所示。
從圖5可以看出，第1到3步驟，只新增單個檔案時，Shard2並沒有產生分片資料，只有測試到步驟4連續新增100個相同檔案時Shard2才產生分片資料，並且新增三四百兆的單個檔案，只需11秒多就完成了操作，而即使通過檔案拷貝方式這麼大的檔案也至少需要二三十秒才能完成，可見MongoDB在大容量檔案儲存方面擁有非常高的效能。
通過在客戶端的mongo工具輸入db.printShardingStatus()命令可以檢視詳細分片情況，如下圖6所示。
從圖6可以看出，在shard1中分配了6個chunks，在shard2中分配了7個chunks，分片資料相對還是比較均勻的。
從以上的測試可以得知，採用GridFS可以儲存海量資料，並且可以通過廉價伺服器進行大規模資料庫叢集，非常容易擴充套件部署，程式編碼也非常容易，因此能夠有效支援雲端儲存的應用，能夠滿足大規模資料儲存的應用需求。
圖5 GridFS大容量檔案測試結果
圖6 GridFS大容量檔案分片資訊
4 結論
隨著企業和個人資料的不斷擴大，隨著雲端計算的高速發展，越來越多的應用需要儲存海量資料，並且對高併發和處理海量資料提出了更高的要求，傳統的關係型資料庫對於這些應用場景難以滿足應用需求，而作為NoSQL資料庫之一的MongoDB資料庫能夠完全滿足和解決在海量資料儲存方面的應用，越來越多的大網站和企業選擇MongoDB代替Mysql進行儲存。