MongoDB数据库

2024-05-16

MongoDB数据库（共8篇）

MongoDB数据库篇1

概述

随着互联网技术的飞速发展，数据量呈现爆炸性增长趋势，对互联网中应用的数据库提出了高并发读写、高效率存储以及高可扩展性和高可用性的需求，传统数据库越来越显现出力不从心。Mongo DB以其独特的优势为WEB应用提供了可扩展的高性能数据存储解决方案。Mongo DB的主要特点是开源设计、高性能、易部署、易使用，存储数据方便，它的面向集合存储、模式自由、支持动态查询、支持完全索引等优势正在被越来越多的公司和个人所接受。

Mongo DB是一个介于关系数据库和非关系数据库之间的产品，是非关系数据库当中功能最丰富，最像关系数据库的。它支持的数据结构非常松散，是类似json的bjson格式，因此可以存储比较复杂的数据类型。

Mongo DB有一个强大、灵活和可扩展数据存储区。它结合了能力扩展与关系数据库的许多最有用的功能，如次索引范围查询和排序。Mongo DB也具备十分强大的分片功能，如内装的支持处理样式聚集和空间的索引。

但Mongo DB在机制上仍属于No SQL，由于NoSQL的使用经验缺乏、CPU占有率过大等缺点也制约了MongoDB的发展。

本文首先分析了Auto-Sharding在MongoDB的机制，并对MongoDB的并发吞吐量和CPU占有率进行了测试分析，提出了Mongodb分片机制的优化方案，作为一种抑制MongoDB在大数据量情况下CPU占有率过高的解决方法。

1 Auto-Sharding在Mongo DB的应用

Sharding是MongoDB扩展负载的方法。Sharding可以在不影响程序运行的情况下添加更多硬件设备来满足数据的需求。

MongoDB sharding的基本概念是将collection划分为较小的chunks，这些chunks分布在sharding上。我们不需要知道数据存储在那个sharding上，只需要运行mongos，由mongos知道所有数据所在，所以应用程序可以正常连接到该数据库并发出请求。当有请求时，只需要通过mongos就知道chunks的存储位置，mongos收集数据并将其发送给应用程序。（如图2），将sharding与应用程序分离，在这种机制下，用户可以不必更改程序就可以扩展系统。

MongoDB中分片机制提供如下功能：

1）、当数据量和负载个数发生变化时,分片机制可以自动平衡负载和数据分布的变化

2）、分片机制可以灵活的添加新的硬件设备

3）、扩展性能强,最大可以扩展到一千节点

4）、可以做到无单点故障

5）、出现故障时,利用sharding可以实现自动故障转移

Auto-Sharing的架构图如图1所示

Auto-sharding，是通过mongos的自动分片功能建立一个水平扩展的数据库集群系统，将数据存储在sharding的各个节点上。

Auto-sharding功能的最大特点是能够自动的分片。通过这一功能，用户只需要指定数据的某个字段值作为分片的key，数据会自动平均分配到后端结点。

当增加结点时，sharding能够自动对数据进行分片，对整个系统进行负载平衡。

2 MongoDB的性能测试

2.1 MongoDB并发性的测试

为了说明MongoDB的处理大数据量的并发性能，我们对在相同的配置环境下，MongoDB和My SQL的并发性能测试结果进行比较分析。图2中横坐标表示并发数，纵坐标代表吞吐量，不同颜色的折线分别表示在查询、插入和变更状态下Mongo DB和My SQL不同的吞吐量的变化趋势。从图中可以看出：

1）、mongdb随着并发数的增加，无论是insert吞吐量、update还是select，其吞吐量在不同程度的下降，但较之Mysql的性能会好得多。

2）、在insert及update下，Mongodb吞吐量大约是Mysql的2～3倍，select下，Mongo DB大多也优于Mysql。因此,Mongodb的总并发性能比M ys q要好。这也是很多商家选择Mongo DB原因之一。

2.2 MongoDB的CPU占有率的测试

CP U占有率是数据库选择另一个重要指标之一。本文通过对Handler Socket和MongoDB的CPU占有率性能的测试，进行比较分析，HandlerSocket与Mongo DB一样，也是一个No SQL产品。在一百万数据量情况下，HandlerSocket和Mongo DB的CPU占有率性能如图4。

由图3可知，在大数据量测试情况下，Mongodb的CPU占有率几乎都接近100%，而Handler Socket的CPU占有率只保持在40%左右。

分析占用空间过大的主要原因如下：

空间的预分配问题：为避免形成过多的硬盘碎片，mongodb每次空间不足时都会申请生成一大块的硬盘空间，而且申请的量从64M、128M、256M呈指数递增，直到2G为单个文件的最大体积。随着数据量的增加，在其数据目录里可以看到这些整块生成容量不断递增的文件。而空间的预分配是由MongoDB的Auto-Sharding机制决定的。

MongoDB的Sharding在存储数据时将数据进行了分块存储（Chunk），每一块的大小默认为200M。而Sharding中每一次数据迁移的最小单元就是数据块。

