MongoDB数据库（精选8篇）

MongoDB数据库 第1篇

1.1 云计算

云计算与传统的信息存储和运行不同, 它不是将信息和程序存于个人计算机上, 而是将数据与程序存贮于“云”中, 从而引起了信息存储和运行方式的极大变化[1]。所谓的“云”其实是一个集合, 是由服务器和个人计算机组成, 可以通过网络公开浏览和访问。至于信息具体存储在哪里, 不需要用户关心。云计算的模式不是凭空产生的, 它是以多种现代技术作为基础的, 例如SOA技术、虚拟化技术、网络计算技术、网络宽带技术。但是云计算本身并不是一种具体的技术标准, 而是一种概念。动态性、可扩展、虚拟化、共享性是它的显著特征。云计算对用户要求不高, 用户在使用过程中无需进行控制操作, 无需关心设备设施, 也不需要太多的专业知识。只要通过运计算就可以对共享资源进行访问。在云计算中, 云架构通过智能化的手段连接个人计算机, 从而实现用户请求的处理, 个人计算机是通过互联网与云端联系起来的, 在云计算中资源的配置是自动完成的。

1.2 云数据管理

云数据管理技术的一个有效管理方案就是NoSQL系统, 即非关系型数据库, 是一个集合概念, 它具有高伸缩性、高可用性、支持海量数据等特点, 使用比较广泛。与传统数据库的最大差别就是不使用关系模式来组织数据, 这种特点使其比较适用于云计算环境。当前, 主流NoSQL系统主要有三种, 即BigTable、Dynamo、MongoDB[2]。本文重点介绍MongoDB, 它是一种面向文档的存储系统, 由10gen公司研发, 能够扩展性好、灵活的等优点。其功能比较丰富, 例如对地理空间索引的支持、对MapReduc聚合的支持等, 它还具有以下特征。首先, 丰富的数据类型。MongoDB放弃了关系模型, 是无模式的, 因此为数据模型变更提供很大的方便。第二, 易于扩展。由于MongoDB在设计之初就考虑到了扩展问题, 具有Auto-Sharding机制。另外, 还具有性能优良、管理方便、性能丰富等特征。当然由于MongoDB仍然属于NoSQL系统, 因此也受到其缺点的限制。

2 基于MongoDB的云数据管理系统的设计

MongoDB采用key/value结构储存数据, 这是一种新的编程模式具有存储两大和读取速度高等特点, 而且易于维护安装, 扩展容易。对数据类型要求也不高。本文重点研究Auto-Sharding机制的设计和实现。

2.1 Auto-Sharding集群架构

Auto-Sharding是通过自动分片机制达到系统水平扩容, 与传统的人工介入分片不同, 在MongoDB中分片工作是自动完成的, 而且还可以自动调整数据分布, 使其分布达到平衡。数据库在数字资源管理系统中的应用。所谓的分片就是对数据进行分割, 然后存储于不同的计算机上, 这种分割存储的方式可以降低对计算机性能的要求。其设计主要有三大目标:使集群不可见、实现集群的随时读取、使集群容易扩展。

2.2 数据的拆分方式

为了实现数据的均衡分布, 在MongoDB的Auto-Sharding集群中, 会将数据分割, 并且将较多的数据转移到数据较少的片中。数据组织是有规则的, 一般来说片键相连的数据往往会储存在同一个服务器上。存储形式有两种, 第一是一个单元存储单一范围的数据。但是这种方式存在严重不足, 即会极大增加转移数据量, 难以有效达到数据均匀分布的目标。第二种是每片储存多个范围的数据, 这种方法与第一种相比, 有效减少了数据转移量。所以, 在MongoDB中采用第二种分片方法。

2.3 基于数据操作频率的均衡算法

2.3.1 均衡算法的思想和问题

在MongoDB中, 是通过balancer来实现数据均匀分布, balancer被集成在mongos中。均衡算法主要解决三个问题, 即数据移动的时机、数据移动的数量、移动数据的选择。总体来说, MongoDB中数据均衡算法是有效地, 但是也存在问题, 例如移动时不考虑实际情况, 迁移的数据可能是无效数据, 因此, 没有实质上达到均衡。所以有必要对其进行改进。

2.3.2 FODO 算法设计

首先是设计目标。根据前面的分析, 针对balancer不考虑实际情况选取迁移块的问题, 对其进行改进, 改进点在于在迁移快选择时把数据操作频率作为一个依据, 其触发条件依然不变, 即数量差值, 直至差值小于2时才停止操作。在该算法中, 首先确定需要迁移的块, 然后根据改进FODO算法选择需要迁移的数据, 并对迁移时机和迁移量进行评估, 最终使数据分布均衡。第二是算法流程:均衡算法的触发迁移片的选取快的迁移[3]。

2.3.3 FODO 算法的实现

Balancer类中各个方法实现的主要功能如表1所示

3 基于MongoDB的云数据管理技术应用

在高校教学中, 数字资源占有重要地位, 建设和开发高质量的资源是一项重要的任务。本文以我市A高校为例。当前随着数据量的不断增加, 以往的系统难以适应发展要求。现在针对其存在的问题, 使用MongoDB数据库设计一个资源管理系统。

3.1 需求分析

根据A高校教学资源管理的要求, 设计目标为:设计一个数字资源管理系统, 实现对网络资源的有效利用, 从而帮助学生上传和下载电子资源, 提高其学习效率。因此本系统应该具有以下功能:能够登陆系统并维护用户信息, 能够方便地浏览系统中的资源, 能够按照通过关键词或者关键字进行资源检索, 能够下载所需要的资源, 能够上传新的资源。因此本系统设计主要包括两大模块, 即用户管理模块和资源管理模块。另外, 除了功能需求之外还需要考虑到非功能需求, 主要有一下两点需求:第一, 系统应该具有良好的扩展性, 支持较大规模的数据存储功能, 另外应该确保系统扩展工作不会影响到系统的正常使用。第二, 高可靠性, 在实际使用中, 系统可能会出现故障, 从而导致数据损坏, 因此, 在系统设计时要充分考虑风险因素, 是系统具备一定的容错机制[4]。

3.2 数据库设计

经分析, 数字资源管理系统中实体主要有用户user和资源source。内嵌文档是资源类型Type, 用户集合包括用户名、登陆密码等, 登陆系统以Uid作为账号, Password作为密码。资源的集合名称为Sname, 在Sname下创建索引index ({Sname:1}) , 资源提供者Provider引用的是User集合。为了提高查询的效率, 对MongoDB数据库采用固定集合、服务端代码执行的优化策略。通过对MongoDB进行分布集群部署策略, 使用3个数据库分片, 每个分片包括3个节点的复制集做复制冗余, 解决存储容量的可扩展性、数据的备份容灾需求。

4 结语

云计算是一种新兴概念, 因此云数据的管理技术也处于不断完善过程中, 新兴的NoSQL在一定程度上克服了以往关系型数据库的一些缺点, 具有较大发展潜力, 本文以MongoDB数据库为基础进行了研究, 主要是对均衡算法进行了优化, 最后通过实例检验了该设计的可行性。实验证明MongoDB的高扩展性为系统的扩展提供便利, 为系统迁移到云计算环境奠定了基础。

参考文献

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

[2]蔡柳青.基于MongoDB的云监控设计与应用[D].北京交通大学, 2011:15-17.

[3]王青峰.云计算及云数据管理技术研究初探[J].计算机光盘软件与应用2013 (4) :252-253.

MongoDB数据库 第2篇

在物联网当中, 每个终端节点每隔几秒钟就会将多个传感器采集的数据传输到服务器中, 在大量终端节点的情况下会产生海量的数据。传统关系型数据库已经无法满足海量数据的存储和管理, Mongo DB是专门为解决海量数据而产生的, 本系统使用Mongo DB存储海量传感器数据。服务器端必须能够处理大量终端节点的高并发请求, 本系统使用Boost.Asio网络库应对终端海量高并发请求。

