当前位置:论文网 > 论文宝库 > 信息科技类 > 应用电子技术论文 > 正文

分析大数据下MongoDB数据库档案文档存储去的计算方法

来源:UC论文网2015-12-05 20:44

摘要:

摘 要: 针对大数据下档案存储的现状,通过分析存储档案文档存在重复的原因,提出一种MongoDB存储档案文档的方法,利用MongoDB的GridFs统一处理不同类型和大小的文件,定义3个集合分

摘 要: 针对大数据下档案存储的现状,通过分析存储档案文档存在重复的原因,提出一种MongoDB存储档案文档的方法,利用MongoDB的GridFs统一处理不同类型和大小的文件,定义3个集合分别存储上传者记录、文件信息记录和分块文件内容,提出存储中通过文件MD5校验码值是否相同来进行去重研究,并实现去重的程序代码,有一定的实际意义。采用的分布式存储数据库增强了档案文档存储系统的可扩展性。实验表明,该方法能有效地去除重复的档案文档,提高查询效率。
  关键词: MongoDB; MD5; 大数据; 档案文档去重; GridFs
  中图分类号: TN911?34; TP311 文献标识码: A 文章编号: 1004?373X(2015)16?0051?05
  Research on duplicated document removal in big data archive storage of MongoDB database
  HE Jianying
  (College of Computer, Sichuan University of Arts and Science, Dazhou 635000, China)
  Abstract: In allusion to the present situation in document storage in case of big data, the MongoDB method to save documents is proposed according to the reason analysis of duplication in document storage. GridFs of MongoDB is used to store different type documents. Three different assemblages are definited to store the uploader record, document information record and content of blocked documents respectively. A research is proposed for removing the duplication by checking whether MD5 check code is same or not. It is significant to realize program code for duplicated document removal. The distributive memory database was used to enhance the expandability of the document saving system. The experimental result shows that this method can remove the duplicated documents effectively and improve the efficiency of inquiry.
  Keywords: MongoDB; MD5; big data; file document duplicate removal; GridFs
  0 引 言
  随着信息技术的飞跃发展,各国各地都在大力发展电子政务建设。在此环境下档案局的档案文档也跨入了信息化存储的行列。但档案局的档案类型种类较多,除了纯文本的之外,还有图片、声音、视频、PDF等各种类型的文档,这些文档都是非结构化的数据,在传统的信息系统中,存放这些数据是比较困难的。因此在大数据环境下,设计信息化档案存储系统会首选非结构化的数据库,即NoSQL数据库。利用NoSQL家族中的MongoDB数据库作为存放档案文档的非结构化数据是较为理想的。MongoDB对存放大量的非结构化数据有很大的优势,但因MongoDB本身就是非结构化的,故在存放信息时会产生重复的数据。有人提出了像在关系数据库中一样建立关键索引来解决重复数据的问题,但在以文档方式存储的数据而言,当数据很大时,这种方式将会有弊端。本文研究的是在存储档案文档之前就重复的数据进行去重处理,然后再存入MongoDB数据库中,这样在数据库中存放的将是非重复的数据。
  1 传统的档案存储分析
  在原有的存储档案文档信息系统中,主要是把文档以文件的形式存放在文件系统中,然后用原数据信息建立一个档案文件和数据库的链接,并把该链接的路径存储在关系数据库中,如表1和表2所示。
  通过表1和表2的分析可知,表2中filePathId与表1中的filePathId中的字段关联 ,这样在访问表1中的某个文件时,只需要访问表2中与filePathId字段关联的记录的fileRealPath的值即可访问该文件。对于以文件系统方式存放的档案文件会产生大量的重复文件。即使在存储的时候能简单的通过人工的方式来检查是否有重复的文件存放,但也不能大面积的检查是否有重复的文件,在这种方式下,存储空间很快会被耗尽,要靠不断的增加存储设备来解决大量档案数据存放的问题,而且不利于管理,数据极其不安全,扩展性较差。人们对此已有逐步的认识,也进行了相应的研究。本文的重点是利用MongoDB数据库来存储这些非结构化的数据,并且在存放之前就完成对重复档案文档的去重操作。
  表1 文件基本信息表
  表2 文件存储路径映射表
  2 基于MongoDB的文档存储模型
  2.1 MongoDB的存储机制
  MongoDB是NoSql家族中的一员,具有模式自由等特性。它与关系数据库一样具有3个层次:分别是数据库层、集合层、文档对象层。分别对应关系数据库中的数据库、表和记录。在MongoDB中文档类似于JSON的键/值对,集合则是一组文档的集合,它们是无模式限制的。MongoDB数据库非常适合实时数据的插入、查询、更新、删除及数据备份等操作。尤其适合充当由几十台或者几百台服务器组成的集群数据库。现在大多数的地理规划等领域都在利用MongoDB数据库进行数据存储。MongoDB数据库不仅支持分布式系统,它本身还支持分片存储数据(Mongod)、客户端请求(Clients)、集群配置(Config Server)和路由协议(Mongos)[1]。它采用的是内存映射的方式作为存储引擎,能有效地提高输入/输出的效率[2]。 2.2 MongoDB数据库中重复数据来源
  目前的档案管理系统还处于信息孤岛的层面,各个省市的数据结构不同,存放的方式也不同,惟一能统一的是从市级单位及其下级单位,如区、县、乡、镇单位。利用档案管理系统上传档案文件进行存储的也是这些相关单位。如果同一份档案文档被市级单位分发到其他单位,其他单位会把它作为重要档案文档给上传到档案管理系统中存储起来,这样就会产生多个重复的档案文档。而有部门在不知道的情况下,同一个人上传了几份相同的档案文档;或者利用shp文件批量上传档案文档时遇到其他异常情况,没有一次性的上传完,下次再上传的时候,又是从头开始上传,导致以前的档案文档被重复存储;或者在批量上传的shp文档本身被人为的不小心做成了含有重复的档案文档记录,这样导入shp文件时也会产生重复记录。通过对以上情况的分析可知,档案文档存储时在MongoDB数据库中产生重复数据的来源主要有以下几点:同一个档案文档被不同的单位、部门重复上传;同一个人对同一个档案文档上传多次;批量档案文档准备过程中人为的产生了重复文档;批量上传时,中断上传,下次再上传时将产生重复文档。
  2.3 档案存储模型的建立
  档案存储时采用分布式的方式进行上传存储的,各个市、区、县、乡、镇的不同部门可能在不同的时间和地点对档案文档进行上传操作。数据库采用MongoDB数据库,其分布式存储结构如图1所示。
  
  图1 分布式数据库存储图
  从图1可以看出,各市、县、乡、镇的用户可以随时在不同地点上传档案文档到不同的MongoDB服务器中,操作方便。档案文档不同于一般的文档,将遵循“谁操作谁负责”的原则。故将设置上传者的权限,且将记录上传者的详细信息:如上传时间、地点等的一些信息。而对于档案文档本身而言其文件大小不能统一标准化,且档案文档的格式有差异,考虑到要处理数据大小和类型都可能不同的档案文档,本文将借助于MongoDB的GridFs来处理,GridFs是一种处理大文件的规范,可以存储上百万的文件而不用担心其扩容性[3]。在MongoDB中存放数据时将涉及到3个集合:userInfo.users,fileInfo.files,fileContent.chunks。
  userInfo.users集合用来存放上传档案文档的上传者信息,其结构如下:
  {
  “_ID”://惟一值
  “UserID”://用户的ID值
  “UploadGeography”: //上传的地理位置
  “GeoType”://地址位置的类型,如城//镇、居民点等
  “UploadGeoName”://地理名称
  “UploadGeoNameID”:< String > //地理名称主键值
  “UploadGeoAddress”: //上传的城镇地址等
  “CityName”://城镇名称
  “CountyName”:< String > //县级名称
  “TownName”:< String > //乡镇名称
  “StreetName”:< String > //街道名称
  “GeoPts”: //地理坐标
  “Type”:< String > //坐标类型
  “GeoCoordinates”:< String > //坐标位置
  “UploadFileID”:< objectID> //上传存放文件信息的ID编号
  “UploadTime”:< timestamp > //上传者操作的
  //体时间
  “UploadCount”://同一文档上传的次数
  }
  fileInfo.files集合中存放信息的结构为:
  {
  “fileID”:
  //存放文件ID值与userInfo.users集合中upLoadFileID对应
  “fileLength”:< num > //文件的大小
  “fileChuckSize”:< num > //文件分块存储的分块数
  “fileName”:< String > //上传文件的名称
  “fileMD5”:< hash > //文件内容的MD5校验码值
  “fileCountType”:< String > //文件的类型
  }
  fileContent.chucks集合中存放上传文档的结构如下:
  {
  “f_ID”:< objectID > //惟一的值
  “fileID”:< objectID > //与fileInfo.files集
  //合中的fileID对应
  “countOrder”:< num > //存放上传文件的第几个分块
  “countData”:< binary > //存放文档对应分块部分//的二进制内容
  }
  集合fileInfo.files中的fileID与集合userInfo.users集合中的upLaodfileID相同,用来关联上传的文件信息。集合fileContent.chucks中的fileID与集合fileInfo.files中的fileID相同,用来关联文件存放的具体内容,根据上面3个集合中结构的设计,当一个具有操作权限的用户在某一地点上传了某个档案文件后,将记录该用户上传的详细信息:如操作者,上传的具体区、县、乡的详细地址,上传的日期、文件名、文件的大小、长度、类型等。当该用户再次上传相同的档案文档时,根据表的关联查找,将会做出已在同一地点或不同地点已经上传了相同的档案文件的提示信息。 3 MongoDB中的去重算法
  本算法的设计思想是,根据上传的档案文档判断,无论是否已经被上传过,都会存储上传档案文档操作者的相关信息,即生成一个userInfo.users集合中的一条记录。上传档案文件时为了节省服务器的开销和资源,所上传文档的MD5 校验码值的计算都会在客户端进行。在客户端计算并上传档案文档的MD5校验码值后再在分布式存储数据库中查找遍历fileInfo.files中的每一条记录,查看每条记录中存储的档案文档的MD5码值是否与将要上传的档案文档的MD5码值相同,如果不同,则将在userInfo.user集合中存储一条上传者信息的记录,并且把该记录中的“UploadCount”值设置为1。同时生成集合fileInfo.files中的一条记录,在该记录中通过“fileMD5”存储档案文档的MD5码值。获得要上传的档案文档的大小fileSize,确定档案分块存储的总块数fileChuckSize。在算法中为了规范,不管文件的大小和类型,均采用统一大小(fixedSize)的分块对档案文档进行存放,即总分块数如下所示:
  fileChuckSize=(fileSize%fixedSize)?(fileSize/fixedSize):
  (fileSize/fixedSize+1)
  并把该值记录到fileInfo.files集合中对应记录中。然后对档案文档进行上传并对文档内容按固定的分块大小存放到fileContent.chucks集合中,在该集合里会存储fileChuckSize条记录。如果要上传的档案文档的MD5码值和分布式数据库中存储的fileInfo.files集合中存储的某个记录的fileMD5值相同,则取出该条记录对应的fileID值并把该值存放到一个临时存储字段tempFileID中,已备后期使用。然后提取上传者的信息和tempFileID的值组合成userInfo.users集合中的一条记录,并与集合中的其他记录进行比较,如果有相同的记录,则在该条记录的UploadCount值加1。而组合的这条记录将不再存储在userInfo.users集合中。其中UploadCount值加1是判断该用户是否经常在同一个地点上传相同的档案文档。
  如果在该集合中没有相同的记录,则存储该组合好的记录。下次在访问这个档案文档时,通过userInfo.users集合中的upLoadfileID关联到fileInfo.files集合,再通过fileInfo.files集合中的fileID关联到fileContent.chucks集合,则顺利访问到需要的档案文档,其过程流程图如图2所示。
  根据算法流程图,定义几个类UserInfo,FileInfo,FileContent分别对应3个集合,定义操作数据库的类DBObj,定义去重的类RemoveRepeat。
  
  图2 算法流程图
  去重的关键代码实现如下:
  / *在fileInfo.files集合中查找有没有与指定的hashMD5码相同的记录存在*/
  private String findByFileMD5(hash fileMD5) {
  String tempFileID=null;
  ListrepeatList = new ArrayList();
  GeoEntiy ge = null;
  /*取得传递的fileMD5参数 */
  String json = "{fileMD5 : \"" + fileMD5 + "\"}";
  DBObj fileMD5 = (DBObj) JSON.parse(json);
  DBCursor dbcursor = getDBColl().find(fileMD5);
  /* 根据坐标点查询的记录数量*/
  int rowCount = dbcursor.count();
  /*如果结果大于0则说明有相同的MD5码存在,则存放该记录的fileID值*/
  if (rowCount > 0) {
  tempFileID= rowCount.get("fileID").toString();
  }
  }
  return tempFileID;
  }
  public ListfindRepeatData() {
  /* 构建数据查重的MongoDB语句,并进行查重 */
  DBObj groupObj = new BasicDBObj("$group", JSON.parse(" {_ID: { "
  + " UserID : \"$UserID\" , "
  + " UploadGeography : \"$UploadGeography\" "
  + " GeoType : \"$GeoType\" , "
  + " UploadGeoName : \"$UploadGeoName\" , "
  + " UploadGeoNameID: \"$UploadGeoNameID\" , "
  + " UploadGeoAddress : \"$UploadGeoAddress\" , "
  + " CityName : \"$CityName\" , "
  + " CountyName : \"$CountyName\" , " + " TownName : \"$TownName\" , "
  + " StreetName : \"$StreetName\" , "
  + " GeoPts : \"$GeoPts\" , "+ " Type : \"$Type\" , "
  + " GeoCoordinates: \"$UploadFileID\" , "
  + " UploadTime : \"$UploadTime\" , "
  + " UploadCount: \"$UploadCount\");
  // 排序条件 ?? 按照关键字_ID降序排列
  DBObj sortObj = new BasicDBObj("$sort",JSON.parse("{ _ID:?1 }"));
  // 确定疑似重复数据的条件返回的结果为1
  DBObj matchObj = new BasicDBObj("$match",JSON.parse("{ _ID:?1 });
  // key code
  AggregationOutput output = getDBColl().aggregate(groupObj, sortObj,matchObj);
  Iteratoriter = output.results().iterator();
  //获取查询结果集
  Listlist = new ArrayList();
  while (iter.hasNext()) {
  DBObj dbo = iter.next();
  String _idValue = dbo.get("_ID").toString();
  //通过key,获取对应的value
  if (_idValue != null) {//如果查询结果不为空,则将结
  果转换
  JSONObj pointJson = com.alibaba.fastjson.JSON.parseObject(_idValue);
  // 如果存在坐标点或有想太多 其他值,则获取
  if (pointJson.get("GeoPts") != null) {
  list.addAll(findByPoints(pointJson.get("GeoPts").toString()));
  }
  }
  }
  return list;
  }
  在代码中定义了findByFileMD5()方法判断在已经存储的fileInfo.files集合的记录中有没有与将要上传的档案文档的MD5校验码相同的记录存在。定义方法findRepeatData()用来检查有无重复上传档案文档上传者信息,即判断在usersInfo.user中有没有重复的数据记录,这些方法在批量导入数据记录时也会调用逐一判断。
  4 实验结果与分析
  本实验使用Hadoop作为分布式文件系统运行在不同地理位置的10台主机组成的集群上,在Window7系统中,采用MyEclipse8.5做Java代码开发,分布式数据库MongoDB作数据存储,采用的是8核CPU,8 GB内存,320 GB硬盘。批量导入使用的是shp文件。shp文件的格式定义同集合文件的格式。对单个的文档上传进行验证无误外,为了对更多的数据进行验证,在shp文件中模拟产生10万,20万,30万数据。结果如图3所示。
  
  图3 实验数据测试结果图
  该方法在数据去重中达到90%以上,去重效果还比较理想。算法采用的是分布式文件系统,对文件去重效率较高,且系统具有相应的扩展性。
  5 结 语
  本算法中采用分布式文件系统和分布式数据库MongoDB对档案文档进行存储和去重,利用MongoDB数据库的GridFs来处理不同类型和大小的档案文档,统一对档案文档进行处理。提出利用了去重的算法思想,并通过实验模拟测试去重效果较为理性。该方法具有一定的可行性。为以后大数据的存储的去重有一定的借鉴性。
  参考文献
  [1] 雷德龙,郭殿升,陈崇成,等.基于MongoDB的矢量空间数据云存储与处理系统[J].地理信息科学,2014(7):508?514.
  [2] 吴秀君.面向电子政务的MongoDB与MySQL混合存储策略[J].计算机与现代化,2014(8):62?65.
  [3] CHODOROW Kristina.MongoDB 权威指南[M].北京:人民邮电出版社,2010.
  [4] 郭武士.基于MongoDB GridFS的图片存储方案的实现[J].四川工程职业技术学院学报,2011(4):41?43.
  [5] 卫启云,渠伟勇,黄鸿,等.城市地理编码的部门信息共享与应用实践[J].测绘通报,2014(10):101?104.
  [6] 陈超,王亮,闫浩文,等.一种基于NoSQL 的地图瓦片数据存储技术[J].测绘科学,2013(1):142?143.
  [7] MANBER U. Finding similar files in a large file system [C]// Proceedings of the Winter 1994 USENIX Technical Conference. San Fransisco, CA, USA: [s.n.], 1994: 1?10.
  [8] BRODER A Z. On the resemblance and containment of documents [C]// Proceedings of the International Conference on Compression and Complexity of Sequences. Salerno, Italy: [s.n.], 1997: 21?29.
  [9] 孙有军,张大兴.海量图片文件存储去重技术研究[J].计算机应用与软件,2014(4):56?57.
  [10] RIVEST R. The MD5 message?digest algorithm [J]. RFC 1321, Internet Engineering Task Force, 1992, 22(1) : 15?26.
  [11] 成功,李小正,赵全军.一种网络爬虫系统中URL去重方法的研究[J].中国新技术新产品,2014(12):23?24.

核心期刊推荐