【图数据库实战】HugeGraph架构

一、概述

作为一款通用的图数据库产品，HugeGraph需具备图数据的基本功能，如下图所示。HugeGraph包括三个层次的功能，分别是存储层、计算层和用户接口层。 HugeGraph支持OLTP和OLAP两种图计算类型，其中OLTP实现了Apache TinkerPop3框架，并支持Gremlin查询语言。 OLAP计算是基于SparkGraphX实现。

二、组件

HugeGraph的主要功能分为HugeCore、ApiServer、HugeGraph-Client、HugeGraph-Loader和HugeGraph-Studio等组件构成，各组件之间的通信关系如下图所示。

HugeCore ：HugeGraph的核心模块，TinkerPop的接口主要在该模块中实现。HugeCore的功能涵盖包括OLTP和OLAP两个部分。
ApiServer ：提供RESTFul Api接口，对外提供Graph Api、Schema Api和Gremlin Api等接口服务。
HugeGraph-Client：基于Java客户端驱动程序。HugeGraph-Client是Java版本客户端驱动程序，后续可根据需要提供Python、Go、C++等多语言支持。
HugeGraph-Loader：数据导入模块。HugeGraph-Loader可以扫描并分析现有数据，自动生成Graph Schema创建语言，通过批量方式快速导入数据。
HugeGraph-Studio：基于Web的可视化IDE环境。以Notebook方式记录Gremlin查询，可视化展示Graph的关联关系。HugeGraph-Studio也是本系统推荐的工具。

三、设计理念

常见的图数据表示模型有两种，分别是RDF（Resource Description Framework）模型和属性图（Property Graph）模型。RDF和Property Graph都是最基础、最有名的图表示模式，都能够表示各种图的实体关系建模。RDF是W3C标准，而Property Graph是工业标准，受到广大图数据库厂商的广泛支持。HugeGraph目前采用Property Graph。

HugeGraph对应的存储概念模型也是参考Property Graph而设计的，具体示例详见下图：

在HugeGraph内部，顶点仅存储Id不包含任何属性信息，顶点所有的属性和Label都通过边来存储。如图所示顶点（Id=1）有3个属性分别是name、age和lives，则由三条对应的边指向其具体的属性值，这三条边的Label和顶点属性名相同分别是name、age和lives。

在HugeGraph内部，顶点与顶点之间的关系也通过边来存储的。但关系的属性并没有像顶点一样分来存储，而是和关系存储在一起。

顶点属性值通过边指针方式存储时，如果要更新一个顶点特定的属性值直接通过覆盖写入即可，其弊端是冗余存储了VertexId；如果要更新关系的属性需要通过read-and-modify方式，先读取所有属性，修改部分属性，然后再写入存储系统，更新效率较低。从经验来看顶点属性的修改需求较多，而边的属性修改需求较少，例如PageRank和Graph Cluster等计算都需要频繁修改顶点的属性值。

四、图分区方案

对于分布式图数据库而言，图的分区存储方式有两种：分别是边分割存储（Edge Cut）和点分割存储（Vertex Cut），如下图所示。使用Edge Cut方式存储图时，任何一个顶点只会出现在一台机器上，而边可能分布在不同机器上，这种存储方式有可能导致边多次存储。使用Vertex Cut方式存储图时，任何一条边只会出现在一台机器上，而每相同的一个点可能分布到不同机器上，这种存储方式可能会导致顶点多次存储。

采用EdgeCut分区方案可以支持高性能的插入和更新操作，而VertexCut分区方案更适合静态图查询分析，因此EdgeCut适合OLTP图查询，VertexCut更适合OLAP的图查询。HugeGraph目前采用EdgeCut的分区方案。

五、 VertexId 策略

HugeGraph的Vertex支持三种ID策略，在同一个图数据库中不同的VertexLabel可以使用不同的Id策略，目前HugeGraph支持的Id策略分别是：

自动生成（AUTOMATIC）：使用Snowflake算法自动生成全局唯一Id，Long类型；
主键（PRIMARY_KEY）：通过VertexLabel+PrimaryKeyValues生成Id，String类型；
自定义（CUSTOMIZE_STRING|CUSTOMIZE_NUMBER）：用户自定义Id，分为String和Long类型两种，需自己保证Id的唯一性；

默认的Id策略是AUTOMATIC，如果用户调用primaryKeys()方法并设置了正确的PrimaryKeys，则自动启用PRIMARY_KEY策略。启用PRIMARY_KEY策略后HugeGraph能根据PrimaryKeys实现数据去重。

1.AUTOMATIC ID策略

schema.vertexLabel("person").useAutomaticId().properties("name", "age", "city").create();graph.addVertex(T.label, "person","name", "marko", "age", 18, "city", "Beijing");

2.PRIMARY_KEY ID策略

schema.vertexLabel("person").usePrimaryKeyId().properties("name", "age", "city").primaryKeys("name", "age").create();graph.addVertex(T.label, "person","name", "marko", "age", 18, "city", "Beijing");

3.CUSTOMIZE_STRING ID策略