2 Mongo DB及其部署

2.1 Mongo DB简介

Mongo DB的文档、集合相当于关系型数据库中的行和表, 其文档使用BSON格式存储, 其典型格式如:{id:123, temperature:23, humidity:60}。可见其非常适合物联网终端节点的传感器数据的存储。

Mongo DB通过分片 (Shard) 和副本集 (replica set) 实现对数据的备份和高性能处理。分片, 就是将一份数据分成多个片段, 每个分片储存不同的部分, 分片不仅分担了数据在硬盘的存储, 还分担了数据操作对机器内存、CPU、网络的IO和硬盘的读写压力。如图1所示。

2.2 Mongo DB集群部署

典型的Mongo DB集群部署模型如图1所示。每个分片就是mongod程序的实例, 在进行数据的增删查改操作时需要通过mongos程序将请求分发到对应的分片上, mongos起到了路由的功能, 它需要从配置服务器 (config server) 读分片和路由等元数据信息。replica set就是数据的备份, 也是mongod程序的实例。在生产环境下根据业务的需求来确定服务器的数量和mongos、mongod以及config server的数量。在程序连接数据库时, 只要连接mongos的地址和端口即可。

3 程序设计

本程序的主要功能是处理终端海量的高并发请求, 将数据解析后写入Mongo DB数据库。

3.1 Boost.Asio简介

Boost.Asio是一款非常优秀的C++开源网络库, 支持同步编程和异步编程, 能够构建出能够承受数千并发连接的应用程序, 并且不必涉及显式锁定和线程并发模型, 从而避免使用多线程编程带来的死锁、条件竞争等。

3.2 配置模块和日志模块设计

在程序中, 服务器端口号、Mongo DB集群地址、程序并发执行线程数等配置信息采用JSON格式文件存储。使用Boost库中的property_tree作为程序解析JSON文件的工具。日志可以帮助程序员在开发中快速定位bug, 本程序使用boost::log记录日志。

3.3 Mongo DB模块设计

在高并发请求下, 为避免每次请求到来频繁连接和关闭数据库, Mongo DB的C++驱动提供了线程安全的连接池。本模块设计了Mymongo类, 内部封装了mongo::Scoped DBConnection类, 实例化该类, 便获得一个数据库连接。在Mymongo类的构造函数中完成对数据库的连接认证等, 在析构函数中释放连接到连接池。本程序只需要将终端数据插入到数据库中, 因此Mymongo类只实现了数据的插入功能。

3.4 请求处理模块

本模块实现了Service类, 包含start () 、accept_handler () 、read_handler () 三个成员函数。使用该类时, 其执行流程如图2所示:首先执行其start成员函数, 在函数中采用异步accept方式等待连接到来, 其回调函数为accept_handler, 当连接到来后, 执行回调函数, 在其中采用异步方式读取套接字, 并注册回调函数read_handler, 因为是异步读取, 不等待读取完毕, 再次调用start函数, 等待下一个连接到来。当套接字读取完毕后, 会调用read_handler, 在函数中会解析终端发来的请求, 并使用Mymongo类将数据写入Mongo DB数据库。如图2所示。

3.5 io_service模型选择

io_service类是Boost.Asio的核心, 相当于前摄器模式中的Proactor角色, asio的任何操作都需要其参与。在主函数中首先实例化一个io_service对象, 在实例化Service对象时作为其参数, 启动Service对象的start () 函数后, 在多个线程中调用这个io_service对象的run () 函数。这相当于在多个线程中同时阻塞等待异步操作的完成, 当有异步操作完成时, 便会调用相应的回调函数。这是其最为常用的模型, 可以编写出非常健壮的应用程序, 本程序选择一个io_service实例多个线程的模型。

4 结语

本文所设计的传感器数据存储系统, 使用了Mongo DB数据库存储管理海量数据, 并使用Boost.Asio网络库的异步编程方式, 配合多线程技术, 编写了能够接收海量高并发请求的服务器端程序, 在程序中使用Mongo DB连接池来连接数据库, 避免资源的浪费。

参考文献

[1]郭匡宇.基于Mongo DB的传感器数据分布式存储的研究与应用[D].南京邮电大学, 2013.

[2]Mongo DB.sharding.https://docs.mongodb.org/manual/core/shardingintroduction/.

MongoDB数据库 第3篇

首先启用Mongodb的httpinterface

修改 mongodb.conf

注释此行

代码如下复制代码#nohttpinterface = true

httpinterface 端口为 mongodb端口+1000

如mongodb默认端口为 27018则httpinterface 为 28018

需要重启mongodb

下载插件

代码如下复制代码

#wget github.com/erh/mongo-munin/tarball/master

下载下来文件名是 master 重命名之后再解压

代码如下复制代码

#tar xvf erh-mongo-munin-*tar.gz

#cp erh-mongo-munin-*/mongo_* /etc/munin/plugins/

#munin-node restart

在munin服务节点上

代码如下复制代码

#sudo -u munin /usr/share/munin/munin-update

$ cd /etc/munin/plugins/

$ munin-run mongo_ops

getmore.value 0

insert.value 46235

update.value 44290

command.value 13918

query.value 444044

MongoDB数据库 第4篇

关键词：数据集成,数据共享,Mongo DB,分布式系统

0 引言

随着科学技术的发展以及互联网的高度普及,近几年来全球范围内积累的数据量已经超过了过去5000年的总和。在数据量急速增长的同时,数据的存放也愈发分散,然而,存放分散的数据中又存在千丝万缕的关联,因此,如何有效地对这些数据进行整合与利用,从中发掘潜在价值,已经成为一个亟待解决的问题。针对这个问题,本文设计并实现了一个基于Mongo DB的多源信息集成系统,该系统使用Mongo DB作为存储底层,实现了多种异构数据源的高效、可靠融合,有效地解决了大数据量形势下多源数据集成与共享的效率问题,具有较强的现实意义。

1 关键技术研究

1. 1 数据集成技术

数据集成是将不同来源、格式和特点的数据进行逻辑或者物理上的集中与整合,从而实现数据的全面共享。目前,常用的数据集成有两种方式: 逻辑集成和物理集成。

逻辑集成,即本地只提供查询用的接口或者视图,而数据不存储在本地。逻辑集成的示意图如图1所示。

物理集成,即将不同数据源的数据全部存储在本地,查询只需查询本地存储的数据即可。物理集成的示意图如图2所示。

1. 2 Mongo DB

Mongo DB是一种新兴的非关系型数据库,它提供了一套强大、灵 活、可扩展的 数据存储 方式。Mongo DB使用键值对的方式存储数据,它的结构不固定,不同元组可以拥有不一样的字段,适合于存储非结构化的数据。

Mongo DB相比关系型数据库有许多优点:

( 1) 易于扩展: Mongo DB采用的面向文档的数据模型使其可以在服务器之间分割数据。且不同集合之间的数据没有外键的约束,因而容易实现数据的扩展。

( 2) 大数据量时高性能: 一般关系型数据库使用的Cache是Query Cache,这是一种 大粒度的Cache,每次在更新表的时候Cache就失效,因而对数据频繁改变的数据集存取效率不高。Mongo DB的Cache是记录级的、细粒度的Cache,因此更适合数据频繁改变的数据存取。

( 3) 数据结构灵活: Mongo DB采取键值对的形式存储数据,而不用为存储的数据建立存储结构,可以灵活的为数据增加和减少字段。

1. 3 分布式存储系统

分分布布式式存存储储系系统统将将大大量量服服务务器器通通过过计计算算机机网网络互联,对外作为一个整体提供存储服务。分布式存储系统具有可扩展、低成本、高性能等普通单机存储系统无可比拟的优势。目前,常用的分布式存储系统包括分布式文件系统、分布式键值系统、分布式表格系统和分布式数据库。

