CN110633378A - 一种支持超大规模关系网络的图数据库构建方法 - Google Patents

Abstract

本发明公开了一种支持超大规模关系网络的图数据库构建方法，通过基于key‑value式的图元素建模，将图元素切割成多个不同的图元素存储分片后存储至不同服务器，同时将每个图元素存储分片复制多份并分别存储至不同服务器，通过Raft协议保持位于不同服务器内的同一图元素存储分片的数据同步，使得构建的图数据库可以支持的图的规模更大，且其可以完全的水平扩展，服务器数量越多支持的图规模越大，同时整个图数据库的抗故障能力强，单个服务器故障时对于服务不会造成影响。

Description

一种支持超大规模关系网络的图数据库构建方法

技术领域

本发明涉及大数据处理技术领域，尤其涉及一种支持超大规模关系网络的图数据库构建方法。

背景技术

随着大数据和人工智能的迅猛发展，超大规模关系网络逐步在社交推荐、风险控制、物联网、区块链、安全防控领域被广泛使用，而作为所有这些应用的技术基石，大规模分布式关系网络的存储和计算平台越来越受到学术界和工业界的关注。这类关系网络通常以数据结构中的图论(Graph)为理论基础，构成图的核心要素有两个：点(vertex或node，也称为节点)以及点上的属性，和边(edge，也称为关联关系)以及边上的属性。例如，点可以对应于社交网络中的个人，其属性可以是邮箱、账号等；边可以对应于社交网络中的好友关系或者转账关系，边具有方向性，边的属性可以是转账金额等。这样的技术平台通常需要满足以下几个技术要求：能存储超大规模数据，支持百亿级别节点和万亿级别的关联关系；支持垂直和水平动态扩展功能，以满足互联网式的突发性业务波动；支持在线访问，满足企业级要求的高并发和低时延要求；支持的查询语言需要能支持复杂的查询、计算和变更等操作。

目前业界主流的图数据库有两类：1、以Neo4j为代表的原生单机版图数据库引擎。由于这类数据库在使用时需要将全部图结构加载到内存中，其服务能力上限受限于单机可以提供的内存大小，在业务发生突发增长时，无法水平扩展。对于大数据类的应用来说是无法接受的。2、以JanusGraph为代表的基于通用分布式存储引擎及定制图查询引擎的方案。这类方案通常以开源TinkerPop为主要的图查询框架，以开源HBase为主要的存储框架。这类框架可以提供较好的水平扩展能力，但其主要问题在于HBase类存储模块对图结构非原生友好，在查询时通常会加载过多无关数据，导致网络吞吐量教大。同时由于HBase组件依赖于多个Master类型的节点，这类节点的故障会导致系统服务不可用。

发明内容

本发明针对现有技术中的不足，提供了支持超大规模关系网络的图数据库构建方法，具体包括：

一种支持超大规模关系网络的图数据库构建方法，包括：对关系网络数据进行图元素获取，将图元素以key-value的方式进行建模，创建节点和边信息；将图元素切割成多个不同的图元素存储分片，并分别存储至不同服务器；将每个图元素存储分片复制多份并分别存储至不同服务器，通过Raft协议保持位于不同服务器内的同一图元素存储分片的数据同步；将元数据以key-value的方式进行建模并储存至元数据存储分片，对所述元数据存储分片复制多份并分别存储至不同服务器，通过Raft协议保持位于不同服务器内的元数据存储分片的数据同步。

优选的，所述步骤对关系网络数据进行图元素获取，将图元素以key-value的方式进行建模，分别创建点和边信息，具体包括：将每条边信息以key-value方式分别建模成边输入键值组和边输出键值组；根据预设存储分片数量对各节点和边信息进行设置，分配对应存储分片。

优选的，所述步骤将图元素切割成多个不同的图元素存储分片，并分别存储至不同服务器，具体包括：判断各节点的原始身份标识的数据类型是否跟设定类型相同，若不同则将其通过预设算法转换为设定类型后作为该节点身份标识，否则直接将所述节点的原始身份标识作为其节点身份标识；将边输入键值组和该边起点的节点信息储存至同一图元素存储分片，将边输出键值组和该边终点的节点数据储存至另一图元素存储分片。

优选的，所述步骤判断各节点的原始身份标识的数据类型是否跟设定类型相同，若不同则将其通过预设算法转换为设定类型后作为该节点身份标识，否则直接将所述节点的原始身份标识作为其节点身份标识，具体包括：判断各节点的原始身份标识的数据类型是否为整型数据，若是则直接将该原始身份标识作为其节点身份标识；如果原始身份标识的数据类型非整型数据，则将该原始身份标识通过哈希散列算法转变为整型数据后作为其节点身份标识。