Mongo DB后台有一个叫做Balancer的后台程序，会检查各个Sharding结点的分布情况，当发现不同结点间Chunk数相差达到一定大小时，就开始进行数据迁移，以平衡数据在各个Sharding结点的分布。Balancer迁移数据的过程是，先把要迁移的数据从磁盘读到内存，再进行迁移。

但当数据量比较大时，通常需要迁移的数据可能并没有被加载到内存里，这时0会先把内存中的热数据踢除，以加载从磁盘读取的需要迁移的数据，然后在迁移完数据后再删除掉原来结点上的数据。在这过程中，由于热数据被踢回磁盘中，会严重影响系统的性能。

3 MongoDB的改进

针对mongodb的缺点，本文采用哈希算法对数据进行分配，从而避免mongodb占用空间过大的问题。

哈希算法一般分两步进行。首先求出cache的哈希值。接着计算object的哈希值，如果object的哈希值与某个cache的哈希值匹配，则将其映射到该cache上。哈希算法的示意图如图5所示

由图4可知：

Cache A上的存储对象有object 1;

Cache B上的存储对象有object 2、object3;

Cac he C上的存储对象有ob j ec t 4、object5、object6;

Cache D上的存储对象有object 7、object8、object9、object10;

3.1 Cache的排序规则和优化方案

当Cache C删除时，原本存储在Cache C上的object会转移到Cache D上，造成Cache D的负载过高。同样当有Cache E添加时，由于新增的Cache E的哈希值不确定，新增的Cache E可能落到负载少的Cache A和Cache D之间，使得Cache A的负载为零，造成资源的浪费。

根据以上问题，我们提出一个优化方案。根据位于在Cache上的对象个数和其对象访问量的大小，对Cache进行排序。当有Cache删除时，将位于被删除的Cache上的object转移到最小的Cache上。当有Cache加入时，将Cache添加到最大的Cache上，从而达到负载的平衡。假设每个object的访问量相同，根据图4可知，Cache的排序从大到小为：Cache D、Cache C、Cache B、Cache A。

假设每个object的访问频率相同，根据图4可知，Cache的排序从大到小为：Cache D、Cache C、Cache B、Cache A。当Cache C删除时，根据Cache的排序大小，将原本位于在Cache C上的object转移到Cache A上，避免负载压力过大，如图5所示。

当有Cache添加时，由于Cache D上的负载最大，应该将新Cache放置在Cache C和Cache D之间，这样可以减小Cache D的负载压力，如图6所示。

3.2 存储对象排序的优化方案

当添加或删除cache时，由于cache数量的变化，其余cache的哈希值会发生变化，同时存储对象的哈希值也会发生变化，对象a因为哈希值的变化，从c a c e h A转移到c a c h e B,而对象b可能因为同样的原因从cacehC转移到cacheB,由于a、b之间没有查询优先的判断，对象a、b在cache B的存储是随机的，这对系统的查询性能是不利的。

优化方案提出对存储对象被查询的概率进行排序，在cache发生变化时，发生冲突的对象根据被查询的概率大小，来决定存储的位置，通过这种措施，实现系统查询速度的提高。

1)在哈希表的结构中,添加键频(Count)项,即概率键,在建立哈希表添加元素时直接和所在链表处的其他对象所对应的键频(Count)进行对比排序；

2)将改进后的存储对象加入hash算法中

当Cache C删除时，原本位于在Cache C上的object会转移到Cache A上，坐落在Cache A上的object有四个，根据Object元素自身所带的频键，根据频键的大小来决定Object的存储位置。通过这个改进，可以实现对数据查询速度的优化。

4 总结

虽然Mongo DB吞吐量性能很高，但是当出现海量数据的读取时，CPU占有率过大，直接影响系统的性能，通过改进后的哈希算法，可以将存储的数据均匀的分布在节点上，实现数据均匀分片，减少系统对CPU的占有率，实现对系统的优化。该系统可以更好实现对海量数据的存储，对Web应用提供有力的支持。

系统的优化效果还需要进一步的试验验证和比对分析。基于MongoDB的云存储系统是一个新兴的研究领域,可以实现一个稳定、安全、高效的系统,还需要进一步研究和实践。

摘要：MongoDB作为一款性能优良,功能丰富,支持海量数据存储的产品受到很多商家的青睐。但由于MongoDB系统中采用的Auto-Sharding的算法存在着数据在各个节点上的分配不均匀的现象,使CPU占有率过高,直接影响了系统的性能。通过对MongoDB的研究分析,提出了用一致性哈希算法进行优化的方案,设计了一个针对海量数据存储的分布式文件系统,以有效解决数据分配不均匀的问题。

关键词：海量数据,MongoDB,哈希算法

参考文献

[1]S.Shepler,B.Callaghan.RFC 3530:Network FileSystem(NFS)version 4Protocol.The Internet Society,2003

[2]Ghemaw at S,Gobioff H,Leu ng S T.T hegooglef ile system//Proceedin gs of the 19th ACMSym pos ium on OperatingSys t ems Principles.Sagamore,2003:29～43

[3]ZHU S,SET IA S,JAJOD IA S.LEAP:efficient securitym ech an ism s for large-scale dis-tributed sensor networks[C]//Proc.of the10th ACM Con fon Computer and CommunicationsSecurity,2003:62-2

