基于MongoDb海量数据存储的商户平台监控系统

1、浙江大学硕士学位论文 STYLEREF 标题,章标题(无序号) * 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 技术背景 PAGEREF _Toc353996864 h 2 HYPERLINK l _Toc353996865 1.3 国内外研究现状 PAGEREF _Toc353996865 h 3 HYPERLINK l _Toc353996866 1.3.

3、1 国外研究现状 PAGEREF _Toc353996866 h 3 HYPERLINK l _Toc353996867 1.3.2 国内研究现状 PAGEREF _Toc353996867 h 3 HYPERLINK l _Toc353996868 1.4 本文选题背景及研究内容 PAGEREF _Toc353996868 h 4 HYPERLINK l _Toc353996869 第2章 监控系统关键技术 PAGEREF _Toc353996869 h 6 HYPERLINK l _Toc353996870 2.1 Maven2原理 PAGEREF _Toc353996870 h 6 HY

4、PERLINK l _Toc353996871 2.2 非关系型数据库 PAGEREF _Toc353996871 h 7 HYPERLINK l _Toc353996872 2.2.1 NoSQL的发展和现状 PAGEREF _Toc353996872 h 7 HYPERLINK l _Toc353996873 2.2.2 NoSQL处理上的优势 PAGEREF _Toc353996873 h 8 HYPERLINK l _Toc353996874 2.3 MongoDB技术 PAGEREF _Toc353996874 h 9 HYPERLINK l _Toc353996875 2.3.1

5、MongoDB数据结构 PAGEREF _Toc353996875 h 9 HYPERLINK l _Toc353996876 2.3.2 MongoDB处理海量数据的策略 PAGEREF _Toc353996876 h 10 HYPERLINK l _Toc353996877 2.4 EJSChart技术 PAGEREF _Toc353996877 h 12 HYPERLINK l _Toc353996878 2.5 本章小结 PAGEREF _Toc353996878 h 13 HYPERLINK l _Toc353996879 第3章 数据库设计 PAGEREF _Toc35399687

6、9 h 14 HYPERLINK l _Toc353996880 3.1 配置库 PAGEREF _Toc353996880 h 14 HYPERLINK l _Toc353996881 3.1.1 整体框架和集合间关系 PAGEREF _Toc353996881 h 14 HYPERLINK l _Toc353996882 3.1.2 配置库集合详细设计 PAGEREF _Toc353996882 h 15 HYPERLINK l _Toc353996883 3.2 实时采集库 PAGEREF _Toc353996883 h 18 HYPERLINK l _Toc353996884 3.2.

7、1 实时采集库集合详细设计 PAGEREF _Toc353996884 h 18 HYPERLINK l _Toc353996885 3.3 汇总库 PAGEREF _Toc353996885 h 19 HYPERLINK l _Toc353996886 3.3.1 汇总库集合详细设计 PAGEREF _Toc353996886 h 20 HYPERLINK l _Toc353996887 3.4 本章小结 PAGEREF _Toc353996887 h 20 HYPERLINK l _Toc353996888 第4章 数据库集群的搭建 PAGEREF _Toc353996888 h 22 H

8、YPERLINK l _Toc353996889 4.1 集群数据存储结构 PAGEREF _Toc353996889 h 22 HYPERLINK l _Toc353996890 4.2 集群数据的写入协议 PAGEREF _Toc353996890 h 23 HYPERLINK l _Toc353996891 4.2.1 客户端请求消息头 PAGEREF _Toc353996891 h 24 HYPERLINK l _Toc353996892 4.2.2 数据库响应消息头 PAGEREF _Toc353996892 h 24 HYPERLINK l _Toc353996893 4.3 监控

9、系统的集群配置方案 PAGEREF _Toc353996893 h 25 HYPERLINK l _Toc353996894 4.4 集群主节点的选举仲裁机制 PAGEREF _Toc353996894 h 28 HYPERLINK l _Toc353996895 4.5 本章小结 PAGEREF _Toc353996895 h 29 HYPERLINK l _Toc353996896 第5章 监控系统的详细设计 PAGEREF _Toc353996896 h 30 HYPERLINK l _Toc353996897 5.1 系统整体架构 PAGEREF _Toc353996897 h 30

