基于MongoDb海量數(shù)據(jù)存儲(chǔ)的商戶(hù)平臺(tái)監(jiān)控系統(tǒng)

1、浙江大學(xué)碩士學(xué)位論文 STYLEREF 標(biāo)題,章標(biāo)題(無(wú)序號(hào)) * MERGEFORMAT Abstract 目 錄 PAGE IV PAGE II目 錄 TOC o 1-3 h z u HYPERLINK l _Toc353996858 摘要 PAGEREF _Toc353996858 h i HYPERLINK l _Toc353996859 Abstract PAGEREF _Toc353996859 h ii HYPERLINK l _Toc353996860 圖目錄 PAGEREF _Toc353996860 h IV HYPERLINK l _Toc353996861 表目錄 PA

2、GEREF _Toc353996861 h VI HYPERLINK l _Toc353996862 第1章 緒論 PAGEREF _Toc353996862 h 1 HYPERLINK l _Toc353996863 1.1 課題背景 PAGEREF _Toc353996863 h 1 HYPERLINK l _Toc353996864 1.2 技術(shù)背景 PAGEREF _Toc353996864 h 2 HYPERLINK l _Toc353996865 1.3 國(guó)內(nèi)外研究現(xiàn)狀 PAGEREF _Toc353996865 h 3 HYPERLINK l _Toc353996866 1.3.

3、1 國(guó)外研究現(xiàn)狀 PAGEREF _Toc353996866 h 3 HYPERLINK l _Toc353996867 1.3.2 國(guó)內(nèi)研究現(xiàn)狀 PAGEREF _Toc353996867 h 3 HYPERLINK l _Toc353996868 1.4 本文選題背景及研究?jī)?nèi)容 PAGEREF _Toc353996868 h 4 HYPERLINK l _Toc353996869 第2章 監(jiān)控系統(tǒng)關(guān)鍵技術(shù) PAGEREF _Toc353996869 h 6 HYPERLINK l _Toc353996870 2.1 Maven2原理 PAGEREF _Toc353996870 h 6 HY

4、PERLINK l _Toc353996871 2.2 非關(guān)系型數(shù)據(jù)庫(kù) PAGEREF _Toc353996871 h 7 HYPERLINK l _Toc353996872 2.2.1 NoSQL的發(fā)展和現(xiàn)狀 PAGEREF _Toc353996872 h 7 HYPERLINK l _Toc353996873 2.2.2 NoSQL處理上的優(yōu)勢(shì) PAGEREF _Toc353996873 h 8 HYPERLINK l _Toc353996874 2.3 MongoDB技術(shù) PAGEREF _Toc353996874 h 9 HYPERLINK l _Toc353996875 2.3.1

5、MongoDB數(shù)據(jù)結(jié)構(gòu) PAGEREF _Toc353996875 h 9 HYPERLINK l _Toc353996876 2.3.2 MongoDB處理海量數(shù)據(jù)的策略 PAGEREF _Toc353996876 h 10 HYPERLINK l _Toc353996877 2.4 EJSChart技術(shù) PAGEREF _Toc353996877 h 12 HYPERLINK l _Toc353996878 2.5 本章小結(jié) PAGEREF _Toc353996878 h 13 HYPERLINK l _Toc353996879 第3章 數(shù)據(jù)庫(kù)設(shè)計(jì) PAGEREF _Toc35399687

6、9 h 14 HYPERLINK l _Toc353996880 3.1 配置庫(kù) PAGEREF _Toc353996880 h 14 HYPERLINK l _Toc353996881 3.1.1 整體框架和集合間關(guān)系 PAGEREF _Toc353996881 h 14 HYPERLINK l _Toc353996882 3.1.2 配置庫(kù)集合詳細(xì)設(shè)計(jì) PAGEREF _Toc353996882 h 15 HYPERLINK l _Toc353996883 3.2 實(shí)時(shí)采集庫(kù) PAGEREF _Toc353996883 h 18 HYPERLINK l _Toc353996884 3.2.

7、1 實(shí)時(shí)采集庫(kù)集合詳細(xì)設(shè)計(jì) PAGEREF _Toc353996884 h 18 HYPERLINK l _Toc353996885 3.3 匯總庫(kù) PAGEREF _Toc353996885 h 19 HYPERLINK l _Toc353996886 3.3.1 匯總庫(kù)集合詳細(xì)設(shè)計(jì) PAGEREF _Toc353996886 h 20 HYPERLINK l _Toc353996887 3.4 本章小結(jié) PAGEREF _Toc353996887 h 20 HYPERLINK l _Toc353996888 第4章 數(shù)據(jù)庫(kù)集群的搭建 PAGEREF _Toc353996888 h 22 H

8、YPERLINK l _Toc353996889 4.1 集群數(shù)據(jù)存儲(chǔ)結(jié)構(gòu) PAGEREF _Toc353996889 h 22 HYPERLINK l _Toc353996890 4.2 集群數(shù)據(jù)的寫(xiě)入?yún)f(xié)議 PAGEREF _Toc353996890 h 23 HYPERLINK l _Toc353996891 4.2.1 客戶(hù)端請(qǐng)求消息頭 PAGEREF _Toc353996891 h 24 HYPERLINK l _Toc353996892 4.2.2 數(shù)據(jù)庫(kù)響應(yīng)消息頭 PAGEREF _Toc353996892 h 24 HYPERLINK l _Toc353996893 4.3 監(jiān)控

9、系統(tǒng)的集群配置方案 PAGEREF _Toc353996893 h 25 HYPERLINK l _Toc353996894 4.4 集群主節(jié)點(diǎn)的選舉仲裁機(jī)制 PAGEREF _Toc353996894 h 28 HYPERLINK l _Toc353996895 4.5 本章小結(jié) PAGEREF _Toc353996895 h 29 HYPERLINK l _Toc353996896 第5章 監(jiān)控系統(tǒng)的詳細(xì)設(shè)計(jì) PAGEREF _Toc353996896 h 30 HYPERLINK l _Toc353996897 5.1 系統(tǒng)整體架構(gòu) PAGEREF _Toc353996897 h 30

10、HYPERLINK l _Toc353996898 5.2 監(jiān)控平臺(tái)各模塊的設(shè)計(jì)方案 PAGEREF _Toc353996898 h 31 HYPERLINK l _Toc353996899 5.2.1 數(shù)據(jù)采集模塊 PAGEREF _Toc353996899 h 31 HYPERLINK l _Toc353996900 5.2.2 數(shù)據(jù)匯總模塊 PAGEREF _Toc353996900 h 32 HYPERLINK l _Toc353996901 5.2.3 監(jiān)控展現(xiàn)模塊 PAGEREF _Toc353996901 h 32 HYPERLINK l _Toc353996902 5.2.4

11、監(jiān)控配置模塊 PAGEREF _Toc353996902 h 33 HYPERLINK l _Toc353996903 5.3 監(jiān)控系統(tǒng)的程序?qū)崿F(xiàn) PAGEREF _Toc353996903 h 33 HYPERLINK l _Toc353996904 5.4 商戶(hù)平臺(tái)對(duì)監(jiān)控系統(tǒng)的調(diào)用方式 PAGEREF _Toc353996904 h 35 HYPERLINK l _Toc353996905 5.5 本章小結(jié) PAGEREF _Toc353996905 h 37 HYPERLINK l _Toc353996906 第6章 數(shù)據(jù)庫(kù)集群性能測(cè)試 PAGEREF _Toc353996906 h 3

12、8 HYPERLINK l _Toc353996907 6.1 測(cè)試環(huán)境 PAGEREF _Toc353996907 h 38 HYPERLINK l _Toc353996908 6.1.1 硬件環(huán)境 PAGEREF _Toc353996908 h 38 HYPERLINK l _Toc353996909 6.1.2 軟件環(huán)境 PAGEREF _Toc353996909 h 38 HYPERLINK l _Toc353996910 6.2 測(cè)試點(diǎn)和測(cè)試方案 PAGEREF _Toc353996910 h 38 HYPERLINK l _Toc353996911 6.3 查詢(xún)性能測(cè)試 PAGER