[4]Thomas Anderson,Michael Dahlin,Jeanna Neefe,David Patterson,Drew Roselli,and Randolph Wang.Serverless networkfil e systems.In Proceedings ofthe15th ACM Symposium on OperatingSystemPrinciples,pages 109–126,CopperMountain Resort,Colorado,December 1995

[5]唐箭.云存储系统的分析与应用研究.电脑知识与技术.2009,5(20):13～14

[6]KenDunham.TheProblemwithPZP.InformationSeeurityJournal:AGlobalPerspeetive,2006,15(2):5～8

[7]Kristina Cbodorow.MongoDB权威指南

[8]Kelsey J,Kohno T.Herding hash functions andthe nostradamus attack[C].EUROCRYPT 2006.Berlin:Springer-Verlag,2006,:183～200

[9]R.Merkle.One Way hash Functions and DES.Advances in Cryptology-Crypto‘89.Springer-Verlag,1990

MongoDB数据库篇2

电脑资料

数据库的数据操作主要分为两大类：数据的更新和数据的查询，本次课主要讲解MongoDB的数据更新，在下次课会介绍MongoDB的数据查询。

MongoDB数据库篇3

Mongo DB是一种强大、灵活、可扩展的数据存储方式。它扩展了关系型数据库的众多有用功能, 如辅助索引、范围查询和排序。 Mongo DB的功能非常丰富,比如内置的对Map Reduce式聚合的支持, 以及对地理空间索引的支持。Mongo DB既有优点也有缺点,但是总体来说还是相当不错的,它是No SQL数据库中最接近SQL数据的一种基于文档的数据库产品,主要为网页应用提供可扩展的高性能数据存储解决方案,并且已经应用在一些世界顶级的互联网公司的产品中。

2 Mongo DB的自动分片技术介绍

使用自动分片技术的Mongo DB集群包括以下三个组件:分片服务器、路由服务器配置服务器。

分片服务器负责存储数据。为了提供高可用性和数据一致性, 在生产环境中,分片服务器集群中,每一个片都是一个副本集。如果是开发环境或者测试环境中,可以不采用副本集机制。本文主要研究Mongo DB的自动分片技术,为了更好的观察Mongo DB的自动分片技术本文中的每一个片都是一个单独的Mongod服务,并没有采用副本集技术。

路由服务器,也可称为查询路由服务器,它是mongos实例程序,接收客户端的请求,把请求直接分发给适当的一个或几个分片服务器,收集分片服务器的操作结果汇总成最终结果,然后将最终结果返回给客户端。一个Mongo DB集群可以有多个路由服务器。

配置服务器存储Mongo DB集群的元数据。包括数据的分片策略。路由服务器根据这些元数据把请求分发到特殊的分片服务器。并且在3.2版本以后,配置服务器可以应用副本集机制。

3性能测试

此次测试共涉及5台服务器:3台Mongo DB服务器。机器配置: CPU为Intel(R) Core(TM) i7-5500U CPU @ 2.40GHz、内存为16G、硬盘1T、操作系统为Linux。分别在3台机器运行一个mongod实例和一个mongos进程。在Scala程序设计语言下,使用Mongo DB官方提供的casbah工具包编写程序对Mongo DB进行操作。

(1)对三个数据集分别插入1亿条数据,要求数据的L1字段取值均匀的分布在长整型取值空间上;

在插入的数据每条为1k B的情况下,普通插入的方式在数据量小于1000万条时,三个数据集性能都是是比较高效的,但之后每秒插入数据量骤降。原因是Mongo DB的普通插入只是把数据写入内存就结束了,所以在内存有空闲时,普通插入速度是非常高效的,但是随着写入数据量的增加,内存逐渐被占用,此事再写入数据需要在磁盘和内存间进行大量的数据交换,因此性能下降较快。

虽然随着写入数据量的增加,写入性能明显下降,但是分片数据集下降率比未分片的数据集低。在数据量大于2000万后的写入数据性能,分片数据集比未分片数据集要好。

比较collection1和collection2发现,在数据量大于4000万后, collection1的写入性能更好,原因是在数据量达到4000万时,collec- tion2数据集第一个块写满,数据均衡的操作,数据在不同的shard间移动,导入写入速度下降。而collection1进行了分块操作,在数据写入之前,已经将数据均匀的分布在了三个shard上,所以collection1随着数据量的上升写入性能下降较为缓慢,写入操作的压力被均匀的分布在了三个片上。

(2)分别根据普通索引、分片索引查询1000条数据测试结果如图1所示,对未分片的数据集进行查询3,查询性能非常不稳定,但是对分片的collection1进行的1和2查询相对比较稳定。查询1使用的是分片索引,查询2使用的是普通索引,观察可以发现,使用分片索引的查询效率高于普通索引。原因是根据分片索引,mongos可以把查询操作有选择的分发到相关的一部分mongod服务器上,而根据普通索引的查询,mongos必须把查询操作分发给每一个mongod服务器。

4结语