2 系统设计

2. 1 系统架构

系统总体设计目标是对多种不同来源的异构数据进行数据集成和整合。系统设计的架构图如图3所示。

系统主要由接入系统管理、数据格式管理、数据采集、数据转化、数据存储和数据查询六个模块组成。接入系统管理负责定制待接入数据源的相关信息,如IP、端口号、数据库口令等; 数据格式管理完成待接入数据与目标数据结构的定制与结构映射; 数据采集模块实现多源异构数据的采集,采集到的数据经过数据转化模块和数据存储模块将数据存储到分布式存储系统( Mongo DB集群) 中,从而完成多源数据的集成与整合。数据查询模块提供一个统一的查询接口用于查询存储在本地的数据。

2. 2 核心模块设计 - 数据存取模块

数据转化模块可以将待接入的数据根据定义的结构映射转化为目标数据。由于系统需要接入多种数据源,数据结构上存在差异性,因此需要分别对各种数据源进行定制,这样才能使相同类型数据实现共享存储。然而,由于数据量庞大,且不同数据源的字段差异很大,如果使用传统的关系型数据库存储数据,会浪费大量的空间,且当数据量急剧增长时,查询效率也会迅速降低; 而扩展数据库采用向上扩 展的机制,其升级费 用非常昂贵; 综合考虑各种因素,本系统采用Mongo DB作为存储底层,一方面,文档型数据库Mongo DB摆脱了不同数据源 之间数据 字段的差 异,另一方面,Mongo DB开源、易于扩展、支持分布式的特性使得其在处理海量数据时具有比关系型数据库更优异的性能。

为了解决大数据量带来的存取效率问题,本文采用分布式集群的方式搭建Mongo DB,并采用了数据分片的基本思想,即将数据集合拆分,然后将其分布到不同的Mongo DB节点上。Mongo DB集群的部署方式如图4所示。

系统使用三台服务器搭建Mongo DB集群,并为其建立了3个分片,每个分片拥有3个复用集。由于系统需要频繁接入数据源,即数据写入较为频繁,因此,针对不同数据源选择不同的片键,片键尽可能均匀分布以保证数据可以被均匀的分布在各个分片中,从而提高系统的整体性能。

正常情况下,使用其中一个分片作为主分片进行数据读写,同一复用集中的其他分片和主分片通信以保证数据的完整性和一致性,同时,在主分片处于忙碌状态时,其他分片也可以提供查询的功能,从而提高了系统的并发查询性能。此外,每个分片拥有3个复用集,即拥有2个额外的数据备份,从而保证在缺失1台服务器 ( 服务器宕机,网络不能联通等问题) 的情况下,其他2台服务器上仍然保持有全部的数据,从而提高了系统的容错性与可靠性。

数据存取模块在Mongo DB集群内部按照目标数据的操作实体为其建立数据集合,不同来源的该类操作实体统一存储在一个集合中,从而实现了多源数据的集成与整合,数据集合示意图如图5所示。

3 多源信息集成系统的实现

3. 1 系统运行环境

本系统的运行环境如表1所示。

3. 2 核心模块实现

系统的核心模块为数据存取模块,下面详细讲述其实现方法,

( 1) 搭建Mongo DB集群

本系统使用Mongo DB集群来存取数据。Mongo DB集群划分为3个分片shard1、shard2、shard3来并行访问数据。每一个分片有3个复用集,shard1( shard11、shard21、shard31 ) 、shard2 ( shard12、shard22、shard32 ) 、shard3 ( shard13、shard23、shard33) 。Mongo DB部署在3台服务器上,所以需要3个管理端对数据存取进行分别管理,管理端为config1、config2、config3。Mongo DB的部署信息如表2所示。

( 2) 对Mongo DB集群数据分片

Mongo DB有两种分片,一种是数据库级别上的分片,这时不同的集合按照存储内容大小被伪平均分布到不同的分片上。另一种是集合级别上的分片,这时集合中的数据也会按照片键伪平均分布到各个分片上。本系统同时采用了这两种分片方式来对数据存取进行优化。

首先对Mongo DB整个库进行分片:

接着对Mongo DB所需集合分别进行分片:

( 3) Mongo DB集群存取数据的实现

数据存取模块接入的数据以结构化数据的形式存在,需要转化为非结构化的数据后才能存储在Mongo DB中。存取模块首先需要从系统接入控制表中找到接入系统的相关信息,然后根据系统相关信息在字段表中查找到对应的所有字段,根据字段信息生成字段与数据之间的映射,将结构化数据转化为非结构化数据,转化后的非结构化数据即可保存到Mongo DB集群。在查询时首先根据查询条件生成对应的Mongo DB查询语句,查询出数据结果后,将非结构化数据结果转化为结构化数据的结果,并将结构化数据结果转交给数据查询模块,具体流程如图6所示。

Mongo DB集群的数据存取利用了Mongo DB的JAVA API来进行实现,核心代码如下:

结构化数据转化为非结构化数据:

SystemInfo info = ReadSystemInfo( SystemID) ;

List < String > fields = info. get All Fields( ) ;

/ / olddata是结构化 数据,newdata是非结构 / /化数据

4 性能优化和结果分析

本文对以Oracle、Mongo DB单机、Mongo DB集群为存储底层的多源信息集成系统的数据集成效率进行了比较。测试集采用的数据为多个异构数据集。数据集的基本信息如表3所示。

测试分别以Oracle、Mongo DB单机和Mongo DB集群作为存储底层部署实现多源数据集成系统。3个测试集合分别在各系统上执行数据集成操作,测试结果如表4所示。

图7展示了3个测试集合在不同存储底层的集成系统上的平均集成时间。分析发现,在集成数据量较小时( 测试集1) ,传统的关系型数据库集成数据的性能优于Mongo DB单机的性能,并且由于集群节点之间的通信有一定的时间开销,Mongo DB集群性能略低于Mongo DB单机性能; 随着数据量的不断增加,Mongo DB单机的效率逐渐优于Oracle的效率,MongoDB集群的效率逐渐优于MongoDB单机的效率。在数据量很大的情况下,Mongo DB集群的性能明显优于Mongo DB单机和Oracle的性能,故选用Mongo DB集群模式搭建存储底层可以显著提高系统性能。

为了进一步提高Mongo DB集群的查询效率,系统将所有查询条件中出现的字段全部加上了索引,实现代码如下:

在设置完索引之后,分别测量了索引前和索引后查询所需时间的平均值,比较了查询效率,测试结果如表5所示。

图8是对表5的图形化展示,通过图片可以看出在数据量较大的情形下,索引后数据查询的效率得到较大的提升,这有力说明了对于较大数据量,在Mongo DB中建立索引可以有效提高查询的效率。

5 结束语

本文设计并实现了一个基于Mongo DB的多源信息集成系统。该系统能够对需要接入的数据源进行定制接入。系统采用了Mongo DB作为存储底层,采用了分布式集群分片的模式存储数据,解决了数据量提升后数据集成性能的瓶颈。目前,该系统已经在实际工程中得到了应用,具有较好的接入效果。

今后将在以下方面做进一步的研究:

( 1) 优化Mongo DB索引,进一步提高系统性能。

( 2) 对Mongo DB分片进行进一步研究,以便应对数据量急剧增长的情况。

MongoDB数据库 第5篇