优选的，步骤将每个图元素存储分片复制多份并分别存储至不同服务器，通过Raft协议保持位于不同服务器内的同一图元素存储分片的数据同步，具体包括：将多个图元素存储分片复制N份并分别存入N个不同服务器，其中N份图元素存储分片中包括一主分片和N-1个从分片；将各图元素存储逻辑分片的主分片存储至不同服务器。

本发明还公开了一种对图数据库进行访问的方法，所述图数据库通过上述图数据库构建方法进行构建，具体包括：接受客户端的查询语句，将查询语句通过词法解析和语法解析生成抽象语法树，并根据抽象语法树解析出执行计划和步骤；根据执行计划创建出一个执行队列，并将各步骤作为执行单元依次放入该队列；通过解析执行计划，获取部分需要访问的图元素存储分片，并交由存储客户端提取数据；通过解析元数据管理命令，获取需访问的元数据存储分片，并交由元数据客户端提取；存储客户端将图语义的操作转换为key-value语义，元数据客户端将图元数据语义的操作转换为key-value语义。

优选的，所述步骤通过解析执行计划，获取部分需要访问的图元素存储分片，并交由存储客户端提取数据，具体包括：如果一组图元素存储分片的主分片数据提取失败，对该组图元素存储分片的其余从分片进行数据比对，将其中拥有最新信息的从分片修改设置为该组图元素存储分片的主分片；所述存储客户端向更换后的该组图元素存储分片的主分片提取数据。

本发明还公开了一种服务器，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述任一所述支持超大规模关系网络的图数据库构建方法的步骤。

本发明还公开了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现上述任一所述的支持超大规模关系网络的图数据库构建方法的步骤。

本发明通过基于key-value式的图元素建模，将图元素切割成多个不同的图元素存储分片后存储至不同服务器，同时将每个图元素存储分片复制多份并分别存储至不同服务器，通过Raft协议保持位于不同服务器内的同一图元素存储分片的数据同步，使的通过该方法构建的图数据库可以支持的图的规模更大，且其可以完全的水平扩展，服务器数量越多，支持的图规模越大，避免了传统的以Neo4j为代表的原生单机版图数据库引擎由于在使用时需要将全部图结构加载到内存中，其服务能力上限受限于单机可以提供的内存大小，在业务发生突发增长时无法水平扩的问题。同时该图数据库采用全对称的服务器节点，通过Raft协议保持位于不同服务器内的存储分片数据同步，避免了以JanusGraph为代表的基于通用分布式存储引擎及定制图查询引擎的图数据库的HBase类存储模块依赖于多个Master类型的节点，一旦出现此类Master节点的故障会导致系统服务不可用的问题，使得整个图数据库的抗故障能力强，可靠性高，单个服务器故障时对于服务不会造成影响。

本发明的附加方面和优点将在下面的描述中部分给出，部分将从下面的描述中变得明显，或通过本发明的实践了解到。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1为本发明一实施例公开的支持超大规模关系网络的图数据库构建方法的流程示意图。

图2为本发明一实施例公开的基于key-value方式的点信息建模示意图。

图3为本发明一实施例公开的边输出键值组建模示意图。

图4为本发明一实施例公开的边输入键值组建模示意图。

图5为本发明一实施例公开的图元素存储分片示意图。

图6为本发明一实施例公开的对图数据库进行访问的方法流程示意图。

图7为本发明一实施例公开的服务器结构示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例的附图，对本发明实施例的技术方案进行清楚、完整地描述。显然，所描述的实施例是本发明的一部分实施例，而不是全部的实施例。基于所描述的本发明的实施例，本领域普通技术人员在无需创造性劳动的前提下所获得的所有其他实施例，都属于本发明保护的范围。

在本发明中，除非另作定义，此处使用的技术术语或者科学术语应当为本发明所属领域内具有一般技能的人士所理解的通常意义。本发明专利申请说明书以及权利要求书中使用的“第一”、“第二”以及类似的词语并不表示任何顺序、数量或者重要性，而只是用来区分不同的组成部分。同样，“一个”或者“一”等类似词语也不表示数量限制，而是表示存在至少一个。

附图1公开了一种支持超大规模关系网络的图数据库构建方法，其具体包括：

步骤S101，对关系网络数据进行图元素获取，将图元素以key-va lue的方式进行建模，创建节点和边信息。