经过测试分析得知,使用Mongo DB自动分片技术可以提高数据量较大时的性能,并且时Mongo DB更稳定。并且,在使用自动分片技术时,应设置块的划分,一方面可以使数据均匀的分布在每一个片上,而且可以减少数据平衡时的数据移动。在查询操作时,使用片索引效率比普通索引效率高。对于使用非常频繁的查询,应该考虑使用这个索引的关键词来进行分片。在未来的研究工作中,将对Mongo DB集群不仅使用自动分片技术,而且加入副本集技术,并观测在有Mongod故障情况下,Mongo DB集群的性能以及故障服务的恢复方法等。

参考文献

[1]程显峰.Mongo DB权威指南[M].北京人民邮电出版社,2011.

MongoDB数据库篇4

本文介绍了python是如何实现excel数据添加到mongodb，为了将数据导入mongodb，引入了pymongo，xlrd包,需要的朋友可以参考下

利用pymongo包进行数据库的连接，使用xlrd包读取excel数据，由于二者数据结构的不同，要将excel格式数据转换为json格式数据，由于编码问题会出现“TypeError: ‘str‘ object does not support item assignment”，要利用json.loads方法对数据进行解码

分享代码如下

#coding=utf-8 import xlrdimport sysimport jsonimport pymongofrom pymongo import MongoClient #连接数据库client=MongoClient(‘localhost‘,27017)db=client.scrapyaccount=db.weibo data=xlrd.open_workbook(‘test.xlsx‘)table=data.sheets()[0]#读取excel第一行数据作为存入mongodb的字段名rowstag=table.row_values(0)nrows=table.nrows#ncols=table.ncols#print rowsreturnData={}for i in range(1,nrows): #将字段名和excel数据存储为字典形式，并转换为json格式 returnData[i]=json.dumps(dict(zip(rowstag,table.row_values(i)))) #通过编解码还原数据 returnData[i]=json.loads(returnData[i]) #print returnData[i] account.insert(returnData[i])

MongoDB数据库篇5

MongoDB是一个基于分布式文件存储、面向文档的NoSQL (非关系型) 数据库, 以BSON (Binary JavaScript Object Notation) 格式组织数据, 具有高性能、易部署和易扩展等特点, 近几年在企业计算领域得到快速应用。

MongoDB数据库分片是通过并行处理数据实现负载均衡的一种重要手段, 是通过数据库集群实现分布式计算的关键技术。在生产环境中, 必须对分片各环节进行合理的架构设计和配置, 在提高计算性能和效率的同时, 有效规避分片风险。

2. MongoDB数据库分片技术架构

MongoDB数据库集群自动切分数据做负载均衡, 分片的技术架构如图1所示。

(1) 配置服务器:存储分片集群的配置信息即:片的信息以及数据与片的对应信息。

(2) 路由服务器:分片路由进程, 负责应用程序和片数据的对应关系解析。

(3) 片:保存子集合数据的容器, 一个片可以是一个副本集。

(4) 应用程序客户端:Java、Python、PHP、Ruby等具体的应用程序。

3. MongoDB数据库分片实施策略

3.1 部署配置服务器

配置服务器存储了分片集群的配置信息, 是路由服务器能否正确启动的关键。根据MongoDB开发文档的建议, 在生产环境中应部署三个配置服务器。

(1) 配置服务器不需要很多资源和空间, 通常可以将路由服务器和其中一台配置服务器在同一台计算机中运行, 如图2所示。

启动配置服务器的命令代码如下:

(2) 配置服务器使用两步提交机制来维护集群配置的不同副本, 即先检测集群中所有的配置服务器是否正常, 如果某台配置服务器宕掉则整个集群的配置信息将变为只读, 暂时停止均衡数据, 但客户端仍可进行读写操作。

3.2 规划健壮的片

生产环境中, 使用分片功能应保证集群中至少有两个片, 健壮的片都应是一个副本集, 以保证该片某台服务器宕掉后不会导致整个片失效。下面以三个副本集, 每个副本集由三台服务器组成的分片为例进行规划。

(1) 副本集一:replset1, 如图3所示:

配置副本集的命令代码如下:

启动mongo客户端连接任一副本集服务器对副本集进行初始, 初始化命令代码如下:

(2) 副本集二:replset2, 如图4所示:

配置副本集的命令代码如下:

启动mongo客户端连接任一副本集服务器对副本集进行初始。

(3) 副本集三:replset3, 如图5所示:

配置副本集的命令代码如下:

启动mongo客户端连接任一副本集服务器对副本集进行初始。

3.3 启动路由进程

(1) 同一台计算机中mongos路由进程的数量不受限制, 建议一个应用服务器只运行一个mongos进程, 以防宕机影响其他应用与mongos的通话。在IP为172.20.1.10的服务器上启动路由进程的命令代码如下:

(2) 启动mongo客户端, 为集群添加分片。启动客户端及增加分片的命令代码如下:

(3) 定义分片规则。首先在数据库级别开启分片功能, 这是对集合进行分片的前提条件, 然后对某一集合定义分片规则。数据库开启分片功能及对集合进行分片的命令代码如下:

以上命令代码开启动webdata数据库的分片功能, 定义了subcol集合按照_id键进行分片, 再添加数据时就会依照_id的值自动将数据分散到各个片上, 实现了数据的负载均衡。

4. 结束语

在云计算背景下, 企业通过MongoDB管理生产环境中的关键数据和核心业务流程, 实现分布式计算, 数据库分片是关键技术和重要手段之一。本文从MongoDB数据库分片的技术架构入手, 探讨了生产环境中部署配置服务器、构建副本集和启动路由进程等分片环节的实施策略, 但在以下两个方面还有待进一步的研究:

(1) 分片安全认证的应用机制。在分片环境下, 对数据库的访问进行合理的权限设置, 准确把握安全认证机制, 对保障数据安全、应急主从复制等环节都是极其重要的。

(2) 多路由进程的自动协调机制。单一路由进程的分片架构中, 如果路由服务器瘫痪, 将导致所有分片数据不能访问, 其稳定性很大程度上取决于路由服务器的健壮性配置。对于访问要求较高的企业应用, 应配置多个路由服务器, 启动多个路由进程, 并赋予自动协调机制。

摘要：分片是数据库实现集群的关键技术, MongoDB通过分片切分数据实现负载均衡。本文从MongoDB数据库分片的技术架构入手, 探讨生产环境中部署配置服务器、构建副本集和启动路由进程等分片环节的实施策略。

关键词：MongoDB,生产环境,分片策略

参考文献

[1]程显峰.Mongo D B权威指南[M].北京:人民邮电出版社, 2011:135-144

[2]申德荣.分布式数据库系统原理与应用[M].北京:机械工业出版社, 2011:205-351

[3]肖迎元.分布式实时数据库技术[M].北京:科学出版社, 2009:21-112

[4]吴淼.一种针对MongoDB数据库的证据获取方法[J].中国司法鉴定, 2011, (03) :54-62

MongoDB数据库篇6

网络行为分析与控制系统是针对当前企业局域网管理中存在的计算机分散管理困难、难以保障企业核心数据安全等问题而提出的一套解决方案。改变了传统的被动管理模式,把人对计算机的管理转化为计算机对自身的管理,既减轻了管理者的工作强度,又提高了管理的效率和针对性。现有的网络行为分析与控制系统中,数据库采用My SQL。随着受控计算机的增加、管理规则粒度精细化以及新产品的开发,各种问题接踵而来:

数据激增:在日志表中,上线1个月的数据就达到千万;

异构数据:有些复杂结构的信息甚至是对象,以前都是以JSON/XML格式或者展开存在一张二维表中,存储效率低下、操作复杂;

大量文件管理:产生的文件主要是图片、本地原始日志数据为主,难以管理;

日志格式多样:为了准确记录有效信息和方便后期的数据挖掘、分析统计,针对不同的子系统,日志格式会稍有不同。根据需求和后来新功能的添加,日志格式也会有相应的变化;

开发要更加敏捷:开发成本和维护成本要更低,要能够快速地更新进化,新功能要在最短的周期内上线;

传统的日志存储方案主要有:文本格式、关系型数据库、专用系统。文本格式存储效率最高,但不方便从海量日志中查询到有效数据;关系型数据库不能满足大并发的环境;专用系统部署、维护复杂。

1 网络行为分析与控制系统基本情况及Mongo DB部署情况

网络行为分析与控制系统是应企业的实际需求进行开发的,是企业上网行为监控的忠实助手。系统的主要功能模块有:资产管理、基本信息维护、监控信息设置、规则设置、系统管理。系统由三部分组成:客户端、管理服务器端、控制台。客户端用于收集数据和执行系统管理策略;服务端用于存储数据和管理规则策略;控制台用于查看系统数据、设定管理策略和进行维护。

目前,网络行为分析与控制系统使用My SQL+Mongo DB的方案:My SQL存储控制信息;Mongo DB存储日志和文件。部署如图1所示。

客户端采集到的日志数据通过节点服务器存储到日志数据库中,监控中心,直接访问Mongo DB查询和分析日志数据。

2 Mongo DB简介

Mongo DB是一个高性能、开源、无模式的文档型分布式数据库,其集Key-Value存储方式和传统的关系型数据库优势于一身,是一种介于关系数据库和非关系数据库之间的新型数据库,目的是为Web2.0应用提供可扩展、高性能的数据存储解决方案。Mongo DB的Sharding是水平扩展(Scale Out,亦或横向扩展、向外扩展)的解决方案,其主要目的是为突破单节点数据库服务器的I/O能力限制,解决数据库扩展性问题。Sharding的思想是从分区的思想扩展而来,是能够跨数据库,甚至跨越物理机器的。Grid FS可将Mongo DB以文件方式进行存储,Grid FS规范提供了一种透明的机制。Grid FS的一个优点是可以存储上百万的文件而无需担心扩容性,通过同步复制,可以解决分布式文件的备份问题,通过ARP-ping可以实现双机热备切换。还解决了使用文件系统存储文件时管理和索引缓慢、难以备份的问题。

(1)典型的Mongo DB应用场景如下:

一个或多个分片,每个分片承载全部数据的一个分区(自动管理)。读和写被自动发送到合适的分片。每个分片都由一个或者多个服务器作为备份集支持(备份集只承载该分片的数据),承载着相同数据的拷贝。在任意时间,系统中只有一个主要集而其他都是次要集。若主要集失效则其中一个次要集自动变为主要集。所有的写入和一致读出都作用于主要集上,所有的最终一致读出都分配在次要集中。

(2)多个配置服务器,每个都承载着元数据的一个拷贝,用以表明哪些数据在哪个分片上。

(3)一个或多个路由器,每个路由器充当一个或多个客户端的服务器。客户端向路由器发送查询更新请求,路由器在查询配置服务器后,将它们路由给合适的分片。

(4)一个或多个客户端,每个都是用户应用(一部分),并且通过mongo客户端库(驱动)向路由器发送命令。

mongod是服务器程序(数据或配置),Mongos是路由器程序。

3 性能测试

3.1 测试环境

在一台曙光A620r-G上安装VMware ESXi-5.1.0,并虚拟出两台机器用于测试。

Datacenter用来安装数据库(Mongo DB 2.2.2/My SQL5.2.29),Tester用于跑测试程序。Mongo DB采用本机Sharding方式部署,如图3所示。

3.2 测试方案和结果

使用测试程序依次向Mongo DB/My SQL插入1亿条数据(每条数据大约1KB):

(1)并发插入性能:插入1亿条数据,32个线程,每次100条,结果如图4所示。

Mongo DB的插入速度,平均在22000条/秒;My SQL的时1500条/秒,优势明显。

(2)并发查询性能,每次生成指定数量的线程同时发起查询,记录平均时间,结果如图5所示。

整体看来,Mongo DB并发读取比My SQL略快些。两个数据库的瓶颈都在磁盘I/O上。实际部署时,由于Mongo DB的每个分片都会部署到不同的物理机上,优势会更加明显。

4 结论

将Mongo DB与网络行为分析与控制系统结合起来,可以实现准确记录有效日志信息和方便后期的数据挖掘、分析统计、快速查询;使用Grid FS高效有序地对系统产生的图片、本地原始日志数据等进行管理;通过分片技术的应用,保障数据的安全和灾难恢复相关问题。

经过上述实验测试表明,将Mongo DB数据库应用于网络行为分析与控制系统,是可行的,并且成本较低,使用普通服务器就能达到传统高性能服务器的效果,能够显著提高网络行为分析与控制系统的可维护性、可扩展性和系统负载。

摘要：在网络行为分析与控制系统中,传统的关系数据库在异构数据、海量日志的管理上难以胜任。NoSQL非关系型数据库的出现,对于解决面向文档的超大规模和高并发的问题提供了卓有成效的方案。本文在研究非关系数据库的基础上,着重分析MongoDB的特点和优势,通过性能测试,提出将MongoDB数据库应用于网络行为分析与控制系统,有效提高了大规模日志数据在网络行为分析与控制系统中的存储效率。

关键词：NoSQL,MongoDB,网络行为分析与控制系统

参考文献

[1](美)霍多罗夫,(美)迪洛尔夫著,程显峰译.MongoDB权威指南.北京:人民邮电出版社.2011.

[2](美)霍多罗夫著.深入学习MongoDB.北京:人民邮电出版社.2012.

[3]红丸著.MongoDB管理与开发精要.北京:机械工业出版社.2012.

[4]刘一梦.基于MongoDB的云数据管理技术的研究与应用[D].北京交通大学.2012.

[5]Introduction to MongoDB.http://www.mongodb.org/about/introduction/.

MongoDB数据库篇7

传感网中主要存储方式的优缺点。第一, 集中式存储。优点:与传统的数据存储思想吻合, 数据访问方便。缺点:当网络中的节点多时, 会有很多数据需要传输, 靠近存储点的节点会因转发数据而消耗能量太快。第二, 本地存储。优点:数据存储简单, 存储过程几乎没有通信开销。缺点:存储能力有限, 不能长期保存数据, 数据容易丢失。查询请求在网络中广播将占用大量网络资源, 所以, 不适用于查询请求频繁的网络。第三, 分布式存储。优点:与传感器网络本身的特性非常吻合, 中间件技术可以提供较为丰富的查询模式。缺点:无线传感器节点的存储和处理能力有限, 不能支撑大量的数据存储;系统需要为中间件提供额外的开销。

其中:n为传感器的个数 (假设传感器网络是均匀分布的) , M为产生数据的速率, Q为查询数据的速率, m为数据分布存储的点位数, 而O () 则为数据由传感节点传递到接受点的平均代价。

2 智能交通领域传感网的特点

2.1 智能交通领域的传感网数据的特点

第一, 传感器地理位置敏感。第二, 数据采集量巨大。第三, 数据兼有时效性强和长期保存的两方面特点。第四, 传感器工作存在明显的繁忙期与空闲期。第五, 需要进行区域的数据检索。

2.2 与智能交通特点相适应的网络结构与存储模型