10、HYPERLINK l _Toc353996898 5.2 监控平台各模块的设计方案 PAGEREF _Toc353996898 h 31 HYPERLINK l _Toc353996899 5.2.1 数据采集模块 PAGEREF _Toc353996899 h 31 HYPERLINK l _Toc353996900 5.2.2 数据汇总模块 PAGEREF _Toc353996900 h 32 HYPERLINK l _Toc353996901 5.2.3 监控展现模块 PAGEREF _Toc353996901 h 32 HYPERLINK l _Toc353996902 5.2.4

11、监控配置模块 PAGEREF _Toc353996902 h 33 HYPERLINK l _Toc353996903 5.3 监控系统的程序实现 PAGEREF _Toc353996903 h 33 HYPERLINK l _Toc353996904 5.4 商户平台对监控系统的调用方式 PAGEREF _Toc353996904 h 35 HYPERLINK l _Toc353996905 5.5 本章小结 PAGEREF _Toc353996905 h 37 HYPERLINK l _Toc353996906 第6章 数据库集群性能测试 PAGEREF _Toc353996906 h 3

12、8 HYPERLINK l _Toc353996907 6.1 测试环境 PAGEREF _Toc353996907 h 38 HYPERLINK l _Toc353996908 6.1.1 硬件环境 PAGEREF _Toc353996908 h 38 HYPERLINK l _Toc353996909 6.1.2 软件环境 PAGEREF _Toc353996909 h 38 HYPERLINK l _Toc353996910 6.2 测试点和测试方案 PAGEREF _Toc353996910 h 38 HYPERLINK l _Toc353996911 6.3 查询性能测试 PAGER

13、EF _Toc353996911 h 39 HYPERLINK l _Toc353996912 6.4 插入性能测试 PAGEREF _Toc353996912 h 39 HYPERLINK l _Toc353996913 6.5 测试结果总结 PAGEREF _Toc353996913 h 40 HYPERLINK l _Toc353996914 6.6 本章小结 PAGEREF _Toc353996914 h 40 HYPERLINK l _Toc353996915 第7章 总结和展望 PAGEREF _Toc353996915 h 42 HYPERLINK l _Toc353996916

14、 7.1 总结 PAGEREF _Toc353996916 h 42 HYPERLINK l _Toc353996917 7.2 展望和进一步的工作 PAGEREF _Toc353996917 h 43 HYPERLINK l _Toc353996918 参考文献 PAGEREF _Toc353996918 h 44 HYPERLINK l _Toc353996919 作者简历 PAGEREF _Toc353996919 h 46 HYPERLINK l _Toc353996920 致 谢 PAGEREF _Toc353996920 h 47浙江大学硕士学位论文 STYLEREF 样式1 *

15、MERGEFORMAT 表目录 监控系统关键技术 PAGE 2 PAGE 13监控系统关键技术Maven2原理Maven作为Apache的一个开源项目，旨在给项目管理提供更多的支持9。它最早的意图只是为了给apache组织的几个项目提供统一的开发、测试、打包和部署，管理项目的配置文件和依赖的jar包，让开发者在多个项目中方便的切换和管理大型项目。Maven的基本原理很简单，Maven管理着远程仓库、本地仓库和pom.xml文件。xml文件是jar包的描述文件，主要描述了配置文件，规则、项目的依赖关系，包括项目（或者组织的唯一标识）、项目的通用名称、项目的版本，组织和license等。通过pom

16、.xml的定义的依赖，将jar包从远程仓库下载到本地仓库中来，供本地程序使用，并且每个应用系统使用同一个本地仓库，而同一个版本的jar包只会打包下载一次。图2.1 pom.xml文件Maven采用了现在非常流行的插件式的体系架构，只保留着最小的核心，其余的功能都是通过扩展插件的形式提供出来10。同时，下载插件的操作只有在执行Maven任务的时候才会进行。这个原理和php扩展与应用库的原理相似，都是在维护一个官方的仓库，通过网络下载到本地的仓库中，并且内核都很小。Maven的原理架构如图2-2所示。相比于Ant，maven的优势就显得比较突出。Maven包含了Ant的所有功能，并且更加强大，如对

17、第三方依赖库的同一版本管理，项目的目录结构都比较统一，每个项目可以很好的做到兼容，支持多种插件，并且可以把这些插件连同第三方依赖一起进行统一版本的管理。而Ant需要为不同的项目编写不通用的build.xml脚本，这使得每个项目都很繁杂并且不兼容。图2.2 Maven原理图这里的步骤 eq oac(,2)是为了检查本地库库中是否已经存在需要下载的jar包了，如果没有才会执行 eq oac(,3)、 eq oac(,4)步骤。非关系型数据库非关系型数据库的特点是：非关系型、分布式的、开源的、水平可扩展的11。非关系型数据库的出现和兴起是随着互联网web2.0网站的兴趣而出现的，因为在面对大规模数据