关系网络以数据结构中的图论为理论基础，构成图的核心要素有两个：点(vertex或node，也称为节点)以及点上的属性，边(edge，也称为关联关系)以及边上的属性。例如，点可以对应于社交网络中的个人，其属性可以是邮箱、账号等；边可以对应于社交网络中的好友关系或者转账关系，边具有方向性，边的属性可以是转账金额等。

在该实施例中我们以key-value的方式对关系网络中的数据进行建模，其中Key-value为以键值方式存储数据的方式，键通常为唯一id。本实施例首先将图元素建模为key-value的方式，具体建模如下。

附图2为本实施例公开的点、点类型和点属性建模示意图，其中点的key部分由以下4个字段组成：partID(4字节)、vertexid(8字节)、tagid(4字节)、version(8字节)。

其中，可根据预设的图元素存储分片数量对各个节点和边的属性进行设置，设置其对应的图元素存储分片。

partID部分由4个字节组成，可由vertexid取模图元素存储分片数量得到。

vertexid部分由8个字节组成，用于存储节点的唯一id。

Tagid由4个字节组成，用于标识节点的类型。

Version部分由8个字节组成，每次更新节点后会同时更新该字段，表示数据版本更新。

其中点的value部分为序列化后的属性，每个属性字段类型和长度由节点的类型Tag决定。

例如，假设图元素存储分片数量的数量为3个，其中图元素存储分片数量的目的是可以将点和边分散到不同的服务器上处理，当然在真实应用时通常会设置一个很大的存储分片数量，例如100,000。

在该例子中Key各部分信息如下：

partID字段：Vertexid 100的partID获取方式为：根据具体分片数量对100求分片数量的余数，即100mod 3＝1。同理，Vertexid 101的partID＝101mod 3＝2,Vertexid 102的partID＝102mod 3＝0,Vertexid 200的partID＝200mod 3＝2。

Vertexid字段：这个字段是由用户指定的，例如“Stoudemire”的vertexid是100。

Tagid字段：类型team的tagid为0，类型player的tagid为1.

Version字段：为写入时的时间戳，例如1562303896。

Value部分：value部分是序列化后的字符串，value内不记录每个字段的类型和长度，例如：id 100的value部分，存储的是字符串“Stoudemire”和整型36的二进制形式。

附图3和4为为本实施例公开的边和边属性建模示意图：其中将每条边信息以key-value方式分别建模成边输入键值组和边输出键值组。即将每一条逻辑上的边，分别建模为两组独立的key-value，分别称为边输出键值组out-key和边输入键值组in-key。

边的key部分由6个字段组成：partID(4字节)、srcID(8字节)、edgeType(4字节)、edgeRank(8字节)、dstId(8字节)、version(8字节)。

其中partID部分作用与点的partID部分类似，计算方法为根据srcID散列到对应的图元素存储分片partition上。SrcID用于存储该边所对应的起始节点的vertexID；可以理解为这条逻辑边的起点id。edgeType字段用于存储该边的类型；edgeRank字段用于表示该边的优先级或者时间戳等信息；dstid用于存储该边所对应的终点的vertexID；version用于存储该边的版本，每次更新这条边时版本号会增加。

其中边的value部分和点的value部分类似，存储序列化后的属性，每个属性字段类型和长度存储在元数据服务中，与edgeType字段一一对应。

在一些具体实施例中，如果为了节省存储空间，也可以只将value部分存储在边输出键值组out-key或者边输入键值组in-key中的其中一个上，而不是两者都存储，可以有效减少数据存储空间。

下面以一个“球队-球员-粉丝”的关系网络信息为例来说明将图元素以key-value方式进行构建的过程：

其中，在这个球员关系网络中有两种类型的节点：球队(Team)，它的属性是球队名Name；球员(Player)，它的属性是球员名Name和年龄Age；

有两种类型的边(或者叫关系)：

球员服役serve关系(球员->球队)：服役开始和终止的年份start_year和end_year；球员喜欢球员关系Like(球员->球队)：球员还可以喜欢其他的球队，这个喜好程度以Likeness衡量。

其中在这个网络中，所有节点(球队和球员)的唯一标识符是其id。

例如：有3个球员和1个球队的关系如下图。

有三个球员，id号100，它的tag(类型)是player，属性中姓名为“Stoudemire”，年龄为36，id号101的球员“Vicenta”年龄为0，id号102的球员“jummy”的球员年龄也为0。

有一个球队，id号为201，它的tag是team，属性为球队名字“Magic”。

Id 101的球员和id 201的球队之间有个serve关系，属性为start_year:2002,end_year:2010.用于表明球员Vicenta在球队Magic的服役开始时间为2002年，终止为2010年。

id100的球员和id101的球员之间有个喜爱(like)关系，喜好程度为90.02。

