图数据库与JanusGraph部署

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

JanusGraph是Titan的一个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

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