18、量和高并发访问的web2.0动态网站时，传统的关系型数据库显得力不从心，暴露了很多致命的问题。而这时，非关系型数据库则由于其自身的特点得到很好的发展。NoSQL的发展和现状NoSQL（Not Only SQL）早起就有人提出，是一项对传统关系数据库的革命性运动。但是NoSQL数据库并不是想取代已经广泛使用的传统的关系型数据库，只是采用了一种不同于关系型的方式解决关系型数据库的数据存储和计算方面的问题。NoSQL数据库的定义并不像传统数据库那样的严格，只需要数据库内部数据的组织采用非关系型的方式就可以称之为NoSQL12。目前的NoSQL数据按照内部的数据组织形式可以分为5类：图2.3 目前No

19、SQL的分类131）基于Key/Value的NoSQL数据库。特点就是简单并且足够强大，运行速度快。但存在一个很严重的问题，就是需要查找一段范围内的key。2）基于排序Key/Value的NoSQL数据库。在原来的Key/Value的基础上做了数据集的有序化处理。但是它没有对value提供具体的数据模型，通常而言，value的模型应该可以由应用负责解析和存取的。3）基于Big Table的NoSQL数据库。它的出现时为了解决上面value没有提供具体的数据模型的问题。4）基于文档的NoSQL数据库。对BigTable模型做了改进，第一是允许value中有主观的模式，而不是无限制的map嵌套；第

20、二是索引，提高了数据库的检索速度和效率。这方面的代表产品是MongoDB，也是本文所采用的数据解决方案。5）基于图式的NoSQL数据库。可以认为是从排序Key/Value数据库发展过来的的一个分支，允许构建图结构的数据模型。NoSQL处理上的优势满足数据库高并发读写的需求。NoSQL满足了web2.0网站的实时生成动态页面和提供动态信息而带来的对数据库高并发的要求。传统的数据库在处理上万次的sql查询和写数据时，显得很有压力，而NoSQL则可以轻松达到数十万次。满足海量数据的高效率存储和访问的需求。一个大型的SNS网站，每天产生的动态用户信息就可以达到1亿。对于关系型数据库而言，在一张含有亿条

21、记录的表里进行SQL的操作其效率是及其低下的。而对于web网站的用户登录系统，其注册账号就数以亿计了。满足数据库的高可扩展性和高可用性的需求。基于web的架构中，数据库的横向扩展往往被局限于技术，当一个应用系统的用户数和访问量足够大时，数据库很难通过更多的硬件和服务节点来扩充性能和负载能力。而对数据库系统的升级扩展往往需要停机维护和数据迁移，这对于web网站来说损失是不小的。MongoDB技术MongoDB数据结构MongoDB是一个高性能，开源、无模式的文档型数据库。比之于传统的关系型数据库，mongodb用集合的概念取代了表的概念，用文档的概念取代了行。对MongoDB数据库的理解就是把数

22、据分组存储在数据集中，每个集合在数据库中都有一个唯一的标识名称，并且可以包含无限数目的文档14。这样的组织及结构也才能保证MongoDB数据的模式自由性。MongoDB的数据组织结构如图2.4所示：图2.4 MongoDB数据组织结构该图通过用户评论博客描述了MongoDB数据的组织形式和数据的关联关系。这里有两个集合（表）：用户表和博客表。博客表中又存在着非简单数据模型，文章及其评论。在传统的数据库中，这两个model会被设计成单独的表结构，但是现在是作为博客表的一个字段存在（集合形式）。一个用户可以在博客上写很多文章和评论，用户对文章和评论是一对多的关系。通过集合字段的存储模式可以体现出了

23、这种模式关系。可以看出，MongoDB的数据组织结构使数据库的变得简单，表之间的关系在表的结构中就已经定义好了。MongoDB处理海量数据的策略主从模式（Master/Slave）通常的数据库配置方案是一个Master和一个或多个Slave。Master和Slave节点做到数据同步。从数据库在启动的时候即马上和主服务器进行数据的同步，这种同步是部分从数据库的启动先后的，也不需要手动操作。同时，可以对Mater节点进行数据的读写操作，但是Slave节点只允许读取操作而不能写入。这样既提高了数据库的读的效率，也保证了数据的一致性。同时写入多个节点就可能造成数据在各个节点的不一致，最后从节点到主节点