id101的球员和id102的球员之间有个喜爱关系，喜好程度为10。

步骤S102,将图元素切割成多个不同的图元素存储分片，并分别存储至不同服务器。

通过采用切边的方式，将整个图切割成多个图元素存储分片partition，在本申请中，partition是一个存储逻辑概念，通常一个partition中的数据会一起存放在同一台服务器上。当该服务器发生故障的时候，会将该存储分片partition一起迁移到另一台正常工作的服务器上。

本申请中，将每一边的起点键值组与边输出键值组out-key存储在同一个图元素存储分片上，将该边的终点键值组与边输入键值组in-key存储在另外一个图元素存储分片上。通过将起点数据和边输出数据存储在一起，将终点数据和边输入数据存储在一起，使得在访问起点时，可以同时访问起点所对应的边，可有效提高数据查询效率，避免过多的网络通信导致的查询效率低下。

具体的例如，考虑节点101，节点201，和从101指向201的边。

在物理存储上，节点101的key-value会存储在partID为1的partition上(见前面例子中partid)。节点201的key-value存储在partID为2的partition上。这意味着点101和点102通常会存储在两台不同的服务器上。101指向201的边所对应的两个key-value：out-key存储在partID为1的partition上，in-key存储在partID为2的partition上。即逻辑上两个节点101、102和一条边，被存储到了两个partition上。

因此，partID为1的partition上存储了：节点101，和节点101指向201的边的out-key。

PartID为2的partition上存储了：节点201，和节点101指向201的边的in-key。

在另一些具体实施例中，该步骤102还可包括：

判断各节点的原始身份标识的数据类型是否跟设定类型相同，若不同则将其通过预设算法转换为设定类型后作为该节点身份标识，否则直接将所述节点的原始身份标识作为其节点身份标识；

将边输入键值组和该边起点的节点信息储存至同一图元素存储分片，将边输出键值组和该边终点的节点数据储存至另一图元素存储分片。

此外，由于当前主流CPU为64位，从CPU、内存、总线、硬盘到操作系统都为64位做了特别优化。因此当vertexid是64位时其操作效率最高。然而通常来说，大多数业务系统的id并不是刚好为64位，反而通常是字符串(例如微信账号、手机号、或者MAC地址)或者长数值(例如身份证号)。如对这类长度不对齐的id的是否相等的比较操作，需要按字节一一比较，无法完全发挥64位系统的优势。所以本实施例将id设计为64位，目前现有的数据库往往是使用hash(哈希)函数把任意长度的字符串都直接映射为64位的，虽然64位系统本身可以容纳约1.8*10E19个整数，但是无论采用何种hash函数，在节点数量到达40-100亿级别数量级时，就会出现较高概率的冲突。即可能出现两个无关的原始id会被映射成了同一个vertexid，造成冲突。

因此本申请中需对vertexid进行分类型编码，以避免直接散列的哈希冲突问题。

在一些节点数量不到20亿的实施例中：对于原始id为整形类型时，保持该值不变作为vertexid；对于原始id为其他类型时，将该值哈希散列为整形，再作为vertexid。

例如原始id本身为整型数值(100，200)时，直接采用该数值作为vertexid存储在系统中。如果原始id本身不是整形数值(例如，字符串“Hubert”，浮点型3.13),先将该原始id通过MurmurHash算法生成为64位整型，再作为vertexid。(例如“Hubert”->17622465712001802105)。

在另一些节点数量到达百亿实施例中，可采用对vertexid进行分段和分类型编码相结合的方式。将原始id分别分成多部分分别进行处理，本实施例中将原始id分别分成两部分分别进行判断和处理。

本申请的编码方式如下：第一部分，第1位到第8位为用户类型编码，为枚举型，共支持256种业务类型；其中0x00意味着：第二部分未做任何变化，其值即为原始id，同时也为某个最经常使用的用户标识的基本类型(例如内部业务编码)。从0x01到0xFF为各种业务类型，例如身份证、学校、手机号、MAC地址等。这里需要特别注意的是，由于第二部分中，不论选用哪种hash函数，当数量到40亿时就会出现hash冲突，因此必须要保证每个业务种类中的个数不超过10亿。否则采用根据对于数据分布做二级分类：例如，id类型是身份证号时，可以根据省份和城市作二级分类。如果基于id是用户MAC时，可以根据手机种类、PC种类、IOT设备种类这样的设备类型作为二级分类。以用户账户划分时，可以根据账户注册时间或者地址作为二级分类。其核心思想是充分利用第一部分的256种类型，使得第二部分对应的hash结果数量不要超过10亿。

