CN113961754A - 一种基于持久内存的图数据库*** - Google Patents

Abstract

本发明提供了一种基于持久内存的图数据库***，包括计算层和存储层，所述的存储层包括具有图数据存储模型的图数据库和存储架构，在图数据存储模型中，图被划分为独立的节点集和独立的边集，且节点集和边集之间没有交集，节点集中的每个节点均具有一个唯一的节点地址，边集中的每个边均有唯一的边地址；所述的存储架构包括持久内存。本方案优化图数据存储模型，提出了一种新的基于集合的图数据存储模型，与传统的基于邻接矩阵和邻接链表的图数据存储模型有着本质的不同和全新的视角，通过该模型能够严格反映图数据的数学定义，有效地保存数据之间的关系，与现有的图数据存储模型相比，具有更好的时空效率。

Description

一种基于持久内存的图数据库***

技术领域

本发明属于图数据库技术领域，尤其是涉及一种基于持久内存的图数据库***。

背景技术

图数据库是指以图这种数据结构存储和查询数据的数据库。其可以有效地反映数据与数据之间的关联，而通过发掘数据之间的内在关联可以发现内在的规律或模式，从而产生或发现有价值的信息。与其他数据库不同，关系在图数据库中占首要地位。这意味着应用程序不必使用外键来推断数据连接。图数据的特性决定了其具备其他较为简单的数据结构所不具备的优势，如与关系数据库或其他NoSQL数据库相比，图数据库有着更高的性能、灵活性、敏捷性以及更好的可扩展性等特点。因此，近年来图计算与图存储逐渐成为了大数据处理的新的手段和发展热点。

数学上图的概念，可以定义为一个二元组:G＝(N，E)，其中N 为顶点的集合，E为边的集合。节点表示事物的实体，如一个人，一个网络拓扑节点或者一个城市。边表示事物实体之间的关系和联系，如社交网络中，两个人可以用图中的两个节点表示，两个人相互认识则在两个节点之间有一条边；城市交通网络中，两座城市可以是图中的两个节点，两个城市之间的距离可以用一条带权重的边表示等等。当使用图数据结构对以上的场景进行建模时，就可以利用图数据结构的性质和相关算法对图结构进行分析，从而得到图中各个节点之间的相互关系及其联系的规律。

图数据存储模型是图数据库***的基础，如图1-图3所示，目前的图数据存储模型主要有两种结构：邻接链表和邻接矩阵，邻接链表将节点存储为记录或对象，每个节点都存储与其相邻的节点列表。这种结构具有很好的空间复杂度，在图中添加节点方便，但时间复杂度较高。查询图中的节点时，需要遍历邻接列表才能找到目标节点，这会对非目标节点造成额外的遍历。另一种数据结构是邻接矩阵，它是一个大小为N×N的二维数组，其中N 是图中的顶点数，这种表示方法易于实现和查询，但在在顶点添加时会消耗大量的空间和时间复杂度。目前的图数据库***主要采用这两种数据结构来存储图数据，例如，Neo4J采用邻接链表， GraphRedis采用邻接矩阵作为基本的图存储数据结构。由上述可知，两种结构对于图数据的存储要么存在空间无效性问题，要么存在时间无效性问题，无法兼顾空间效率和时间效率。

另外，目前已有的图数据库***主要有Neo4J，OrientDB， gStore、TriAD等。这些已有的图数据库***的存储架构需要将图数据转换为文件，并最终依赖文件***实现图数据的持久存储，存在软件栈层复杂等问题。

发明内容

本发明的目的是针对上述问题，提供一种基于持久内存的图数据库***。

为达到上述目的，本发明采用了下列技术方案：

一种基于持久内存的图数据库***，包括计算层和存储层，所述的存储层包括具有图数据存储模型的图数据库和存储架构，在图数据存储模型中，图被划分为独立的节点集和独立的边集，且节点集和边集之间没有交集，节点集中的每个节点均具有一个唯一的节点地址，边集中的每个边均具有唯一的边地址，所述的存储架构包括持久内存。

在上述的基于持久内存的图数据库***中，所述的数据存储模型具有如下定义一：

S＝(N，E，Ψ_S，λ_S，T)，其中：

S表示图数据存储模型的有向弱连接标记图；

N表示节点集；

E表示边集；

Ψ_S表示从E到N∪N的关联函数；

T＝T_N∪T_E是一组标签，T_N表示节点的标签，T_E表示边的标签；

λ_S是从T_N∪T_E到T的标签函数；

不同的节点具有不同的标签；

在同一方向上连接同一个节点的两个边具有不同的标签。