24、上进行数据同步就可能取得错误的数据。主从模式的缺点是不能保证数据库的安全性。即主节点宕机或异常情况下的数据库的正常使用。因为它没有节点自动切换的功能。图2.5 Master/Slave示意图副本模式（Relpica-Set）副本模式是在主从模式的基础上而来，它包含了主从模式所包含的功能。集群结构也同主从模式一样，一个Primary节点和一个或多个Secondary节点。需要注意的是这里的主节点和从节点不是一成不变的，它们的关系不像是主从模式那样固定。副本模式的Primary节点是通过自动协商竞选出来的。副本模式最大的优势在于其数据库安全性能的提高。副本模式的配置方案保证了Primary节点宕机

25、时的数据库的正常运行。因为在主节点异常时，Secondary节点会通过竞选的机制来选取其中的一个节点来充当Primary节点。而这些操作对应用程序来说，这些是完全透明的，不会影响到程序的正常运行。同时，当原来的主节点回复后，当前的“临时”主节点就会自动降为slave。图2.6 Replca-Set示意图分片（Sharding）分片集群是一种可以水平扩展的模式，在特别适合处理大数据。构建一个分片集群需要三个部分15：1）分片服务（Shard Server）：用于存储实际的数据分片，实际环境中可以由多台机器组成一个replica-set来承担，可以避免主机单点故障。2）配置服务（Config Se

26、rver）：存储整个集群的元数据。3）路由服务（Routing Server）：前端路由，屏蔽分配服务的细节，使整个集群对客户端来说是一个单一的数据库，前端可以透明的使用。图2.7 Sharding架构示意图14MongoDB的分片机制是根据shard keys来划分数据，keys可以通过文档的一个或者多个物理键值组成。同时，chunk不存储实际的数据，而是一组数据集合，表示为collection、minKey和maxKey构成的三元组。当chunk的大小查过了ChunkSize，mongoDB会根据minKey和maxKey的中间值将这个chunk切分为两个子chunk，再根据各个分片的负载

27、情况，存储到分片16。EJSChart技术EJSChart提供了真正易于使用和完全定制化的图表展示，可以快速发布各种数据的各种格式。之所以选择EJSChart作为监控数据图层的展示，是由于其所具有的特点：1）交互性。EJSChart提供了拐点信息提示、鼠标轨迹跟踪、键盘事件、图像的放大、缩小等功能，使得图层的展示不再死板，而是可以根据用户自己的爱好和关注点对图像做出选择的查看。2）坐标轴的自动缩放。开发人员不必再在图像展示前确定坐标轴的范围，EJSChart会自动的计算和测量出刻度来展示各种数据值。3）堆叠性。多个图像可以在一个图层上展示，它们可以很好的占据图层，而不会出现图像的混乱。这很适应

28、监控系统多个项目的线数据的展示。4）多种图类型支持。EJSChart提供了线图、块图、饼图、柱状图等的支持，可以满足各种实际的业务需求。而随着EJSChart的火热发展，新的高可用的图将会出现。5）Ajax动态数据加载。EJSChart提供了xml格式的数据显示，同时可以动态的加载数据，这样一方面提高了图层的应用范围，同时也是加快的页面的展示速度。6）兼容性好。EJSChart在IE、firefox、chrome等浏览器上都具有很好的兼容性，显示的图像不会因为浏览器的不同而存在差异。本章小结本章介绍了监控系统所使用到的关键技术。包括java程序的标准构建工具maven的实现原理、非关系型数据库

29、的发展和现状，以及其比之于传统关系型数据库上的优势、并重点介绍了非关系型数据库中发展的比较成熟的MongoDB，论述了MongoDB的数据结构，以及其在处理海量数据上特有的集中策略，这些策略包括：主从模式、副本模式、分片。在分析了各自的原理和特点后，在本项目中采用了副本模式作为集群服务器的搭建方案。最后介绍了下完全基于JS实现的页面图像展示技术EJSChart，重点介绍了EJSChart的几大特点，以及其在处理页面图像上的优势，从而确定其作为图像展示的解决方法。浙江大学博士学位论文: STYLEREF 论文中文标题 * MERGEFORMAT 错误！文档中没有指定样式的文字。浙江大学硕士学位论