第二部分：第9位到第64位为节点id或hash值，这56bit可以容纳约7.2亿亿个整数值。

具体例如下面几个例子：

1.对于原始id就是整型的系统，例如1，某人学号10510055，可不经过hash直接存放：第1位为0，第2位到第8位为业务编码的“北京-学号”枚举型(比如0x02)，第9位到第64位开始存放整型10510055(0xA05EE7)。全部合起来vertexid就是0x0200 0000 00A0 5EE7，原始id就是A0 5E E7。

2.对于原始id是字符串的类型，例如某人身份证010801199010124412X,第1位为1，第2位到第8位是业务编码“身份证-北京”的枚举值(比如0x01),第9位到第64位存放该身份证的56bit hash值(E4 39FA A792 805B)。全部合起来就是0x81E4 39FA A792 805B。而要得到原始id，则需要从数据库中，将其value字段取出来。

通过这类分段和分类型编码相结合的方式，使得两个部分都可以通过位移操作可以直接获取，处理器运算极快；对于第一部分枚举型，可以直接存放在CPU L1缓存中(只需要256B)，存取速度也很快。若原始id为整型直接获取，无需从数据库中再查询一次value值。

步骤S103,将每个图元素存储分片复制多份并分别存储至不同服务器，通过Raft协议保持位于不同服务器内的同一图元素存储分片的数据同步。

具体的，将多个图元素存储分片复制N份并分别存入N个不同服务器，其中N份图元素存储分片中包括一主分片和N-1个从分片；将各图元素存储逻辑分片的主分片存储至不同服务器。

采用Raft协议来实现同一个存储分片Partition的多副本一致性。对于每一个Partition，Raft协议将服务器分为一个主分片leader和N-1个从分片follower，整个集群中需有大于N/2个服务器保持正常工作。

对于一个写入过程：客户端写入请求先发送至该分片的leader，由leader同步至follower。当成功写入的节点个数大于半数时，leader返回客户端成功。

对于一个读取过程，则客户端通过leader实例读取。

当出现服务器故障下线或者新服务器上线时，所有的参与者(原leader和follower)通过选取出新的leader，并通过leader指派日志复制，可以实现服务不中断的数据迁移。

例如如附图5所示，在本文的例子中，节点和边所对应的key-value在经过上一个步骤后，分别存储在Partition 1,Partition 2,Partition 3中。在本步骤中，如附图4所示，对于Partition 1来说，将其复制3份拷贝，分别放置在服务器Server 1，Server 2和Server 3中，采用Raft协议来保证这3份拷贝之间的数据是完全一致的，这三个拷贝也称为一个Raft Group。

Partition 1的leader在Server 1上，Server 2和Server 3上是两个follower。

Partition 2的leader在Server2上，两个follower在另外两个服务器上。

在写入过程中例如写入节点100的keyvalue，由前可知，这个keyvalue会写入到partition1，根据RAFT协议，发起写入的用户即客户端，会先连接server1上的主分片partition1，由它向server2和server3的partition1负责写入。当server2或server3中任一者返回成功，且server1向自身硬盘也写入成功，server1告知该用户其写入请求成功。如果3台服务器中，未达到半数以上成功，则返回客户端失败。此时由客户端决定后续操作，重试或者放弃该操作。

对于一个读取过程来说，客户端只需和leader通信。在一些实施例中，如果Server1故障，由于Partition 1的主分片leader在Server1上，向Partition1的写入和读取请求会暂时性失败，而Partition 2和Partition 3所受影响的仅为从分片follower，客户端不会感知任何失败。之后，Partition 1的两个从分片follower重新发起投票，将其中数据最新的一个Follower提升为Leader，这两个拷贝仍可实现继续对外服务。若故障机器Server1被修复并加入集群服务，其上Partition1会从另外两台机器拉取数据更新自身。若故障机器Server1修复前，再次发生Server2故障，则全集群将无法继续服务。

本实施例通过将图元素切割成多个不同的图元素存储分片并分别存储至不同服务器，同时将每个图元素存储逻辑分片复制多份按主分片和从分片分别存储至不同服务器，采用Raft协议使所有的访问请求均通过主分片Leader，在存在多个Raft Group时，对不同节点的访问压力可以较为均匀的分摊到各个Raft Group。例如对于节点100的访问会落到Server1上，对节点101的访问会落到Server2，对节点201的访问会落到Server3上。这三个请求可以实现并发执行，也保证了各服务器压力较为均匀，防止单个服务器压力过大，更好的实现并发访问。避免了目前以Neo4j为代表的原生单机版图数据库引擎的服务能力上限受限于单机可以提供的内存大小，在业务发生突发增长时无法水平扩展的问题。