13、EF _Toc353996911 h 39 HYPERLINK l _Toc353996912 6.4 插入性能測(cè)試 PAGEREF _Toc353996912 h 39 HYPERLINK l _Toc353996913 6.5 測(cè)試結(jié)果總結(jié) PAGEREF _Toc353996913 h 40 HYPERLINK l _Toc353996914 6.6 本章小結(jié) PAGEREF _Toc353996914 h 40 HYPERLINK l _Toc353996915 第7章 總結(jié)和展望 PAGEREF _Toc353996915 h 42 HYPERLINK l _Toc353996916

14、 7.1 總結(jié) PAGEREF _Toc353996916 h 42 HYPERLINK l _Toc353996917 7.2 展望和進(jìn)一步的工作 PAGEREF _Toc353996917 h 43 HYPERLINK l _Toc353996918 參考文獻(xiàn) PAGEREF _Toc353996918 h 44 HYPERLINK l _Toc353996919 作者簡(jiǎn)歷 PAGEREF _Toc353996919 h 46 HYPERLINK l _Toc353996920 致 謝 PAGEREF _Toc353996920 h 47浙江大學(xué)碩士學(xué)位論文 STYLEREF 樣式1 *

15、MERGEFORMAT 表目錄 監(jiān)控系統(tǒng)關(guān)鍵技術(shù) PAGE 2 PAGE 13監(jiān)控系統(tǒng)關(guān)鍵技術(shù)Maven2原理Maven作為Apache的一個(gè)開(kāi)源項(xiàng)目，旨在給項(xiàng)目管理提供更多的支持9。它最早的意圖只是為了給apache組織的幾個(gè)項(xiàng)目提供統(tǒng)一的開(kāi)發(fā)、測(cè)試、打包和部署，管理項(xiàng)目的配置文件和依賴(lài)的jar包，讓開(kāi)發(fā)者在多個(gè)項(xiàng)目中方便的切換和管理大型項(xiàng)目。Maven的基本原理很簡(jiǎn)單，Maven管理著遠(yuǎn)程倉(cāng)庫(kù)、本地倉(cāng)庫(kù)和pom.xml文件。xml文件是jar包的描述文件，主要描述了配置文件，規(guī)則、項(xiàng)目的依賴(lài)關(guān)系，包括項(xiàng)目（或者組織的唯一標(biāo)識(shí)）、項(xiàng)目的通用名稱(chēng)、項(xiàng)目的版本，組織和license等。通過(guò)pom

16、.xml的定義的依賴(lài)，將jar包從遠(yuǎn)程倉(cāng)庫(kù)下載到本地倉(cāng)庫(kù)中來(lái)，供本地程序使用，并且每個(gè)應(yīng)用系統(tǒng)使用同一個(gè)本地倉(cāng)庫(kù)，而同一個(gè)版本的jar包只會(huì)打包下載一次。圖2.1 pom.xml文件Maven采用了現(xiàn)在非常流行的插件式的體系架構(gòu)，只保留著最小的核心，其余的功能都是通過(guò)擴(kuò)展插件的形式提供出來(lái)10。同時(shí)，下載插件的操作只有在執(zhí)行Maven任務(wù)的時(shí)候才會(huì)進(jìn)行。這個(gè)原理和php擴(kuò)展與應(yīng)用庫(kù)的原理相似，都是在維護(hù)一個(gè)官方的倉(cāng)庫(kù)，通過(guò)網(wǎng)絡(luò)下載到本地的倉(cāng)庫(kù)中，并且內(nèi)核都很小。Maven的原理架構(gòu)如圖2-2所示。相比于Ant，maven的優(yōu)勢(shì)就顯得比較突出。Maven包含了Ant的所有功能，并且更加強(qiáng)大，如對(duì)

17、第三方依賴(lài)庫(kù)的同一版本管理，項(xiàng)目的目錄結(jié)構(gòu)都比較統(tǒng)一，每個(gè)項(xiàng)目可以很好的做到兼容，支持多種插件，并且可以把這些插件連同第三方依賴(lài)一起進(jìn)行統(tǒng)一版本的管理。而Ant需要為不同的項(xiàng)目編寫(xiě)不通用的build.xml腳本，這使得每個(gè)項(xiàng)目都很繁雜并且不兼容。圖2.2 Maven原理圖這里的步驟 eq oac(,2)是為了檢查本地庫(kù)庫(kù)中是否已經(jīng)存在需要下載的jar包了，如果沒(méi)有才會(huì)執(zhí)行 eq oac(,3)、 eq oac(,4)步驟。非關(guān)系型數(shù)據(jù)庫(kù)非關(guān)系型數(shù)據(jù)庫(kù)的特點(diǎn)是：非關(guān)系型、分布式的、開(kāi)源的、水平可擴(kuò)展的11。非關(guān)系型數(shù)據(jù)庫(kù)的出現(xiàn)和興起是隨著互聯(lián)網(wǎng)web2.0網(wǎng)站的興趣而出現(xiàn)的，因?yàn)樵诿鎸?duì)大規(guī)模數(shù)據(jù)

18、量和高并發(fā)訪問(wèn)的web2.0動(dòng)態(tài)網(wǎng)站時(shí)，傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)顯得力不從心，暴露了很多致命的問(wèn)題。而這時(shí)，非關(guān)系型數(shù)據(jù)庫(kù)則由于其自身的特點(diǎn)得到很好的發(fā)展。NoSQL的發(fā)展和現(xiàn)狀NoSQL（Not Only SQL）早起就有人提出，是一項(xiàng)對(duì)傳統(tǒng)關(guān)系數(shù)據(jù)庫(kù)的革命性運(yùn)動(dòng)。但是NoSQL數(shù)據(jù)庫(kù)并不是想取代已經(jīng)廣泛使用的傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)，只是采用了一種不同于關(guān)系型的方式解決關(guān)系型數(shù)據(jù)庫(kù)的數(shù)據(jù)存儲(chǔ)和計(jì)算方面的問(wèn)題。NoSQL數(shù)據(jù)庫(kù)的定義并不像傳統(tǒng)數(shù)據(jù)庫(kù)那樣的嚴(yán)格，只需要數(shù)據(jù)庫(kù)內(nèi)部數(shù)據(jù)的組織采用非關(guān)系型的方式就可以稱(chēng)之為NoSQL12。目前的NoSQL數(shù)據(jù)按照內(nèi)部的數(shù)據(jù)組織形式可以分為5類(lèi)：圖2.3 目前No

19、SQL的分類(lèi)131）基于Key/Value的NoSQL數(shù)據(jù)庫(kù)。特點(diǎn)就是簡(jiǎn)單并且足夠強(qiáng)大，運(yùn)行速度快。但存在一個(gè)很?chē)?yán)重的問(wèn)題，就是需要查找一段范圍內(nèi)的key。2）基于排序Key/Value的NoSQL數(shù)據(jù)庫(kù)。在原來(lái)的Key/Value的基礎(chǔ)上做了數(shù)據(jù)集的有序化處理。但是它沒(méi)有對(duì)value提供具體的數(shù)據(jù)模型，通常而言，value的模型應(yīng)該可以由應(yīng)用負(fù)責(zé)解析和存取的。3）基于Big Table的NoSQL數(shù)據(jù)庫(kù)。它的出現(xiàn)時(shí)為了解決上面value沒(méi)有提供具體的數(shù)據(jù)模型的問(wèn)題。4）基于文檔的NoSQL數(shù)據(jù)庫(kù)。對(duì)BigTable模型做了改進(jìn)，第一是允許value中有主觀的模式，而不是無(wú)限制的map嵌套；第