呼叫中心每天需要处理大量数据,随着时间的推移,业务应用数据量会变得越来越大,因而对数据库处理能力的要求也越来越高。目前大多数呼叫中心的数据库系统都选择采用主流商业数据库,如SQL Server、Oracle等。但是,随着呼叫中心业务不断发展,传统的关系型数据库在处理大数据,松散结构数据上暴露了一些难以克服的问题。主要有两方面:1.数据:传统的关系型数据库只能存储结构化的数据,这对于时时刻刻更新的呼叫中心应用开发来说无疑是不适用的,因为随时随地有新的应用出现,旧的数据库无法使用新的应用,只能不断的更新表结构,频繁的更改数据库设计。2.读写效率低:传统的关系型数据库为了实现ACID,往往需要频繁的应用文件锁,而呼叫中心应用对于数据库的读写并发要求非常高,以至于使用传统关系数据库会产生严重的数据库读写瓶颈。

呼叫中心的应用数据库主要提供系统的数据存储和数据访问等功能,例如存储客户资料,工单,话单,号码文件等。这些数据的特点:1.结构松散,如不同的服务有不同的工单。2.大数据量,如号码文件可能会有数十万条,每天的话单和工单也会有数百万条。3.读写操作高并发性,呼叫中心主要通过坐席与客户进行沟通,坐席访问统一的数据库。随着坐席规模的增加,对数据库访问的并发性要求也越来越高。4.不要求实时一致性,但是要求最终一致性。如,话单和工单是实时产生的,查询时可以容忍短时间的不一致,只需保证最终结果一致。因此,使用非关系数据库Mongo DB存储呼叫中心部分应用数据是非常适合的。

1 MongoDB技术介绍

Mongo DB是一种分布式文件存储系统,最初由10gen团队发展推出。它是一种面向文件存储的非关系型数据库,采用key-value的形式存储,key(键)是字符串,value(值)存储结构信息,可以是任意类型的数据。

1.1 MongoDB特点

Mongo DB作为一种可扩展,高性能,无模式,基于文档存储的非关系型数据库[1]具有以下几个特点:

1.模式自由,支持动态查询、完全索引,可轻易查询文档中内嵌的对象及数组[2];

2.面向文档存储,易存储对象类型的数据,包括文档内嵌对象及数组;

3.高效的数据存储,支持二进制数据及大型对象(如照片,音频和视频等);

4.提供了主-从、主-主模式的数据复制及服务器之间的数据复制;

5.自动分片以支持云级别的伸缩性,支持水平的数据库集群,可动态添加额外的服务器。

1.2 MongoDB实施

1.2.1安装

Mongo DB的使用十分方便,无需安装,只须在网上直接下载解压,即可使用。安装解压完后运行启动命令“mongod-dbpath=文件存放路径’”,默认的文件存放路径是在“/data/db”。如图1所示即为安装成功[3]。

1.2.2操作

Mongo DB数据库与关系数据库概念对比:MongoDB数据库中的文档也就相当于传统关系数据库中的记录,不同的是传统关系数据库中的行只能是有限的几种数据类型,但是Mongo DB文档可以是任意类型,包括文档型,也就是可以支持迭代。Mongo DB数据库中的集合相当于传统关系数据库中的表,不同的是它是模式自由的存储,不需要像关系数据库那样定义各种属性。Mongo DB提供多种操作,包括创建集合,删除集合,对文档的CURD操作,几乎可以提供所有传统关系数据库中已有的功能。

1.2.3 Sleepy Mongoose

Sleepy Mongoose是一个全功能的MongoDB HTTP接口,它的默认端口号是28017,Sleepy Mongoose的安装比较复杂,要求在安装之前已经成功安装过Mongo DB数据库,python driver(2.5级以上版本),setuptools。安装成功后提示如图2所示:

呼叫中心是一个复杂的系统,其中涉及到很多不同类型,不同功能的数据,并不是所有的数据都适合使用Mongo DB或者使用传统关系型数据库存储。其中,松散结构的数据,大数据,对读写性能要求高的应用数据适合使用Mongo DB存储;而对于事务性要求高的系统数据,如用户账户管理等信息适合使用关系型数据库存储。经分析,决定使用Mongo DB进行工单的存储。

呼叫中心的工单管理是呼叫中心非常重要的功能之一,根据不同类型的业务会产生不同类型的工单,如咨询类工单,投诉类工单,举报类工单,不同类型工单所需要存储的数据信息是不同的,也就是工单数据具有结构松散性的特点,若使用传统关系型数据库,则需要设计多个表才能满足需求,而且可扩展性也不够,例如,如果要加入新的工单类型,则需要从新定义数据库表结构。引入Mongo DB可以有效的解决工单数据存储的问题。

本设计是基于已有的呼叫中心平台进行实现的,为了将功能与已有系统整合,本设计也采用同已有呼叫中心相同的设计架构,即使用基于Spring和Struts框架的MVC架构进行开发。整体的设计思想是:页面使用Jsp实现,Struts负责请求的响应,转发和处理,Spring进行整体业务逻辑的控制。在业务层调用自定义的HttpMsgSender类,通过Sleepy Mongoose提供的HTTP接口进行数据库的操作。自定义的Http Msg Sender类封装了一个静态post方法发送并响应http请求信息。

系统的整体架构如图3所示:

具体流程为:

1.工单保存:坐席登录web页面(Jsp),填写工单,点击保存,控制层(Action)将数据以JSON格式传递给业务层(Service),然后业务层调用Http Msg Sender类的post方法,发送http消息给Sleepy Mongoose,添加数据。

2.读取工单:坐席登录web页面(Jsp),点击查看工单按钮,控制层(Action)调用业务层(Service)的Http Msg Sender类的post方法,发送http消息给Sleep Mongoose,查询获取数据,将数据以JSON格式传回控制层,最后显示在页面。

下面为Http Msg Sender的源代码:

3总结

从2009年2月首度推出至今,MongoDB经历了四年多的发展,已经成为No SQL家族中发展最迅速的一员,与其他No SQL数据库相比,Mongo DB是所有No SQL数据管理系统中与关系数据库最类似的,提供了丰富的查询语句,对查询语句的优化也可以借鉴SQL优化经验。这点有利于与已有系统进行整合,在开发过程中也可借鉴以前的经验。同时,Mongo DB提供了高性能的REST框架支持,在web开发中也有很强的优势。呼叫中心系统是一个复杂的分布式跨平台系统,呼叫量和业务种类的不断增加,对数据的存储和分析提出了更高的要求,本文只是提出了Mongo DB在呼叫中心系统中的一种应用,随着它的不断发展和完善,未来基于Mongo DB存储的呼叫中心应用会越来越广泛。

参考文献

[1]CHODOROW K,DIROLF M.Mongo DB:The Definitive Guide[M].O'Reilly Media,2008:1-3.

[2]李三来.MongoDB学习手册[OL].[2011].http://www.open-open.com/doc/view/e42b772ed528466fbf5c8ac4f579b ff5.LI S L.MongoDB Learning Manual[OL].[2011].http://www.open-open.com/doc/view/e42b772ed528466fbf5c8ac4f579b ff5.(in Chinese)

MongoDB数据库 第6篇

高能物理实验是典型的数据密集型应用,其大数据量和高计算量等一些特性为网格计算的发展做出了巨大贡献,是网格发展的驱动者与受益者[1,2]。北京谱仪BESIII[3]是北京正负电子对撞机BEPCII[4]上的大型通用磁谱仪。它通过测量正负电子对撞反应后产生的次级粒子来研究物质微观结构的基本组成单元及其相互作用的性质,该实验主要进行 τ-粲物理研究。目前,有来自中国、俄罗斯、美国、德国、意大利等多个国家的400多名科研人员进行实验数据的处理和分析工作,并且在国际顶级物理期刊上发表了大量物理成果。BESIII实验的数据处理包括数据重建和蒙特卡洛模拟等过程,每一个过程都需要耗费大量的计算资源和存储资源。为此,高能物理研究所已经建立了包含4000多个CPU核、3 PB磁盘容量以及4 PB磁带容量的计算系统。

