图数据库与JanusGraph部署

26. 二月 2018 数据库 0

NoSQL

关于NoSQL有两种解释:一种是Non SQL,表示NoSQL与传统的关系数据库有本质上的不同;另一种是Not only SQL,表示NoSQL不仅仅能像普通(关系)数据库一样存储结构化数据,也可以存储非结构化数据。在数据规模很大的场景下,NoSQL通常是更好的选择,因为它易于横向拓展和分布式部署,相比传统关系数据库更加灵活。

通常NoSQL有以下四种:

  • KV数据库,存储key-value数据,如Redis、MemcacheDB等
  • 列式数据库(data store),如HBase、Cassandra等
  • 文档数据库,如MongoDB、RethinkDB等
  • 图数据库(graph database),如Neo4j、JanusGraph等

图数据库

图数据库就是用“图”的方式来存储数据。比如官方文档中的例子:

图来自官方Doc

在上图中我们可以发现元素有:节点(Vertex)、有向边(Edge),属性(Property)。节点表示实体,边表示关系,属性定义了实体和关系中的相关信息。

这跟ER图很像,关系数据库也可以表示为ER图,但是在关系数据库中,是无法沿着边进行访问的,只能通过链式进行遍历和计算。而在图数据库中,存储的是真实的图,可以沿着图的路径进行遍历和计算。举个例子,比如要找途中Hercules的父亲的父亲,在关系数据库中,需要先根据Herclues这一行的father列定位到他的父亲,再访问他的父亲通过同样的方法定位到父亲的父亲,需要两次索引定位;而在图数据库中可以直接沿着father边找到对应的人。(在关系数据库存在外键的时候,可以避免join操作,效率更高)

JanusGraph

JanusGraphTitan的一个fork。Titan项目创建于2012年,于2016年停止维护,是一个方便拓展的图数据库,支持HBase、Cassandra等作为后端(BerkleyDB不提了),ES、Lucene等做全文索引,以TinkerPop作为图的查询和计算框架。2017年,JanusGraph项目fork了Titan,到目前已经推出了0.2.0版本。

图来自官方Doc

JanusGraph的CAP

CAP定理说的是:一个分布式计算机系统无法同时满足以下三点(定义摘自Wikipedia):

  • 一致性(Consistency) ,所有节点访问同一份最新的数据副本
  • 可用性(Availability),每次请求都能获取到非错的响应——但是不保证获取的数据为最新数据
  • 分区容错性(Partition tolerance),以实际效果而言,分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性,就意味着发生了分区的情况,必须就当前操作在C和A之间做出选择。

关于JanusGraph在CAP理论上的侧重,是要看底层存储的。如果底层是Cassandra,那么就是偏向于AP(Cassandra是最终一致性的);如果底层是HBase,就是偏向于CP(强一致性);BerkleyDB单机不存在这个问题。

JanusGraph单机部署

JanusGraph通过gremlin-server提供服务,有两种模式:WebSocket和HTTP,两种模式无法同时存在于同一个实例上,但是可以通过创建两个实例达到共存的目的。官网描述略长,这里总结得简单一些。默认后端使用HBase+ElasticSearch。

具体步骤如下:

1. 从Github release页下载 janusgraph-{VERSION}-hadoop2.zip ,并解压

2. 准备 .properties 文件

并在新文件开始添加

3. 准备 gremlin-server.yaml ,这里写了两个实例配置

3.1 修改 socket-gremlin-server.yaml

3.2 修改 http-gremlin-server.yaml

4. 启动server

成功后会在屏幕上打log

5.1 测试WebSocket

使用gremlin测试,打开 bin/gremlin.sh

:> 符号是立即执行的意思。如果修改过port,同时也要修改一下 conf/remote.conf 。

5.2 测试HTTP

注意不要使用单引号,会报错

 


发表评论

电子邮件地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据