20、二是索引，提高了數(shù)據(jù)庫(kù)的檢索速度和效率。這方面的代表產(chǎn)品是MongoDB，也是本文所采用的數(shù)據(jù)解決方案。5）基于圖式的NoSQL數(shù)據(jù)庫(kù)。可以認(rèn)為是從排序Key/Value數(shù)據(jù)庫(kù)發(fā)展過(guò)來(lái)的的一個(gè)分支，允許構(gòu)建圖結(jié)構(gòu)的數(shù)據(jù)模型。NoSQL處理上的優(yōu)勢(shì)滿(mǎn)足數(shù)據(jù)庫(kù)高并發(fā)讀寫(xiě)的需求。NoSQL滿(mǎn)足了web2.0網(wǎng)站的實(shí)時(shí)生成動(dòng)態(tài)頁(yè)面和提供動(dòng)態(tài)信息而帶來(lái)的對(duì)數(shù)據(jù)庫(kù)高并發(fā)的要求。傳統(tǒng)的數(shù)據(jù)庫(kù)在處理上萬(wàn)次的sql查詢(xún)和寫(xiě)數(shù)據(jù)時(shí)，顯得很有壓力，而NoSQL則可以輕松達(dá)到數(shù)十萬(wàn)次。滿(mǎn)足海量數(shù)據(jù)的高效率存儲(chǔ)和訪問(wèn)的需求。一個(gè)大型的SNS網(wǎng)站，每天產(chǎn)生的動(dòng)態(tài)用戶(hù)信息就可以達(dá)到1億。對(duì)于關(guān)系型數(shù)據(jù)庫(kù)而言，在一張含有億條

21、記錄的表里進(jìn)行SQL的操作其效率是及其低下的。而對(duì)于web網(wǎng)站的用戶(hù)登錄系統(tǒng)，其注冊(cè)賬號(hào)就數(shù)以?xún)|計(jì)了。滿(mǎn)足數(shù)據(jù)庫(kù)的高可擴(kuò)展性和高可用性的需求?；趙eb的架構(gòu)中，數(shù)據(jù)庫(kù)的橫向擴(kuò)展往往被局限于技術(shù)，當(dāng)一個(gè)應(yīng)用系統(tǒng)的用戶(hù)數(shù)和訪問(wèn)量足夠大時(shí)，數(shù)據(jù)庫(kù)很難通過(guò)更多的硬件和服務(wù)節(jié)點(diǎn)來(lái)擴(kuò)充性能和負(fù)載能力。而對(duì)數(shù)據(jù)庫(kù)系統(tǒng)的升級(jí)擴(kuò)展往往需要停機(jī)維護(hù)和數(shù)據(jù)遷移，這對(duì)于web網(wǎng)站來(lái)說(shuō)損失是不小的。MongoDB技術(shù)MongoDB數(shù)據(jù)結(jié)構(gòu)MongoDB是一個(gè)高性能，開(kāi)源、無(wú)模式的文檔型數(shù)據(jù)庫(kù)。比之于傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)，mongodb用集合的概念取代了表的概念，用文檔的概念取代了行。對(duì)MongoDB數(shù)據(jù)庫(kù)的理解就是把數(shù)

22、據(jù)分組存儲(chǔ)在數(shù)據(jù)集中，每個(gè)集合在數(shù)據(jù)庫(kù)中都有一個(gè)唯一的標(biāo)識(shí)名稱(chēng)，并且可以包含無(wú)限數(shù)目的文檔14。這樣的組織及結(jié)構(gòu)也才能保證MongoDB數(shù)據(jù)的模式自由性。MongoDB的數(shù)據(jù)組織結(jié)構(gòu)如圖2.4所示：圖2.4 MongoDB數(shù)據(jù)組織結(jié)構(gòu)該圖通過(guò)用戶(hù)評(píng)論博客描述了MongoDB數(shù)據(jù)的組織形式和數(shù)據(jù)的關(guān)聯(lián)關(guān)系。這里有兩個(gè)集合（表）：用戶(hù)表和博客表。博客表中又存在著非簡(jiǎn)單數(shù)據(jù)模型，文章及其評(píng)論。在傳統(tǒng)的數(shù)據(jù)庫(kù)中，這兩個(gè)model會(huì)被設(shè)計(jì)成單獨(dú)的表結(jié)構(gòu)，但是現(xiàn)在是作為博客表的一個(gè)字段存在（集合形式）。一個(gè)用戶(hù)可以在博客上寫(xiě)很多文章和評(píng)論，用戶(hù)對(duì)文章和評(píng)論是一對(duì)多的關(guān)系。通過(guò)集合字段的存儲(chǔ)模式可以體現(xiàn)出了

23、這種模式關(guān)系?？梢钥闯?，MongoDB的數(shù)據(jù)組織結(jié)構(gòu)使數(shù)據(jù)庫(kù)的變得簡(jiǎn)單，表之間的關(guān)系在表的結(jié)構(gòu)中就已經(jīng)定義好了。MongoDB處理海量數(shù)據(jù)的策略主從模式（Master/Slave）通常的數(shù)據(jù)庫(kù)配置方案是一個(gè)Master和一個(gè)或多個(gè)Slave。Master和Slave節(jié)點(diǎn)做到數(shù)據(jù)同步。從數(shù)據(jù)庫(kù)在啟動(dòng)的時(shí)候即馬上和主服務(wù)器進(jìn)行數(shù)據(jù)的同步，這種同步是部分從數(shù)據(jù)庫(kù)的啟動(dòng)先后的，也不需要手動(dòng)操作。同時(shí)，可以對(duì)Mater節(jié)點(diǎn)進(jìn)行數(shù)據(jù)的讀寫(xiě)操作，但是Slave節(jié)點(diǎn)只允許讀取操作而不能寫(xiě)入。這樣既提高了數(shù)據(jù)庫(kù)的讀的效率，也保證了數(shù)據(jù)的一致性。同時(shí)寫(xiě)入多個(gè)節(jié)點(diǎn)就可能造成數(shù)據(jù)在各個(gè)節(jié)點(diǎn)的不一致，最后從節(jié)點(diǎn)到主節(jié)點(diǎn)

24、上進(jìn)行數(shù)據(jù)同步就可能取得錯(cuò)誤的數(shù)據(jù)。主從模式的缺點(diǎn)是不能保證數(shù)據(jù)庫(kù)的安全性。即主節(jié)點(diǎn)宕機(jī)或異常情況下的數(shù)據(jù)庫(kù)的正常使用。因?yàn)樗鼪](méi)有節(jié)點(diǎn)自動(dòng)切換的功能。圖2.5 Master/Slave示意圖副本模式（Relpica-Set）副本模式是在主從模式的基礎(chǔ)上而來(lái)，它包含了主從模式所包含的功能。集群結(jié)構(gòu)也同主從模式一樣，一個(gè)Primary節(jié)點(diǎn)和一個(gè)或多個(gè)Secondary節(jié)點(diǎn)。需要注意的是這里的主節(jié)點(diǎn)和從節(jié)點(diǎn)不是一成不變的，它們的關(guān)系不像是主從模式那樣固定。副本模式的Primary節(jié)點(diǎn)是通過(guò)自動(dòng)協(xié)商競(jìng)選出來(lái)的。副本模式最大的優(yōu)勢(shì)在于其數(shù)據(jù)庫(kù)安全性能的提高。副本模式的配置方案保證了Primary節(jié)點(diǎn)宕機(jī)