随着成员组织之间合作的加深以及实验数据的迅速积累, 单一的计算集群已经不能满足实验对资源增长的需求。整合各种异构资源,建立一个分布式协同的计算处理平台,成为解决资源短缺的可行方案。因此,BESIII实验构建统一的分布式计算平台,整合集群、网格、云计算等计算资源,将它们用于BESIII的数据处理和物理分析。目前,该计算平台已经包括高能物理研究所、北京大学、山东大学、武汉大学、中国科学技术大学、美国明尼苏达大学、俄罗斯杜布纳联合核子研究所等多个站点。

记账被定义为记录网格范围内资源利用情况的一个过程[5]。BESIII分布式计算平台用于进行数据模拟、重建与分析时,将有大量的作业运行其上。对这些作业的运行情况进行收集与分析是十分必要的,不仅可以使用户了解自己作业运行情况,还能使管理员掌握整个平台资源使用情况,达到调节系统性能的目的。

1 No SQL 与 Mongo DB 概述

No SQL是非关系型数据存储的广义定义,在大数据存取上具备关系型数据库无法比拟的性能优势。传统的关系数据库在应付大数据量分析以及高并发性方面,暴露了很多难以克服的问题,例如对数据库高并发读写的需求; 对海量数据的高效率存储和访问的需求; 对数据库的高可扩展性和高可用性的需求。 为了解决这类问题,非关系数据库应运而生。Google的BigTable[6]与Amazon的Dynamo[7]是非常成功的商业No SQL实现。 一些开源的No SQL体系,如Facebook的Cassandra[8],Apache的Hadoop HBase[9],也得到了广泛认同。

Mongo DB[10]是一个面向文档的数据库,是非关系数据库当中功能最丰富、最像关系数据库的。它支持的数据结构非常松散,是类似JSON的BSON格式,可以存储比较复杂的数据类型, 高性能、易部署、易使用,存储数据非常方便。主要功能特性有: 面向集合存储,易存储对象类型数据; 模式自由; 支持动态查询; 支持完全索引,包含内部对象; 支持复制和故障恢复; 使用高效的二进制数据存储,包括大型对象( 如视频等) ; 极易扩展,可以在多台服务器之间分割数据,平衡集群的数据和负载,自动重排文档; 内存映射存储引擎,将所有数据映射到虚拟内存,由操作系统对内存页面进行调度,提高查询速度; 自动处理碎片,以支持云计算层次扩展性; 支持RUBY,PYTHON,JAVA,C ++ 等多种语言。

2 需求分析

与一般意义上商业分布式计算平台不同,本计算平台主要用于科学计算,因此记账系统无需作为用户计算资源使用情况的付费依据。本文从BESIII实验的特性和用户需求出发,列出本系统的一些功能性需求。另外,可扩展性,资源异构,分散化以及分布式等网格特性还为本系统提出了其他一些关键要求, 这些作为一般性需求在下面列出。

 功能性需求

1) 能够追踪用户的作业。用户能够获得已提交作业的相关信息,例如作业运行的站点,计算资源、存储资源的消耗,输出数据的位置等等,方便用户对自己作业运行情况进行查询。

2) 评估计算平台整体资源使用情况。管理员需要了解平台各个资源使用的程度。更进一步,管理员能够获得某一作业某一特定时间使用某一资源的详细信息。这些信息对调试系统以及追踪恶意用户将很有用处。

 一般性的需求

1) 查询性能的需求。本系统是典型的WORM( wirte once, read many) 访问模式,通常情况下数据只会被写入一次,但是却要多次被查询。相对插入效率,更希望拥有高查询效率。此外, 系统需要在多用户并发查询时表现出良好的性能。

2) 可扩展性要求。在可预测的未来几年内,计算平台将越来越多地用于物理分析,无论是用户的数量还是平台的资源都会快速的增长。本系统需要有良好的可扩展性来应对大数据量带来的挑战。

3) 用户透明性。从可用性的角度来说,一个理想的记账系统对用户是完全透明的。用户在使用记账系统的时候不应该也不需要了解底层的结构,这就需要系统为用户提供一个便捷的调用方式,屏蔽底层访问的复杂性。

4) 可用性需求。每时每刻都有作业运行在计算平台上,记账系统需要对每一条信息进行记录,同时,记账系统需要可以在任何时候响应用户的查询。因此,需要通过副本策略来保证系统容错性与可用性,同时还需保证副本之间数据的一致性。

5) 安全性保证。记账系统记录整个系统的详细信息,这些信息不能随意对外开放,因此需要安全性保证,对访问进行权限管理。例如,对于普通用户,只能查询自己的信息,而对于管理员来说,则拥有访问所有信息的权限。

3 设计与实现

基于上述提到的BESIII分布式计算记账系统的一些实际需求,下文首先对所需收集数据类型进行定义,然后介绍系统的总体框架,并对各个模块的设计进行说明。

3. 1 数据类型定义

考虑到BESIII分布式计算平台所运行任务种类的实际情况,确定了几种需要收集的数据类型,限于篇幅,本文只列出每种类型的主要字段,对这几种数据类型的定义描述如下:

( 1) Job类型

Job类型信息主要用于用户对自己作业状态的查询,字段描述如下:

User: 标识作业的所有者。

Job Type: 作业类型。

Job Group: 一般情况下用户都是批量提交作业,每一批作业被定义为一个组。

Site: 此字段用于标识该作业所运行的站点。

start Time、end Time: 这两个字段描述作业开始运行的时间以及最终结束的时间。

CPUTime: 标识作业运行所消耗的CPU时间。

Exec Time: 标识作业从开始运行到最后结束一共所花费的时间。

Disk Space: 标识该作业数据所占磁盘空间。

( 2) Pilot类型

在作业被发送到某一站点运行之前,BESIII分布式计算平台的作业管理系统,首先会发送一个引导( Pilot) 作业,Pilot作业的唯一任务是提前配置好用户作业运行所需要的环境。Pilot类型包含的字段描述如下:

User: 同Job类型中的User。

Site: 同Job类型中的Site。

Grid CE: 标识网格计算资源。

Grid Status: 运行Pliot作业的站点的状态。

Grid Middleware: 该站点所使用的网格中间件。

( 3) Data Operation类型

该类型是除了Job类型之外另一个比较重要的类型。它主要记录网格环境中关于数据的一些操作信息。由于在网格环境中,物理文件与逻辑文件需要保持一致性,因此记录的字段涉及到物理文件的操作以及相应目录服务中逻辑文件的改变。包含字段描述如下:

3. 2 记账系统总体架构

记账主要分为两个步骤: 一是获取各种类型的记账信息,并将这些信息持久存储起来,二是对信息的处理,将信息用于响应用户查询请求。前者是后者的基础,而后者是前者的目的,它们相辅相成,共同构成了记账系统的框架。本文记账系统由三个模块组成,分别为信息收集模块、信息存储模块和信息分析模块。信息收集模块完成记账信息的收集; 存储模块基于Mongo DB搭建,完成记账信息的持久化存储; 分析模块则是响应用户查询请求,对数据进行处理后将结果反馈给用户。下文将对本系统三个模块的设计进行详细阐述。记账系统的整体框架如图1所示。

( 1) 信息收集模块

信息的收集是整个记账系统工作的第一步。信息收集模块是由分布在作业管理系统和数据管理系统中的数据收集器组成的,每个子系统中定义的数据收集器会指定收集某一种类型的记录。Job类型以及Pilot类型的信息由作业管理系统中的信息收集器负责收集,而Data Operation类型信息则由数据管理系统中定义的信息收集器负责收集。信息的获取通过解析系统log日志来完成。例如在用户提交作业运行时,作业管理系统中定义的用于收集Job类型和Pilot类型的信息其收集器首先会自动解析作业管理系统生成的log日志,然后提取每种类型所定义的如User、Site等字段填充到一条记录中,从而完成一条完整记录的收集。