第一, 结合分布式存储和集中式存储两种方法。在“繁忙”期, 数据主要沉积在传感器中, 而在“空闲”期中, 数据则通过网络传输到传感器接入网关中。第二, 数据处理结合面向文档的数据库和面向事务处理的数据库。使用Mongo DB数据库实现实时采集;采用My SQL数据库系统进行后期处理, 可以实现联机事务处理与联机事物分析。第三, 在云平台层和网关汇聚层之间, 设立逻辑抽象层。将用户的查询请求与物理存储的数据分割开来;同时, 屏蔽大量传感器设备的物理参数特性。第四, 云平台层实现存储和处理能力的弹性动态分配, 再结合面向文档的数据库管理系统Mongo DB, 就可以很好地实现对频繁更新海量数据的存储和处理。第五, 应用管控层主要对整个系统进行综合调控。

如图1、图2的系统架构有以下几方面优点:第一, 底层传感器中存储有最“新鲜”数据, 可以通过车载传感器和车联网系统, 动态、实时地接受这些传感器的数据。第二, 采用了在“繁忙”时存储、“空闲”时发送的策略, 很好地处理了数据的存储问题和数据的上传瓶颈问题。第三, 系统采用Mongo DB数据库处理“原始数据”, 能很好地实现数据的频繁更新插入及多种索引, 能够实现基于地理信息的范围所搜、自动数据分片等功能。采用关系数据库My SQL处理联机事物处理和联机事物分析。第四, 系统引入逻辑抽象层的概念, 使上层处理层中呈现更容易被程序员和用户所理解的描述, 使很多与传感器硬件相关的信息被屏蔽掉。

2.3 关键数据的Mongo DB存储实现

以采集数据集合和网关设备集合这两个集合做例子, 展示Mongo DB数据库的存储实现技术和地理空间查询技术的应用。

第一, 采集数据集合:ITS_Data

第二, 地理空间查询技术。

>db.ITS_Data.find ({“Dev Loca”:{“$within”:{“$geometry”:eareRect}}})

以上可以检索出在给出的地域范围内所有传感器发出的数据内容。

>db.ITS_Data.find ({“Dev Loca”:{“$near”:{“$geometry”:eareRect}}})

以上可以检索出在给出的地域范围附近所有的传感器发出的数据内容。

>db.ITS_Data.find ({“Dev Loca”:{“$within”:{“$geometry”:eareRect}}, “Dev Type”:”Temp”})

以上可以检索出在给出的地域范围内所有温度传感器发出的数据内容。

摘要：通过讨论智能交通领域的传感网具有的独特特性, 设计出一种数据存储和数据查询的模型, 应用MongoDB数据库的特点, 展现其在智能交通数据处理领域中数据检索的优势, 对智能交通中传感网的数据存储给出了解决方案。

关键词：MongoDB,智能交通,传感网,模型设计

参考文献

[1]丁治明, 高需.面向物联网海量传感器采样数据管理的数据库集群系统框架[J].计算机学报, 2012, 6 (35) :120-121.

MongoDB数据库篇8

本邮件收发系统在实现基本的对电子邮件的接收和发送等功能的基础上, 还支持单个用户添加多个邮箱帐户并统一进行管理等功能。用户添加了多个邮箱帐户后可以分别接收各个邮箱中的邮件, 并且在发邮件的时候可以选择使用任一邮箱发送。功能测试和验证结果表明, 该系统稳定、可扩展, 达到实时性要求。

1 技术简介

本邮件收发系统通过POP3协议和SMTP协议实现对电子邮件的接收和发送, 按照RFC 822协议所定义的格式对邮件实体进行解析。通过前期的技术选型, 最终确定整个系统采用B/S架构, 服务器端程序采用Node.js作为主要的开发语言, 数据库系统采用Mongo DB。

Node.js是一个Java Script的运行环境, 采用C++编写而成。之所以选择Node.js, 主要是因为通过前期调研了解到邮件收发系统是一个I/O密集型 (I/O bound) 的应用。而Node.js的无阻塞 (Non-Blocking) I/O、事件驱动 (Event-Driven) 等特性恰好适用于该种应用场景。且Node.js采用Google的V8Java Script引擎, 确保了其拥有良好的性能。

Mongo DB是一个基于分布式文件存储的数据库。由C++语言编写。其特点是高性能、易部署、易使用, 存储数据非常方便。本系统采用Mongo DB的主要原因是Mongo DB原生支持Node.js, 可以提升开发效率。

2 收发原理

如图1所示, 在电子邮件传递的过程中, 发件者的邮件代理从本地通过SMTP协议将邮件发送到SMTP邮件服务器, 邮件服务器通过SMTP协议将邮件发送到收件者的POP3邮件服务器。收件者的邮件代理使用POP3协议将邮件从其POP3邮件服务器拉取到本地。

而本系统在整个过程中则起到邮件用户代理这一角色, 本系统所部属的服务器本身不具备邮件发送功能, 需要用户将自己的邮箱帐户配置到系统中, 由本系统来代为发送和接收。

3 需求分析与功能设计

邮件收发系统的应用功能应包括以下几个方面:用户基本信息管理, 用户邮箱帐户管理, 邮件的接收、发送, 草稿邮件管理和联系人管理。