25、時(shí)的數(shù)據(jù)庫(kù)的正常運(yùn)行。因?yàn)樵谥鞴?jié)點(diǎn)異常時(shí)，Secondary節(jié)點(diǎn)會(huì)通過(guò)競(jìng)選的機(jī)制來(lái)選取其中的一個(gè)節(jié)點(diǎn)來(lái)充當(dāng)Primary節(jié)點(diǎn)。而這些操作對(duì)應(yīng)用程序來(lái)說(shuō)，這些是完全透明的，不會(huì)影響到程序的正常運(yùn)行。同時(shí)，當(dāng)原來(lái)的主節(jié)點(diǎn)回復(fù)后，當(dāng)前的“臨時(shí)”主節(jié)點(diǎn)就會(huì)自動(dòng)降為slave。圖2.6 Replca-Set示意圖分片（Sharding）分片集群是一種可以水平擴(kuò)展的模式，在特別適合處理大數(shù)據(jù)。構(gòu)建一個(gè)分片集群需要三個(gè)部分15：1）分片服務(wù)（Shard Server）：用于存儲(chǔ)實(shí)際的數(shù)據(jù)分片，實(shí)際環(huán)境中可以由多臺(tái)機(jī)器組成一個(gè)replica-set來(lái)承擔(dān)，可以避免主機(jī)單點(diǎn)故障。2）配置服務(wù)（Config Se

26、rver）：存儲(chǔ)整個(gè)集群的元數(shù)據(jù)。3）路由服務(wù)（Routing Server）：前端路由，屏蔽分配服務(wù)的細(xì)節(jié)，使整個(gè)集群對(duì)客戶(hù)端來(lái)說(shuō)是一個(gè)單一的數(shù)據(jù)庫(kù)，前端可以透明的使用。圖2.7 Sharding架構(gòu)示意圖14MongoDB的分片機(jī)制是根據(jù)shard keys來(lái)劃分?jǐn)?shù)據(jù)，keys可以通過(guò)文檔的一個(gè)或者多個(gè)物理鍵值組成。同時(shí)，chunk不存儲(chǔ)實(shí)際的數(shù)據(jù)，而是一組數(shù)據(jù)集合，表示為collection、minKey和maxKey構(gòu)成的三元組。當(dāng)chunk的大小查過(guò)了ChunkSize，mongoDB會(huì)根據(jù)minKey和maxKey的中間值將這個(gè)chunk切分為兩個(gè)子chunk，再根據(jù)各個(gè)分片的負(fù)載

27、情況，存儲(chǔ)到分片16。EJSChart技術(shù)EJSChart提供了真正易于使用和完全定制化的圖表展示，可以快速發(fā)布各種數(shù)據(jù)的各種格式。之所以選擇EJSChart作為監(jiān)控?cái)?shù)據(jù)圖層的展示，是由于其所具有的特點(diǎn)：1）交互性。EJSChart提供了拐點(diǎn)信息提示、鼠標(biāo)軌跡跟蹤、鍵盤(pán)事件、圖像的放大、縮小等功能，使得圖層的展示不再死板，而是可以根據(jù)用戶(hù)自己的愛(ài)好和關(guān)注點(diǎn)對(duì)圖像做出選擇的查看。2）坐標(biāo)軸的自動(dòng)縮放。開(kāi)發(fā)人員不必再在圖像展示前確定坐標(biāo)軸的范圍，EJSChart會(huì)自動(dòng)的計(jì)算和測(cè)量出刻度來(lái)展示各種數(shù)據(jù)值。3）堆疊性。多個(gè)圖像可以在一個(gè)圖層上展示，它們可以很好的占據(jù)圖層，而不會(huì)出現(xiàn)圖像的混亂。這很適應(yīng)

28、監(jiān)控系統(tǒng)多個(gè)項(xiàng)目的線(xiàn)數(shù)據(jù)的展示。4）多種圖類(lèi)型支持。EJSChart提供了線(xiàn)圖、塊圖、餅圖、柱狀圖等的支持，可以滿(mǎn)足各種實(shí)際的業(yè)務(wù)需求。而隨著EJSChart的火熱發(fā)展，新的高可用的圖將會(huì)出現(xiàn)。5）Ajax動(dòng)態(tài)數(shù)據(jù)加載。EJSChart提供了xml格式的數(shù)據(jù)顯示，同時(shí)可以動(dòng)態(tài)的加載數(shù)據(jù)，這樣一方面提高了圖層的應(yīng)用范圍，同時(shí)也是加快的頁(yè)面的展示速度。6）兼容性好。EJSChart在IE、firefox、chrome等瀏覽器上都具有很好的兼容性，顯示的圖像不會(huì)因?yàn)闉g覽器的不同而存在差異。本章小結(jié)本章介紹了監(jiān)控系統(tǒng)所使用到的關(guān)鍵技術(shù)。包括java程序的標(biāo)準(zhǔn)構(gòu)建工具maven的實(shí)現(xiàn)原理、非關(guān)系型數(shù)據(jù)庫(kù)

29、的發(fā)展和現(xiàn)狀，以及其比之于傳統(tǒng)關(guān)系型數(shù)據(jù)庫(kù)上的優(yōu)勢(shì)、并重點(diǎn)介紹了非關(guān)系型數(shù)據(jù)庫(kù)中發(fā)展的比較成熟的MongoDB，論述了MongoDB的數(shù)據(jù)結(jié)構(gòu)，以及其在處理海量數(shù)據(jù)上特有的集中策略，這些策略包括：主從模式、副本模式、分片。在分析了各自的原理和特點(diǎn)后，在本項(xiàng)目中采用了副本模式作為集群服務(wù)器的搭建方案。最后介紹了下完全基于JS實(shí)現(xiàn)的頁(yè)面圖像展示技術(shù)EJSChart，重點(diǎn)介紹了EJSChart的幾大特點(diǎn)，以及其在處理頁(yè)面圖像上的優(yōu)勢(shì)，從而確定其作為圖像展示的解決方法。浙江大學(xué)博士學(xué)位論文: STYLEREF 論文中文標(biāo)題 * MERGEFORMAT 錯(cuò)誤！文檔中沒(méi)有指定樣式的文字。浙江大學(xué)碩士學(xué)位論

30、文第3章 STYLEREF 標(biāo)題 1,章標(biāo)題(有序號(hào)) * MERGEFORMAT 數(shù)據(jù)庫(kù)設(shè)計(jì) PAGE 4 PAGE 21數(shù)據(jù)庫(kù)設(shè)計(jì)配置庫(kù)配置庫(kù)主要是存儲(chǔ)監(jiān)控項(xiàng)相關(guān)的屬性以及監(jiān)控試圖的屬性?？刂票O(jiān)控系統(tǒng)的操作行為，是系統(tǒng)的“指令中心”。該庫(kù)中包含了6個(gè)集合（表）：監(jiān)控項(xiàng)集合、監(jiān)控試圖集合、服務(wù)集合、模塊集合、聯(lián)系人集合和通用配置集合。表3.1 配置庫(kù)框架DBCOLLECTIONEXPLANATIONsdmm_configitem監(jiān)控項(xiàng)view監(jiān)控視圖service服務(wù)module模塊contact聯(lián)系人config通用配置整體框架和集合間關(guān)系配置庫(kù)處在監(jiān)控系統(tǒng)數(shù)據(jù)庫(kù)配置中的核心位置，它是系統(tǒng)

31、的調(diào)度中心，決定著系統(tǒng)工作的模式。因此配置庫(kù)中的集合也比較多比較復(fù)雜，如圖3.1所示：圖3.1 配置庫(kù)集合關(guān)系圖通用配置集合是監(jiān)控系統(tǒng)訪問(wèn)MongoDB數(shù)據(jù)庫(kù)的入口，它最重要的字段就是configValue，其指明執(zhí)行的配置值，也就是對(duì)哪些數(shù)據(jù)進(jìn)行采集監(jiān)控，哪些是不需要的。通用配置集合直接關(guān)聯(lián)到監(jiān)控項(xiàng)集合，是“one-to-many”的關(guān)系。一個(gè)通用配置文檔可以對(duì)應(yīng)多個(gè)監(jiān)控項(xiàng)文檔。監(jiān)控項(xiàng)集合在整個(gè)數(shù)據(jù)庫(kù)方案中很處于中心地位，它的serviceId字段直接關(guān)聯(lián)到服務(wù)集合上，定義這樣的關(guān)聯(lián)關(guān)系是為了得到匯總集合的名稱(chēng)前綴。它的關(guān)聯(lián)關(guān)系是“one-to-one”的模式，即一個(gè)serviceId只能在

