石春菊 孙丽霞
摘要
随着企业社交网越来越被企业所重视和应用,企业社交网络平台中涉及到的数据容量也越来越大、数据之间的关系也越来越复杂,关系型数据库在处理这些大量数据和复杂数据时已经非常吃力,再加上Oralce数据库扩展优化所花费的费用越来越高.本文基于以上原因,提出设计企业社交网络平台时,采用非关系型数据库图数据库和T级存储容量的MongoDB数据库存储数据的方法。
【关键词】企业社交网络 Neo4j MongoDB
1 引言
近年来,在工业4.0的推动下,传统制造企业转向智能化智造,将互联网、物联网、信息技术和智能智造互联到一起,形成新的工业设计、生产、包装、销售、管理于一体的智能化企业。从制造业的分布图上来看,企业分布区域较大,如何将企业互联起来,实现企业协作、新机会挖掘、企业推荐、企业社交。在这个需求下,企业社交网络如国外的Chatter、Yammer、Lotus Connections、Share Point和国内的金蝶云之家、微部落、用于人才管理的TITA以及操作简单如微信的推事本等。这些企业社交网络工具方便了员工间的交流和协同,提高了部门间的协作处理事物的速度,实现了资源共享,提高了办公效率,同时也可以为企业挖掘新的客户,成为企业营销的新方式。由于企业社交中所用到的数据关系密切,如企业之间的供应关系、企业员工关系、产品、采购件和业务等,像这样的数据若采用关系型数据库的形式进行存储,数据冗余将会变的很大,而且当查询复杂企业供应关系时,即多表关联查询时极其不易查询,随着互联网2.0的兴起,网站设计均是采用动态页面架构,需要实时生成动态页面和提供动态信息,要求数据库并发负载非常高,往往要达到每秒上万次读写请求,关系型数据库应付上万次的查询请求还勉强能应付,但要处理上万次的写数据请求,就无法承受了。关系型数据库的扩展是采用纵向扩展方式,成本较高,数据模型的扩展不灵活,水平扩展能力较差。而基于Web架构的需求中,往往需要水平横向扩展,通过增加服务器节点的方式实现数据的迁移。而且关系型数据库在处理超大规模数据上的响应时间和数据处理速度都跟不上客户需求。基于关系型数据库的以上缺点,非关系型数据库应运而生。非关系型数据库是一种区别于关系型数据库的一种数据库管理方式,它采用的数据模型是类似于键/值、文档、列簇的存储模型,水平扩展灵活性高,并且支持海量数据存储。具体的非关系型数据库主要有以下四大类,一类是键值存储数据库,它主要使用哈希表的方式进行存储,通过特定的键和指针指向数据;一类是列存储数据库,通过键指向多列的方式存储数据;一类是文档型数据库,通过建立键值存储模型存儲数据,典型的文档数据库是MongoDB;一类是图形数据库,通过灵活的图数据模型存储复杂关系的数据。
企业社交网络不仅打破了传统的企业之间的交流方式,同时突破了企业员工之间的信息交互方式,企业间、企业与员工的信息交互不仅包括了文字之间的交互,同时包括产品信息的推广、关联、图片、附件及实时信息的更新等。目前关系型数据库虽为主流,但因其在网站规模发展中遇到的瓶颈越来越多,如事务一致性、读写实时性、复杂多表查询等,使得众多开发者转向了非关系型数据库的使用。
在企业社交网络中存储的数据主要有2大部分,一部分是以企业为中心的自我网络中数据的存储,如企业供应商关系、业务量、业务类型、产品紧密度、产品与员工的责任制关系等。在设计中这一部分数据要求可扩展性及更新效率较高,采用图数据库进行存储。另一部分数据就是企业邮箱中数据的存储,由于邮箱中的数据的大小、内容不是固定单一的,为方便管理存储采用面向文档式的数据库存储方式。
2 非关系型数据库
2.1 图数据库
图数据库是利用图结构进行存储和查询数据的一种非关系型数据库,典型的图数据库是Neo4j数据库,它是基于图论算法的数据库,是由节点和关系组成的,节点是以key-value的形式存储的,它的处理完全是事务性的。关系连接相应的节点,表示节点之间的某种联系。节点关系是一个简单的有向无环图。如在制造业中,我们要表示螺丝是企业的某位员工生产的,并供给某些企业用于生产某些产品。可用图1表示:从这个图中可以看出图数据库是是节点和关系的集合,是以图做为数据模型的。在节点和关系上都有相应属性值,属性值是可以任意多个的,它的存储是采用的json格式。
Neo4j数据库是一个完全兼容增删改查、基于图论算法的图形数据库。Noe4j数据库的图形结构导致其数据结构是可有可无的,它在数据建模方面常常用于针对复杂领域的数据集,因此常常被用于社交网络、深度推荐算法等领域的数据建模。Neo4j数据库的规模是自适应的,其读取性能与节点的个数无关,即图的大小不能影响其读取性能,neo4j数据库的读性能可以达到每毫秒遍历2000多节点关系。图数据库的查询语言是Cypher语言。应用程序的编程接口则是通过REST API接口进行访问的,采用的语句是面向对象的Java语言。
企业社交网络中的图数据库的节点标签和关系总图如图2所示。
每一节点标签下,可以包含若干多个节点。创建用户和企业标签节点的语句,例如
CREATE(t1:T{name:”Employee”)
CREATE(t2:T{name:”Enterprise”)
创建企业员工节点N,
CREATE(n:Employee(name:'小明,address:,status:NORMAL,createTime:,IastModifyTime:,.mail:xiaoming@126.com' ,phone:' 8985424'}),节点p中的属性包括:adress、status、createTime、lastModifyTime、name、email、phone。
创建企业节点E,
CREATE(e:Enterprise{mc:鲁银集团禹城粉未治金制品有限公司,address:山东省,business:粉未治金件,biaozhun: ,source:WEB,status:NORMAL,createTime:,lastModifyTime:,email:,phone:,fax:,miaoshu:})
創建员工、企业之间关系,用户隶属于企业
CREATE(n)-[:Has employee]->(e)
上面的语句仅仅是创建一个用户、企业,并建立关系。节点的创建和关系的建立本系统中均是利用java方法批量创建的。
2.2 MongoDB
MongoDB是一个面向文档的数据库,介于关系和非关系型数据库之间的一种数据库,它采用的数据存储方式是接近于JSON的BJSON格式存储的。MongoDB可以存储T级数据库,它采用的是横向扩展数据库的存储方式,通过分区的方式将数据分散到更多机器上,就是将数据添加到集群中即可,横向扩展的优点是即便宜又易于扩展。MongoDB的数据库扩展方式对于用户来说是透明的,用户只需将精力放在编写应用程序上即可。MongodDB中的主键均由客户端的驱动程序自动创建。
MongoDB也是采用key-value的形式进行存储,多个key-value组成文档,一组文档组成集合,文档相当于关系数据库中的一行,集合相当于一个表,集合是动态模式的。集合中的文档可以是各式各样的。多个集合组成数据库,一般常将类型相同的文档存于同一个集合里,可提高查询速度。MongoDB的语法格式同sq1格式类似,主要有以下命令show dbs查看数据库;show collections查看集合;createcollection创建一个集合;insert插入数据;find查找数据;update修改数据;remove删除数据。
企业社交网络中的有一重要的数据管理就是邮件的管理,由于邮件管理部分中有附件,收发邮件中的附件的大小不确定,有时几k,有时几M甚至有几G的附件存在,若采用关系型数据库进行存储的话,一般的方式是在在关系型数据库中存储附件名,通过附件名再查找服务器中的附件实现下载,这种方式使的查询和下载的时间和空间复杂度均有所增加。因此在企业社交网络中附件存储采用的是文档数据库的存储方式。MongoDB中单个文档限制为4MB,但组成集合的文档的数量是没有限制。因为存储的文件的大小理论上讲也是没有限制的,MongoDB自带分片机制,在存储大文件时会自动将大文件分片存储。本系统中的附件集合如图3所示。
附件集合主要存储系统中的附件资源,附件资源的类型有文本文档、声音、图片、视频及其它类型的文件,filename是附件的名称,length附件的长度,uploadDate是附件的上传日期。
3 小结
企业社交网络中所涉及到的这两种非关系型数据库,主要的目的是为了能充分利用Neo4j数据库和MongoDB数据库的优点,在企业社交网络平台中数据之间的关系较多,而且在数据处理过程中会建立或解除关系,如职工归属关系、企业供应关系等。Neo4j提供了直观的可视化界面,以图论为基础、键值对的数据存储方式、水平扩展灵活,对于数据的增删改查可通过REST服务实现。MongoDB文档数据库则以文档作为最小的单位进行存储,通过键定位一个文档,同属于键值数据库的存储方式。关系型数据库与非关系型数据库形成了一种互补式的关系,大部分系统中两者都会用到,并且无法取代,而对于企业来讲,高性能的数据库的存储方式、方便系统扩展才是设计人员所追求的,选取合适的数据库存储方式不仅可以提升系统性能,更能保证系统的高安全性和高可用性。直观的数据存储方式同时也便于系统的扩展。
参考文献
[1]张文盛,郑汉华.基于MongoDB构建高性能网站技术研究[J].吉林师范大学学报(自然科学版),2013(01):123-127.
[2]王余蓝.图形数据库NE04J与关系数据库的比较研究[J].现代电子技术,2012(20).
[3]王慧孜.范炜.WANG HuiZi.FAN Wei图数据库在标签系统中的应用研究[C].数字图书馆论坛,2015(04).
[4]王光磊.MongoDB数据库的应用研究和方案优化[J].中国科技信息,2011(20):93-94.