步骤S104,将元数据以key-value的方式进行建模并储存至元数据存储分片，对所述元数据存储分片复制多份并分别存储至不同服务器，通过Raft协议保持位于不同服务器内的元数据存储分片的数据同步。

本实施例公开的图数据库中有几类重要的元数据：图空间space元数据、分片partition元数据、服务器Server/host元数据、点类型Tag元数据、边类型EdgeType元数据。这些元数据与图数据本身一样，需要放置在一个存储引擎中提供持久化的访问能力。本实施例将这几类元数据都建模为key-value，并建立一个独立的元数据存储引擎，再通过Raft协议以保证数据高可用性。

需要说明是，本步骤的元数据服务可以和前述步骤的图元素存储服务共享物理服务器，仅需要逻辑上隔离。在一些具体实施例中，由于元数据的容量通常远远小于前述步骤中的图元素的数据容量，通常将所有的元数据存储在一个元数据存储分片partition中。以下为元数据建模的示例：

图空间元数据建模：

Key建模：“__spaces__”+spaceId(4)；由标识符“__space__”加4字节标识空间id；

Value建模：partNum(4)+replicaFactor(4)，由该空间分片数量(4字节)和Raft副本数量(4字节)。

分片元数据建模：

Key建模："__parts__"+spaceId(4)+partId(4)，由标识符"__parts__"加4字节空间id加4字节分片id；

Value建模：[ip1][port1]…[ipN][portN],各服务器ip和端口序列化。

服务器元数据建模：

Key建模：“__hosts__“+ip(4)+port(4)，由标识符”__hosts__“加4字节ip地址加4字节端口组成；

Value建模：该字段为空。

点类型元数据建模：

Key建模：“__tags__”+spaceId(4)+tagId(4)+version(8)；

Value建模：为点属性对应的schema类型的序列化。

边类型元数据建模：

Key建模："__edges__"+spaceId(4)+edgeType(4)+version(8)；

Value建模：为边属性对应的schema类型的序列化。

在一些具体实施例中，为提高访问效率，当元数据存储引擎建立完毕后，该引擎的客户端可缓存之前所访问过的元数据，以减少网络交互。进一步的，由于元数据部分的更改需更快地为其所有客户端所感知，客户端均需要监听元数据服务，当任意元数据信息发生更改后，所有客户端需立刻更新自身缓存数据。

由于元数据服务器也是采用多数成功的Raft协议，在一个三台服务器构成的元数据服务中，只有当至少2台服务器故障才会导致元数据服务不可用。元数据服务不可用并不会导致本申请中的图数据库整体不可用，其中会导致产品故障的服务类型为：增加/修改/删除一个图空间/服务器/节点类型/边类型；但对于已有数据的查询、修改和删除并不受影响。

本实施例通过基于key-value式的图元素建模，将图元素切割成多个不同的图元素存储分片后存储至不同服务器，同时将每个图元素存储分片复制多份并分别存储至不同服务器，通过Raft协议保持位于不同服务器内的同一图元素存储分片的数据同步，使的通过方法构建的图数据库可以支持的图的规模更大，且其可以完全的水平扩展，服务器数量越多，支持的图规模越大，避免了传统的以Neo4j为代表的原生单机版图数据库引擎由于在使用时需要将全部图结构加载到内存中，其服务能力上限受限于单机可以提供的内存大小，在业务发生突发增长时无法水平扩的问题。同时该图数据库采用全对称的服务器节点，通过Raft协议保持位于不同服务器内的存储分片数据同步，避免了以JanusGraph为代表的基于通用分布式存储引擎及定制图查询引擎的图数据库的HBase类存储模块依赖于多个Master类型的节点，一旦出现此类Master节点的故障会导致系统服务不可用的问题，使得整个图数据库的抗故障能力强，可靠性高，单个服务器故障时对于服务不会造成影响。

附图6为实施例公开的一种对图数据库进行访问的方法，其中图数据库通过前述各实施例描述的图数据库构建方法进行构建的，该访问方法具体包括如下步骤：

步骤S201，接受客户端的查询语句，将查询语句通过词法解析和语法解析生成抽象语法树，并根据抽象语法树解析出执行计划和步骤。

步骤S202，根据执行计划创建出一个执行队列，并将各步骤作为执行单元依次放入该队列。

根据执行计划创建出一个执行队列，并将各步骤作为执行单元依次放入该队列。另一方面异步地将该队列中的执行单元取出并执行。当一个执行单元需要访问后端存储时，则将该执行单元重新放回队列，并取出下一个执行单元继续执行。当某异步等待中的执行单元完成时，触发一个中断并唤起一个相应的执行线程。通过这样全异步的流水线工作，可以提高图查询引擎层的并发执行效率，避免因单个请求等待后端存储而导致全流水线空闲。