schema.vertexLabel("person").useCustomizeStringId().properties("name", "age", "city").create();graph.addVertex(T.label, "person", T.id, "123456", "name", "marko","age", 18, "city", "Beijing");

4.CUSTOMIZE_NUMBER ID策略

schema.vertexLabel("person").useCustomizeNumberId().properties("name", "age", "city").create();graph.addVertex(T.label, "person", T.id, 123456, "name", "marko","age", 18, "city", "Beijing");

如果用户需要Vertex去重，有三种方案分别是：

采用PRIMARY_KEY策略，自动覆盖，适合大数据量批量插入，用户无法知道是否发生了覆盖行为
采用AUTOMATIC策略，read-and-modify，适合小数据量插入，用户可以明确知道是否发生覆盖
采用CUSTOMIZE_STRING或CUSTOMIZE_NUMBER策略，用户自己保证唯一

六、 EdgeId 策略

HugeGraph的EdgeId是由srcVertexId+edgeLabel+sortKey+tgtVertexId四部分组合而成。其中sortKey是HugeGraph的一个重要概念。在Edge中加入sortKey作为Edge的唯一标识的原因有两个：

如果两个顶点之间存在多条相同Label的边可通过sortKey来区分
对于SuperNode的节点，可以通过sortKey来排序截断。

由于EdgeId是由srcVertexId+edgeLabel+sortKey+tgtVertexId四部分组合，多次插入相同的Edge时HugeGraph会自动覆盖以实现去重。需要注意的是如果批量插入模式下Edge的属性也将会覆盖。

另外由于HugeGraph的EdgeId采用自动去重策略，对于self-loop（一个顶点存在一条指向自身的边）的情况下HugeGraph认为仅有一条边，对于采用AUTOMATIC策略的图数据库（例如TitianDB）则会认为该图存在两条边。

HugeGraph的边仅支持有向边，无向边可以创建Out和In两条边来实现。

七 HugeGraph 事务处理

7.1 TinkerPop事务概述

TinkerPop transaction事务是指对数据库执行操作的工作单元，一个事务内的一组操作要么执行成功，要么全部失败。详细介绍请参考TinkerPop官方文档：http://tinkerpop.apache.org/docs/current/reference/#transactions

7.2 TinkerPop事务操作接口

open 打开事务
commit 提交事务
rollback 回滚事务
close 关闭事务

7.3 TinkerPop事务规范

事务必须显式提交后才可生效（未提交时修改操作只有本事务内查询可看到）
事务必须打开之后才可提交或回滚
如果事务设置自动打开则无需显式打开（默认方式），如果设置手动打开则必须显式打开
可设置事务关闭时：自动提交、自动回滚（默认方式）、手动（禁止显式关闭）等3种模式
事务在提交或回滚后必须是关闭状态
事务在查询后必须是打开状态
事务（非threaded tx）必须线程隔离，多线程操作同一事务互不影响

更多事务规范用例见：Transaction Test

7.4 HugeGraph事务实现

一个事务中所有的操作要么成功要么失败
一个事务只能读取到另外一个事务已提交的内容（Read committed）
所有未提交的操作均能在本事务中查询出来，包括：
- 增加顶点能够查询出该顶点
- 删除顶点能够过滤掉该顶点
- 删除顶点能够过滤掉该顶点相关边
- 增加边能够查询出该边
- 删除边能够过滤掉该边
- 增加/修改（顶点、边）属性能够在查询时生效
- 删除（顶点、边）属性能够在查询时生效
所有未提交的操作在事务回滚后均失效，包括：
- 顶点、边的增加、删除
- 属性的增加/修改、删除

示例：一个事务无法读取另一个事务未提交的内容

1. static void testUncommittedTx(final HugeGraph graph) throws InterruptedException {2. final CountDownLatch latchUncommit = new CountDownLatch(1);3. final CountDownLatch latchRollback = new CountDownLatch(1);4. Thread thread = new Thread(() -> {5. // this is a new transaction in the new thread6. graph.tx().open();7. System.out.println("current transaction operations");8. Vertex james = graph.addVertex(T.label, "author",9. "id", 1, "name", "James Gosling",10. "age", 62, "lived", "Canadian");11. Vertex java = graph.addVertex(T.label, "language", "name", "java",12. "versions", Arrays.asList(6, 7, 8));13. james.addEdge("created", java);14. // we can query the uncommitted records in the current transaction15. System.out.println("current transaction assert");16. assert graph.vertices().hasNext() == true;17. assert graph.edges().hasNext() == true;18. latchUncommit.countDown();19. try {20. latchRollback.await();21. } catch (InterruptedException e) {22. throw new RuntimeException(e);23. }24. System.out.println("current transaction rollback");25. graph.tx().rollback();26. });27. thread.start();28. // query none result in other transaction when not commit()29. latchUncommit.await();30. System.out.println("other transaction assert for uncommitted");31. assert !graph.vertices().hasNext();32. assert !graph.edges().hasNext();33. latchRollback.countDown();34. thread.join();35. // query none result in other transaction after rollback()36. System.out.println("other transaction assert for rollback");37. assert !graph.vertices().hasNext();38. assert !graph.edges().hasNext();39. }

事务实现原理