Graph DataBase介绍

前言

分析社会关系这类复杂图壮结构的海量数据，使用图形数据库（Graph DataBase）是最好的选择。– 作者:李祎

《程序员》介绍各种NoSQL 数据库的文章已经很多，不过大部分都是基于文档存储 (例如mongo DB)或键值(key-value) 存储(例如Redis 和Hbase)的。 本文介绍NoSQL 数据库中大家不是很熟悉的图形数据库（Graph DataBase），它拥有什么特性，以及它适合那些项目。希望开发者阅读本文后，能从中获得一些启发，在今后实施类似项目时多一种技术选择。

作为NoSQL数据库的一个类型，图形数据库（Graph Database）很长时间都局限在图理论相关的学术圈子里，在业界使用得并不广泛。直到近十年电子商务业务模式逐步成熟，电商们需要对用户在他们网站的购买行为进行分析、发掘用户潜在喜好的商品，开始大量使用到了图理论相关的数据挖掘算法，图形数据库才从实验室慢慢走进实际的软件工程项目中。特别是随着Facebook为代表的SNS网站兴起，对上千万的用户行为和关系数据进行挖掘，发掘其商业价值越发成为迫切的需求和工程难题。 工程师们发现使用图形数据库来存储和计算这些海量数据会更为高效和方便， 这极大推动了图形数据库的发展和它在NoSQL世界的知名度。 现在业内比较著名的图形数据库有Twitter网站的FlockDB ， 以及开源项目中的Neo4j 和Infogrid。

Graph Database 的基础概念

• 点(Node)表示一个实体，例如人，商品，或是一个账户。
• 边 （Edge）也称做关系(relation)，表示点和点之间的连接关系，例如用户A买了商品B。通常边是有方向性的，例如用户A购买了商品B，就表示为A->B；如果是用户A和用户C互相都认识，这种关系就是双向的，表示为AB。
• 属性（propertis）表示点（Node）和边(Edge)所附带的信息，例如一个用户，他带有的属性可能是年龄30岁，爱好篮球等等。需要注意的是，每个点的属性(properties)是动态的，例如同样是用户A和C，A有属性“年龄30岁”，C却没有。但是它却包含属性“职业工程师”。

把点(Node),边(Edge)，属性（properties） 概念融合在一起，就可描述出一个图(graph)。图1描述了模拟《黑客帝国》的小型社会图(social graph)。

Node类代表点,id用来标识Node在图中的唯一性，size表示该Node包含的边总数。Relationship类代表另一个点和另一点的边, 表示两个点的唯一关系。rel_id表示另一点的id。rel_value字段用于存储和边相关的任何属性（例如收听关系中被重复收听了多少次等信息）。modify_time表示边建立和修改的时间。RelationshipList代表一个Node和它所有的Relationship集合，它内部包含一个按Relationship的modify_time字段倒序排列的指针链表（LinkArray）组成。

以下图3中的收听关系为例，Thomas 表示为一个点：

Thomas收听了Trinity 和Morpheus,其收听关系可表示为：

客户端SkullClient 封装了所有对Skull DB的访问。SkullClient使用多级缓存和多线程从Skull DB获取数据。所有对Skull DB 中Node和Relationship的创建、读、写、以及删除操作，都通过SkullClient完成。当调用读接口时，SkullClient先访问Memcache，如果找不到数据，再发送Http请求从Solr获取。当调用写接口时，SkullClient将被修改的Relationship调整到RelationshipList列表的第一位，更新Memcache中的数据，同时异步发送Http请求将修改后的Lucene文档发送给Solr。同时发送异步Tcp请求，将写事件通知Event Daemon 模块。

Skull-admin.war模块可部署在任何WEB容器内（例如Tomcat），提供REST接口对Skull DB进行读写操作。它还可以通过jmx控制台进行包括：实时获取Memcache状态（见图5），查询Solr 统计数据,管理Event Daemon内部队列，查询Skull DB内部数据，进行数据导入和导出的操作。

本次测试总共插入 109645条Relationship记录，共耗时6分28秒，每个线程平均85毫秒完成一次更新。其中有2个较陡的响应时间波峰，这是因为Lucene在进行索引写文件操作，在IO上会有一些影响。

本次测试共查询了15211个用户的好友关系，共耗时12秒，每个线程平均15毫秒完成一次查询。由于Relationship数据都被缓存在Memcache中，所以响应时间的的趋势是前高后低。

总结

在移动微博网站(www.139.com)， 我们用Skull DB 存储用户的关系数据,评论转发数据, 登陆IP等数据。 配合Hadoop的Map-Reduce并行框架来计算亲密度、关系度、热度等指标。 Skull DB还被用于BI分析统计，保存用户的标签信息用于用户标签分类，发掘潜在用户的商业价值。我们之所以实现自己的图形数据库，一方面是因为数据存储方案，无法胜任高并发计算，高的IO吞吐效率，同时要对用户关系进行两步以上的遍历的需求。同时，我们对数据一致性要求不高，即使有少数数据不一致也不影响整体结果。 在实际项目中，Skull DB 也还存在Lucene索引效率需要加强，以及数据安全不高等方面的问题。我们项目组也在随着项目深入，不断完善它。Skull DB的成功就在不远处，我们还在路上。

文章知识点与官方知识档案匹配，可进一步学习相关知识MySQL入门技能树首页概览31276 人正在系统学习中

来源：E哥-书影青山