32、服務(wù)集合中取得一個(gè)前綴。服務(wù)集合的作用就是存儲(chǔ)上面描述的集合前綴，前綴的作用是用來(lái)區(qū)分監(jiān)控?cái)?shù)據(jù)，相當(dāng)于是數(shù)據(jù)的分類(lèi)。表現(xiàn)這個(gè)功能的字段是collectionPrefix。監(jiān)控試圖集合和其他的集合的關(guān)聯(lián)最多，因?yàn)樗亲詈蟊O(jiān)控圖層展示所讀取的數(shù)據(jù)庫(kù)。它和監(jiān)控項(xiàng)集合存在著“one-to-many”的關(guān)系，和服務(wù)集合和模塊集合存在“one-to-one”，是對(duì)數(shù)據(jù)的一次大的匯總。模塊集合和聯(lián)系人集合存儲(chǔ)著輔助的一些數(shù)據(jù)。配置庫(kù)集合詳細(xì)設(shè)計(jì)通用配置集合定義了系統(tǒng)的執(zhí)行行為，它不僅決定著對(duì)那些數(shù)據(jù)進(jìn)行采集和匯總，而且還可以配置執(zhí)行的頻率和定時(shí)任務(wù)，這個(gè)是通過(guò)parentKey和configValue來(lái)起作

33、用的。同時(shí)，可以通過(guò)configKey來(lái)做到分布式的處理，提高系統(tǒng)的運(yùn)行效率。表3.2 通用配置集合（config）字段類(lèi)型說(shuō)明_idObjectId配置編號(hào)configKeyString配置項(xiàng)parentKeyString父配置項(xiàng)configValueString配置值beginTimeDate（可選）生效時(shí)間endTimeDate（可選）失效時(shí)間seqInt（可選）序列memoString（可選）備注statusInt狀態(tài): 0 無(wú)效 1 有效createTimeDate創(chuàng)建時(shí)間updateTimeDate更新時(shí)間監(jiān)控項(xiàng)集合存儲(chǔ)了監(jiān)控項(xiàng)數(shù)據(jù)。它相當(dāng)于對(duì)采集的原始數(shù)據(jù)的分類(lèi)，對(duì)用戶(hù)關(guān)心的數(shù)據(jù)

34、進(jìn)行統(tǒng)一的監(jiān)控處理。這是通過(guò)監(jiān)控項(xiàng)集合的主鍵_id來(lái)區(qū)分不同類(lèi)別的采集結(jié)果的。表3.3監(jiān)控項(xiàng)集合（item）字段類(lèi)型說(shuō)明_idObjectId監(jiān)控項(xiàng)編號(hào)itemString監(jiān)控項(xiàng)itemEntitiesArrayItemEntity（可選）監(jiān)控項(xiàng)鍵值對(duì)象列表ItemEntity: key Stringvalue StringparticlesArrayInt 顆粒度數(shù)組（秒）serviceIdString（可選）服務(wù)編號(hào)moduleIdString（可選）模塊編號(hào)contactIdsArrayString（可選）聯(lián)系人編號(hào)數(shù)組customizableIpBoolean（可選）可自定義傳入IPm

35、emoString（可選）備注signTypeString（可選）簽名方式signKeyString（可選）簽名密鑰allowedIpsArrayString（可選）允許訪問(wèn)IP列表statusInt狀態(tài): 0 無(wú)效 1 有效 2 待審核createTimeDate創(chuàng)建時(shí)間updateTimeDate更新時(shí)間服務(wù)集合的作用其實(shí)和監(jiān)控項(xiàng)集合的功能類(lèi)似，都是用來(lái)區(qū)分?jǐn)?shù)據(jù)類(lèi)別的。只不過(guò)服務(wù)集合是用來(lái)區(qū)分匯總后的數(shù)據(jù)，是對(duì)結(jié)果數(shù)據(jù)的區(qū)分。其中最為重要的字段是collectionPrefix，它完成上面的區(qū)分功能。表3.4監(jiān)控視圖集合（service）字段類(lèi)型說(shuō)明_idObjectId服務(wù)編號(hào)servi

36、ceString服務(wù)collectionPrefixString監(jiān)控?cái)?shù)據(jù)集前綴contactIdsArrayString（可選）聯(lián)系人編號(hào)數(shù)組memoString（可選）備注statusInt狀態(tài): 0 無(wú)效 1 有效createTimeDate創(chuàng)建時(shí)間updateTimeDate更新時(shí)間模塊集合用在監(jiān)控試圖的展示上。其主要功能是區(qū)分各個(gè)模塊的數(shù)據(jù)，存儲(chǔ)一些輔助信息。它主要是和服務(wù)模塊以及聯(lián)系人模塊有關(guān)聯(lián)關(guān)系，它有個(gè)status的字段，這個(gè)字段有兩個(gè)狀態(tài)：有效和無(wú)效。通過(guò)這個(gè)字段在對(duì)模塊數(shù)據(jù)的監(jiān)控上做區(qū)分，只對(duì)有效的模塊進(jìn)行監(jiān)控操作。表3.5模塊視圖集合（module）字段類(lèi)型說(shuō)明_idObj

37、ectId模塊編號(hào)moduleString模塊serviceIdString（可選）服務(wù)編號(hào)contactIdsArrayString（可選）聯(lián)系人編號(hào)數(shù)組memoString（可選）備注statusInt狀態(tài): 0 無(wú)效 1 有效createTimeDate創(chuàng)建時(shí)間updateTimeDate更新時(shí)間監(jiān)控視圖集合是前端展示監(jiān)控?cái)?shù)據(jù)的數(shù)據(jù)結(jié)構(gòu)。它存儲(chǔ)著展示圖層的具體信息，包括圖層名稱(chēng)、橫縱坐標(biāo)的數(shù)值、模塊、聯(lián)系人等。圖層的展示就是通過(guò)這個(gè)集合加載數(shù)據(jù)的。表3.6監(jiān)控視圖集合（view）字段類(lèi)型說(shuō)明_idObjectId監(jiān)控視圖編號(hào)viewString監(jiān)控視圖itemIdsArrayString

38、監(jiān)控項(xiàng)編號(hào)數(shù)組typeInt視圖類(lèi)型: 1 折線(xiàn)圖viewTemplateJSON（可選）監(jiān)控視圖模板serviceIdString（可選）服務(wù)編號(hào)moduleIdString（可選）模塊編號(hào)contactIdsArrayString（可選）聯(lián)系人編號(hào)數(shù)組memoString（可選）備注signTypeString（可選）簽名方式signKeyString（可選）簽名密鑰allowedIpsArrayString（可選）允許訪問(wèn)IP列表statusInt狀態(tài): 0 無(wú)效 1 有效2 待審核createTimeDate創(chuàng)建時(shí)間updateTimeDate更新時(shí)間聯(lián)系人集合是個(gè)輔助集合類(lèi)，存儲(chǔ)著商