30、文第3章 STYLEREF 标题 1,章标题(有序号) * MERGEFORMAT 数据库设计 PAGE 4 PAGE 21数据库设计配置库配置库主要是存储监控项相关的属性以及监控试图的属性。控制监控系统的操作行为，是系统的“指令中心”。该库中包含了6个集合（表）：监控项集合、监控试图集合、服务集合、模块集合、联系人集合和通用配置集合。表3.1 配置库框架DBCOLLECTIONEXPLANATIONsdmm_configitem监控项view监控视图service服务module模块contact联系人config通用配置整体框架和集合间关系配置库处在监控系统数据库配置中的核心位置，它是系统

31、的调度中心，决定着系统工作的模式。因此配置库中的集合也比较多比较复杂，如图3.1所示：图3.1 配置库集合关系图通用配置集合是监控系统访问MongoDB数据库的入口，它最重要的字段就是configValue，其指明执行的配置值，也就是对哪些数据进行采集监控，哪些是不需要的。通用配置集合直接关联到监控项集合，是“one-to-many”的关系。一个通用配置文档可以对应多个监控项文档。监控项集合在整个数据库方案中很处于中心地位，它的serviceId字段直接关联到服务集合上，定义这样的关联关系是为了得到汇总集合的名称前缀。它的关联关系是“one-to-one”的模式，即一个serviceId只能在

32、服务集合中取得一个前缀。服务集合的作用就是存储上面描述的集合前缀，前缀的作用是用来区分监控数据，相当于是数据的分类。表现这个功能的字段是collectionPrefix。监控试图集合和其他的集合的关联最多，因为它是最后监控图层展示所读取的数据库。它和监控项集合存在着“one-to-many”的关系，和服务集合和模块集合存在“one-to-one”，是对数据的一次大的汇总。模块集合和联系人集合存储着辅助的一些数据。配置库集合详细设计通用配置集合定义了系统的执行行为，它不仅决定着对那些数据进行采集和汇总，而且还可以配置执行的频率和定时任务，这个是通过parentKey和configValue来起作

33、用的。同时，可以通过configKey来做到分布式的处理，提高系统的运行效率。表3.2 通用配置集合（config）字段类型说明_idObjectId配置编号configKeyString配置项parentKeyString父配置项configValueString配置值beginTimeDate（可选）生效时间endTimeDate（可选）失效时间seqInt（可选）序列memoString（可选）备注statusInt状态: 0 无效 1 有效createTimeDate创建时间updateTimeDate更新时间监控项集合存储了监控项数据。它相当于对采集的原始数据的分类，对用户关心的数据

34、进行统一的监控处理。这是通过监控项集合的主键_id来区分不同类别的采集结果的。表3.3监控项集合（item）字段类型说明_idObjectId监控项编号itemString监控项itemEntitiesArrayItemEntity（可选）监控项键值对象列表ItemEntity: key Stringvalue StringparticlesArrayInt 颗粒度数组（秒）serviceIdString（可选）服务编号moduleIdString（可选）模块编号contactIdsArrayString（可选）联系人编号数组customizableIpBoolean（可选）可自定义传入IPm

35、emoString（可选）备注signTypeString（可选）签名方式signKeyString（可选）签名密钥allowedIpsArrayString（可选）允许访问IP列表statusInt状态: 0 无效 1 有效 2 待审核createTimeDate创建时间updateTimeDate更新时间服务集合的作用其实和监控项集合的功能类似，都是用来区分数据类别的。只不过服务集合是用来区分汇总后的数据，是对结果数据的区分。其中最为重要的字段是collectionPrefix，它完成上面的区分功能。表3.4监控视图集合（service）字段类型说明_idObjectId服务编号servi

36、ceString服务collectionPrefixString监控数据集前缀contactIdsArrayString（可选）联系人编号数组memoString（可选）备注statusInt状态: 0 无效 1 有效createTimeDate创建时间updateTimeDate更新时间模块集合用在监控试图的展示上。其主要功能是区分各个模块的数据，存储一些辅助信息。它主要是和服务模块以及联系人模块有关联关系，它有个status的字段，这个字段有两个状态：有效和无效。通过这个字段在对模块数据的监控上做区分，只对有效的模块进行监控操作。表3.5模块视图集合（module）字段类型说明_idObj

37、ectId模块编号moduleString模块serviceIdString（可选）服务编号contactIdsArrayString（可选）联系人编号数组memoString（可选）备注statusInt状态: 0 无效 1 有效createTimeDate创建时间updateTimeDate更新时间监控视图集合是前端展示监控数据的数据结构。它存储着展示图层的具体信息，包括图层名称、横纵坐标的数值、模块、联系人等。图层的展示就是通过这个集合加载数据的。表3.6监控视图集合（view）字段类型说明_idObjectId监控视图编号viewString监控视图itemIdsArrayString