步骤S203，通过解析执行计划，获取部分需要访问的图元素存储分片，并交由存储客户端提取数据。

如果一组图元素存储分片的主分片数据提取失败，对该组图元素存储分片的其余从分片进行数据比对，将其中拥有最新信息的从分片修改设置为该组图元素存储分片的主分片；

所述存储客户端向更换后的该组图元素存储分片的主分片提取数据。

具体的，例如在写入过程中，例如写入节点100的keyvalue，由前可知，这个keyvalue会写入到partition1，根据RAFT协议，发起写入的用户即客户端，会先连接server1上的partition1(主分片leader)，由它向server2和server3的partition1(从分片follower)负责写入。当server2或server3中任一者返回成功，且server1向自身硬盘也写入成功，server1告知该用户其写入请求成功。如果3台服务器中，未达到半数以上成功，则返回客户端失败。此时由客户端决定后续操作——重试或者放弃该操作。

对于一个读取过程来说，客户端只需和leader通信

如果Server1故障，由于Partition1的主分片leader在Server1上，向Partition1的写入和读取请求会暂时性失败；而Partition 2和Partition 3所受影响的仅为从分片follower，客户端不会感知任何失败。之后，Partition 1的两个follower重新发起投票，将其中数据最新的一个从分片follower提升为主分片leader，这两个拷贝仍可实现继续对外服务。若故障机器Server1被修复并加入集群服务，其上Partition1会从另外两台机器拉取数据更新自身。若故障机器Server1修复前，再次发生Server2故障，则全集群将无法继续服务。

步骤S204，通过解析元数据管理命令，获取需访问的元数据存储分片，并交由元数据客户端提取。

步骤S205，存储客户端将图语义的操作转换为key-value语义，元数据客户端将图元数据语义的操作转换为key-value语义。

本实施例通过基于key-value式的图元素建模，将图元素切割成多个不同的图元素存储分片后存储至不同服务器，同时将每个图元素存储分片复制多份并分别存储至不同服务器，通过Raft协议保持位于不同服务器内的同一图元素存储分片的数据同步，使的通过方法构建的图数据库可以支持的图的规模更大，且其可以完全的水平扩展，服务器数量越多，支持的图规模越大。同时全对称的服务器节点，通过Raft协议保持位于不同服务器内的存储分片数据同步，提高整个图数据库的抗故障能力强，单个服务器故障时对于服务不会造成影响。

附图7为实施例公开的一种服务器的示意图。所述服务器用于支持超大规模关系网络的图数据库的构建，该实施例的服务器1包括存储器12、处理器11以及存储在所述存储器中并可在所述处理器上运行的计算机程序，例如图数据库软件。所述处理器执行所述计算机程序时实现上述各支持超大规模关系网络的图数据库构件方法实施例中的步骤。

示例性的，所述计算机程序可以被分割成一个或多个模块/单元，所述一个或者多个模块/单元被存储在所述存储器中，并由所述处理器执行，以完成本发明。所述一个或多个模块/单元可以是能够完成特定功能的一系列计算机程序指令段，该指令段用于描述所述计算机程序在所述服务器中的执行过程。

所述服务器可包括，但不仅限于处理器、存储器。本领域技术人员可以理解，所述示意图仅仅是服务器的示例，并不构成对服务器设备的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件，例如所述服务器设备还可以包括输入输出设备、网络接入设备、总线等。

所称处理器可以是中央处理单元(Central Processing Unit，CPU)，还可以是其他通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application SpecificIntegrated Circuit，ASIC)、现成可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等，所述处理器是所述服务器设备的控制中心，利用各种接口和线路连接整个服务器设备的各个部分。

所述存储器可用于存储所述计算机程序和/或模块，所述处理器通过运行或执行存储在所述存储器内的计算机程序和/或模块，以及调用存储在存储器内的数据，实现所述服务器设备的各种功能。所述存储器可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序等此外，存储器可以包括高速随机存取存储器，还可以包括非易失性存储器，例如硬盘、内存、插接式硬盘，智能存储卡(SmartMedia Card,SMC)，安全数字(Secure Digital,SD)卡，闪存卡(Flash Card)、至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。

