一种基于持久内存的图数据存储架构的制作方法

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


背景技术：

2.图数据库是指以图这种数据结构存储和查询数据的数据库。其可以有效地反映数据与数据之间的关联，而通过发掘数据之间的内在关联可以发现内在的规律或模式，从而产生或发现有价值的信息。与其他数据库不同，关系在图数据库中占首要地位。这意味着应用程序不必使用外键来推断数据连接。图数据的特性决定了其具备其他较为简单的数据结构所不具备的优势，如与关系数据库或其他nosql数据库相比，图数据库有着更高的性能、灵活性、敏捷性以及更好的可扩展性等特点。因此，近年来图数据技术在社交网络、物联网、知识图谱、推荐系统、智慧城市等场景中得到了广泛的应用，并且越来越多的应用场景发现可以使用图数据进行建模和模拟，图计算与图存储将成为大数据处理的新的手段和发展热点。
3.数学上图的概念，可以定义为一个二元组:g＝(v，e)，其中v为顶点的集合，e为边的集合，边有方向的图称为有向图，边没有方向的图称为无向图。节点表示事物的实体，如一个人，一个网络拓扑节点或者一个城市。边表示事物实体之间的关系和联系，如社交网络中，两个人可以用图中的两个节点表示，两个人相互认识则在两个节点之间有一条边；城市交通网络中，两座城市可以是图中的两个节点，两个城市之间的距离可以用一条带权重的边表示等等。当使用图数据结构对以上的场景进行建模时，就可以利用图数据结构的性质和相关算法对图结构进行分析，从而得到图中各个节点之间的相互关系及其联系的规律。
4.目前已有的图数据库主要有neo4j，orientdb，gstore、triad等。这些已有的图数据库的存储架构需要将图数据转换为文件，并最终依赖文件系统实现图数据的持久存储。


技术实现要素：