一条记录最终持久化存储到数据库中才算完成对它的收集。频繁的与数据库进行交互需要消耗相当多的时间,尤其是当记录非常多时,如果每一条记录存储都访问一次数据库,将造成性能上的极大损失。为了减小频繁访问数据库带来的性能损失,本文添加了一层缓冲机制,所收集到的记录首先会被发送到缓冲层,待缓冲层内的记录数据达到预设的上限后,访问一次数据库,将缓冲层中的记录批量提交到数据库中,由此显著地降低了访问数据库的次数,提高性能。

( 2) 信息存储模块

本系统的存储模块基于Mongo DB搭建,存储服务定义了一系列与Mongo DB交互的方法,包括记账信息的提交、数据的查询等等。传统的关系型数据库在设计之初就没有考虑分布式和分区,极大地限制了它的可扩展性,随着数据量的增大会面临存储瓶颈与性能瓶颈。Mongo DB天然的具有高扩展性,可以利用廉价的机器组成集群将数据分散存储,当存储空间不足时,只需要通过简单的步骤往集群中添加新机器即可,实现真正意义上的水平扩展。

一个Mongo DB集群由配置服务进程,分片节点,路由进程组成。本系统使用三台服务器badger01、badger02、badger03构建Mongo DB集群,一份完整的数据被分成片,集群中的每一个节点存储一个分片。数据是根据片键进行分片,片键的指定对于数据分布的均匀以及查询的效率有着重要的影响,在这里我们优化了片键选取策略,使用双字段作为复合键,既保证了插入数据能够均匀的分布在三台服务器上,也使CRUD( 创建,查询, 更新,删除) 操作能够利用局部性,提高查询效率,同时保证了有足够的粒度进行细分,避免以后添加新机器造成无法分片。 同时,为了保证系统的高可用性,本系统采用Mongo DB提供的副本集策略对数据进行备份,每一份数据拥有三份副本,新数据首先根据片键被分配到相应的服务器存储,而其他两份副本则分别同步到另外两台服务器。三份副本只有一份处于活跃状态,称为主副本,它定期与其他两份副本进行通讯,保证副本间数据的一致性,当主副本由于某种原因下线后,剩下的两份副本会自动选择出新的主副本继续向用户提供服务,而当原副本重新上线之后则会自动变为从副本。Mongo DB集群整体架构如图2所示。

图2中上半部分为三个分片,每一个分片由一个拥有三分副本的副本集组成,副本集中的三份副本分别存储在三台服务器上。图中左边为配置服务,存储整个集群的配置信息,它是整个集群中最重要的部分,因此在三台服务器各开启一个配置服务来保证整个集群的的高可用性。下方的Mongos服务是一个路由进程,屏蔽集群底层结构,使应用程序透明的存取数据库。

( 3) 信息分析模块

分析模块位于整个系统架构的最上层,用户可以通过web portal或者命令行界面与分析模块中的查询分析服务进行交互。 一个典型的查询过程可以描述为: 1用户提交查询请求,此请求应包括查询条件以及其他一些必要信息,如期望的结果展示方式等; 2查询分析服务解析用户查询请求,根据查询条件检索数据库得到相应数据; 3查询分析服务对所得数据进行处理,将处理后的数据发送给对应的画图函数; 4画图函数根据所得数据画出图表,并将最终结果通过查询分析服务返回给用户。为了减少第三步的数据处理时间,同时考虑到记账信息的分布式存储,本文采用Map/Reduce[11]计算框架。计算过程分为Map、Reduce两个步骤,具体计算过程如下所示: 1系统创建一个MapReduce主进程,主进程将大量的Map任务分配到数据所在节点。2 Map任务通过Map函数将节点相关数据进行处理,并保存为以键值对形式存在的中间数据。3 Reduce任务将Map任务生成的中间数据进行汇总,并最终将结果返回。从上述步骤可以看出,在数据的处理过程中,多个节点上的Map任务可以并发进行,从而提高了处理速度。

3. 3 统计查询实时响应问题

记账系统的查询性能是系统总体性能的重要指标,通过对大量用户查询请求进行分析后发现,90% 以上的查询请求属于统计信息查询,而对于记账信息的细节查询则非常少。此外,由于Pilot类型以及Data Operation类型主要为管理人员服务,因此对于绝大多数用户来说关心的是Job类型的记账信息。为了能够实时响应用户对于Job类型信息的统计查询,本文提出一种基于动态时间窗口的数据压缩算法对Job类型信息进行预处理。

一条Job类型信息包含多个字段,这些字段可以分为两类, 一种是帮助区分记录的一些属性,称为基本属性; 另一种是一些可以被用来计算的属性,称为计算属性。本文将从BESIII分布式计算平台收集的原始记账信息存储在一个名为Raw Data的集合中。对于Raw Data中的数据,使用压缩算法周期性的进行压缩操作,并将压缩后的结果存储到名为Bucket Data的集合中。 基于动态时间窗口的数据压缩算法描述如下:

( 1) 根据Raw Data中数据的存在时间来选择合适大小的时间窗口。存在时间越长的数据设置的时间窗口越大,存在时间越短的数据设置的时间窗口则越小。

( 2) 根据时间窗口来匹配数据。

( 3) 将同一时间窗口内的具有相同基本属性的记录聚合成一条记录。合成后的记录的一般属性不变,计算属性为被聚合记录计算属性的累加。

( 4) 对Bucket Data中的数据重新进行压缩。压缩后的数据也不是一成不变的,对于某些处于临界区域的数据,不同时间压缩它们的时间窗口大小可能会发生改变。

压缩操作涉及到对Raw Data和Bucket Data两个集合的操作,因此进行压缩操作势必会对系统性能造成一定影响,为了使压缩操作对系统的影响降到最低,本文将压缩操作的周期设定为一天,并且将执行压缩操作的时间设置在每天的凌晨1点。 压缩操作的流程如图3所示。

一般情况下,存在时间越近的数据被查询的可能性越高,为了更有效地管理数据,为不同存在时间的数据设置不同的时

间窗口粒度,存在时间越短的数据设置的粒度越细。时间窗口与记录存在时间的映射关系如下: 一周之内的数据以1小时作为时间窗口进行聚合,即将一小时内的具有相同一般属性的记录聚合成一条记录; 30天以内的数据以四小时作为时间窗口; 半年之内的数据以1天作为时间窗口; 大于半年而小于一年的数据以2天作为时间窗口; 大于一年的数据则以一周作为时间窗口。聚合后的数据每条记录会增加两个段: bucket Length, 表示生成此数据所对应的的时间窗口大小; Entries In Bucket,表示此记录是由多少条Raw Data中的记录聚合而成。

通过测试发现,经压缩后的数据规模缩小将近30倍,显著降低了统计查询时的检索量以及计算量,大幅度降低响应此类查询的时间,用户往往能在几秒之内得到分析结果。

3. 4 系统实现

本系统基于中间件软件DIRAC[12]实现。在DIRAC中定义了两种组件,分别名为Services和Agents。Service是一个被动的组件,它在启动之后就会自动的监听某一个端口,当有用户请求发送过来的时候,它会对该请求作出响应,然后根据具体的请求进行具体的操作,如向数据库插入新的数据或者查询数据库等。Service自身也可以作为客户端来调用其他服务,这时的Service相当于一个转派进程,将请求转发给其他服务响应。本系统将查询分析服务与存储服务定义为Service,用户和应用程序可以通过远程过程调用RPC( Remote Process Call) 来获得查询分析服务与存储服务所定义的功能。

与Service被动接受请求不同,Agent是一个主动的组件,它可以周期性的调用特定的方法实现某些操作。本文的数据压缩操作就是一个需要周期性调动的操作,因此,把压缩操作作为一个Agent开启,如此一来,数据压缩操作便会周期性的运行而无需人工干预。