39、戶(hù)的個(gè)人信息。它與其他集合的關(guān)聯(lián)是最多的，這樣也保證了系統(tǒng)中各個(gè)商戶(hù)數(shù)據(jù)的安全性，只有當(dāng)前商戶(hù)的用戶(hù)可以看到自己的數(shù)據(jù)或者已經(jīng)授權(quán)的商戶(hù)的數(shù)據(jù)信息。表3.7聯(lián)系人集合（contact）字段類(lèi)型說(shuō)明_idObjectId聯(lián)系人編號(hào)續(xù)表 3.7字段類(lèi)型說(shuō)明companyString（可選）公司departmentString（可選）部門(mén)contactString（可選）聯(lián)系人emailString（可選）郵箱mobileString（可選）手機(jī)telString（可選）電話(huà)addressString（可選）地址memoString（可選）備注statusInt狀態(tài): 0 無(wú)效 1 有效create

40、TimeDate創(chuàng)建時(shí)間updateTimeDate更新時(shí)間實(shí)時(shí)采集庫(kù) 實(shí)時(shí)采集庫(kù)存儲(chǔ)著實(shí)時(shí)采集的原始監(jiān)控?cái)?shù)據(jù)。這個(gè)數(shù)據(jù)庫(kù)存儲(chǔ)的數(shù)據(jù)就非常的大，通常一個(gè)集合的數(shù)據(jù)會(huì)有1億條。它是對(duì)每個(gè)服務(wù)每天的數(shù)據(jù)的采集，同時(shí)會(huì)對(duì)舊的數(shù)據(jù)做定時(shí)的清理。表3.8實(shí)時(shí)采集庫(kù)框架DBCOLLECTIONROWsdmm_realservice1.20120701service1的1日明細(xì)數(shù)據(jù)service1.20120702service1的2日明細(xì)數(shù)據(jù)service2.20120701service2的1日明細(xì)數(shù)據(jù)service2.20120702service2的2日明細(xì)數(shù)據(jù) 可以看出，數(shù)據(jù)的采集是按不同服務(wù)不同

41、日期采集的，并且以service.collectionPrefix + yyyyMMdd的集合名稱(chēng)存儲(chǔ)數(shù)據(jù)。數(shù)據(jù)的監(jiān)控處理也是按照服務(wù)和天數(shù)進(jìn)行。實(shí)時(shí)采集庫(kù)集合詳細(xì)設(shè)計(jì)實(shí)時(shí)采集庫(kù)集合只有一個(gè)，就是明細(xì)數(shù)據(jù)集合。這些數(shù)據(jù)是線(xiàn)上采集的最原始的數(shù)據(jù)，其中的itemEntities字段記錄著用戶(hù)關(guān)心的數(shù)值，itemEntities是個(gè)鍵值對(duì)形式的數(shù)組數(shù)據(jù)，value一般存儲(chǔ)是數(shù)字型數(shù)據(jù)，這些數(shù)值經(jīng)過(guò)匯總后會(huì)被記錄到監(jiān)控試圖上；而itemId是監(jiān)控項(xiàng)編號(hào)，用以指明數(shù)據(jù)所屬的類(lèi)別，即是在哪個(gè)監(jiān)控項(xiàng)下的監(jiān)控?cái)?shù)據(jù)。表3.9明細(xì)數(shù)據(jù)集合字段類(lèi)型說(shuō)明_idObjectId編號(hào)itemIdString監(jiān)控項(xiàng)編號(hào)cl

42、ientIdString（可選）應(yīng)用編號(hào)ipAddressString（可選）IP地址itemEntitiesArrayItemEntity 監(jiān)控項(xiàng)鍵值對(duì)象列表ItemEntity: key Stringvalue StringcollectTimeDate采集時(shí)間createTimeDate生成時(shí)間戳采集庫(kù)中的明細(xì)數(shù)據(jù)集合之間是相互獨(dú)立的。由于明細(xì)數(shù)據(jù)集合的數(shù)據(jù)量龐大，所以建立了索引，提高數(shù)據(jù)的檢索速度。MongoDB索引和關(guān)系型數(shù)據(jù)庫(kù)的規(guī)則是一樣的，在經(jīng)常要用到查詢(xún)的列建立索引。一般的形式是ensureIndex(列名:1, 列名:-1.)，其中指明了在什么列上建立索引，以及建立索引的順序

43、。特別是在建立復(fù)合索引的時(shí)候一定要考慮好是升序還是降序。匯總庫(kù)對(duì)實(shí)時(shí)采集庫(kù)中的數(shù)據(jù)對(duì)每個(gè)服務(wù)按照匯總時(shí)間顆粒度切分?jǐn)?shù)據(jù)集，數(shù)據(jù)行存儲(chǔ)具體監(jiān)控項(xiàng)。匯總集合是按照預(yù)定的時(shí)間粒度來(lái)分別存儲(chǔ)數(shù)據(jù)的。預(yù)定時(shí)間值是在監(jiān)控項(xiàng)集合中的itemEntities字段中指示，其是個(gè)數(shù)組類(lèi)型的字段，可以指定多個(gè)值。表3.10匯總庫(kù)框架DBCOLLECTIONROWsdmm_storeservice1.60.20120701.nlservice1的1日1分鐘匯總數(shù)據(jù)service1.300. 20120701.nlservice1的1日5分鐘匯總分組數(shù)據(jù)service1.3600.20120701service1的1日

44、1小時(shí)匯總數(shù)據(jù)service1.d.2012service1的2012年按日匯總數(shù)據(jù)service1.m.2012service1的2012年按月匯總數(shù)據(jù)service1.yservice1的按年匯總數(shù)據(jù)由表3.10可見(jiàn)，匯總庫(kù)的集合是很據(jù)時(shí)間粒度的匯總，或者是按天、按月、按年的匯總，命名的規(guī)則和采集庫(kù)類(lèi)似，具體如下：1、按監(jiān)控項(xiàng)顆粒度配置匯總sdmm_config.service.collectionPrefix + particle + yyyyMMdd；2、按日匯總 sdmm_config.service.collectionPrefix + d + yyyy3、按月匯總 sdmm_co

45、nfig.service.collectionPrefix + m + yyyy4、按年匯總 sdmm_config.service.collectionPrefix + y匯總庫(kù)集合詳細(xì)設(shè)計(jì)匯總庫(kù)里的集合雖然比采集庫(kù)的復(fù)雜，但是都是其內(nèi)部的數(shù)據(jù)結(jié)構(gòu)都是一樣的，因此也只有一個(gè)集合，即匯總數(shù)據(jù)集合。其中比較重要的字段是itemEntities和particle。itemEntities即關(guān)心的監(jiān)控項(xiàng)的鍵值對(duì)象列表，和明細(xì)數(shù)據(jù)集合中的類(lèi)似，只是匯總數(shù)據(jù)集合的itemEntities包含了“同類(lèi)型”的雖有的監(jiān)控項(xiàng)的鍵值對(duì)象；particle是時(shí)間顆粒度，表示是做怎樣的時(shí)間間隔的匯總操作，監(jiān)控的是哪段

46、時(shí)間內(nèi)的數(shù)據(jù)。表3.11匯總數(shù)據(jù)集合字段類(lèi)型說(shuō)明_idObjectId編號(hào)itemIdString監(jiān)控項(xiàng)編號(hào)clientIdString（可選）應(yīng)用編號(hào)ipAddressString（可選）IP地址itemEntitiesArrayItemEntity 監(jiān)控項(xiàng)鍵值對(duì)象列表ItemEntity: key Stringvalue StringparticleInt顆粒度（秒）assembleTimeDate匯總時(shí)間createTimeDate生成時(shí)間戳匯總庫(kù)中的匯總數(shù)據(jù)集合之間是相互獨(dú)立的。同時(shí)，匯總數(shù)據(jù)集合也建立了索引來(lái)提高自身的檢索速度。本章小結(jié)本章介紹了監(jiān)控系統(tǒng)數(shù)據(jù)庫(kù)系統(tǒng)的設(shè)計(jì)方案。整個(gè)系統(tǒng)