38、监控项编号数组typeInt视图类型: 1 折线图viewTemplateJSON（可选）监控视图模板serviceIdString（可选）服务编号moduleIdString（可选）模块编号contactIdsArrayString（可选）联系人编号数组memoString（可选）备注signTypeString（可选）签名方式signKeyString（可选）签名密钥allowedIpsArrayString（可选）允许访问IP列表statusInt状态: 0 无效 1 有效2 待审核createTimeDate创建时间updateTimeDate更新时间联系人集合是个辅助集合类，存储着商

39、户的个人信息。它与其他集合的关联是最多的，这样也保证了系统中各个商户数据的安全性，只有当前商户的用户可以看到自己的数据或者已经授权的商户的数据信息。表3.7联系人集合（contact）字段类型说明_idObjectId联系人编号续表 3.7字段类型说明companyString（可选）公司departmentString（可选）部门contactString（可选）联系人emailString（可选）邮箱mobileString（可选）手机telString（可选）电话addressString（可选）地址memoString（可选）备注statusInt状态: 0 无效 1 有效create

40、TimeDate创建时间updateTimeDate更新时间实时采集库 实时采集库存储着实时采集的原始监控数据。这个数据库存储的数据就非常的大，通常一个集合的数据会有1亿条。它是对每个服务每天的数据的采集，同时会对旧的数据做定时的清理。表3.8实时采集库框架DBCOLLECTIONROWsdmm_realservice1.20120701service1的1日明细数据service1.20120702service1的2日明细数据service2.20120701service2的1日明细数据service2.20120702service2的2日明细数据 可以看出，数据的采集是按不同服务不同

41、日期采集的，并且以service.collectionPrefix + yyyyMMdd的集合名称存储数据。数据的监控处理也是按照服务和天数进行。实时采集库集合详细设计实时采集库集合只有一个，就是明细数据集合。这些数据是线上采集的最原始的数据，其中的itemEntities字段记录着用户关心的数值，itemEntities是个键值对形式的数组数据，value一般存储是数字型数据，这些数值经过汇总后会被记录到监控试图上；而itemId是监控项编号，用以指明数据所属的类别，即是在哪个监控项下的监控数据。表3.9明细数据集合字段类型说明_idObjectId编号itemIdString监控项编号cl

42、ientIdString（可选）应用编号ipAddressString（可选）IP地址itemEntitiesArrayItemEntity 监控项键值对象列表ItemEntity: key Stringvalue StringcollectTimeDate采集时间createTimeDate生成时间戳采集库中的明细数据集合之间是相互独立的。由于明细数据集合的数据量庞大，所以建立了索引，提高数据的检索速度。MongoDB索引和关系型数据库的规则是一样的，在经常要用到查询的列建立索引。一般的形式是ensureIndex(列名:1, 列名:-1.)，其中指明了在什么列上建立索引，以及建立索引的顺序

43、。特别是在建立复合索引的时候一定要考虑好是升序还是降序。汇总库对实时采集库中的数据对每个服务按照汇总时间颗粒度切分数据集，数据行存储具体监控项。汇总集合是按照预定的时间粒度来分别存储数据的。预定时间值是在监控项集合中的itemEntities字段中指示，其是个数组类型的字段，可以指定多个值。表3.10汇总库框架DBCOLLECTIONROWsdmm_storeservice1.60.20120701.nlservice1的1日1分钟汇总数据service1.300. 20120701.nlservice1的1日5分钟汇总分组数据service1.3600.20120701service1的1日

44、1小时汇总数据service1.d.2012service1的2012年按日汇总数据service1.m.2012service1的2012年按月汇总数据service1.yservice1的按年汇总数据由表3.10可见，汇总库的集合是很据时间粒度的汇总，或者是按天、按月、按年的汇总，命名的规则和采集库类似，具体如下：1、按监控项颗粒度配置汇总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汇总库集合详细设计汇总库里的集合虽然比采集库的复杂，但是都是其内部的数据结构都是一样的，因此也只有一个集合，即汇总数据集合。其中比较重要的字段是itemEntities和particle。itemEntities即关心的监控项的键值对象列表，和明细数据集合中的类似，只是汇总数据集合的itemEntities包含了“同类型”的虽有的监控项的键值对象；particle是时间颗粒度，表示是做怎样的时间间隔的汇总操作，监控的是哪段