系统分析模块分析结果的展示由DIRAC提供的画图类来实现,该类基于Matplotlib[13]实现由数据到图表的转换,Matplotlib是一个2D绘图的PYTHON第三方类库库,它提供一整套和Matlib相似的命令API,十分适合交互式地进行制图,而且也可以很方便地将它作为绘图控件,嵌入GUI应用程序中。DIRAC画图类封装了Matplotlib的一些方法,可以方便地生成直方图、饼图、线性图等图表。

为了给用户提供便捷的操作,除了命令 行接口之 外,系统还提供网页接口,用户只需输入查询条件,即可在当前页面生成图表。图4展示的是从2013年11月18日到2013年12月18日一个月 内在计算平台各个站点运行作业情况的一个分布,可以看到名为BES. UMN. us的站点运 行作业的 数目占总 数目为54. 2% ,远高于其他站点。

3. 5 安全性保证

本文基于DIRAC自带的安全传输框架DISET( DIRAC SEcure Transport)[14]实现记账系统的安全性。DISET构建于开发安全套接层Open SSL( Open Secure Sockets Layer)[15]协议之上, 实现客户端和服务器端的双端认证,自动进行用户身份识别、执行权限认证以及访问权限认证。在DIRAC中用户被组织成为虚拟组织VO( Virtual Organization)[16]。各个VO这对不同的资源被赋予不同的许可和使用权限,这些信息被存储在DIRAC的配置系统CS( Configuration Service) 中。当用户想要对记账系统进行某种操作时,DISET会首先检查所有的数字证书认证机构CA( Certification Authority) 服务器以检验证书的合法性从而进行用户身份识别。当用户证书被验证通过,就会进行权限认证, 首先会根据用户可识别名DN( Distinguished Name) 找到用户所在VO,然后访问CS查看该VO所拥有的访问权限,执行权限从而对该用户的访问权限,执行权限进行认证。完整过程如图5所示。

4 性能测试

BESIII分布式计算记账系统是WORM模式,其主要功能就是响应用户的查询请求,因此相对于插入性能,查询性能将作为系统性能的主要评价标准。

首先进行的测试是Mongo DB与My SQL查询性能的比较。 测试环境由四台配置为2. 4 GHz 2 × 4核CPU、16 GB RAM和4 × 450 GB服务器组成,My SQL部署在其中一台服务器上,Mongo DB部署在由三台服务器组成的集群上。My SQL与Mongo DB中的数据总量都是约3500万条记录。使用python编写脚本分别查询1000、10 000、50 000、100 000、200 000、500 000、1 000 000条记录。实验结果如图6所示,纵坐标表示时间,单位是秒,横坐标表示查询 记录数目,单位是千 条,两条折线 分别代表My SQL与Mongo DB查询所需时间的变化。从图6中可以看出, 在查询数目不大的情况下,两种数据库的查询效率没有明显的差别,随着查询记录数目的增多,Mongo DB的查询性能明显的优于My SQL。

记账系统需要应对多用户并发查询的情况,因此需要测试在多用户并发查询下的查询性能。为避免干扰,测试进程运行在单独的一台机器上,该进程向服务器发起查询请求,返回一个大约包含10万条记录的结果。模拟多用户并发查询的进程分布在其他的机器上,这些进程将不停的向服务器发起随机查询。 表1为此进程在不同数目并发进程下的查询时间,单位是毫秒, 变化趋势为图7所示。从图中可以看出,随着并发进程数目的增加,该进程的查询时间基本呈现一个线性增长的趋势,在并发进程为200时响应时间也可以在1秒钟左右。测试结果表明Mongo DB在并发条件下仍然表现出了很好的查询性能,完全可以满足需要。

5 结 语

MongoDB数据库 第7篇

随着网络技术的飞速发展, 在线考试是现阶段研究开发的一个热点。它是建立在国际互联网上的应用系统, 使考试不受地域的限制。一套完备的在线考试系统可以使用户在网上学习过后及时检验自己的学习效果, 及时发现自己的不足, 使得学习效率得到很大提高。在线考试系统中题目的生成、试卷的提交、成绩的批阅等都可以在网络上自动完成, 只要形成一套成熟的题库就可以实现考试的自动化。

传统的考试方式投入人员及时间较多, 涉及的预算成本也比较高, 考试之后还需要进行试题分析及结果统计等, 往往周期较长, 每次组织考试都要投入大量人力物力及相应资源, 而且效率也低。随着IT信息技术的不断发展, 利用网络技术在市数据中心部署一套系统, 定期不断更新题库, 市内参考人员可以统一在某一时段不同地点进行在线考试, 从而节约统一管理的人力物力投入及一些统计周期时间, 提高工作效率。

2 在线学习测试系统主要技术

在线学习测试系统与其他的基于web的应用系统一样运用的主要技术包括服务器后台开发技术和数据库技术。在本系统设计过程中服务器后台开发技术采用的是Node.js, 数据库技术采用的Mongodb。

Node.js是一个基于Chrome Java Script运行时建立的一个平台, 用来方便地搭建快速的易于扩展的网络应用。Node.js借助事件驱动, 非阻塞I/O模型变得轻量和高效, 非常适合运行在分布式设备的数据密集型的实时应用方面。

Javascript是一个事件驱动语言, Node利用了这个优点, 编写出可扩展性高的服务器。Node采用了一个称为“事件循环 (event loop) ”的架构, 使得编写可扩展性高的服务器变得既容易又安全。提高服务器性能的技巧多种多样, Node选择了一种既能提高性能, 又能减低开发复杂度的架构。Node采用一系列“非阻塞”库来支持事件循环的方式。本质上就是为文件系统、数据库之类的资源提供接口。向文件系统发送一个请求时, 无需等待硬盘 (寻址并检索文件) , 硬盘准备好的时候非阻塞接口会通知Node。该模型以可扩展的方式简化了对慢资源的访问, 直观、易懂。

Mongodb是一个基于分布式文件存储的数据库, 介于关系数据库和非关系数据库之间, 是非关系数据库当中功能最丰富最像关系数据库的。Mongodb支持的数据结构非常松散, 是类似json的bson格式, 因此可以存储比较复杂的数据类型。Mongodb最大的特点是支持的查询语言非常强大, 其语法有点类似于面向对象的查询语言, 几乎可以实现类似关系数据库单表查询的绝大部分功能, 而且还支持对数据建立索引。Mongodb服务端可运行在Linux、Windows或OS X平台, 支持32位和64位应用, 非常方便系统开发完成后在不同硬件平台的服务器上部署。

3 在线学习测试系统总体框架设计

在线学习测试系统总体框架分为3层:应用层、数据处理层、持久化层, 总体框架结构如图1所示。

(1) 应用层:面向用户, 提供用户所需各类业务应用, 主要包括知识测试、试题管理、用户管理等。

(2) 数据处理层:为应用层提供各项可重复利用的核心服务, 主要包括随机抽取组件服务、顺序抽取组件服务、用户登录管理组件服务、用户密码加密组件服务。

(3) 持久化层:负责存在用户数据以及各种业务数据, 为系统提供数据来源。

4 在线学习测试系统的系统组成

在线学习测试系统主要由web/应用服务器和数据库服务器组成。其中web+应用服务器主要作用是用作部署的web模块和核心业务处理模块, 向用户提供在线理论知识测试工具的业务应用, 服务器接受web终端用户操作请求, 调用相应的核心业务应用与处理单元, 并通过web页面将结果反馈给web终端用户, 数据库服务器则负责测试系统的所有业务数据的存储和管理, 整个系统的组成网络结构, 如图2所示。