根据需求分析可以设计出系统的功能模块, 各个系统功能模块之间的关系如图2所示。

3.1 用户登录和注册

(1) 根据用户所属的不同角色显示不同的操作页面。管理员登录时, 除了显示普通用户所展示的界面之外, 还显示管理相关的入口链接。

(2) 新用户注册后成为普通用户。管理员在管理界面可以将普通用户提权为管理员。超级管理员有最高级权限, 且自身不可被其他管理员操作, 由系统配置文件定义。

3.2 用户角色管理

角色管理主要是给注册的用户分配角色, 即修改用户的角色, 删除用户的角色。

3.3 用户管理

添加用户, 修改用户, 删除用户。

3.4 邮件收发及管理

(1) 邮件接收, 对用户各个邮箱帐户中新邮件的接收, 统一查看用户已下载的所有邮件, 接收邮件中的附件等。未阅读的新邮件会高亮显示。

(2) 邮件发送, 用户可以指定一个自己的邮箱帐户来发送邮件, 在邮件中可以添加附件。邮件发送后将被保存在“已发送”信箱中以备查。

(3) 邮件管理。可以删除或者永久删除邮件, 已删除的邮件将移入“已删除”目录以便恢复, 永久删除的邮件不能恢复。

3.5 邮箱帐户管理

用户可以添加、编辑或删除邮箱帐户, 用户可以使用已添加的邮箱帐户收发邮件。

3.6 联系人管理

(1) 用户可以在联系人页面中添加、编辑、删除联系人信息。

(2) 用户在发送邮件的时候可以直接从联系人列表中快速选取收件地址。

4 实现与测试

本系统最核心的部分就是实现对邮件的接收和发送。在这个过程中主要使用POP3协议和SMTP协议来达到对电子邮件的接收和发送, 并且通过实现RFC822协议来解析邮件实体。

用户在使用本系统之前需要添加自己的邮箱帐户, 包括输入自己邮箱的用户名、密码和邮件供应商提供的邮件服务器 (POP3和SMTP服务器) 地址以及对应端口。之后在每次的收件和发件过程中, 系统将和邮件服务器建立起一个或多个socket连接, 并且按照POP3和SMTP协议所规定的数据格式, 将相应指令或数据通过该Socket连接发送到邮件服务器。而邮件服务器则会按照协议规定, 返回相应的指令和数据。系统在收到服务器的响应后, 即开始按照RFC 822协议中的规定, 将收到的数据包进行解析或者是进行相应的错误处理。

以下是系统核心部分的代码, 实现系统收发核心功能。

在本系统的开发过程中, 主要使用单元测试来确保代码中各个对象和函数对各种输入数据所得到的输出的正确性。

在计算机编程中, 单元测试是针对程序模块 (软件设计的最小单位) 来进行正确性检验的测试工作。程序单元是应用的最小可测试部件。在过程化编程中, 一个单元就是单个程序、函数、过程等;对于面向对象编程, 最小单元就是方法, 包括基类 (超类) 、抽象类、或者派生类 (子类) 中的方法。

本系统的单元测试使用Node.js的第三方单元测试模块Mocha完成。在此过程中第三方断言模块使用Should.js。代码覆盖率报告使用jscoverage生成。

5 系统界面设计

进入系统后, 可看到本系统的主要用户界面。在界面的上方, 是系统相关的导航条。用户可以进入管理账户页面和设置用户个人信息的页面, 如果是管理员用户还可看到进入管理的入口。界面右上角是搜索邮件的搜索框, 用户可以键入关键字并搜索自己收件箱中的邮件。

在界面的左侧, 是邮箱相关功能的工具栏。通过该工具栏, 用户可以进入写信和管理员界面, 同时工具栏中还提供了进入用户各个邮箱帐户的入口, 以及进入草稿箱、已删除邮件等信箱的入口。

在发邮件界面中 (如图3所示) , 用户可以直接将写好的邮件发送到收件人信箱或者保存为草稿。界面的右侧显示了用户添加的联系人列表, 用户可以通过直接单击联系人姓名来将其快速加入到收件人当中, 而不需要手动输入对方的邮箱地址, 这样不仅减少了用户输入出错的几率且为用户提供了方便。

在邮件列表界面中 (如图4所示) , 系统用列表的形式展示了用户接收到的邮件。其中第一列显示邮件发件人的名称或者是邮箱地址中的用户名, 第二列显示邮件的标题以及摘要, 最后一列显示邮件发送的日期。每一页显示的邮件数目可以通过系统的配置文件进行设定。

在此界面中, 用户可以对多封邮件进行删除或者彻底删除操作。被删除的邮件将被移入已删除信箱, 用户进入已删除信箱可对该邮件进行恢复操作;彻底删除的邮件将直接从数据库中删除且不可恢复。同时, 用户还可以将多封新邮件标记为已读状态。

6结语

经过前期的调研, 中期的开发和后期的测试, 系统实现了用户基本信息管理, 用户邮箱帐户管理, 邮件的接收、发送, 草稿邮件管理和联系人管理等功能, 并且通过单元测试保证了系统各核心部件功能的正确运行, 确保本系统是可用、完整、稳定且安全的。