所述支持超大规模关系网络的图数据库构建方法如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明实现上述实施例方法中的全部或部分流程，也可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一计算机可读存储介质中，该计算机程序在被处理器执行时，可实现上述各个方法实施例的步骤。其中，所述计算机程序包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质可以包括：能够携带所述计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(ROM，Read-OnlyMemory)、随机存取存储器(RAM，Random Access Memory)、电载波信号、电信信号以及软件分发介质等。需要说明的是，所述计算机可读介质包含的内容可以根据司法管辖区内立法和专利实践的要求进行适当的增减，例如在某些司法管辖区，根据立法和专利实践，计算机可读介质不包括电载波信号和电信信号。

最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的范围。

总之，以上所述仅为本发明的较佳实施例，凡依本发明申请专利范围所作的均等变化与修饰，皆应属本发明专利的涵盖范围。

Claims (9)

1.一种支持超大规模关系网络的图数据库构建方法，其特征在于，包括：

对关系网络数据进行图元素获取，将图元素以key-value的方式进行建模，创建节点和边信息；

将图元素切割成多个不同的图元素存储分片，并分别存储至不同服务器；

将每个图元素存储分片复制多份并分别存储至不同服务器，通过Raft协议保持位于不同服务器内的同一图元素存储分片的数据同步；

将元数据以key-value的方式进行建模并储存至元数据存储分片，对所述元数据存储分片复制多份并分别存储至不同服务器，通过Raft协议保持位于不同服务器内的元数据存储分片的数据同步。

2.根据权利要求1所述的图数据库构建方法，其特征在于，所述步骤对关系网络数据进行图元素获取，将图元素以key-value的方式进行建模，分别创建点和边信息，具体包括：

将每条边信息以key-value方式分别建模成边输入键值组和边输出键值组；

根据预设存储分片数量对各节点和边信息进行设置，分配对应存储分片。

3.根据权利要求1-2任一所述的图数据库构建方法，其特征在于：所述步骤将图元素切割成多个不同的图元素存储分片，并分别存储至不同服务器，具体包括：

判断各节点的原始身份标识的数据类型是否跟设定类型相同，若不同则将其通过预设算法转换为设定类型后作为该节点身份标识，否则直接将所述节点的原始身份标识作为其节点身份标识；

将边输入键值组和该边起点的节点信息储存至同一图元素存储分片，将边输出键值组和该边终点的节点数据储存至另一图元素存储分片。

4.根据权利要求3所述的图数据库构建方法，其特征在于，所述步骤判断各节点的原始身份标识的数据类型是否跟设定类型相同，若不同则将其通过预设算法转换为设定类型后作为该节点身份标识，否则直接将所述节点的原始身份标识作为其节点身份标识，具体包括：

判断各节点的原始身份标识的数据类型是否为整型数据，若是则直接将该原始身份标识作为其节点身份标识；

如果原始身份标识的数据类型非整型数据，则将该原始身份标识通过哈希散列算法转变为整型数据后作为其节点身份标识。

5.根据权利要求4所述的图数据库构建方法，其特征在于：步骤将每个图元素存储分片复制多份并分别存储至不同服务器，通过Raft协议保持位于不同服务器内的同一图元素存储分片的数据同步，具体包括：

将多个图元素存储分片复制N份并分别存入N个不同服务器，其中N份图元素存储分片中包括一主分片和N-1个从分片；

将各图元素存储逻辑分片的主分片存储至不同服务器。

6.一种对图数据库进行访问的方法，所述图数据库通过权利要求1-6任一所述的图数据库构建方法进行构建，其特征在于：

接受客户端的查询语句，将查询语句通过词法解析和语法解析生成抽象语法树，并根据抽象语法树解析出执行计划和步骤；

根据执行计划创建出一个执行队列，并将各步骤作为执行单元依次放入该队列；

通过解析执行计划，获取部分需要访问的图元素存储分片，并交由存储客户端提取数据；

通过解析元数据管理命令，获取需访问的元数据存储分片，并交由元数据客户端提取；

存储客户端将图语义的操作转换为key-value语义，元数据客户端将图元数据语义的操作转换为key-value语义。

7.根据权利要求6所述的对图数据库进行访问的方法，其特征在于：所述步骤通过解析执行计划，获取部分需要访问的图元素存储分片，并交由存储客户端提取数据，具体包括：

如果一组图元素存储分片的主分片数据提取失败，对该组图元素存储分片的其余从分片进行数据比对，将其中拥有最新信息的从分片修改设置为该组图元素存储分片的主分片；

所述存储客户端向更换后的该组图元素存储分片的主分片提取数据。

8.一种服务器，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，其特征在于：所述处理器执行所述计算机程序时实现如权利要求1-5任一所述方法的步骤。

9.一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，其特征在于：所述计算机程序被处理器执行时实现如权利要求1-5任一所述方法的步骤。

Images