46、时间内的数据。表3.11汇总数据集合字段类型说明_idObjectId编号itemIdString监控项编号clientIdString（可选）应用编号ipAddressString（可选）IP地址itemEntitiesArrayItemEntity 监控项键值对象列表ItemEntity: key Stringvalue StringparticleInt颗粒度（秒）assembleTimeDate汇总时间createTimeDate生成时间戳汇总库中的汇总数据集合之间是相互独立的。同时，汇总数据集合也建立了索引来提高自身的检索速度。本章小结本章介绍了监控系统数据库系统的设计方案。整个系统

47、包括了三个重要的数据库：配置库、采集库和汇总库。配置库是监控系统的配置解决方案，存储配置信息，数据库系统的“指令中心”。配置库是系统的灵活性得到很大的提高。采集库是监控系统实时采集的原始数据的存储库，其特点是数据庞大，并且数据可能是没有规则的。汇总库是监控系统对原始数据MapReduce处理后的结果数据，是最终体现的监控视图上的数据。数据按照时间颗粒度和监控项来分别存储在汇总库的各个集合当中。数据库系统是监控系统的核心所在，其设计的优劣直接影响着监控系统的性能。浙江大学硕士学位论文第4章 STYLEREF 标题 1,章标题(有序号) * MERGEFORMAT 数据库集群的搭建 PAGE 4

48、PAGE 29数据库集群的搭建集群数据存储结构Mongodb的数据文件都存储在系统指定的路径下，一般是通过配置的dbpath来指定目录，本系统指定为/data/dbs。集群中的每个数据库的结构都是类似的，是大致的一些列文件所组成，即一个.ns文件和若干的数据文件。.ns文件存储着所有命名空间的元数据。数据库中的每个集合都有各自对应的名字空间，索引文件也有。这些命名空间就统一在.ns文件中管理。.ns文件的存储结构是哈希表，key值是命名空间的名字，value值是对应的命名空间的信息。哈希表节点的数据大小时628字节，而.ns文件默认的大小是16M，因此.ns文件默认可以存放26715个命名空间

49、17。但是，可以根据实际的需要通过-nssize选项来设置.ns文件的大小。数据文件存储着具体的数据，并且数据文件是可增长的，每新分配一次，数据文件的大小都是上一次文件大小的2倍。但是这种增长不是无限制的，每个数据文件最大只能为2G，超过2G的会另起文件存储。这样的机制是百利而无一害的，它不仅反之了较小的数据库存储产生的磁盘碎片导致的磁盘空间的浪费，同时又能保证较大的数据库有相应的预留空间留待使用，还提高了数据检索的速度。图4.1 数据文件格式DataFileHeader是数据文件的头部，后面是Extent的部分，也就是数据的主体部分17。文件空间是按照Extent为单位分配的，每个集合所申请

50、的Extent是通过双向链表的形式链接组织在一起，链表的表头和表尾数据存放在命名空间信息里。Record即记录之意，是数据具体的存放地，是在Extent里分配的，每个Extent里的所有Record同样是按照双向链表的数据结构存储，表头和表尾存放在Extent头部。对数据的访问方法是先遍历Extent链表，在对找到的对应的Extent遍历其中的Record链表，找到对应的记录。如图4.2所示：图4.2 数据存储示意图空闲的Record根据其大小，形成19个单向的链表。这些Record是Extend里剩余的空间或者是被删除的记录。在存储空间申请的时候，是先从DeleteRecord单链表中进行查

51、找的，由图上可以看出，从第一个链表开始，一直查找，有空余空间的话，就把这个空间分配出去，没有就继续往下找；如果DeleteRecord都查找完毕，说明没有空余的空间可用，需要分配新的空间，从而在Extent里分配一个新的Record块。这种模式是基于MongoDB内部的预分配机制，每个预分配的文件用0填充，这样保持额外的空间和空余的数据文件，可以有效的避免由于数据暴增所带来的磁盘压力大的问题。集群数据的写入协议MongoDB集群写入协议是基于socket的请求响应协议，系统客户端通过TCP/IP和数据集群交互。集群数据库默认的Socket的端口是27017，但是这个是可以改变的，可以通过-po