5.本发明的目的是针对上述问题，提供一种基于持久内存的图数据存储架构。
6.为达到上述目的，本发明采用了下列技术方案：
7.一种基于持久内存的图数据存储架构，包括支持图数据查询与存储并行的混合内存架构，且所述的混合内存架构包括动态随机存储和持久内存，由所述的动态随机存储提供查询内存，由所述的持久内存提供存储内存。
8.在上述的基于持久内存的图数据存储架构中，所述的动态随机存储和持久内存分别连接于图数据库系统的内存总线以构建混合内存架构。
9.在上述的基于持久内存的图数据存储架构中，所述的动态随机存储为dram存储介质。
10.在上述的基于持久内存的图数据存储架构中，所述持久内存中具有图数据库的内存布局架构，以供图数据直接部署与运行在持久内存上。
11.在上述的基于持久内存的图数据存储架构中，所述的持久内存为nvm存储介质。
12.在上述的基于持久内存的图数据存储架构中，所述持久内存中的内存布局架构如下：
13.super blocknode setedge setproperty zone
14.super block(超级块)包含了node set(节点集)，edge set(边集)、property zone(属性集)的起始地址、结束地址和分配给持久内存空间的魔数和总大小。
15.在上述的基于持久内存的图数据存储架构中，所述节点集中节点集的数据结构如下：
16.node idnext edgenode labelproperty list
17.node id是节点id，每个节点具有唯一的id；
18.next edge存储指向连接到当前节点的第一条边的引用指引；
19.node label表示节点的标签；
20.property list表示相应节点的相关属性。
21.在上述的基于持久内存的图数据存储架构中，所述边集中边集项的数据结构如下：
[0022][0023]
edge id是边id，每条边具有一个唯一的id；
[0024]
firstnode是指向此边的头节点的指针；
[0025]
secondnode是指向此边的尾节点的指针；
[0026]
first previousedge和first nextedge分别是指向连接到此firstnode的上一条边和下一条边的指针；
[0027]
second previousedge和second nextedge分别是指向连接到此secondnode的上一条边和下一条边的指针；
[0028]
edge label表示边的标签；
[0029]
property list表示相应边的相关属性。
[0030]
在上述的基于持久内存的图数据存储架构中，节点集包括图数据库的所有节点实体，节点集中的每个节点条目均在图数据库中显示一个节点；
[0031]
边集包括图数据库的所有边实体，每个边条目均在图数据库中表示一条边。
[0032]
在上述的基于持久内存的图数据存储架构中，所述节点与边的属性项采用键值对结构。
[0033]
本发明的优点在于：
[0034]
1、该架构实现了图数据库直接部署与运行在持久内存之上，该架构有别于传统的图数据库系统，使得基于该架构下实现的持久内存图数据库不再依赖底层文件系统运行，减少了软件栈的层级；
[0035]
2、采用dram与nvm混合的混合内存架构，实现在nvm上直接存储的同时有效利用dram性能优于持久内存的特性，将图数据的查询过程主要在dram中进行，实现了高效的查
询性能；
[0036]
3、基于新型的nvm内存与dram混合的方式解决“关联性”较强的图数据高效存储及查询的技术问题，有效支持知识图谱、金融大数据等典型应用场景，为数据挖掘与分析提供基于图数据的存储技术与方法。
附图说明
[0037]
图1为本发明基于持久内存的图数据库系统中基于集合的图数据存储模型图；
[0038]
图2为本发明基于持久内存的图数据库系统图数据的逻辑状态示意图；
[0039]
图3为本发明基于持久内存的图数据库系统图数据的物理状态示意图；
[0040]
图4为属性区域的动态哈希表结构；
[0041]
图5为各图数据库系统的空间载入效率对比图；
[0042]
图6为各图数据库系统的时间载入效率对比图；
[0043]
图7为各图数据库系统的创建操作性能对比图；
[0044]
图8为各图数据库系统的节点计数效率对比图；
[0045]
图9为各图数据库系统的边计数效率对比图；
[0046]
图10为各图数据库系统的读取操作性能对比图；
[0047]
图11为各图数据库系统的更新及删除操作性能对比图；
[0048]
图12为在freebase数据集下各系统的bfs性能对比图；
[0049]
图13为在ldbc数据集下各系统的bfs性能对比图。
具体实施方式
[0050]
下面结合附图和具体实施方式对本发明做进一步详细的说明。
[0051]
本实施例公开了一种基于持久内存的图数据存储架构，包括动态随机存储和持久内存的混合内存架构，且动态随机存储用于提供查询内存，持久内存用于提供存储内存以支持图数据查询与存储并行。具体为，动态随机存储和持久内存分别连接于图数据库系统的内存总线以构建混合内存架构。这里的动态随机存储采用dram存储介质，持久内存采用nvm(非易失性存储器)存储介质。并且持久内存中具有图数据库的内存布局架构，以供图数据直接部署与运行在持久内存上，不依赖于底层文件系统的独立运行。
[0052]
具体地，持久内存中的内存布局架构如下：
[0053]
super blocknode setedge setproperty zone
[0054]
super block(超级块)包含了node set(节点集)，edge set(边集)、property zone(属性集)的起始地址、结束地址和分配给持久内存空间的魔数和总大小。优选配备活跃超级块和备份超级块两个超级块的副本。
[0055]
节点集中节点项数据结构如下：
[0056]
node idnext edgenode labelproperty list
[0057]
节点集包括图数据库的所有节点实体，节点集中的每个节点条目均在图数据库中显示一个节点。node id是节点id，每个节点具有唯一的id；next edge存储指向连接到当前节点的第一条边的引用指引；node label表示节点的标签，在创建节点时初始化，它存储一个32字节的字符串格式，以显示用于从某个域筛选节点的节点类型；property list表示相
应节点的相关属性。本实施例中每个节点条目的固定大小为128字节，其中node id占8个字节，next edge占8个字节，node label占32个字节，property list占80个字节。
[0058]
边集中边集项的数据结构如下：
[0059][0060]
边集包括图数据库的所有边实体，每个边条目均在图数据库中表示一条边。每条边的数据结构包括九个字段，其中：
[0061]
edge id是边id，每条边具有一个唯一的id；
[0062]
firstnode是指向此边的头节点的指针；
[0063]
secondnode是指向此边的尾节点的指针；如果没有与此边关联的节点，则这两个字段仅指示创建此边时首先显示的节点。
[0064]
first previousedge和first nextedge分别是指向连接到此firstnode的上一条边和下一条边的指针；
[0065]
second previousedge和second nextedge分别是指向连接到此secondnode的上一条边和下一条边的指针；边的指针链接允许直接访问下一个边的实体。
[0066]
edge label表示边的标签，使用方式与节点相同；
[0067]
property list表示相应边的相关属性。
[0068]
本实施例每个边条目固定大小为192个字节，edgeid、firstnode、second node、firstnextedge、firstpreviousedge、secondnextedge、secondpreviousedge分别占8个字节，node label占32个字节，propertylist占104个字节。
[0069]
进一步地，节点与边的属性项采用键值对结构如下表所示，键的大小在这里固定为8字节，值的大小最大支持255字节：
[0070]
property keyproperty value
[0071]
property key表示键，property value表示值。
[0072]
优选地，本实施例存储架构的存储模型和图数据库优选采用本技术人自主研发的能够与nvm实现良好匹配的如下结构：
[0073]
如图1所示，将图数据抽象为一个独立的节点集和一个独立的边集，且节点集和边集之间没有交集，具体定义如下：
[0074]
s＝(n，e，ψs，λs，t)，其中：
[0075]
s表示图数据库模型的弱连接标记图；
[0076]
n表示节点集；
[0077]
e表示边集；
[0078]
ψs表示从es到ns∪ns的关联函数；
[0079]
t＝tn∪te是一组标签，tn表示节点的标签，te表示边的标签；
[0080]
λs是从tn∪te到t的标签函数；
[0081]
不同的节点具有不同的标签；
[0082]
在同一方向上连接同一个节点的两个边具有不同的标签，即ψe＝ψ
′e∩e≠e
′→
λs(e)≠λs(e
′
)。
[0083]
图数据库为具有定义一所描述模式的有向标记的图，且具有如下定义二：
[0084]
g＝(n，e，ψ，λ，v)，其中：
[0085]
g表示图数据库的标记图；
[0086]
n表示节点的集合，即节点集，e表示边的集合，即边集；
[0087]
ψ是从e到n
×
n的关联函数；
[0088]
v是一个标签集合；
[0089]
λ是一个从n∪e映射到v的标签函数；这样就存在一个从一个节点到一条边的映射函数：
[0090]
τ为对于一个在g中的节点n，和在s中的节点n
′
，n的标签存在于n
′
的标签域之中；λ(n)∈dom(λs(τ(n
′
)))，τ(n
′
)表示节点n
′
的标签；
[0091]
τ为对于每一条在图g中的，从节点n到节点n
′
的边e，以及在图s中的每一条从τ(n)到τ(n
′
)的边e来说，在g中的边e的标签存在于在s的边e的标签域中：
[0092]
ψs(τ(e))＝(τ(n)，τ(n
′
))andλ(e)∈dom((λs(τ(e)))；
[0093]
τ(n)、τ(n
′
)、τ(e)分别表示节点n的标签，节点n
′
的标签和边e的标签。
[0094]
节点集中的每个节点均具有一个唯一的节点地址和节点id，边集中的每个边均具有唯一的边地址和边id，即给定一个集合和一个元素，一对节点通过一条或多条边连接，当向图中添加节点或边时，分别向节点集和/或边集添加节点项和/或边项的方式向图中添加节点和/或边即可。该元素是否属于集合是确定的，同时集合中的任何两个元素都被认为是不同的，能够保证集合中不同元素分布在内存中不同地址，因此可以通过唯一的64位地址确定与分配一个元素。
[0095]
另外，节点集和边集中的条目随机分布，通过唯一的内存偏移量对其进行定位与寻址，即，在一个集合中，每个元素都具有相等的状态，并且元素可以无序分布。
[0096]
从前述可知，本方案基于集合的存储模型具有确定性、互异性和无序性，因此具有与持久内存非常自然且良好的匹配特性，为在持久内存上设计与实现图数据库的存储架构打下很好的基础。
[0097]
如图2和图3所示分别为一个示例的基于本技术人自主研发的图数据存储模型和本实施例的存储架构实现的图数据的逻辑状态图和物理状态图，这里只给出了节点集和边集的状态，不考虑属性区域的状态。从前述的逻辑状态图和物理状态图能够看出本方案将数据与数据之间的关联关系完整、真实地保存了下来。另外，可以看到数据在逻辑上是按顺序分布的，而在物理上是不按顺序分布的，本方案采用只能通过唯一的存储地址或偏移量来随机存取的nvm恰好迎合了前述特征，能够实现nvm与图数据库之间的良好匹配。
[0098]
进一步地，如图4所示，基于本存储架构的图数据库系统的属性区域是一个动态哈希表，它是节点属性和边属性的主要容器。动态哈希表的大小可以随着节点和边属性的实际数量动态增加或减少。动态哈希表的初始大小为16位，包含216个桶，可以增量扩展到64位。在每个桶中，有四个条目可以包含四个属性条目。每个散列项有四个元素：第一个是valid flag，它是一个标志位，用于标识当前项是否有效，如果属性项有效，则将其设置为1，否则将其设置为0。第二个是type flag，它标识属性是节点属性还是边属性，本实施例中，规定1代表节点属性0代表边属性。第三个字段是8字节的key的哈希值，key的哈希由一
个输入密钥结构为nodeid/edgeid+property key的公共哈希函数生成。第四个字段是属性值，它被格式化为支持最大长度255字节的字符串。图4演示了属性区域中动态哈希表的详细信息。
[0099]
属性区域用于在图数据库中存储节点和边的属性，它是一个动态哈希表区域，位于边集之后。由于节点和边的属性可能会发生变化，属性长度也可能会发生变化，所以本实施例采用动态扩展算法将节点或边的属性动态添加或删除到动态哈希表中，动态扩展算法的具体算法可以由本领域技术人员根据需要确定，不在此赘述。
[0100]
本存储架构基于dram和nvm混合内存体系架构，实现了图数据在nvm上的直接持久存储和在dram中的高效查询，解决“关联性”较强的图数据高效存储与查询问题，同时实现不依赖于底层文件系统，避免图数据库系统的软件栈层级复杂问题，有效支持知识图谱、金融大数据等典型应用场景。
[0101]
针对现有的图数据库系统存在的软件栈层级复杂，本方案对图数据的存储与持久化需借助底层文件系统的问题，重新设计并提出了一种基于持久内存的图存储架构，该架构基于dram和nvm混合内存体系结构，使得基于该架构下实现的持久内存图数据库不再依赖底层文件系统运行，减少了软件栈的层级，并有效利用dram和nvm各自的特性，将图数据直接持久存储在nvm上，将图数据的查询过程主要在dram中进行，避免依赖文件系统的同时实现了高效的查询性能。
[0102]
为了体现本基于本方案提供的存储架构的图数据库系统的优势，本实施例从加载操作、基本图数据操作和图遍历操作三个测度对本图数据库系统及现有技术的图数据库系统进行进行实验比对。
[0103]
本实验选择freebase、ldbc、twitter和graph500作为本实验的数据集，并以pmgd、redisgraph和neo4j作为比较图数据库系统，本系统称为eulerdb。其中，pmgd是一个当前最先进的内存持久化图数据库系统，redisgraph是第一个使用稀疏矩阵表示图中的邻接矩阵并使用线性代数查询图的可查询属性图数据库系统。neo4j是一个成熟的商业图数据库系统，它使用邻接表存储图数据，并使用无索引的邻接查询机制。选择上述图数据库系统作为比较对象图数据库系统，不仅可以评价本图数据库系统的性能，而且可以验证eulerdb提出的基于集合的图存储模型与其他基于邻接矩阵和邻接表的图存储模型之间的差异。
[0104]
实验结果如下：
[0105]
1.1加载操作性能
[0106]
由图5可以看到，在加载空间效率方面，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是最小的数据集。
[0107]
由图6可知，eulerdb在系统中实现了最快的数据加载效率。它可以在101秒内加载
freebase数据集，最终数据集大小为2027.52mb，平均加载速度可达每秒20.07mb。这种速度在内存中的一般数据传输和复制中非常常见，但对于图加载过程，由于加载过程不仅需要从原始数据集中读取图数据，还需要在内存中重构图的节点和边结构，因此将涉及大量的元数据和索引数据的构造操作，每秒20.07mb的速度意味着它可以每秒加载42711个节点和与节点相关的边，所以它一种非常快的速度。另外三个系统pmgd、redisgraph和neo4j的加载时间分别为232、245、164.08秒。eulerdb的性能优于最慢的redisgraph系统142.5％，优于neo4j系统62.4％。
[0108]
所以，本图数据库系统能够兼顾空间效率和时间效率，在空间效率和时间效率上都具有突出的表现，相较于当前的数据库系统具有明显的时空效率。
[0109]
1.2基本图数据操作性能
[0110]
基本操作包括创建操作、读取操作、更新操作和删除操作。
[0111]
1.2.1创建操作，本实验评估了insert node(插入节点)、insert edge(插入边)、insert node property(插入节点属性)、insert edge property(插入变属性)和insert node with edges(带边节点插入)五个操作的延迟。如图7，对于上面列出的五个操作，eulerdb分别实现了3.10微秒、8.25微秒、13.86微秒、13.82微秒和29.62微秒的操作延迟。显然，eulerdb在综合性能上优于其他系统，特别是插入节点延迟仅为pmgd的25.22％，插入边延迟为pmgd的40.90％。结果表明，eulerdb的直接存储结构以及基于集合的图存储模型与nvm随机可访问性特征的良好匹配点。redi sgraph的插入节点和边延迟分别为112.98微秒和282.58微秒，而neo4j的插入节点和边延迟分别为5900微秒和6840微秒，说明内存中的图数据库在基本操作性能上仍然优于传统的图数据库。对于insert node property和insert edge property延迟，eulerdb分别达到了13.86微秒和13.82微秒的延迟，这是因为eulerdb采用动态哈希表作为存储节点和边的属性，所有的属性项都存储在哈希表中，无论是节点还是边的属性，因此插入延迟都将保持不变。对于带边插入节点操作，这是一个复合操作，它插入节点以及与节点相关的边。在实际应用场景中，节点插入操作往往与边插入和属性插入相关联，本实验对相关操作进行评估发现组合操作的延迟非常接近每个操作延迟的总和。这个原因不难解释，因为组合操作是由每个操作按顺序组成的，每个操作在内存中按顺序执行，并且组合操作的延迟将呈现每个操作的累加结果。
[0112]
1.2.2读取操作，本实验测试count nodes(计数节点)、count edges(计数边)、get node(读取节点)、get edge(读取边)、get property(读取属性)和get label(读取标签)等操作，以全面测评读取相关的操作。图8和图9中显示了节点计数和边计数的性能。计数节点，计数边操作可以反映遍历图数据库的整个图的能力。与负载空间和时间效率非常不同的是，在本次评估中，eulerdb显示出明显优于其他系统的性能。对于freebase数据集，完成计数节点操作只需43.63毫秒，而neo4j则需要2425.13毫秒，比eulerdb慢两个数量级。pmgd在58.54毫秒内完成此操作，比eulerdb慢25.47％。对于其他三个数据集，ldbc、twi tter、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对于不同的数据集表现出较小的性能差异，表现出良好的性能稳定性和可扩展性。
[0113]
然后，图10显示与get相关的操作延迟，从左到右的五条数据柱分别表示get node、gete dge、get label、get nodes by property(通过属性读取节点)、get edgesby property(通过属性读取边)的操作性能。对于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获取节点或边花费更多的时间。
[0114]
1.2.3更新操作，在图中，对节点或边的更新操作基本上是更新其属性，所以本实验测试update node property(更新节点属性)和update edge property(更新边属性)的延迟。为了实验结果的一目了然，这里将更新操作和删除操作的性能放在一个图中。图11所示，前两个数据柱分别说明了更新节点属性和边属性延迟，三四两个数据柱分别说明了删除节点和删除边的延迟，五六两个数据柱分别说明书删除节点属性和删除边属性的延迟。对于eulerdb，更新节点属性和更新边属性的延迟分别为3.187微秒和3.169微秒，而pmgd的延迟分别为18.618微秒和18.546微秒。eulerdb的两个延迟分别为pmgd的17.11％和17.09％。此外，在eulerdb中，更新节点或边的属性是更新位于属性区域中的动态哈希表，而在其他系统中更新属性将涉及链接列表搜索操作，因此eulerdb的更新延迟比其他系统要低。
[0115]
1.2.4删除操作，本方案测试delete node和delete edge以及delete node property和delete edge property四个操作。结果显示在图11的后面四个数据柱中。在eulerdb中，四个操作的删除延迟分别为16.496微秒、10.725微秒、3.115微秒和3.119微秒，pmgd系统的四个数据分别为212.30微秒、1391.16微秒、12.296微秒和12.291微秒。从以上两个系统的测试结果可以看出，删除节点的延迟明显高于删除边的延迟。这是因为从图中删除节点时，它不仅会删除节点条目本身，还需要删除连接到节点的边。从图中删除边比删除节点简单，但也需要同时更新源节点条目和目标节点条目的信息。
[0116]
但eulerdb的延迟间隔远小于pmgd，说明eulerdb在删除操作上的综合性能优于pmgd。删除节点和边属性操作的延迟与所有四个系统的更新节点和边属性操作非常相似。这表明删除属性操作在所有四个系统中共享相似的处理流程。除此之外，redisgraph的删除延迟为几百个微秒，neo4j的删除延迟为几千个微秒。它与其他操作的性能显示出相同的趋势。综上所述，我们可以得出结论：eulerdb和pmgd在基本操作性能上优于redisgraph和neo4j。
[0117]
1.3图遍历操作性能
[0118]
本实验选择广泛使用的广度优先搜索(bfs)查询作为基准测试算法，来探索每个系统在图遍历方面的能力。在freebase和ldbc两个数据集下，对广度优先搜索算法从两跳到五跳的查询时间进行了评估。同时还尝试在twitter和graph500两个数据集上执行bfs遍历查询，因为这两个数据集很大，无法在24小时内得到结果，所以这里只报告两个较小数据。查询时间结果如图12和图13所示。
[0119]
对于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能够稳定有效地执行常用的图遍历算法，处理不同的数据集，同时也能提供良好稳定的性能。
[0120]
本文中所描述的具体实施例仅仅是对本发明精神作举例说明。本发明所属技术领域的技术人员可以对所描述的具体实施例做各种各样的修改或补充或采用类似的方式替代，但并不会偏离本发明的精神或者超越所附权利要求书所定义的范围。
[0121]
尽管本文较多地使用了存储架构、节点集、边集、动态随机存储、持久内存表等术语，但并不排除使用其它术语的可能性。使用这些术语仅仅是为了更方便地描述和解释本发明的本质；把它们解释成任何一种附加的限制都是与本发明精神相违背的。