在上述的基于持久内存的图数据库***中，所述的图数据库为具有所述定义一所描述模式的有向标记的图，且具有如下定义二：G＝(N，E，Ψ，λ，V)，其中：

G表示图数据库的图；

N表示节点集，E表示边集；

Ψ是从E到N×N的关联函数，表示；

V是一个标签集合；

λ是一个从N∪E映射到V的标签函数；

τ为对于一个在G中的节点n，和在S中的节点n′，n的标签存在于n′的标签域之中；λ(n)∈dom(λ_s(τ(n′)))，τ(n′)表示节点n′的标签；

τ为对于每一条在图G中的，从节点n到节点n′的边e，以及在图S中的每一条从τ(n)到τ(n′)的边e来说，在G中的边e 的标签存在于在S的边e的标签域中：

Ψ_s(τ(e))＝(τ(n)，τ(n′))andλ(e)∈dom((λ_s(τ(e)))；

τ(n)、τ(n′)、τ(e)分别表示节点n的标签，节点n′的标签和边 e的标签。

在上述的基于持久内存的图数据库***中，所述的存储架构为包括动态随机存储和持久内存的混合内存架构，且所述的动态随机存储用于提供查询内存，所述的持久内存用于提供存储内存。

在上述的基于持久内存的图数据库***中，所述持久内存中具有图数据库的内存布局架构，以供图数据库直接部署与运行在持久内存上。

在上述的基于持久内存的图数据库***中，所述持久内存中的内存布局架构如下：

Super Block

Node Set

Edge Set

Property Zone

Super Block(超级块)包含了Node Set(节点集)，Edge Set (边集)、PropertyZone(属性集)的起始地址、结束地址和分配给持久内存空间的魔数和总大小。

在上述的基于持久内存的图数据库***中，所述节点集中节点项的数据结构如下：

Node ID

Next Edge

Node Label

Property List

Node ID是节点ID，每个节点具有唯一的ID；

Next Edge存储指向连接到当前节点的第一条边的引用指引；

Node Label表示节点的标签；

Property List表示相应节点的相关属性；

所述边集中边集项的数据结构如下：

Edge ID是边ID，每条边具有一个唯一的ID；

FirstNode是指向此边的头节点的指针；

SecondNode是指向此边的尾节点的指针；

First PreviousEdge和First NextEdge分别是指向连接到此FirstNode的上一条边和下一条边的指针；

Second PreviousEdge和Second NextEdge分别是指向连接到此SecondNode的上一条边和下一条边的指针；

edge Label表示边的标签；

Property List表示相应边的相关属性；

且节点集包括图数据库的所有节点实体，节点集中的每个节点条目都在图数据库中显示一个节点；

边集包括图数据库的所有边实体，每个边条目都在图数据库中表示一条边。

在上述的基于持久内存的图数据库***中，本***包括活跃超级块和备份超级块两个超级块的副本。

在上述的基于持久内存的图数据库***中，所述的计算层包括基于锁机制的事务管理模块以保证操作的一致性。

在上述的基于持久内存的图数据库***中，所述的事务管理模块包括锁构建单元和锁协议单元；

锁构建单元，用于为图数据构建字段级的锁和锁基类；

锁协议单元，采用包括膨胀阶段和收缩阶段两阶段锁协议，当事务进入膨胀阶段时，在读取对象之前获取对象的读锁，在修改对象之前获取对象的写锁；当事务进入收缩阶段时，停止锁的获取。

本发明的优点在于：

1、优化图数据存储模型，提出了一种新的基于集合的图数据存储模型，与传统的基于邻接矩阵和邻接链表的图数据存储模型有着本质的不同和全新的视角，通过该模型能够严格反映图数据的数学定义，有效地保存数据之间的关系，与现有的图数据存储模型相比，具有更好的时空效率；

3、优化图数据直接存储架构，提出了一种基于DRAM(动态随机存取存储器)和NVM(非易失性存储内存)混合存储结构的图数据直接存储架构，该架构实现了图数据库直接部署与运行在持久内存之上，实现了图数据在NVM上的直接存储和在DRAM中的高效查询，该架构有别于传统的图数据库***，使得基于该架构下实现的持久内存图数据库不再依赖底层文件***运行，并有效利用DRAM性能优于持久内存的特性，将图数据的查询过程主要在DRAM中进行，实现了高效的查询性能；

3、基于本是方案提供的图数据存储模型、图数据直接存储架构，实现了不依赖于底层文件***的图数据库***，有效减少软件栈的层级，提升***的时空效率，提高图数据***的性能。

附图说明

图1为原生图；

图2为邻接矩阵结构的模型图；

图3为邻接链表结构的模型图；

图4为本发明基于持久内存的图数据库***中基于集合的图数据存储模型图；

图5为属性区域的动态哈希表结构；

图6为本发明基于持久内存的图数据库***图数据的逻辑状态示意图；

图7为本发明基于持久内存的图数据库***图数据的物理状态示意图；

图8为各图数据库***的空间载入效率对比图；

图9为各图数据库***的时间载入效率对比图；

图10为各图数据库***的创建操作性能对比图；

图11为各图数据库***的节点计数效率对比图；

图12为各图数据库***的边计数效率对比图；

图13为各图数据库***的读取操作性能对比图；

图14为各图数据库***的更新及删除操作性能对比图；

图15为在Freebase数据集下各***的BFS性能对比图；

图16为在LDBC数据集下各***的BFS性能对比图。

具体实施方式

下面结合附图和具体实施方式对本发明做进一步详细的说明。

本实施例公开了一种基于持久内存的图数据库***，包括接口层、计算层和存储层等。其中存储层包括具有图数据存储模型的图数据库和存储架构。

如图4所示，本方案图数据存储模型重新思考了图G＝(N，E) 的数学定义，将图数据抽象为一个独立的节点集和一个独立的边集，且节点集和边集之间没有交集，具体定义如下：

S＝(N，E，Ψ_S，λ_S，T)，其中：

S表示图数据存储模型的有向弱连接标记图；

N表示节点集；

E表示边集；

Ψ_S表示从E_S到N_S∪N_S的关联函数；

T＝T_N∪T_E是一组标签，T_N表示节点的标签，T_E表示边的标签；

λ_S是从T_N∪T_E到T的标签函数；

不同的节点具有不同的标签；

在同一方向上连接同一个节点的两个边具有不同的标签，即Ψ_e＝Ψ′_e∩e≠e′→λ_s(e)≠λ_s(e′)。

图数据库为具有定义一所描述模式的有向标记的图，且具有如下定义二：

G＝(N，E，Ψ，λ，V)，其中：

G表示图数据库的图；

N表示节点的集合，即节点集，E表示边的集合，即边集；

Ψ是从E到N×N的关联函数；

V是一个标签集合；

λ是一个从N∪E映射到V的标签函数；这样就存在一个从一个节点到一条边的映射函数：

τ为对于一个在G中的节点n，和在S中的节点n′，n的标签存在于n′的标签域之中；λ(n)∈dom(λ_s(τ(n′)))，τ(n′)表示节点n′的标签；

τ为对于每一条在图G中的，从节点n到节点n′的边e，以及在图S中的每一条从τ(n)到τ(n′)的边e来说，在G中的边e 的标签存在于在S的边e的标签域中：

Ψ_s(τ(e))＝(τ(n)，τ(n′))andλ(e)∈dom((λ_s(τ(e)))；

τ(n)、τ(n′)、τ(e)分别表示节点n的标签，节点n′的标签和边 e的标签。

节点集中的每个节点均具有一个唯一的节点地址和节点ID，边集中的每个边均具有唯一的边地址和边ID，即给定一个集合和一个元素，一对节点通过一条或多条边连接，当向图中添加节点或边时，分别向节点集和/或边集添加节点项和/或边项的方式向图中添加节点和/或边即可。该元素是否属于集合是确定的，同时集合中的任何两个元素都被认为是不同的，能够保证集合中不同元素分布在内存中不同地址，因此可以通过唯一的64位地址确定与分配一个元素。

另外，节点集和边集中的条目随机分布，通过唯一的内存偏移量对其进行定位与寻址，即，在一个集合中，每个元素都具有相等的状态，并且元素可以无序分布。

从前述可知，本方案基于集合的存储模型具有确定性、互异性和无序性，因此具有与持久内存非常自然且良好的匹配特性。

本方案提供的基于集合的图数据存储模型能够严格地反应图数据的数学定义，有效地保存图数据之间的关系，与现有图数据存储模型相比，具有更好地时间和空间效率。并能够实现与持久内存介质特性良好的匹配性，为在持久内存上设计与实现图数据库打下基础。

进一步地，本实施例中的存储架构为包括动态随机存储和持久内存的混合内存架构，且动态随机存储用于提供查询内存，持久内存用于提供存储内存。具体为，动态随机存储和持久内存分别连接于图数据库***的内存总线以构建混合内存架构。这里的动态随机存储采用DRAM存储介质，持久内存采用NVM(非易失性存储器)存储介质。并且持久内存中具有图数据库的内存布局架构，以供图数据直接部署与运行在持久内存上，不依赖于底层文件***的独立运行。

具体地，持久内存中的内存布局架构如下：

Super Block

Node Set

Edge Set

Property Zone

Super Block(超级块)包含了Node Set(节点集)，Edge Set (边集)、PropertyZone(属性集)的起始地址、结束地址和分配给持久内存空间的魔数和总大小。本***包括活跃超级块和备份超级块两个超级块的副本。

节点集中节点项数据结构如下：

Node ID

Next Edge

Node Label

Property List

节点集包括图数据库的所有节点实体，节点集中的每个节点条目均在图数据库中显示一个节点。Node ID是节点ID，每个节点具有唯一的ID；Next Edge存储指向连接到当前节点的第一条边的引用指引；Node Label表示节点的标签，在创建节点时初始化，它存储一个32字节的字符串格式，以显示用于从某个域筛选节点的节点类型；Property List表示相应节点的相关属性。本实施例中每个节点条目的固定大小为128字节，其中Node ID 占8个字节，Next Edge占8个字节，Node Label占32个字节， Property List占80个字节。

边集中边集项的数据结构如下：

边集包括图数据库的所有边实体，每个边条目均在图数据库中表示一条边。每条边的数据结构包括九个字段，其中：

Edge ID是边ID，每条边具有一个唯一的ID；

FirstNode是指向此边的头节点的指针；

SecondNode是指向此边的尾节点的指针；如果没有与此边关联的节点，则这两个字段仅指示创建此边时首先显示的节点。

First PreviousEdge和First NextEdge分别是指向连接到此FirstNode的上一条边和下一条边的指针；

Second PreviousEdge和Second NextEdge分别是指向连接到此SecondNode的上一条边和下一条边的指针；边的指针链接允许直接访问下一个边的实体。

Edge Label表示边的标签，使用方式与节点相同；

Property List表示相应边的相关属性。

本实施例每个边条目固定大小为192个字节，EdgeID、 FirstNode、Second Node、FirstNextEdge、FirstPreviousEdge、 SecondNextEdge、SecondPreviousEdge分别占8个字节，Node Label占32个字节，PropertyList占104个字节。

进一步地，节点与边的属性项采用键值对结构如下表所示，键的大小在这里固定为8字节，值的大小最大支持255字节：

Property Key

Property Value

Property Key表示键，Property Value表示值。

如图5所示，本实施例的图数据库***的属性区域是一个动态哈希表，它是节点属性和边属性的主要容器。动态哈希表的大小可以随着节点和边属性的实际数量动态增加或减少。动态哈希表的初始大小为16位，包含216个桶，可以增量扩展到64位。在每个桶中，有四个条目可以包含四个属性条目。每个散列项有四个元素：第一个是Valid flag，它是一个标志位，用于标识当前项是否有效，如果属性项有效，则将其设置为1，否则将其设置为0。第二个是Type flag，它标识属性是节点属性还是边属性，本实施例中，规定1代表节点属性0代表边属性。第三个字段是8字节的key的哈希值，key的哈希由一个输入密钥结构为nodeID/EdgeID+property key的公共哈希函数生成。第四个字段是属性值，它被格式化为支持最大长度255字节的字符串。图5 演示了属性区域中动态哈希表的详细信息。

属性区域用于在图数据库中存储节点和边的属性，它是一个动态哈希表区域，位于边集之后。由于节点和边的属性可能会发生变化，属性长度也可能会发生变化，所以本实施例采用动态扩展算法将节点或边的属性动态添加或删除到动态哈希表中，动态扩展算法的具体算法可以由本领域技术人员根据需要确定，不在此赘述。

如图6和图7所示分别为一个示例的图数据的逻辑状态图和物理状态图，这里只给出了节点集和边集的状态，不考虑属性区域的状态。从前述的逻辑状态图和物理状态图能够看出本方案将数据与数据之间的关联关系完整、真实地保存了下来，解决了目前图数据存储模型存在的割裂了图数据之间的关联导致查询效率和空间效率不高的问题。另外，可以看到数据在逻辑上是按顺序分布的，而在物理上是不按顺序分布的，本方案采用只能通过唯一的存储地址或偏移量来随机存取的NVM恰好迎合了前述特征，能够实现存储介质与图数据库之间的良好匹配。

本存储架构基于DRAM和NVM混合内存体系架构，实现了图数据在NVM上的直接持久存储和在DRAM中的高效查询，解决“关联性”较强的图数据高效存储与查询问题，同时实现不依赖于底层文件***，避免图数据库***的软件栈层级复杂问题，有效支持知识图谱、金融大数据等典型应用场景。

进一步地，本方案的计算层包括基于锁机制的事务管理模块以保证操作的一致性，以避免事务之间的冲突，使本***一次能够支持多个事务，不同事务可以同时更新一个数据。具体地，事务管理模块包括锁构建单元和锁协议单元；锁构建单元用于为图数据构建字段级的锁以及用于处理共享字段的锁基类。本方案中的锁是字段级实现的，一个字段的锁不易导致另一个字段的冲突，例如，如果节点中的NextEdge锁由一个事务持有，则其他事务可以在不违反任何规则的情况下同时获取PropertyList上的锁。

此外，由于节点和边都有公共和相同的字段，因此本方案还提供了用于处理共享字段的锁基类以提高效率及节省空间。

锁协议单元采用包括膨胀阶段和收缩阶段两阶段锁协议，当事务进入膨胀阶段时，在读取对象之前获取对象的读锁，在修改对象之前获取对象的写锁；当事务进入收缩阶段时，停止锁的获取。

优选地，为了保护图数据库不受死锁的影响，本方案采用等待图的方式来检测死锁。图中的每个节点表示一个事务，每个边表示两个事务之间的“等待”关系。如果一个事务Ti正在等待另一个事务所持有的锁Tj，则存在一个从Ti到Tj的边点。当等待图生成一个循环时，可能会发生死锁，本方案通过中止请求可能导致死锁的事务,即前述示例中，通过中止事务Ti或Tj来防止死锁，不会错过对死锁的预测，也能够避免不必要的中止。

为了体现本基于持久内存的图数据库***的优势，本实施例从加载操作、基本图数据操作和图遍历操作三个测度对本图数据库***及现有技术的图数据库***进行进行实验比对。

本实验选择Freebase、LDBC、Twitter和Graph500作为本实验的数据集，并以PMGD、RedisGraph和Neo4J作为比较图数据库***，本***称为EulerDB。其中，PMGD是一个当前最先进的内存持久化图数据库***，RedisGraph是第一个使用稀疏矩阵表示图中的邻接矩阵并使用线性代数查询图的可查询属性图数据库***。Neo4J是一个成熟的商业图数据库***，它使用邻接表存储图数据，并使用无索引的邻接查询机制。选择上述图数据库***作为比较对象图数据库***，不仅可以评价本图数据库***的性能，而且可以验证EulerDB提出的基于集合的图存储模型与其他基于邻接矩阵和邻接表的图存储模型之间的差异。

实验结果如下：

1.1加载操作性能

由图8可以看到，在加载空间效率方面，PMGD和EulerDB是最好的两个***，PMGD甚至优于EulerDB。这是因为EulerDB和 PMGD都是持久内存图数据库。它们的图数据结构都是根据持久内存的特点重新设计的。然而，EulerDB的数据结构比PMGD存储了更多的索引信息和属性信息，EulerDB的每个节点条目和边条目都比PMGD稍大，因此当加载相同的数据集时，EulerDB比 PMGD占用的空间稍大。特别是对于LDBC数据集，EulerDB加载后的空间占用为378MB，PMGD的数量为209MB。但是对于一个容易达到几百兆字节的持久内存容量来说，几百兆字节的差异可以忽略不计。对于其他***，RedisGraph和Neo4J也达到了与 EulerDB和PMGD相似的空间效率，可见RedisGraph中邻接矩阵的图存储结构与Neo4J中无索引邻接列表结构的存储空间效率相似Twitter是加载过程最大的数据集，LDBC是最小的数据集。

由图9可知，EulerDB在***中实现了最快的数据加载效率。它可以在101秒内加载Freebase数据集，最终数据集大小为 2027.52MB，平均加载速度可达每秒20.07MB。这种速度在内存中的一般数据传输和复制中非常常见，但对于图加载过程，由于加载过程不仅需要从原始数据集中读取图数据，还需要在内存中重构图的节点和边结构，因此将涉及大量的元数据和索引数据的构造操作，每秒20.07MB的速度意味着它可以每秒加载42711 个节点和与节点相关的边，所以它一种非常快的速度。另外三个***PMGD、RedisGraph和Neo4J的加载时间分别为232、245、 164.08秒。EulerDB的性能优于最慢的RedisGraph***142.5％，优于Neo4J***62.4％。

所以，本图数据库***能够兼顾空间效率和时间效率，在空间效率和时间效率上都具有突出的表现，相较于当前的数据库***具有明显的时空效率。

1.2基本图数据操作性能

基本操作包括创建操作、读取操作、更新操作和删除操作。

1.2.1创建操作，本实验评估了insert node(***节点)、 insert edge(***边)、insert node property(***节点属性)、 insert edge property(***变属性)和insertnode with edges (带边节点***)五个操作的延迟。如图10，对于上面列出的五个操作，EulerDB分别实现了3.10微秒、8.25微秒、13.86微秒、13.82微秒和29.62微秒的操作延迟。显然，EulerDB在综合性能上优于其他***，特别是***节点延迟仅为PMGD的 25.22％，***边延迟为PMGD的40.90％。结果表明，EulerDB的直接存储结构以及基于集合的图存储模型与NVM随机可访问性特征的良好匹配点。RedisGraph的***节点和边延迟分别为 112.98微秒和282.58微秒，而Neo4J的***节点和边延迟分别为5900微秒和6840微秒，说明内存中的图数据库在基本操作性能上仍然优于传统的图数据库。对于insert node property和insert edge property延迟，EulerDB分别达到了13.86微秒和 13.82微秒的延迟，这是因为EulerDB采用动态哈希表作为存储节点和边的属性，所有的属性项都存储在哈希表中，无论是节点还是边的属性，因此***延迟都将保持不变。对于带边***节点操作，这是一个复合操作，它***节点以及与节点相关的边。在实际应用场景中，节点***操作往往与边***和属性***相关联，本实验对相关操作进行评估发现组合操作的延迟非常接近每个操作延迟的总和。这个原因不难解释，因为组合操作是由每个操作按顺序组成的，每个操作在内存中按顺序执行，并且组合操作的延迟将呈现每个操作的累加结果。

1.2.2读取操作，本实验测试count nodes(计数节点)、count edges(计数边)、getnode(读取节点)、get edge(读取边)、get property(读取属性)和get label(读取标签)等操作，以全面测评读取相关的操作。图11和图12中显示了节点计数和边计数的性能。计数节点，计数边操作可以反映遍历图数据库的整个图的能力。与负载空间和时间效率非常不同的是，在本次评估中， EulerDB显示出明显优于其他***的性能。对于Freebase数据集，完成计数节点操作只需43.63毫秒，而Neo4J则需要2425.13毫秒，比EulerDB慢两个数量级。PMGD在58.54毫秒内完成此操作，比EulerDB慢25.47％。对于其他三个数据集，LDBC、Twitter、 Graph500、EulerDB分别在40.38毫秒、212.42毫秒和32.98 毫秒内完成计数节点操作。值得注意的是，EulerDB对于 Graph500(一个相对较大的数据集)具有极好的计数节点/边性能。这可以归因于Graph500是一个综合数据集，它具有简单的节点和边结构，节点和边没有任何属性。此数据集的内容由许多具有两个节点ID的二进制对组成。如果两个节点ID组合在一对中，则表示两个节点之间直接有一条边。因此，可以通过将数据集的大小除以二进制对的长度来获得数据集中的节点总数。由于 EulerDB分别存储节点区域和边区域，节点集和边集都有明确的存储起始地址和结束地址，因此计算节点集或边集中的节点数非常方便。对于边计数操作，它显示出与节点计数操作相似的性能趋势。对于Freebase、LDBC、Twitter和Graph500四种不同的数据集，EulerDB分别实现了56.78毫秒、41.63毫秒、1894.58 毫秒和669.35毫秒的查询时间。其性能明显优于第二好的PMGD ***，比RedisGraph和Neo4J高出两个数量级，同时EulerDB对于不同的数据集表现出较小的性能差异，表现出良好的性能稳定性和可扩展性。

然后，图13显示与get相关的操作延迟，从左到右的五条数据柱分别表示getnode、gete dge、get label、get nodes by property(通过属性读取节点)、get edgesbyproperty(通过属性读取边)的操作性能。对于EulerDB，get node、gete edge、 get label、get nodes by property、get edges by property 操作的延迟分别为0.226微秒、0.335微秒、2.03微秒、8.67微秒和27.86微秒，而PMGD的延迟分别为1.879微秒、1.979微秒、 6.01微秒、16.98微秒和43.37微秒。EulerDB的get节点延迟和get边延迟分别为12.03％和16.93％。与RedisGraph和Neo4J 相比，EulerDB的延迟比其他两个***低一到两个数量级。对于 get label延迟，这四个***都将标签信息存储在节点条目或边条目中。因此，获取节点标签或边标签与获取节点和边非常相似。以EulerDB为例，要获取一个节点标签，只需要先获取节点条目，然后获取节点条目中的标签字段，因此获取标签的延迟与获取节点和边的延迟非常接近。特别是对于获取标签操作，EulerDB可以达到2.03微秒的延迟，PMGD可以达到6.01微秒的延迟。对于按属性获取节点和按属性获取边的操作，我们注意到它比获取节点和获取边的操作要高得多。因为这两个操作不会返回一个节点或一条边，而是返回具有相同属性的所有节点和边。因此，此操作需要遍历以属性值作为过滤器的图才能得到结果，这将比通过单个节点ID或边ID获取节点或边花费更多的时间。

1.2.3更新操作，在图中，对节点或边的更新操作基本上是更新其属性，所以本实验测试Update node property(更新节点属性)和Update edge property(更新边属性)的延迟。为了实验结果的一目了然，这里将更新操作和删除操作的性能放在一个图中。图14所示，前两个数据柱分别说明了更新节点属性和边属性延迟，三四两个数据柱分别说明了删除节点和删除边的延迟，五六两个数据柱分别说明书删除节点属性和删除边属性的延迟。对于EulerDB，更新节点属性和更新边属性的延迟分别为3.187 微秒和3.169微秒，而PMGD的延迟分别为18.618微秒和18.546 微秒。EulerDB的两个延迟分别为PMGD的17.11％和17.09％。此外，在EulerDB中，更新节点或边的属性是更新位于属性区域中的动态哈希表，而在其他***中更新属性将涉及链接列表搜索操作，因此EulerDB的更新延迟比其他***要低。

1.2.4删除操作，本方案测试delete node和delete edge 以及delete nodeproperty和delete edge property四个操作。结果显示在图14的后面四个数据柱中。在EulerDB中，四个操作的删除延迟分别为16.496微秒、10.725微秒、3.115微秒和3.119微秒，PMGD***的四个数据分别为212.30微秒、1391.16 微秒、12.296微秒和12.291微秒。从以上两个***的测试结果可以看出，删除节点的延迟明显高于删除边的延迟。这是因为从图中删除节点时，它不仅会删除节点条目本身，还需要删除连接到节点的边。从图中删除边比删除节点简单，但也需要同时更新源节点条目和目标节点条目的信息。

但EulerDB的延迟间隔远小于PMGD，说明EulerDB在删除操作上的综合性能优于PMGD。删除节点和边属性操作的延迟与所有四个***的更新节点和边属性操作非常相似。这表明删除属性操作在所有四个***中共享相似的处理流程。除此之外，RedisGraph 的删除延迟为几百个微秒，Neo4J的删除延迟为几千个微秒。它与其他操作的性能显示出相同的趋势。综上所述，我们可以得出结论：EulerDB和PMGD在基本操作性能上优于RedisGraph和Neo4J。

1.3图遍历操作性能

本实验选择广泛使用的广度优先搜索(BFS)查询作为基准测试算法，来探索每个***在图遍历方面的能力。在Freebase 和LDBC两个数据集下，对广度优先搜索算法从两跳到五跳的查询时间进行了评估。同时还尝试在Twitter和Graph500两个数据集上执行BFS遍历查询，因为这两个数据集很大，无法在24小时内得到结果，所以这里只报告两个较小数据。查询时间结果如图16所示。

对于Freebase数据集，EulerDB从2跳到5跳的BFS查询时间分别为0.12毫秒、0.57毫秒、10.68毫秒和120.61毫秒。对于LDBC数据集，EulerDB从2跳到5跳的查询时间分别为0.10 毫秒、0.23毫秒、9.846毫秒和221.74毫秒。对于PMGD***， Freebase数据集的查询时间分别为2.778毫秒、2.953毫秒、 128.73毫秒和513.5毫秒，LDBC数据集的查询时间分别为3.345 毫秒、4.522毫秒、146.85毫秒和985.38毫秒。在这四个***中，EulerDB的性能最好，从2跳到3跳，查询时间增加了4倍左右，而从3跳到5跳，查询时间增加了10-20倍左右，两个数据集保持了相同的性能趋势。这说明BFS是一种具有指数计算复杂度的图遍历算法。随着查询深度的增加，查询时间会迅速增加。 BFS的查询时间能否控制在合理的范围内，且查询时间不会随着查询深度的增加而显著增加，是衡量图数据库性能的重要指标。通过BFS查询的实验结果，验证了EulerDB能够稳定有效地执行常用的图遍历算法，处理不同的数据集，同时也能提供良好稳定的性能。

本文中所描述的具体实施例仅仅是对本发明精神作举例说明。本发明所属技术领域的技术人员可以对所描述的具体实施例做各种各样的修改或补充或采用类似的方式替代，但并不会偏离本发明的精神或者超越所附权利要求书所定义的范围。

尽管本文较多地使用了计算层、存储层、图数据存储模型、图数据库、存储架构、节点集、边集、动态随机存储、持久内存等术语，但并不排除使用其它术语的可能性。使用这些术语仅仅是为了更方便地描述和解释本发明的本质；把它们解释成任何一种附加的限制都是与本发明精神相违背的。

Claims (10)

1.一种基于持久内存的图数据库***，包括计算层和存储层，所述的存储层包括具有图数据存储模型的图数据库和存储架构，其特征在于，在图数据存储模型中，图被划分为独立的节点集和独立的边集，且节点集和边集之间没有交集，节点集中的每个节点均具有一个唯一的节点地址，边集中的每个边均具有唯一的边地址，所述的存储架构包括持久内存。

2.根据权利要求1所述的基于持久内存的图数据库***，其特征在于，所述的图数据存储模型具有如下定义一：

S＝(N，E，Ψ_S，λ_S，T)，其中：

S表示图数据存储模型的有向弱连接标记图；

N表示节点集；

E表示边集；

Ψ_S表示从E到N∪N的关联函数；

T＝T_N∪T_E是一组标签，T_N表示节点的标签，T_E表示边的标签；

λ_S是从T_N∪T_E到T的标签函数；

不同的节点具有不同的标签；

在同一方向上连接同一个节点的两个边具有不同的标签。

3.根据权利要求2所述的基于持久内存的图数据库***，其特征在于，所述的图数据库为具有所述定义一所描述模式的有向标记的图，且具有如下定义二：

G＝(N，E，Ψ，λ，V)，其中：

G表示图数据库的图；

N表示节点集，E表示边集；

Ψ是从E到N×N的关联函数；

V是一个标签集合；

λ是一个从N∪E映射到V的标签函数；

τ为对于一个在G中的节点n，和在S中的节点n′，n的标签存在于n′的标签域之中；λ(n)∈dom(λ_s(τ(n′)))，τ(n′)表示节点n′的标签；

τ为对于每一条在图G中的，从节点n到节点n′的边e，以及在图S中的每一条从τ(n)到τ(n′)的边e来说，在G中的边e的标签存在于在S的边e的标签域中：

Ψ_s(τ(e))＝(τ(n)，τ(n′))andλ(e)∈dom((λ_s(τ(e)))；

τ(n)、τ(n′)、τ(e)分别表示节点n的标签，节点n′的标签和边e的标签。

4.根据权利要求1所述的基于持久内存的图数据库***，其特征在于，所述的存储架构为包括动态随机存储和持久内存的混合内存架构，且所述的动态随机存储用于提供查询内存，所述的持久内存用于提供存储内存。

5.根据权利要求4所述的基于持久内存的图数据库***，其特征在于，所述持久内存中具有图数据库的内存布局架构，以供图数据库直接部署与运行在持久内存上。

6.根据权利要求5所述的基于持久内存的图数据库***，其特征在于，所述持久内存中的内存布局架构如下：

Super Block Node Set Edge Set Property Zone

Super Block(超级块)包含了Node Set(节点集)，Fdge Set(边集)、Property Zone(属性集)的起始地址、结束地址和分配给持久内存空间的魔数和总大小。

7.根据权利要求6所述的基于持久内存的图数据库***，其特征在于，所述节点集中节点项的数据结构如下：

Node ID Next Edge Node Label Property List

Node ID是节点ID，每个节点具有唯一的ID；

Next Edge存储指向连接到当前节点的第一条边的引用指引；

Node Label表示节点的标签；

Property List表示相应节点的相关属性；

所述边集中边集项的数据结构如下：

Edge ID是边ID，每条边具有一个唯一的ID；

FirstNode是指向此边的头节点的指针；

SecondNode是指向此边的尾节点的指针；

First PreviousEdge和First NextEdge分别是指向连接到此FirstNode的上一条边和下一条边的指针；

Second PreviousEdge和Second NextEdge分别是指向连接到此SecondNode的上一条边和下一条边的指针；

edge Label表示边的标签；

Property List表示相应边的相关属性；

且节点集包括图数据库的所有节点实体，节点集中的每个节点条目都在图数据库中显示一个节点；

边集包括图数据库的所有边实体，每个边条目都在图数据库中表示一条边。

8.根据权利要求7所述的基于持久内存的图数据库***，其特征在于，本***包括活跃超级块和备份超级块两个超级块的副本。

9.根据权利要求1-8任意一项所述的基于持久内存的图数据库***，其特征在于，所述的计算层包括基于锁机制的事务管理模块以保证操作的一致性。

10.根据权利要求9所述的基于持久内存的图数据库***，其特征在于，所述的事务管理模块包括锁构建单元和锁协议单元；

锁构建单元，用于为图数据构建字段级的锁和锁基类；

锁协议单元，采用包括膨胀阶段和收缩阶段两阶段锁协议，当事务进入膨胀阶段时，在读取对象之前获取对象的读锁，在修改对象之前获取对象的写锁；当事务进入收缩阶段时，停止锁的获取。

Images