47、包括了三個(gè)重要的數(shù)據(jù)庫(kù)：配置庫(kù)、采集庫(kù)和匯總庫(kù)。配置庫(kù)是監(jiān)控系統(tǒng)的配置解決方案，存儲(chǔ)配置信息，數(shù)據(jù)庫(kù)系統(tǒng)的“指令中心”。配置庫(kù)是系統(tǒng)的靈活性得到很大的提高。采集庫(kù)是監(jiān)控系統(tǒng)實(shí)時(shí)采集的原始數(shù)據(jù)的存儲(chǔ)庫(kù)，其特點(diǎn)是數(shù)據(jù)龐大，并且數(shù)據(jù)可能是沒(méi)有規(guī)則的。匯總庫(kù)是監(jiān)控系統(tǒng)對(duì)原始數(shù)據(jù)MapReduce處理后的結(jié)果數(shù)據(jù)，是最終體現(xiàn)的監(jiān)控視圖上的數(shù)據(jù)。數(shù)據(jù)按照時(shí)間顆粒度和監(jiān)控項(xiàng)來(lái)分別存儲(chǔ)在匯總庫(kù)的各個(gè)集合當(dāng)中。數(shù)據(jù)庫(kù)系統(tǒng)是監(jiān)控系統(tǒng)的核心所在，其設(shè)計(jì)的優(yōu)劣直接影響著監(jiān)控系統(tǒng)的性能。浙江大學(xué)碩士學(xué)位論文第4章 STYLEREF 標(biāo)題 1,章標(biāo)題(有序號(hào)) * MERGEFORMAT 數(shù)據(jù)庫(kù)集群的搭建 PAGE 4

48、PAGE 29數(shù)據(jù)庫(kù)集群的搭建集群數(shù)據(jù)存儲(chǔ)結(jié)構(gòu)Mongodb的數(shù)據(jù)文件都存儲(chǔ)在系統(tǒng)指定的路徑下，一般是通過(guò)配置的dbpath來(lái)指定目錄，本系統(tǒng)指定為/data/dbs。集群中的每個(gè)數(shù)據(jù)庫(kù)的結(jié)構(gòu)都是類(lèi)似的，是大致的一些列文件所組成，即一個(gè).ns文件和若干的數(shù)據(jù)文件。.ns文件存儲(chǔ)著所有命名空間的元數(shù)據(jù)。數(shù)據(jù)庫(kù)中的每個(gè)集合都有各自對(duì)應(yīng)的名字空間，索引文件也有。這些命名空間就統(tǒng)一在.ns文件中管理。.ns文件的存儲(chǔ)結(jié)構(gòu)是哈希表，key值是命名空間的名字，value值是對(duì)應(yīng)的命名空間的信息。哈希表節(jié)點(diǎn)的數(shù)據(jù)大小時(shí)628字節(jié)，而.ns文件默認(rèn)的大小是16M，因此.ns文件默認(rèn)可以存放26715個(gè)命名空間

49、17。但是，可以根據(jù)實(shí)際的需要通過(guò)-nssize選項(xiàng)來(lái)設(shè)置.ns文件的大小。數(shù)據(jù)文件存儲(chǔ)著具體的數(shù)據(jù)，并且數(shù)據(jù)文件是可增長(zhǎng)的，每新分配一次，數(shù)據(jù)文件的大小都是上一次文件大小的2倍。但是這種增長(zhǎng)不是無(wú)限制的，每個(gè)數(shù)據(jù)文件最大只能為2G，超過(guò)2G的會(huì)另起文件存儲(chǔ)。這樣的機(jī)制是百利而無(wú)一害的，它不僅反之了較小的數(shù)據(jù)庫(kù)存儲(chǔ)產(chǎn)生的磁盤(pán)碎片導(dǎo)致的磁盤(pán)空間的浪費(fèi)，同時(shí)又能保證較大的數(shù)據(jù)庫(kù)有相應(yīng)的預(yù)留空間留待使用，還提高了數(shù)據(jù)檢索的速度。圖4.1 數(shù)據(jù)文件格式DataFileHeader是數(shù)據(jù)文件的頭部，后面是Extent的部分，也就是數(shù)據(jù)的主體部分17。文件空間是按照Extent為單位分配的，每個(gè)集合所申請(qǐng)

50、的Extent是通過(guò)雙向鏈表的形式鏈接組織在一起，鏈表的表頭和表尾數(shù)據(jù)存放在命名空間信息里。Record即記錄之意，是數(shù)據(jù)具體的存放地，是在Extent里分配的，每個(gè)Extent里的所有Record同樣是按照雙向鏈表的數(shù)據(jù)結(jié)構(gòu)存儲(chǔ)，表頭和表尾存放在Extent頭部。對(duì)數(shù)據(jù)的訪問(wèn)方法是先遍歷Extent鏈表，在對(duì)找到的對(duì)應(yīng)的Extent遍歷其中的Record鏈表，找到對(duì)應(yīng)的記錄。如圖4.2所示：圖4.2 數(shù)據(jù)存儲(chǔ)示意圖空閑的Record根據(jù)其大小，形成19個(gè)單向的鏈表。這些Record是Extend里剩余的空間或者是被刪除的記錄。在存儲(chǔ)空間申請(qǐng)的時(shí)候，是先從DeleteRecord單鏈表中進(jìn)行查

51、找的，由圖上可以看出，從第一個(gè)鏈表開(kāi)始，一直查找，有空余空間的話(huà)，就把這個(gè)空間分配出去，沒(méi)有就繼續(xù)往下找；如果DeleteRecord都查找完畢，說(shuō)明沒(méi)有空余的空間可用，需要分配新的空間，從而在Extent里分配一個(gè)新的Record塊。這種模式是基于MongoDB內(nèi)部的預(yù)分配機(jī)制，每個(gè)預(yù)分配的文件用0填充，這樣保持額外的空間和空余的數(shù)據(jù)文件，可以有效的避免由于數(shù)據(jù)暴增所帶來(lái)的磁盤(pán)壓力大的問(wèn)題。集群數(shù)據(jù)的寫(xiě)入?yún)f(xié)議MongoDB集群寫(xiě)入?yún)f(xié)議是基于socket的請(qǐng)求響應(yīng)協(xié)議，系統(tǒng)客戶(hù)端通過(guò)TCP/IP和數(shù)據(jù)集群交互。集群數(shù)據(jù)庫(kù)默認(rèn)的Socket的端口是27017，但是這個(gè)是可以改變的，可以通過(guò)-po

52、rt參數(shù)配置?；趕oket的數(shù)據(jù)交互是在Bson數(shù)據(jù)的上面做了一層簡(jiǎn)單的包裝，加入了1個(gè)20字節(jié)大小的消息頭，這是個(gè)類(lèi)C結(jié)構(gòu)體的數(shù)據(jù)結(jié)構(gòu)。數(shù)據(jù)交互中有兩個(gè)消息頭協(xié)議，客戶(hù)端請(qǐng)求消息頭和數(shù)據(jù)庫(kù)響應(yīng)消息頭?？蛻?hù)端請(qǐng)求消息頭每個(gè)從客戶(hù)端發(fā)送過(guò)來(lái)的數(shù)據(jù)都是由標(biāo)準(zhǔn)的消息頭和具體的需要數(shù)據(jù)所組成。協(xié)議頭的格式如下18：struct MsgHeader int32 messageLength; int32 requestID;int32 responseTo; int32 opCode; messageLength指示這個(gè)消息的大?。ㄗ止?jié)數(shù)），這個(gè)大小是已經(jīng)包含了4個(gè)字節(jié)的消息頭。requestID是消息