52、rt参数配置。基于soket的数据交互是在Bson数据的上面做了一层简单的包装，加入了1个20字节大小的消息头，这是个类C结构体的数据结构。数据交互中有两个消息头协议，客户端请求消息头和数据库响应消息头。客户端请求消息头每个从客户端发送过来的数据都是由标准的消息头和具体的需要数据所组成。协议头的格式如下18：struct MsgHeader int32 messageLength; int32 requestID;int32 responseTo; int32 opCode; messageLength指示这个消息的大小（字节数），这个大小是已经包含了4个字节的消息头。requestID是消息

53、的唯一标识，由客户端或者数据库生成。并且，如果这个是客户端生成的，它将在数据库响应后返回给客户端，从而可以保证查询的一致性。responseTo结合requestID被返回到客户端。opCode操作码，消息操作的类型定义。表4.1请求操作码19操作码名操作码值说明OP_REPLY1客户端请求的响应OP_MSG1000通用消息命令OP_UPDATE2001更新OP_INSERT2002插入RESERVED2003保留字段OP_QUERY2004查询OP_GET_MORE2005获取跟多数据OP_DELETE2006删除OP_KILL_CURSORS2007操作结束数据库响应消息头数据库响应消息是

54、数据库为了响应客户端的OP_QUERY和OP_GET_MORE请求时发出的消息。其消息的格式化头为18：struct MsgHeader header; int32 responseFlags; int64 cursorID; int32 startingFrom; int32 numberReturned; document* documents; documents是返回的具体数据，numberReturned是总的返回数量，startingFrom标示游标开始的位置，responseFlags是返回给客户端的标示信息位，具体含义如4.2表：表4.2响应标示码19数值信息说明0Cursor

55、NotFound游标未指定有效值1QueryFailure查询失败2ShardConfigStale提示需要更新config配置3AwaitCapable查询等待4-31Reserved保留字段，忽略监控系统的集群配置方案本系统采用副本模式（Replica-Set）的海量数据处理解决方案。建立了三个节点的数据集群，分别部署在三台服务器上。配置文件如下：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指定节点的优先级，优先级的值为110，值越大说明这个节点称为主节点的可能性就越高。我们将240服务器上的主机设置为仲裁机，它不负责任何的读写，只是一个仲裁者，负责主节点崩溃后剩余节点的选举操作。定义仲裁者是为了防止剩余节点都称为Secondary节点而没有Primary节点而出现的整个服务不可用，它会根据当前优先级最高的并且数据新鲜度最新的节点作为主节点。集群节点（配置库节点sdmm-confi

57、g）的配置如下：表4.3 集群节点配置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参数指定服务端口号；dbpath来指定数据库路径；logpath用来指定MongoDB日志文件，这里是直接文件而不是目录；keyFile是集群的私钥的完整路径，这个属性只对Replica Set集群架构起作用；fork参数的作用是使进程按守护进程额方式运行MongoDB；auth指示客户端连接到集群上需要经过验证，认证的信息都是存储在keyFile所指向的文件，加上验证是为数据库集群建立一个受信任的环境；directoryperdb来设置每个数据库是被保存在一个单独的目录中，默认的情况时不分开的，目录的路径有dbpath参数决定，这样设置可以提高数据集群的读写效率；nssize是设置.

59、ns文件的大小的；maxConns指明同步连接到集群上的线程的最大数，其最大值为20000，超过最大值不起作用；oplogSize指定日志的大小，单位为兆字节；logappend指明日志是追加的方式写入日志文件中，但是由于oplogSize的指定，这种追加不是无限制的；journal参数确保写入的稳定性和数据的一致性；nohttpinterface关闭HTTP端口。集群一共有三个数据库，分别是配置库sdmm-config、采集库sdmm-real、汇总库sdmm-store。每个库又配置了三个数据节点，其配置都如上面的配置一样，监控平台集群配置的示意图如图4.3所示：图4.3 监控平台集群架构

60、图配置库的数据直接决定着采集库和汇总库的操作，而采集库的数据又直接决定着汇总库的操作。它们之间不是数据或者指令的交互，而是数据之间的限制。每个数据库都是一个集群配置，Mongodb(M)表示Primary节点，Mongodb(S)表示Secondary节点，Mongodb(A)表示Arbiter节点。主节点和备节点是存储数据的地方，而仲裁节点不存储数据。主节点提供所有的服务，即增删改查；备节点只提供查询的服务，这样可以减少主节点的压力，当客户端进行数据查询时，查询请求会自动转到备节点上进行查询。同时，备节点需要定时的跟主节点进行数据的同步，所以在主节点和备节点间有数据的交互。客户端不直接和仲裁