在线学习测试系统的主要功能模块包括:知识测试、试题管理和用户管理3个主要部分。知识测试模块主要实现系统自动出题、在线学习测试并记录用户的学习测试结果, 系统自动出题功能包括从题库中随机抽取题目或者用户选中特定的题型进行学习测试功能;试题管理模块主要实现题库审核、题库批量导入导出以及题目修改等功能;用户管理模块主要实现用户信息查询、修改和登录管理功能。

5 在线学习测试系统关键模块设计

5.1 用户登录验证模块设计

用户登录是整个系统的入口, 确保用户能安全有效的登录是整个系统设计的关键之一, 在本系统中用户的登录验证采用Bcrypt加密技术对用户密码进行加密。Bcrypt, 是一个跨平台的文件加密工具。由它加密的文件可在所有支持的操作系统和处理器上进行转移。它的口令必须是8至56个字符, 并将在内部被转化为448位的密钥。Bcrypt使用的是布鲁斯?施内尔在1993年发布的Blowfish加密算法, 使用保罗?柯切尔的算法实现。在本系统中采用的是应用于Node.js的第三方加密处理模块——Bcrupt加密模块, 核心代码实现如下:

5.2 用户登录处理模块设计

系统用户登录处理流程:用户进入系统需要进行身份验证, 首先用户输入账号密码提交到系统后台验证, 后台用户登录处理模块对用户提交过了的账号密码进行验证判断是否正确, 如果密码错误则返回重新登陆页面, 账号密码正确则进入核对登陆用户类型处理, 依据用户的账户类别分别进入到不同的用户功能页面, 整个系统用户登录处理流程, 如图3所示。

依据系统用户登录处理流程进行代码设计, 用户登录处理模块实现的核心代码如下:

6 在线学习测试系统运行环境搭建与实验测试

本系统是基于Node.js和Mongodb运行的, 在系统运行环境搭建需要安装Node.js和Mongodb以及对系统工程进行配置, 具体的实施步骤如下:

(1) 下载并安装与操作系统对应的Mongodb安装文件 (http://www.mongodb.org/downloads) , 安装成功后进入到安装目录下的bin文件夹执行mongo’命令, 启动mongodb数据库。

(2) 下载安装与系统对应的Node.js (http://www.nodejs.org/) , 使用npm-v查看是否安装成功。

(3) 拷贝在线学习测试系统到指定目录, 在命令行中运行npm install安装工程所需依赖包, 安装成功后运行npm start启动运行在线学习测试系统服务器, 启动运行如图4所示。

(4) 在浏览器中输入服务器地址和端口进入在线学习测试系统, 本次实验采用的是默认端口3000, 本地测试地址为:127.0.0.1:3000, 实验测试验证在线学习测试系统运行正常。

7 结语

MongoDB数据库 第8篇

1)网站更加具有开放性,面向社会、校际和广大师生构建共享型精品课程资源平台的观念已形成共识。

2)网站功能不断丰富,在线教学、互动交流、视频教学等功能正逐渐应用到现有系统中,资源平台与课堂教学的互动性进一步提高。

精品课程网站的建设是动态的,其架构的设计必须紧跟专业建设、课程建设、教学改革和网络技术的发展,是一项长期的系统工程,将多种IT技术和手段整合,研究网站架构既具有重要的现实意义,又具有很强的操作性和实践性。

1 总体架构设计

精品课程资源是教学资源库的重要组成部分,构建共享型教学资源库是当前教学方式和手段改革的基本要求。基于Internet构建共享型精品课程网站,必须保证服务稳定性以及数据安全性,为课堂教学提供有力保障。

精品课程网站总体架构设计分为硬架构和软架构两部分,如图1、图2所示。

1)视频文件通过静态页面访问,视频服务器基于外网IP提供服务。

2)数据库通过Web服务器端动态脚本访问,基于数据安全性考虑,数据库服务器基于内网IP提供服务。

3)服务器操作系统采用稳定性和安全性较高的FreeBSD。

4)网站所有软件及开发工具的采用基于开源免费原则。

2 服务器配置

2.1 视频服务器配置

Red5是由Java语言开发提供基于Flash的流媒体服务器,支持H.263和H.264等视频格式,支持实时录制和播放,基于FreeBSD实现Red5媒体服务器,首先应安装Java环境。服务器配置的基本命令如下:

red5无需安装,解压解归档后将对应的目录移动至/usr/local下:

设置开机自动启动媒体服务,建立或修改/etc/rc.local文件,增加如下脚本,并设置可执行权限:

修改red5.sh文件中启动服务器的代码,在行末加&符号,以使服务在后台运行。

2.2 数据库服务器配置

精品课程虽然包含课程概况、教学团队、教学内容、教学方法、教学手段、实践教学、教学效果、教学与学习资源等基本要点,但各门课程的要点又有所区别,各要点下包含的子要点也不完全相同,适合于使用非关系型面向文档的MongoDB数据库。采用Ports方式安装MongoDB数据库的基本命令如下:

开机启动MongoDB服务器,设为主服务器,开启安全认证,在rc.local文件中增加如下脚本:

2.3 Web服务器配置

Web服务器是用户访问精品课程资源的接口和桥梁,基于Python和MongoDB构建精品课程网站,应确保Web服务器安装了Python、Django、Python MongoDB驱动、Mod_python和Apache服务器。

Mod_python是嵌入到Apache服务器的Python解释器,编辑apache的配置文件httpd.conf,设置Python应用的方法如下:

Web应用中访问静态文件如图片、其他文件等由apache来处理:

开机启动apache服务,在rc.local文件中增加如下脚本:

修改/boot/loader.conf文件,开启accept filter机制,增加如下脚本:

3 系统功能架构设计

精品课程网站系统功能架构如图3所示。

1)系统采用B/S结构实现,全部功能均可通过公网IP访问,是一个共享型资源平台。

2)视频教学模块利用Red5技术,能够进行在线视频录制和播放,实现远程视频教学和远程课堂管理,充分应用了现代教学方法和手段。

3)在线交流模块,可实现班级管理、在线答疑、作业布置和作业提交功能,具有良好的互动性。

4 Web开发框架的选择

基于Python的Web开发框架有Django、Pylons、Tornado、Bottle和Quixote等,其中Django是Python语言驱动的模型-视图-控制器(MVC)框架,具有良好的业务流程分离机制,易于实现快速Web开发和部署。

Django的控制器层由框架本身根据配置文件自动完成,视图层由视图和模板共同组成,模型层定义数据模型,web请求机制如图4所示。

Django框架配置文件关联规则如图5所示。

其中模板和模型配置由settings.py文件来完成,视图配置能过调用urls.py文件来完成。

5 结束语

基于网络构建共享型精品课程资源平台,是开展现代化教学的基本保证。只有有效利用网络资源优势,全面提高数字化资源质量,才能充分发挥精品课程的作用。本文以精品课程网站所应提供的课程建设和视频点播两大基本功能为出发点,提出了基于Python、MongoDB和Red5技术的网站总体架构设计思路,并从服务器架构设计、系统功能架构设计和Web开发框架选择等方面进行了研究和论证。但以下两方面仍有待作进一步的研究:

1)提高“工学结合”耦合度。基于工作过程,设计精品课程教学过程,充实真实项目库,提高精品课程“工学结合”耦合度,是培养学生解决实际问题能力的重要途径。

2)增强课堂教学与资源平台的互动。只有进一步提高课堂教学与资源平台的对接度,将资源平台切实引入的课堂教学中,不断丰富课堂教学内容,加强教学的直观性和启发性,才能达到最佳的教学效果。

参考文献

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

[2]陈建勋.Web信息架构[M].北京:电子工业出版社,2008:134-323.

[3]王冉阳.基于Django和Python的Web开发[J].电脑编程技巧与维护,2009(2):56-58.

[4]孙超.流媒体服务器Red5的扩展设计、测试与优化[D].上海:上海交通大学图书馆,2009.