53、的唯一標(biāo)識(shí)，由客戶(hù)端或者數(shù)據(jù)庫(kù)生成。并且，如果這個(gè)是客戶(hù)端生成的，它將在數(shù)據(jù)庫(kù)響應(yīng)后返回給客戶(hù)端，從而可以保證查詢(xún)的一致性。responseTo結(jié)合requestID被返回到客戶(hù)端。opCode操作碼，消息操作的類(lèi)型定義。表4.1請(qǐng)求操作碼19操作碼名操作碼值說(shuō)明OP_REPLY1客戶(hù)端請(qǐng)求的響應(yīng)OP_MSG1000通用消息命令OP_UPDATE2001更新OP_INSERT2002插入RESERVED2003保留字段OP_QUERY2004查詢(xún)OP_GET_MORE2005獲取跟多數(shù)據(jù)OP_DELETE2006刪除OP_KILL_CURSORS2007操作結(jié)束數(shù)據(jù)庫(kù)響應(yīng)消息頭數(shù)據(jù)庫(kù)響應(yīng)消息是

54、數(shù)據(jù)庫(kù)為了響應(yīng)客戶(hù)端的OP_QUERY和OP_GET_MORE請(qǐng)求時(shí)發(fā)出的消息。其消息的格式化頭為18：struct MsgHeader header; int32 responseFlags; int64 cursorID; int32 startingFrom; int32 numberReturned; document* documents; documents是返回的具體數(shù)據(jù)，numberReturned是總的返回?cái)?shù)量，startingFrom標(biāo)示游標(biāo)開(kāi)始的位置，responseFlags是返回給客戶(hù)端的標(biāo)示信息位，具體含義如4.2表：表4.2響應(yīng)標(biāo)示碼19數(shù)值信息說(shuō)明0Cursor

55、NotFound游標(biāo)未指定有效值1QueryFailure查詢(xún)失敗2ShardConfigStale提示需要更新config配置3AwaitCapable查詢(xún)等待4-31Reserved保留字段，忽略監(jiān)控系統(tǒng)的集群配置方案本系統(tǒng)采用副本模式（Replica-Set）的海量數(shù)據(jù)處理解決方案。建立了三個(gè)節(jié)點(diǎn)的數(shù)據(jù)集群，分別部署在三臺(tái)服務(wù)器上。配置文件如下：config = _id : sdmm_store, members : _id : 0, host : 2:27017, priority : 10, _id : 1, host : 1:27018, priority : 1,_id : 2,

56、 host : 23:27019, priority : 1, _id : 3, host : 40:27020, priority : 1, arbiterOnly : true 這里priority指定節(jié)點(diǎn)的優(yōu)先級(jí)，優(yōu)先級(jí)的值為110，值越大說(shuō)明這個(gè)節(jié)點(diǎn)稱(chēng)為主節(jié)點(diǎn)的可能性就越高。我們將240服務(wù)器上的主機(jī)設(shè)置為仲裁機(jī)，它不負(fù)責(zé)任何的讀寫(xiě)，只是一個(gè)仲裁者，負(fù)責(zé)主節(jié)點(diǎn)崩潰后剩余節(jié)點(diǎn)的選舉操作。定義仲裁者是為了防止剩余節(jié)點(diǎn)都稱(chēng)為Secondary節(jié)點(diǎn)而沒(méi)有Primary節(jié)點(diǎn)而出現(xiàn)的整個(gè)服務(wù)不可用，它會(huì)根據(jù)當(dāng)前優(yōu)先級(jí)最高的并且數(shù)據(jù)新鮮度最新的節(jié)點(diǎn)作為主節(jié)點(diǎn)。集群節(jié)點(diǎn)（配置庫(kù)節(jié)點(diǎn)sdmm-confi

57、g）的配置如下：表4.3 集群節(jié)點(diǎn)配置port27017dbpath/opt/mongodata/sdmm_config/data/dbs/r0logpath/opt/mongodata/sdmm_config/logs/r0.logkeyFile/opt/mongodata/sdmm_config/conf/keyFile/keyforktrueauthtruedirectoryperdbtruenssize128maxConns1500oplogSize10240journaltruelogappendtruenohttpinterfacetruereplSetsdmm_config這里的

58、port參數(shù)指定服務(wù)端口號(hào)；dbpath來(lái)指定數(shù)據(jù)庫(kù)路徑；logpath用來(lái)指定MongoDB日志文件，這里是直接文件而不是目錄；keyFile是集群的私鑰的完整路徑，這個(gè)屬性只對(duì)Replica Set集群架構(gòu)起作用；fork參數(shù)的作用是使進(jìn)程按守護(hù)進(jìn)程額方式運(yùn)行MongoDB；auth指示客戶(hù)端連接到集群上需要經(jīng)過(guò)驗(yàn)證，認(rèn)證的信息都是存儲(chǔ)在keyFile所指向的文件，加上驗(yàn)證是為數(shù)據(jù)庫(kù)集群建立一個(gè)受信任的環(huán)境；directoryperdb來(lái)設(shè)置每個(gè)數(shù)據(jù)庫(kù)是被保存在一個(gè)單獨(dú)的目錄中，默認(rèn)的情況時(shí)不分開(kāi)的，目錄的路徑有dbpath參數(shù)決定，這樣設(shè)置可以提高數(shù)據(jù)集群的讀寫(xiě)效率；nssize是設(shè)置.

59、ns文件的大小的；maxConns指明同步連接到集群上的線(xiàn)程的最大數(shù)，其最大值為20000，超過(guò)最大值不起作用；oplogSize指定日志的大小，單位為兆字節(jié)；logappend指明日志是追加的方式寫(xiě)入日志文件中，但是由于oplogSize的指定，這種追加不是無(wú)限制的；journal參數(shù)確保寫(xiě)入的穩(wěn)定性和數(shù)據(jù)的一致性；nohttpinterface關(guān)閉HTTP端口。集群一共有三個(gè)數(shù)據(jù)庫(kù)，分別是配置庫(kù)sdmm-config、采集庫(kù)sdmm-real、匯總庫(kù)sdmm-store。每個(gè)庫(kù)又配置了三個(gè)數(shù)據(jù)節(jié)點(diǎn)，其配置都如上面的配置一樣，監(jiān)控平臺(tái)集群配置的示意圖如圖4.3所示：圖4.3 監(jiān)控平臺(tái)集群架構(gòu)

60、圖配置庫(kù)的數(shù)據(jù)直接決定著采集庫(kù)和匯總庫(kù)的操作，而采集庫(kù)的數(shù)據(jù)又直接決定著匯總庫(kù)的操作。它們之間不是數(shù)據(jù)或者指令的交互，而是數(shù)據(jù)之間的限制。每個(gè)數(shù)據(jù)庫(kù)都是一個(gè)集群配置，Mongodb(M)表示Primary節(jié)點(diǎn)，Mongodb(S)表示Secondary節(jié)點(diǎn)，Mongodb(A)表示Arbiter節(jié)點(diǎn)。主節(jié)點(diǎn)和備節(jié)點(diǎn)是存儲(chǔ)數(shù)據(jù)的地方，而仲裁節(jié)點(diǎn)不存儲(chǔ)數(shù)據(jù)。主節(jié)點(diǎn)提供所有的服務(wù)，即增刪改查；備節(jié)點(diǎn)只提供查詢(xún)的服務(wù)，這樣可以減少主節(jié)點(diǎn)的壓力，當(dāng)客戶(hù)端進(jìn)行數(shù)據(jù)查詢(xún)時(shí)，查詢(xún)請(qǐng)求會(huì)自動(dòng)轉(zhuǎn)到備節(jié)點(diǎn)上進(jìn)行查詢(xún)。同時(shí)，備節(jié)點(diǎn)需要定時(shí)的跟主節(jié)點(diǎn)進(jìn)行數(shù)據(jù)的同步，所以在主節(jié)點(diǎn)和備節(jié)點(diǎn)間有數(shù)據(jù)的交互。客戶(hù)端不直接和仲裁