随着社交、电商、金融、零售、物联网等行业的快速发展，现实社会织起了了一张庞大而复杂的关系网，亟需一种支持海量复杂数据关系运算的数据库即图数据库。本系列文章是学习知识图谱以及图数据库相关的知识梳理与总结

本文会包含如下内容：

如何获取后端存储的数据结构以存储为端是mysql为例，分析hugegraph的数据存储结构hugegraph以mysql为存储时的建库SQL语句

本篇文章适合人群：架构师、技术专家、对知识图谱与图数据库感兴趣的高级工程师

本次分析基于hugegraph 0.11.2进行。

1. 如何获取后端存储数据结构

hugegraph针对不同的后端存储，基本上是使用同一套数据存储结构，区别在于根据不同存储的特点，建表语句及存储读写数据的差异

以mysql为例，讲一下如何获取后端存储的数据结构。

1. 新增一个图配置文件，如sqlgraph.properties, 内容如下： 注意：serializer需要选择mysql，否则在初始化时会报错。

backend=mysqlserializer=mysqlstore=sqlgraph# mysql backend configjdbc.driver=com.mysql.jdbc.Driverjdbc.url=jdbc:mysql://172.25.20.219:3306jdbc.username=videowebjdbc.password=suntekjdbc.reconnect_max_times=3jdbc.reconnect_interval=3jdbc.sslmode=false

2. 在rest-server.properties、gremlin-server.yaml中增加图的名称及对应的配置文件，如 下

graphs: {      hugegraph: conf/hugegraph.properties,      pcigraph: conf/pcigraph.properties,      testgraph: conf/testgraph.properties,      sqlgraph: conf/sqlgraph.properties}

3. 运行bin/init-store.sh脚本，运行成功，则在配置的mysql中以图名称创建数据库sqlgraph, 数据表共创建27张。

2.后端存储底层数据结构分析2.1 底层数据结构

底层数据结构共用27-29个对象，以MySQL为例，共用27张表

pk、vl、el、il分别对应属性，顶点，关系（边），索引的schema定义，有关详细的字段描述，请参见：以g_开头的表示业务数据用的表，以s_开头的表示hugegraph系统本身使用到的表。g/s_vi、g/s_ei只在RocksDS与Hbase中才会创建这两张表边的数据使用两张表保存，*_ie、*_oe, 分别存储入边、出边的数据，目的是为了正向和反向查询的遍历的性能针对索引，涉及到的表较多，其中范围索引针对不同的数据类型，使用不同的表进行存储，目的是为了提高查询性能。虽然增加了数据写入的复杂性，因为要管理索引的建立、更新和同步，但也提供了良好的查询性能注意：唯一性索引不可用来查询，只可对属性的值进行限定，当出现重复值时将报错2.2 数据示例2.2.1 顶点的数据

顶点ID、Label、以及properties数据。properties 使用json字符串存储，结构是Map<String,Object>，key 是属性中Key为Id的值，注意LABEL列的值是vl表中相应VertexLabel的记录ID，属性中的KEY是表中相应PropertyKey的记录ID

2.2.2 边的数据

边存储了开始节点和结束节点的ID，边的方向、结束节点的VertexLabel、sortValues值以及相应的属性 。

所以边的数据是存储了2份。

出边的数据

入边的数据

2.2.3 索引的数据

索引的存储主要使用倒排索引的结构进行存储，存储索引的值与文档ID的关系，给前缀、精确查询提供很好的性能。

下面两个分别是fi【float范围索引表】，si【二级索引表】的数据示例

2.2.4 系统表

hugegraph系统表使用s_开头，system_vertices, system_edge 的定义也是放在vertex_label 和 edge_label里面的。只是他们存储的数据不一样，系统定义的数据，其ID<0。

主要是Task、用户及及其权限的定义信息。

系统内部存在很多 异步任务。 比如新增节点，修改节点都会触发 rebuild index 这类任务。这些任务都是异步执行的，任务的状态都存在 task 节点里面。 系统在重启或异常停止恢复时候，都会去读取任务的状态决定是否需要restore

2.2.5 c【counter】表

存储的是全局ID，比如propertyKey表下一个id 是 88，IndexLabel表的下一个ID是7

3.详细的数据结构

以mysql为例，详细的建表语句详见如下： 详见更多