CN116204683A - 动态图数据存储系统、读取系统及对应方法 - Google Patents

Abstract

本申请实施例公开了一种动态图数据存储系统、读取系统及对应方法。应用于计算机技术领域，上述系统设置于存储设备的执行层，其中数据获取组件从图数据中获取待处理的顶点数据和边数据；顶点存储组件利用所述顶点数据对顶点块区域进行顶点块的更新，利用对顶点块区域的更新结果更新顶点块地址数组；其中所述顶点块区域包含各顶点的顶点块，所述顶点块地址数组用以存储顶点对应的顶点块地址信息；边存储组件确定段空间，所述段空间包括边区域；利用所述边数据对所述边数据的起始顶点对应的边区域进行更新。本申请能够有效提高动态图数据的存储效率。

Description

动态图数据存储系统、读取系统及对应方法

本申请是申请日为2022年09月15日，申请号为202211118844.7，发明名称为“动态图数据存储系统、读取系统及对应方法”的中国专利申请的分案申请。

技术领域

本申请涉及计算机技术领域，特别是涉及一种动态图数据存储系统、读取系统及对应方法。

背景技术

超大规模图计算已经在各个领域发挥着越来越大的作用。在诸如信息推荐、用户画像、设备聚类、风险识别等实际场景下包含了各种图计算，例如连通分量发现、图模式匹配、局部子图遍历、图神经网络和实时页面排序等。然而图计算所使用的图数据往往不是静态的，而是会随着服务而不断变化，呈现出一个实时变化的动态图数据。

在动态图计算场景中，属性图通常被用来作为解决涉及实体间关系的分析问题的数据模型。所谓属性图是一种有向图，每个顶点和每条边都会有一个类型标签，每个类型的顶点和边都可以具有若干属性。由于属性图数据会不断更新，因此亟需一种高效的动态图数据存储方式。

发明内容

本申请提供了一种动态图数据存储系统、读取系统及对应方法，用以提高动态图数据的存储效率。

本申请提供了如下方案：

第一方面，一种动态图数据存储系统，设置于存储设备的执行层，所述系统包括：

数据获取组件，被配置为获取待处理的边数据，所述边数据包括该边的起始顶点信息、结束顶点信息以及属性信息；

边存储组件，被配置为确定段空间，所述段空间包括段头和边区域；根据所述段头中包含的各顶点的边指针，在所述段空间中确定所述起始顶点对应的边区域；利用所述结束顶点信息和所述属性信息更新所述起始顶点对应的边区域。

根据本申请实施例中一可实现的方式，所述边数据还包括标签信息；

所述边存储组件在确定段空间时，具体执行：利用所述标签信息查询段标签数组，确定所述标签信息对应的段地址信息；依据所述段地址信息确定对应的段空间。

根据本申请实施例中一可实现的方式，所述数据获取组件，进一步被配置为获取待处理的顶点数据；

所述系统还包括：顶点存储组件，被配置为利用所述顶点数据对顶点块区域进行顶点块的更新，利用对顶点块区域的更新结果更新顶点块地址数组；

其中所述顶点块区域包含各顶点的顶点块，所述顶点块地址数组用以存储顶点对应的顶点块地址信息。

根据本申请实施例中一可实现的方式，所述待处理为待添加，所述更新为添加处理；或者，

所述待处理为待删除，所述更新为删除处理或者标注失效标签。

根据本申请实施例中一可实现的方式，若所述待处理的边数据为待添加的边数据，则所述边存储组件在利用所述标签信息查询段标签数组，确定所述标签信息对应的段地址信息时，具体执行：

利用所述标签信息查询段标签数组；

若未查询到所述标签信息对应的段地址信息，则分配第一大小的存储空间作为所述标签信息对应的段空间，在所述段空间的段头中添加元数据，并在段标签数组中添加所述标签信息对应的段空间的段地址信息。

根据本申请实施例中一可实现的方式，所述元数据包括段空间的标识信息、所述标签信息以及所述段空间的大小信息。

根据本申请实施例中一可实现的方式，若所述待处理的边数据为待添加的边数据，则所述边存储组件在根据所述段头中包含的各顶点的边指针，在所述段空间中确定所述起始顶点对应的边区域时，具体执行：

查询所述段头中包含的各顶点的边指针；

若未查询到所述起始顶点的边指针，则在所述段空间中为所述起始顶点分配第二大小的存储区域作为边区域；若查询到所述起始顶点的边指针，则在所述段空间中确定所述起始顶点对应的边区域。

根据本申请实施例中一可实现的方式，所述系统还包括：段迁移组件；

所述边存储组件在所述段空间中为所述起始顶点分配第二大小的存储区域作为边区域时，具体执行：

若所述段空间中存在第二大小的空闲空间，则从所述空闲空间中为所述起始顶点分配第二大小的存储区域作为边区域；否则，触发所述段迁移组件将所述段空间迁移到另一更大的段空间后，在所述另一更大的段空间为所述起始顶点分配第二大小的存储区域作为边区域。

根据本申请实施例中一可实现的方式，所述系统还包括：区域迁移组件；

若所述待处理的边数据为待添加的边数据，则所述边存储组件在利用所述结束顶点信息和所述属性信息更新所述起始顶点对应的边区域时，具体执行：

若所述起始顶点对应的边区域中存在空闲槽，则将所述结束顶点信息和所述属性信息添加至所述空间槽；否则，触发所述区域迁移组件将所述起始顶点对应的边区域迁移到更大的边区域后，在所述更大的边区域中添加所述结束顶点信息和所述属性信息。

根据本申请实施例中一可实现的方式，所述系统还包括：段迁移组件；

所述区域迁移组件具体被配置为：

若所述段空间中存在第四大小的空闲空间，则从所述空闲空间分配第四大小的存储区域作为所述起始顶点对应的新的边区域，将所述起始顶点对应的原边区域的内容复制到新的边区域，依据所述新的边区域更新所述段头中包含的所述起始顶点的边指针；

若所述段空间中不存在第四大小的空闲空间，则触发段迁移组件将所述段空间迁移到另一更大的段空间后，从迁移后的段空间的空闲空间分配第四大小的存储区域作为所述起始顶点对应的新的边区域，将所述起始顶点对应的原边区域的内容复制到新的边区域，依据所述新的边区域更新所述段头中包含的所述起始顶点的边指针。

根据本申请实施例中一可实现的方式，所述段迁移组件，具体被配置为：

分配第三大小的存储空间作为所述标签信息对应的新的段空间；

将所述标签信息对应的原段空间中除了段头之外的内容复制到新的段空间，依据复制的内容添加所述新的段空间的段头，并利用所述新的段空间更新段标签数组中所述标签信息对应的段地址信息为所述新的段空间地址。

根据本申请实施例中一可实现的方式，所述段头还包含指向各顶点的时间片段epoch表的指针，所述epoch表包含：在对应epoch添加的边数据在起始顶点对应的边区域中的偏移量；

所述边存储组件，进一步被配置为：在利用所述结束顶点信息和所述属性信息对所述起始顶点对应的边区域进行更新后，依据当前时间确定是否更新所述起始顶点的epoch表。

根据本申请实施例中一可实现的方式，所述边区域包括边块区域和边属性区域；

所述边存储组件利用所述结束顶点信息和所述属性信息更新所述起始顶点对应的边区域时，具体执行：

利用所述结束顶点信息更新所述起始顶点对应的边块区域，以及利用所述属性信息更新所述起始顶点对应的边属性区域。

根据本申请实施例中一可实现的方式，在所述段空间中除了段头部分的空间中，各顶点的边块区域按照第一方向依次分配，结束顶点信息按照第一方向依次添加，各顶点的属性区域按照第二方向依次分配，属性信息按照第二方向依次添加，其中所述第一方向和所述第二方向相反。

第二方面，提供了一种动态图数据读取系统，设置于存储设备的执行层，所述系统包括：

事务获取组件，被配置为获取边数据的第一读事务信息，所述第一读事务信息至少包括待查询的起始顶点信息；

边读取组件，被配置为确定段空间，所述段空间包括段头和边区域；根据所述段头中包含的各顶点的边指针，在所述段空间中确定所述起始顶点对应的边区域；从所述起始顶点对应的边区域读取边数据。

根据本申请实施例中一可实现的方式，所述第一读事务信息还包括标签信息；

所述确定段空间包括：利用所述标签信息查询段标签数组，确定所述标签信息对应的段地址信息；依据所述段地址信息确定对应的段空间。

根据本申请实施例中一可实现的方式，所述事务获取组件，进一步被配置为获取顶点数据的第二读事务信息，所述第二读事务信息包括待查询的顶点信息；

所述系统还包括：顶点读取组件，被配置为利用所述待查询的顶点信息查询顶点块地址数组，得到所述待查询的顶点信息对应的顶点块地址信息；从所述顶点块地址信息指向的顶点块读取顶点数据。

根据本申请实施例中一可实现的方式，所述段头还包含指向各顶点的时间片段epoch表的指针，所述epoch表包含：在对应epoch添加的边数据在起始顶点对应的边区域中的偏移量；

所述边读取组件在从所述起始顶点对应的边区域读取边数据时，具体执行：依据所述待查询的起始顶点信息查询所述段头中指向各顶点的epoch表的指针，确定所述待查询的起始顶点信息对应的epoch表；依据所述epoch表，在所述起始顶点对应的边区域中确定对应epoch小于或等于所述读事务的时间的边区域；在确定出的边区域中读取边数据。

根据本申请实施例中一可实现的方式，所述边区域包括边块区域和边属性区域；

所述边读取组件从所述起始顶点对应的边区域读取边数据时，具体执行：

从所述起始顶点对应的边块区域读取结束顶点信息和/或从所述起始顶点对应的边属性区域读取边的属性信息。

第三方面，提供了一种动态图数据存储方法，该方法包括：

获取待处理的边数据，所述边数据包括该边的起始顶点信息、结束顶点信息以及属性信息；

确定段空间，所述段空间包括段头和边区域；

根据所述段头中包含的各顶点的边指针，在所述段空间中确定所述起始顶点对应的边区域；

利用所述结束顶点信息和所述属性信息更新所述起始顶点对应的边区域。

第四方面，提供了一种动态图数据读取方法，该方法包括：

获取边数据的第一读事务信息，所述第一读事务信息至少包括待查询的起始顶点信息；

确定段空间，所述段空间包括段头和边区域；

根据所述段头中包含的各顶点的边指针，在所述段空间中确定所述起始顶点对应的边区域；

从所述起始顶点对应的边区域读取边数据。

根据第五方面，提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现上述第三方面或第四方面所述的方法的步骤。

根据第六方面，提供了一种电子设备，其特征在于，包括：

一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时，执行上述第一方面中任一项所述的方法的步骤。

根据本申请提供的具体实施例，本申请可以具备以下技术效果：

1)本申请提出了一种基于段空间的全新的动态视图数据存储系统，在段空间中各顶点均存在对应的边区域用以存储结束顶点信息和边的属性信息。因此，在对边数据进行增加和删除等更新处理时，整个过程仅需要在段空间中边的初始顶点对应的边区域进行更新即可，不会对已经存储的其他顶点的边数据产生影响，能够缩短图数据动态更新的时间，提高动态图数据的存储效率。

2)本申请中存储边数据的段空间与边的标签信息对应，使得同一段空间中存储相同标签信息的边数据，极大地方便了基于标签的边数据读取，适用于在大多数的图计算场景中提高边数据读取效率。

3)本申请中顶点数据存储于各顶点的顶点块，并由顶点块地址数组维护各顶点块的顶点块地址信息，边数据存储于段空间，这种顶点数据和边数据分别独立存储的方式，能够方便地进行顶点数据的更新和边数据的更新，最大限度的降低互相之间的影响，提高动态图数据存储的效率。

4)本申请在段空间中将同一顶点对应的边数据存储于同一边区域，使得同一顶点对应的边数据是邻近的；并且各顶点对应的边数据是依据顶点ID存储于段空间中的边区域，使得相邻顶点ID对应的边数据也是邻近存储的，从而提高了数据局部性，显著提高动态图数据存储系统在逐顶点进行边数据读取时的系统性能和读取效率。

5)本申请中在边区域的空闲槽不足时进行边区域的迁移，在段空间的空闲空间不足时进行段空间的迁移，从而保证新添加的同一顶点的边数据依然是邻近的、相邻顶点ID对应的边数据也依然是邻近的，从而更好地保证数据局部性，进一步提高动态图数据存储系统逐顶点和逐边进行数据读取时的系统性能和读取效率。

6)本申请中进一步区分边块区域和边属性区域，分别用以存储边的结束顶点信息和边属性信息，能够加快读取边结构和属性信息的性能。并且，各顶点的边块区域和边属性区域的分配方向相反，即从两端向中间依次分配，在添加结束顶点和属性信息时添加方向相反，即从两端向中间依次添加，这种方式能够更加充分有效地利用段空间，即提升存储空间的利用率，且提升读取性能。

7)本申请实施例中通过使用独立的epoch表来存储边块的更新时间，仅需要在epoch表中维护在该epoch发生更新的边块偏移量即可，无需针对每一个边块进行各版本时间戳的维护，降低了系统开销；同时也保证了所读取边块数据与读事务时间的一致性，且保证并发控制的正常进行。

当然，实施本申请的任一产品并不一定需要同时达到以上所述的所有优点。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是现有技术中列压缩格式的示意图。

图2为本申请实施例提供的系统架构的示意图；

图3a为本申请实施例提供的段空间的一种主要结构示意图；

图3b为本申请实施例提供的段空间的另一种主要结构示意图；

图4为本申请实施例提供的动态图数据存储的方法流程图；

图5为本申请实施例提供的存储图数据的方法流程图；

图6为本申请实施例提供的顶点块地址数组的示意图；

图7为本申请实施例提供的段标签表地址数组的示意图；

图8为本申请实施例提供的动态图数据读取方法流程图；

图9为本申请实施例提供的epoch表的示意图；

图10为本申请实施例提供的动态图数据存储系统的结构图；

图11为本申请实施例提供的动态图数据读取系统的结构图；

图12为本申请实施例提供的电子设备的结构框架图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员所获得的所有其他实施例，都属于本申请保护的范围。

在本发明实施例中使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本发明。在本发明实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。

应当理解，本文中使用的术语“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。

取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”或“响应于检测”。类似地，取决于语境，短语“如果确定”或“如果检测(陈述的条件或事件)”可以被解释成为“当确定时”或“响应于确定”或“当检测(陈述的条件或事件)时”或“响应于检测(陈述的条件或事件)”。

动态图数据的存储方式很大程度上决定了图数据的读写性能，进而影响图计算负载的性能。目前针对图计算存在一些图数据存储方式，例如CSR(Compressed Sparse Row，行压缩格式)和CSC(Compressed Sparse Column，列压缩格式)。以CSR为例，CSR是一种用于静态图计算的紧凑图存储格式，如图1中所示，它使用一个顶点数组和一个边数组来存储每个顶点的出边。边数组按照边的起点ID的顺序来存储边，顶点数组利用顶点ID进行索引，存储各个顶点的出边在边数组中的偏移量。虽然CSR能够保证高效的连续内存访问，但并不支持图数据的动态实时更新。例如基于CSR要增加一条边时，需要对边数组和顶点数组都进行数据更新，并且在对边数组进行更新时，会影响其他顶点的边数据，因此存储效率非常低下，是无法满足动态图数据更新需求的。

有鉴于此，本申请提出了一种新的动态图数据存储方式。图2示出了可以应用本申请实施例的示例性系统架构，如图2中所示，该系统主要包括存储设备、存储设备的上游设备和下游设备。

其中存储设备的上游设备可以是向存储设备提供图数据的设备。例如上游设备可以是日志处理设备，该日志处理设备能够将实时产生的日志数据(例如用户的各种网络交易行为、网络交友行为等等的日志数据)转换为图数据，例如从中抽取行为主体和行为对象作为顶点，抽取执行主体和执行对象之间的行为关系作为边。然后将产生的图数据或者更新的图数据提供给存储设备。再例如，上游设备可以是RDBMS(Relational DatabaseManagement System，关系型数据管理系统)，RDBMS能够将关系型数据库中的关系数据转换为图数据或图数据的更新并提供给存储设备。

存储设备是负责对图数据进行存储，以及执行对存储的图数据的增、删、改、查询等处理的设备。存储设备主要分为执行层和存储层。其中存储层是存储图数据的层，而具体如何存储以及如何对存储的图数据进行增、删、改、查询等则由存储设备的执行层完成。执行层在一些场景下也称为存储引擎或者引擎层等。

存储设备可以是单一设备，也可以是多个设备构成的群组，还可以是云服务器端的设备。云服务器又称为云计算服务器或云主机，是云计算服务体系中的一项主机产品，以解决传统物理主机与虚拟专用服务器(VPs，Virtual Private Server)服务中存在的管理难度大，服务扩展性弱的缺陷。

下游设备通常是向存储设备发起读取事务的设备，可以是用户设备，也可以是图分析处理设备。图分析处理设备在具体应用中需要查询顶点数据和/边数据，进而获取顶点特征和边特征以用于进行具体的决策。

应该理解，图2中的上游设备、下游设备和存储设备的数目仅仅是示意性的。根据实现需要，可以具有任意数目的上游设备和存储设备。

为了方便对本申请的理解，首先对本申请所提供的新的动态图数据存储格式进行描述。本申请中使用段空间来管理一定数量的边数据。该段空间主要包括段头和边区域。其中，段头可以包括元数据和各顶点的边指针，还可以进一步包括各顶点的epoch(时间片段)表指针。

元数据主要包括该段空间的标识和段空间的大小，还可以包括边的标签信息等。

在一个段空间中，每个顶点作为边的起始顶点都对应有一个边区域，段头中各顶点的边指针指向该顶点对应的边区域。每个边区域初始存在多个空闲槽供填入该起始顶点对应的边数据。

作为其中一种可实现的方式，如图3a中所示，可以在起始顶点对应的边区域中存储结束顶点信息和边的属性信息。可以在边区域中的一个空闲槽中填入一个边的属性信息和结束顶点信息，属性信息和结束顶点信息都采用固定大小的长度。例如，在顶点0的边区域中，一条边的结束顶点为v1，属性为p1，可以将其填入一个空闲槽。一条边的结束顶点为v2，属性为p2，则可以将其填入一个空闲槽。

但在很多应用场景下边的属性信息和结束顶点信息的读取需求是独立的，例如在一些图计算场景下，仅需要读取边的属性信息，或者在另一些图计算场景下，仅需要读取边的结束顶点信息，再或者在另一些图计算场景下，需要逐顶点扫描各条边的结束顶点信息，以及逐顶点扫描各条边的属性信息。为了提高这种场景下的读取效率，本申请实施例中提供了一种优选的实施方式，可以将边区域区分为边块区域和边属性区域。后续均将以该优选实施方式为例进行描述。

如图3b所示，在一个段空间中，每个顶点作为边的起始顶点都对应有一个边块区域，边块区域中包含该顶点对应的边块。边块中存储的可以是边的结束顶点信息。每个边块区域中初始存在多个空闲槽，每个空闲槽供填入一条边的结束顶点信息。如图3b中所示，ID为0的顶点对应的边块区域中，存放的是一条边的结束顶点v1和另一条边的结束顶点v2。还存在一些空闲槽供以后插入该起始顶点的其他边的信息。另外，每个顶点的边块区域可以包含该边块区域的元数据称为块元数据，包含边块区域的大小等信息。依据段头中每个顶点的边指针可以确定出该顶点的边块区域。

边属性区域存储的是边的属性信息。在一个段空间中，边块(存储的是图的结构数据)和边的属性信息是分开存储的。在段空间中除了段头部分的空间中，各顶点的边块区域按照第一方向依次分配，结束顶点信息按照第一方向依次添加，各顶点的属性区域按照第二方向依次分配，属性信息按照第二方向依次添加，其中第一方向和第二方向相反。也就是说，边块和属性信息分别从两端开始向中间的空闲区域填入。以图3b中所示，边块区域从左往右不断扩展，边的属性区域从右往左不断扩展，直至将中间的空闲区域消耗完。

与边块区域相类似地，每个顶点作为边的起始顶点都对应有一个边属性区域，边属性区域中包含该起始顶点的边的属性信息。每个边属性区域中初始存在多个空闲槽，每个空闲槽供填入一条边的属性信息。如图3b中所示，ID为0的顶点对应的边属性区域中，存放的是一条边的属性信息p1(p1中可能包含该边的一个以上的属性)和另一条边的属性信息p2(p2中可能包含该另一条边的一个以上的属性)。还存在一些空闲槽供插入该起始顶点的其他边的属性信息。另外，由于边的属性信息通常长度固定，因此边属性区域中可以不存在元数据。依据段头中每个顶点的边指针也可以确定出该顶点的边属性区域。

由于边块区域和边属性区域分别从两端开始呈类似镜像的分布，段头中边指针可以包含各顶点ID对应的边块区域和边属性区域的段内整体偏移，只是边块区域是依据该段内整体偏移从左至右寻址，找到的是顶点的边块区域的起始位置；而边属性区域是依据该段内整体偏移从右向左寻址，找到的是顶点的边属性区域的起始位置。

以上为边数据的主要存储架构，该存储架构中的其他内容将在后续实施例中进一步详述。基于上述主要存储架构，在进行边数据的处理时过程可以如图4中所示，包括以下步骤：

步骤402：获取待处理的边数据，边数据包括该边的起始顶点信息、结束顶点信息以及属性信息。

步骤404：确定段空间，段空间包括段头和边区域。

步骤406：根据段头中包含的各顶点的边指针，在段空间中确定起始顶点对应的边区域。

步骤408：利用上述结束顶点信息和属性信息更新该起始顶点对应的边区域。

上述步骤402可以由动态图数据存储系统中的数据获取组件执行，上述步骤404～步骤408中对边数据的存储处理可以由动态图数据存储系统中的边存储组件执行。关于动态图数据存储系统的组成将在后面实施例中详细描述。

若采用图3b中所示的优选存储结构，则上述边区域包括边块区域和边属性区域，根据段头中包含的各顶点的边指针，在段空间中确定起始顶点对应的边块区域和边属性区域，利用结束顶点信息更新起始顶点对应的边块区域，以及利用属性信息更新边属性区域。

从上述的流程中可以看出，本申请提出了一种基于段空间的全新的存储架构，在段空间中各顶点均存在对应的边区域用以存储结束顶点信息和边的属性信息。因此，在对边数据进行增加和删除等更新处理时，整个过程仅需要在段空间中边的初始顶点对应的边区域进行更新即可，不会对已经存储的其他顶点的边数据产生影响，更加高效地适用于动态图数据存储。

上述待处理的边数据可以是待添加的边数据，也可以是待删除的边数据。在此需要说明的是，对于边数据的修改可以看做是删除后再添加边数据。

当需要对一个图结构的图数据进行存储时，需要建立上述存储架构来逐条添加顶点数据和边数据，下面结合实施例对该过程进行详细描述。

图5为本申请实施例提供的存储图数据的方法流程图，如图5中所示，该方法可以包括以下步骤：

步骤502：存储设备初始化。

在存储设备启动后，或者，在需要进行图数据的存储时，进行存储设备初始化。在存储设备初始化时，分别针对顶点块地址数组和段标签表地址数组分配一块内存，以及分配一块虚拟地址空间(可以为预设大小的虚拟地址空间，例如10G)供后续的段标签表、段空间、顶点块和epoch表等使用。

作为其中一种可实现的方式，可以使用诸如mmap函数分配上述虚拟地址空间。Mmap(memory map，存储映射)是一种内存映射文件的方法，可将一个文件或者其它对象映射到进程的地址空间，实现文件磁盘地址和进程虚拟地址空间中一段虚拟地址的一一对映关系。

在本申请实施例中，存储结构的最顶层可以包括顶点块地址数组。该顶点块地址数组用以维护每个顶点的顶点块地址。其中一个顶点块用以存储一个顶点的属性数据，顶点块地址数组存储的可以是每个顶点最新版本的顶点块的地址。如图6中所示，顶点块地址数组包含各顶点ID的顶点块地址，该顶点块地址指向各顶点最新版本的顶点块。每个顶点块中包含顶点块的元数据和属性数据。其中元数据可以包括顶点块大小信息、顶点块的添加时间信息等。顶点块还可以具有一个prev(前向)指针，指向该顶点上一版本的顶点块，从而形成一个顶点块的链表结构。图6中以顶点ID为0的顶点的两个版本的顶点块构成一个链表结构为例。

另外，作为其中一种可实现的方式，可以不针对边的类别进行区分，将各顶点的边数据均放置于一个段空间中。

但通常边是具有类别的，并且在很多图查询和图计算场景下需要对边的类别进行区分。例如在网络交易风险识别场景下获取的图数据中，顶点可以是诸如账户、银行卡、红包id等与金融类相关的主体和对象，顶点之间的边可以是支付行为、存取款行为、签约绑定行为、收发红包行为等等多种类别的与金融类相关的行为关系。再例如，以网络交友诈骗识别场景下获取的图数据中，顶点可以是社交网络账户、实时通信工具账户、金融账户、主机地址、客户端标识等等，顶点之间的边可以是发送好友请求的行为、添加好友的行为、聊天行为、转账行为、收发红包行为、发送链接的行为等多种类别的行为。

因此可以针对边的标签信息对边进行区分，将同一标签信息对应的边数据存储于同一段空间中，从而方便对边数据进行维护和查询。

可以用(x，y)来表示一个段空间，表示该段空间维护的是顶点ID区间x对应的所有标签为y的边数据。例如，段空间(0，a)维护的是顶点ID为0～4095的顶点对应的所有标签为a的边数据，段空间(1，b)维护的是顶点ID为4096～8091的顶点对应的所有标签为b的边数据。

基于此，存储结构的最顶层还可以包括段标签表地址数组。段标签表地址数组用以维护每个段ID对应的段标签表。如图7中所示，每个段ID都对应一个段标签表，段标签表的每个表项是标签对应的段空间的指针，即边标签到段空间地址的映射。

步骤504：添加顶点数据。

对于待添加的顶点数据，逐一利用待添加的顶点数据对顶点块区域添加顶点块来存储顶点的属性信息。然后将添加的顶点块的地址添加到顶点块地址数组，从而形成顶点ID与顶点块地址的映射关系。

后续添加的过程中，如果某顶点的顶点数据发生了更新，则对于该待添加的顶点数据，在顶点块地址数组中发现已经存在该顶点对应的顶点块，则添加该顶点的顶点块以存储该顶点的属性数据后，在该顶点块上增加一个prev指针，指向该顶点上一版本的顶点块。在每个顶点块的元数据中可以保存各顶点块更新的时间信息。

本步骤中关于顶点数据的存储处理可以由动态图数据存储系统中的顶点存储组件执行。

步骤506：获取待添加的边数据，边数据包括边的起始顶点u信息、结束顶点v信息、标签信息L以及属性信息p。

步骤508：利用标签信息L查询段标签数组，如果未查询到对应的段空间地址，说明该标签信息对应的段空间尚未建立，执行步骤510；如果查询到对应的段空间地址，则执行步骤518。

步骤510：分配第一大小的存储空间作为标签信息对应的段空间，在段空间的段头中添加元数据，并在段标签数组中添加标签信息对应的段空间的段地址信息。

本步骤中，第一大小可以依据预设值来选取，例如分配1M给该标签信息L对应的段空间。然后将段空间的ID、段的大小信息、标签信息L等添加到该段空间的段头中的元数据。

步骤512：判断段空间中是否有第二大小的空闲区域，如果是，则执行步骤514；否则，执行步骤530。

在此需要说明的是，如果是在步骤510中初始分配段空间，也可以不执行步骤512的判断，默认初始分配段空间时，一定有足够的空闲区域来作为边区域。也可以在每次进行边区域的初始分配时，均执行本步骤的判断。

步骤514：在段空间中为顶点u分配第二大小的存储区域作为边区域，将结束顶点v信息和属性信息p添加至顶点u的边区域的空闲槽中。

以图3b中所示存储结构为例，在本步骤中，需要为顶点u分配一块存储区域作为边块区域，并且分配一块存储区域作为边属性区域。其中，边块区域从左向右分配，边属性区域从右向左分配。其中为顶点u分配的边块区域大小可以是一个预设值，也可以根据实际需求灵活选取，例如根据结束顶点信息所需要占用的存储区域大小来选取。为顶点u分配的边属性区域可以是一个预设值，作为其中一种可实现的方式，为顶点u分配的边属性区域的大小与边块区域大小对应，例如顶点u对应的边块区域有8个空闲槽，则顶点u对应的边属性区域也有8个空闲槽。

边块区域中除了包含结束顶点v信息之外，还可以包含边块的元数据。因此本步骤还可以进一步添加边块的元数据，例如边块的大小、边块的ID等信息。

步骤516：为顶点u分配一个epoch表，在epoch表中添加当前epoch，并在epoch表中添加步骤514中添加的边在边区域中的偏移量。在段头中更新顶点u的边指针和epoch表指针。然后转至步骤506添加下一条待添加的边数据。

本步骤中涉及的epoch表是为了进行动态图数据存储过程中并发读写操作的一种优选的手段，具体内容将在后续实施例中详述。在此需要说明的是，如果无需进行并发读写，也可以不执行本流程中关于epoch表的处理。或者，若采用其他替代方式控制并发读写，也可以不执行本流程中关于epoch表的处理。

步骤518：确定标签信息L对应的段空间。

本步骤可以利用标签信息L查询段标签数组，确定标签信息L对应的段地址信息，依据段地址信息确定对应的段空间。

步骤520：从该段空间的段头中查询顶点u对应的边指针，如果查询到顶点u的边指针，则执行步骤522；否则，说明尚不存在顶点u的边块区域，执行步骤512。

步骤522：确定顶点u的边指针指向的顶点u的边区域中是否存在空闲槽，如果是，执行步骤524；否则，执行步骤526。

步骤524：将结束顶点v信息和属性信息p添加到顶点u的边区域的空闲槽中，按需更新顶点u的epoch表指针，然后转至步骤506添加下一条待添加的边数据。

若采用图3b中所示的存储结构，则步骤522中针对边区域中是否存在空闲槽的判断包括顶点u的边块区域中是否存在空闲槽以及边属性区域中是否存在空闲槽。若两者都存在空闲槽，则将结束顶点v信息添加到顶点u的边块区域的空闲槽中，将边的属性信息p添加至段空间中顶点u对应的边属性区域中。

其中，按需更新顶点u的epoch表指针包括：如果段头中顶点u的epoch表中已经存在当前epoch，则无需更新；如果段头中顶点u的epoch表中不存在当前epoch，则在顶点u的epoch表中添加当前epoch，并在epoch表中添加该边数据在边区域中的偏移量。具体将在后续实施例中详述。

步骤526：判断段空间中是否存在第四大小的空闲空间，如果是，执行步骤528；否则，执行步骤530。

步骤528：从空闲空间分配第四大小的存储区域作为顶点u对应的新的边区域，将顶点u对应的原边区域的内容复制到新的边区域，依据该新的边区域更新段头中包含的顶点u的边指针，在该新的边区域中转至执行步骤524。

其中，第四大小大于第二大小，例如第四大小可以为第二大小的两倍。本步骤实际上是在顶点u的边区域耗尽时，将顶点u的边区域迁移至另一更大的边区域。

若采用图3b中所示的存储结构，若顶点u的边块区域中没有空闲槽，则本步骤中从空闲空间分配新的更大的存储区域作为顶点u对应的新的边块区域，将顶点u对应的原边块区域的内容复制到新的边块区域，利用该新的边块区域的整体偏移更新段头中包含的顶点u的边指针。

若顶点u的边属性区域中没有空闲槽，则本步骤中从空闲空间分配新的更大的存储区域作为顶点u对应的新的边属性区域，将顶点u对应的原边属性区域的内容复制到新的边属性区域，利用该新的边属性区域的整体偏移更新段头中包含的顶点u的边指针。由于边属性区域和边块区域是镜像的，因此，通常边块区域中空闲槽耗尽时边属性区域的空闲槽也会耗尽，因此同一条边数据在边块和边属性在段内的整体偏移是一致的。

对于起始顶点u对应的原边块区域和原边属性区域可以做删除处理，也可以标记为失效等等。但由于在迁移过程中可能涉及到对原边块区域和原边属性区域的读处理，因此可以待原边块区域的读处理都执行完毕后做删除处理或标记为失效，待原边属性区域的读处理都执行完毕后做删除处理或标记为失效。

步骤530：分配第三大小的存储空间作为标签信息L对应的新的段空间，将标签信息L对应的原段空间中除了段头之外的内容复制到新的段空间，依据复制的内容添加该新的段空间的段头，并利用新的段空间更新段标签数组中标签信息L对应的段地址信息为该新的段空间地址。在该新的段空间中转至执行步骤524。

其中，第三大小大于第一大小，例如第三大小可以为第一大小的两倍。本步骤实际上是在标签信息L对应的段空间耗尽时，将段空间迁移至另一更大的段空间。

从上述流程中可以看出，本申请实施例在段空间中将同一顶点对应的边数据存储于同一边区域，使得同一顶点对应的边数据是邻近的；并且各顶点对应的边数据依据顶点ID存储于段空间中的边区域，使得相邻顶点ID对应的边数据也是邻近存储的，从而提高了数据局部性，显著提高逐顶点进行边数据读取的性能。其中“数据局部性”是程序访问数据时体现出的一种特性，优化目标是让处理过程中需要读取的数据尽可能邻近。

上述流程中步骤528涉及的边区域的迁移可以由动态图数据存储系统中的区域迁移组件执行。步骤530涉及的段空间的迁移可以由动态图数据存储系统中的段迁移组件执行。其他步骤关于边数据的存储处理可以由动态图数据存储系统中的边存储组件执行。

图5所示流程中涉及到了边区域的迁移和段空间的迁移。上述流程中段空间的迁移示出了两种情况：第一种情况是在为一个新的顶点分配边区域时段空间的空闲区域不足，第二种情况是在进行某个顶点的边区域迁移过程中，段空间的空闲区域不足以进行边区域的迁移。

作为其中一种可实现的方式，在进行段迁移的过程中，所有写操作(包括添加、删除等处理)被阻塞，读操作可以正常处理。

作为其中一种可实现的方式，在进行边区域的迁移过程中，针对正在迁移的边区域的写操作被阻塞，读操作可以正常处理。其他边区域的读操作和写操作均可正常处理。

对于上述流程，需要说明的是，步骤504涉及的是顶点数据的添加，步骤506开始之后的步骤涉及的是边数据的添加。在存储图数据时，可以先将顶点数据都添加完毕后，再添加边数据。也可以存储一个顶点的数据后，再针对该顶点存储所有以该顶点作为起始顶点的所有边数据。还可以是顶点数据和边数据并行执行添加。

图5所示流程是存储图数据的整个流程，但随着时间的发展图结构会发生变化从而造成图数据的动态更新。例如在网络交易风险识别场景下，用户行为是随着时间逐渐进行的，可能有新的账户产生和注销、可能有新的账户与银行卡之间进行交互，账户之间可能有新的行为类型产生。其中可能涉及到添加顶点数据、添加边数据、删除顶点数据、删除边数据等。关于顶点数据或边数据的变更可以看做是先删除后添加。其中，若要在已经存储的图数据基础上，添加一个或若干个顶点数据时，直接执行图5所示流程中的步骤504。若要在已经存储的图数据基础上，添加一条或若干条边数据时，直接从图5所示流程中的步骤506开始执行。

在删除顶点数据时，在顶点块地址数组中确定该顶点对应的顶点块，可以删除该顶点块，也可以将该顶点块标记为失效，同时对该顶点对应的边数据进行删除处理。在删除边数据时，利用该边数据的标签信息查询段标签数组得到段空间的地址；再从该段空间的段头中查询边的起始顶点对应的边指针，确定该边指针指向的边区域，包括边块区域和边属性区域，将该边的结束顶点信息从对应边块区域中删除或者标记为失效，将该边的属性信息从对应属性区域中删除或标记为失效。

基于上述存储结构，下面结合实施例对动态图数据的读取方法进行详细描述。

图8为本申请实施例提供的动态图数据读取方法流程图，如图8中所示，该方法可以包括以下步骤：

步骤802：获取边数据的第一读事务信息，第一读事务信息至少包括待查询的起始顶点信息。

图数据主要应用为OLTP(on-line transaction processing，联机事务处理)，针对数据做事务(ACID)处理，可以认为事务是一个针对数据模型进行增删改查的过程。

对于边数据的读操作通常是在获取到读事务后执行的，读事务可能由多种场景触发，大多数的读事务都是基于起始顶点的。例如，在一些图计算中需要计算特定顶点的特征向量时，一方面需要查询该特定顶点的属性数据，另一方面需要查询以该特定顶点作为起始顶点的所有边的属性数据。对于后一方面而言，在读事务信息中会包含该特定顶点的信息，该特定顶点的信息即为待查询的起始顶点信息。

再例如，在一些图计算中需要逐顶点扫描边数据，那么以此产生的读事务是分别读取各顶点的边数据，那么依次将图结构中的各顶点分别作为待查询的起始顶点。

再例如，在一些图计算中需要定位某个特定的边，那么以此产生的读事务是读取特定边的数据，读事务信息中会包含起始顶点和结束顶点的信息。

步骤804：确定段空间，段空间包括段头和边区域。

关于段空间的存储结构可以参见之前实施例中的相关记载，其中边区域可以包括边块区域和边属性区域，在此不做赘述。

作为其中一种可实现的方式，段空间针对边的标签信息而分别建立，那么在第一读事务信息中还可以包括标签信息，即需要读取特定标签的边数据。本步骤中可以利用该标签信息查询段标签数组，确定该标签信息对应的段地址信息；依据该段地址信息确定对应的段空间。

步骤806：根据段头中包含的各顶点的边指针，在段空间中确定起始顶点对应的边区域。

步骤808：从起始顶点对应的边区域读取边数据。

若采用图3b中所示的存储结构，则步骤806中可以确定出起始顶点对应的边块区域和边属性区域，步骤808中可以从起始顶点对应的边块区域中读取结束顶点信息，和/或从起始顶点对应的边属性区域中读取边的属性信息。

本步骤中，依据读事务的不同，可以从起始顶点对应的边块区域以及边属性区域读取起始顶点对应的所有边数据，也可以依据读事务更细粒度的查询条件从起始顶点对应的边块区域以及边属性区域读取与查询条件相匹配的边数据。例如查询条件可以是基于结束顶点的、基于更新时间的、基于数量条件的等等。

上述流程中的步骤802可以由动态图数据读取系统中的事务获取组件执行。步骤804～808可以由动态图数据读取系统中的边读取组件执行。关于动态图数据读取系统的组成将在后面实施例中详细描述。

在图5所示实施例中涉及到epoch表的建立和更新。本申请实施例中涉及的epoch表是为了进行动态图数据存储过程中并发读写操作的一种优选的手段，即采用了一种基于epoch的MVCC(Multi-Version Concurrency Control，多版本并发控制)机制。MVCC机制是当图的某个数值被更新时，MVCC会为该值创建一个新版本，使得并发的读操作可以读到稳定的版本。多版本机制会给读操作引入额外的开销，MVCC的粒度越精细，带来的额外开销就越大。基于此，本申请实施例中采用了一种粗粒度的MVCC机制，以降低多版本带来的额外开销。

图5所示实施例中已经提及，在段空间的段头中还可以进一步包括各顶点的epoch表指针，指向各顶点的epoch表。Epoch表存储的是：在对应epoch添加的边数据在边区域中的偏移量。epoch指的是时间片段，将时间分割成连续且不重叠的epoch，每个epoch的时长可以根据实际需要设置，例如设置为几十微秒。每个epoch可以具有编号，段空间中每个顶点都会关联一个epoch表，epoch表中维护每个顶点的最新边区域存储的所有边的epoch信息。

在对起始顶点对应的边区域进行更新后，依据当前时间确定是否更新起始顶点的epoch表。如果在起始顶点对应的epoch表中已经存在当前时间所属的epoch，则不必更新起始顶点的epoch表；否则在起始顶点的epoch表中新建当前时间所属的epoch，该epoch存储上述边数据在边区域中的偏移量，该偏移量是边区域的内部偏移。

由于边块区域和边属性区域是镜像的，因此在图9中以边块区域为例来解释epoch表的原理。假设顶点ID为0作为起始顶点，在时间t1时向该顶点对应的边块区域中添加了结束顶点v1，那么在该ID为0的顶点对应的epoch表中添加t1所属的epoch编号0，该编号为0的epoch存储的是v1所在边块的偏移量。假设一个epoch的时长为50微秒，在时间t2向该ID为0的顶点对应的边块区域中添加了结束顶点v2，若t1和t2属于同一个epoch，则无需在该ID为0的顶点对应的epoch表中添加新的epoch。

如果在时间t3向该ID为0的顶点对应的边块区域中添加了结束顶点v3，时间t3已经属于第4个epoch，那么在该ID为0的顶点对应的epoch表中添加t3所属的epoch编号3，该编号为3的epoch存储的是v3所在边块的偏移量。在时间t4、t5又添加了结束顶点v7和v4，但时间t4、t5均与时间t3属于同一epoch，则无需更新epoch表。

如果在时间t6向该ID为0的顶点对应的边块区域中添加了结束顶点v5，时间t6已经属于第5个epoch，那么在该ID为0的顶点对应的epoch表中添加t6所属的epoch编号4，该编号为4的epoch存储的是v5所在边块的偏移量。

上述添加的过程实际上属于写操作的过程。基于上述MVCC机制所产生的并发读控制，可以在上述步骤808中，依据待查询的起始顶点信息查询段头中指向各顶点的epoch表的指针，确定待查询的起始顶点信息对应的epoch表；然后依据epoch表，在待查询的起始顶点对应的边区域中查找对应epoch小于或等于读事务的时间的边数据。例如，在待查询的起始顶点对应的边块区域中查找对应epoch小于或等于读事务的时间的边块。再例如，在待查询的起始顶点对应的边属性区域中查找对应epoch小于或等于读事务的时间的属性信息。其中，读事务的时间可以是读事务的发起时间，也可以是用户指定的时间，例如指定一个或几个具体的epoch。若是用户指定的一个或几个具体的epoch，这些epoch均是小于当前时间所属epoch的，在待查询的起始顶点对应的边区域中查找不超过这个指定时间的epoch的边数据。

由于MVCC机制对于写操作是不禁止的，因此为了保证读操作的正常进行，避免读操作和写操作发生冲突而造成读操作异常。仅仅允许读操作读取数据更新时间在读事务产生时间以前的边数据，即对应epoch小于或等于读事务的时间的边数据。

仍以图9为例，假设读事务1的时间为t6,待查询起始顶点的ID为0，那么经过查询该顶点ID为0的epoch表，确定小于或等于t6的epoch号为0和3，则该读事务1从v1、v2、v3、v7和v4所在的边块中查找。当前时间必然大于或等于t6，那么在当前时间发生的写操作必然是发生于编号为5的epoch以后的，因此不会与读事务1对应的读操作发生冲突而对读事务1带来影响。可以理解的，当并发多个读事务时，按照该处理逻辑均能够保证读事务的正常读处理。

另外，在一些场景下，读事务并发数量通常远远大于写事务。因此读事务对应的请求在队列中可能存在延迟的情况，为了避免读请求延迟所造成原本发生于写事务之前的读操作延迟发生于写事务之后所造成的读数据错误，也需要依据epoch表，在待查询的起始顶点对应的边区域中查找对应epoch小于或等于读事务的时间的边数据，从而保证所读取的边数据与读事务时间的一致性。

仍以图9为例，假设读事务1的时间为t3，写事务2的时间为t4。由于并发读事务的数量较多，造成先处理了写事务2，即在t4写入了边块v7。那么在处理读事务1时，如果按照处理时间来进行读取，则就会发生错误将边块v7也纳入其中。而如果采用本申请实施例中的方式，读取epoch小于或等于t3(即读事务时间)的边块，则不会将v7纳入其中，从而保证所读取数据正确。

可以看出，本申请实施例中通过使用独立的epoch表来存储边块的更新时间，仅需要在epoch表中维护在该epoch发生更新的边数据偏移量即可，相比较传统MVCC中需要针对每一个边数据进行各版本时间戳的维护且在读取时需要进行版本检查，大大降低了开销；同时也保证了所读取边数据与读事务时间的一致性，且保证并发控制的正常进行。

除了上述关于epoch表的MVCC机制之外，也可以采用其他方式。例如采用锁机制实现并发读写控制，等等。

作为其中一种可实现的方式，本申请实施例中可以采用锁机制避免并发写带来的冲突，例如避免在段迁移时并发写仍然在原段空间中进行的情况。

若采用锁机制实现并发读写控制，则可以在段空间上使用读写锁的机制。其中，对于正常的添加边的操作需要尝试获取段空间的共享锁。如果一个事务T对段空间加上共享锁，则其他事务可以并发读数据和写数据，但不能够进行段的迁移。

若该添加边的操作触发段的迁移时，获取段空间的互斥锁。当段空间被一个事务的互斥锁锁定的时候，互斥锁会保存这个事务的标识，此后只有这事务能解锁这个互斥锁，在解锁之前，包括这个事务本身的所有事务都无法对这个段空间进行写操作，但可以进行读操作。

锁机制虽然可以控制并发操作,但是其系统开销较大,因此优选本申请实施例中提供的基于epoch表的MVCC机制。也可以在采用基于epoch表的MVCC机制的基础上结合采用部分锁机制。

另外，在边块区域和边属性区域进行边数据的读取时，对于已经被标注失效标签的数据，则不进行读取。

若存储设备的下游设备需要读取顶点数据，则存储设备的执行层会获取到顶点数据的第二读事务信息，该第二读事务信息中包含待查询的顶点信息。可以由动态图数据读取系统中的顶点读取组件利用待查询的顶点信息查询顶点块地址数据，得到待查询的顶点信息对应的顶点块地址信息；从顶点块地址信息指向的顶点块读取顶点数据。

作为其中一种可实现的方式，若第二读事务信息包含时间信息，该时间信息可以是查询条件，例如查询某个时间点对应的顶点数据；或者该时间信息也可以是读事务的发生时间；则在执行上述从顶点块地址信息指向的顶点块读取顶点数据时，可以首先确定顶点块地址信息指向的顶点块，从该顶点块的各版本中确定更新时间小于或等于上述时间信息的版本，从确定出的版本的顶点块中读取顶点数据。

上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

根据另一方面的实施例，提供了一种动态图数据存储系统。图10示出根据一个实施例的动态图数据存储系统的示意性框图，该系统设置于图1所示架构中存储设备的执行层。如图10所示，该系统1000包括：数据获取组件1001和边存储组件1002，还可以进一步包括顶点存储组件1003、段迁移组件1004和区域迁移组件1005。其中各组件的主要功能如下：

数据获取组件1001，被配置为获取待处理的边数据，边数据包括该边的起始顶点信息、结束顶点信息以及属性信息。

边存储组件1002，被配置为确定段空间，段空间包括段头和边区域；根据段头中包含的各顶点的边指针，在段空间中确定起始顶点对应的边区域；利用结束顶点信息和属性信息更新起始顶点对应的边区域。

作为其中一种可实现的方式，边数据还可以包括标签信息，相应地，边存储组件1002在确定段空间时可以具体被配置为：利用标签信息查询段标签数组，确定标签信息对应的段地址信息；依据段地址信息确定对应的段空间。

作为其中一种可实现的方式，数据获取组件1001还可以被配置为：获取待处理的顶点数据。

顶点存储组件1003可以被配置为：利用顶点数据对顶点块区域进行顶点块的更新，利用对顶点块区域的更新结果更新顶点块地址数组；其中顶点块区域包含各顶点的顶点块，顶点块地址数组用以存储顶点对应的顶点块地址信息。

作为其中一种可实现的方式，上述待处理为待添加，上述更新为添加处理。

作为另一种可实现的方式，上述待处理为待删除，上述更新为删除处理或者标注失效标签。

作为其中一种可实现的方式，若待处理的边数据为待添加的边数据，则边存储组件1002在利用标签信息查询段标签数组，确定标签信息对应的段地址信息时，可以具体被配置为：利用标签信息查询段标签数组；若未查询到标签信息对应的段地址信息，则分配第一大小的存储空间作为标签信息对应的段空间，在段空间的段头中添加元数据，并在段标签数组中添加标签信息对应的段空间的段地址信息。

其中，元数据包括段空间的标识信息、标签信息以及段空间的大小信息。

作为其中一种可实现的方式，若待处理的边数据为待添加的边数据，则边存储组件1002根据段头中包含的各顶点的边指针，在段空间中确定起始顶点对应的边区域时，可以具体被配置为：查询段头中包含的各顶点的边指针；若未查询到起始顶点的边指针，则在段空间中为起始顶点分配第二大小的存储区域作为边区域；若查询到起始顶点的边指针，则在段空间中确定起始顶点对应的边区域。

作为其中一种可实现的方式，边存储组件1002在段空间中为起始顶点分配第二大小的存储区域作为边区域时，若段空间中存在第二大小的空闲空间，则从空闲空间中为起始顶点分配第二大小的存储区域作为边区域；否则，触发段迁移组件1004将段空间迁移到另一更大的段空间后，边存储组件1002在另一更大的段空间为起始顶点分配第二大小的存储区域作为边区域。

作为其中一种可实现的方式，若待处理的边数据为待添加的边数据，则边存储组件1002在利用结束顶点信息和属性信息更新起始顶点对应的边区域时，可以具体被配置为：若起始顶点对应的边区域中存在空闲槽，则将结束顶点信息和边属性信息添加至空间槽；否则，触发区域迁移组件1005将起始顶点对应的边区域迁移到更大的边区域后，边存储组件1002在该更大的边块区域中添加边数据。

作为其中一种可实现的方式，区域迁移组件1005在将起始顶点对应的边区域迁移到更大的边区域时，具体执行：

若段空间中存在第四大小的空闲空间，则从空闲空间分配第四大小的存储区域作为起始顶点对应的新的边区域，将起始顶点对应的原边块区域的内容复制到新的边区域，依据新的边区域更新段头中包含的起始顶点的边指针；

若段空间中不存在第四大小的空闲空间，则触发段迁移组件1004将段空间迁移到另一更大的段空间后，区域迁移组件1005从迁移后的段空间的空闲空间分配第四大小的存储区域作为起始顶点对应的新的边区域，将起始顶点对应的原边区域的内容复制到新的边区域，依据新的边区域更新段头中包含的起始顶点的边指针。

对于起始顶点u对应的原边块区域和原边属性区域可以做删除处理，也可以标记为失效等等。但由于在迁移过程中可能涉及到对原边块区域和原边属性区域的读处理，因此可以待原边块区域的读处理都执行完毕后做删除处理或标记为失效，待原边属性区域的读处理都执行完毕后做删除处理或标记为失效。

作为其中一种可实现的方式，段迁移组件1004在将段空间迁移到另一更大的段空间时，具体执行：

分配第三大小的存储空间作为标签信息对应的新的段空间；

将标签信息对应的原段空间中除了段头之外的内容复制到新的段空间，依据复制的内容添加新的段空间的段头，并利用新的段空间更新段标签数组中标签信息对应的段地址信息为新的段空间地址。

作为其中一种可实现的方式，段头还包含指向各顶点的时间片段epoch表的指针，epoch表包含：在对应epoch添加的边数据在起始顶点对应的边区域中的偏移量；边存储组件1002进一步被配置为：在利用结束顶点信息和属性信息对起始顶点对应的边区域进行更新后，依据当前时间确定是否更新起始顶点的epoch表。

作为其中一种优选的实施方式，上述边区域包括边块区域和边属性区域。

边存储组件1002利用结束顶点信息和属性信息更新起始顶点对应的边区域时，具体被配置为利用结束顶点信息更新起始顶点对应的边块区域，以及利用属性信息更新起始顶点对应的边属性区域。

作为其中一种更优选的实施方式，在段空间中除了段头部分的空间中，各顶点的边块区域按照第一方向依次分配，结束顶点信息按照第一方向依次添加，各顶点的属性区域按照第二方向依次分配，属性信息按照第二方向依次添加，其中第一方向和第二方向相反。

根据另一方面的实施例，提供了一种动态图数据读取系统。图11示出根据一个实施例的动态图数据读取系统的示意性框图，该系统设置于图1所示架构中存储设备的执行层。如图11所示，该系统1100包括：事务获取组件1101和边读取组件1102，还可以进一步包括顶点读取组件1103。其中各组件的主要功能如下：

事务获取组件1101，被配置为获取边数据的第一读事务信息，第一读事务信息至少包括待查询的起始顶点信息。

边读取组件1102，被配置为确定段空间，段空间包括段头和边区域；根据段头中包含的各顶点的边指针，在段空间中确定起始顶点对应的边区域；从起始顶点对应的边区域读取边数据。

作为其中一种可实现的方式，第一读事务信息还包括标签信息；相应地，边读取组件1102在确定段空间时，可以具体被配置为：利用标签信息查询段标签数组，确定标签信息对应的段地址信息；依据段地址信息确定对应的段空间。

作为其中一种可实现的方式，事务获取组件1101，进一步被配置为获取顶点数据的第二读事务信息，第二读事务信息包括待查询的顶点信息。

顶点读取组件1103，被配置为利用待查询的顶点信息查询顶点块地址数组，得到待查询的顶点信息对应的顶点块地址信息；从顶点块地址信息指向的顶点块读取顶点数据。

作为其中一种可实现的方式，段头还包含指向各顶点的时间片段epoch表的指针，epoch表包含：在对应epoch添加的边数据在起始顶点对应的边区域中的偏移量。

边读取组件1102从起始顶点对应的边区域读取边数据时，可以被配置为依据待查询的起始顶点信息查询段头中指向各顶点的epoch表的指针，确定待查询的起始顶点信息对应的epoch表；依据epoch表，在起始顶点对应的边区域中确定对应epoch小于或等于读事务的时间的边区域；在确定出的边区域中读取边数据。

作为其中一种优选的实施方式，边区域包括边块区域和边属性区域。

边读取组件1102从起始顶点对应的边区域读取边数据时，可以具体被配置为从起始顶点对应的边块区域读取结束顶点信息和/或从起始顶点对应的边属性区域读取边的属性信息。

需要说明的是，本申请实施例中可能会涉及到对用户数据的使用，在实际应用中，可以在符合所在国的适用法律法规要求的情况下(例如，用户明确同意，对用户切实通知，等)，在适用法律法规允许的范围内在本文描述的方案中使用用户特定的个人数据。

另外，本申请实施例还提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现前述方法实施例中任一项所述的方法的步骤。

以及一种电子设备，包括：

一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时，执行前述方法实施例中任一项所述的方法的步骤。

其中，图12示例性的展示出了电子设备的架构，具体可以包括处理器1210，视频显示适配器1211，磁盘驱动器1212，输入/输出接口1213，网络接口1214，以及存储器1220。上述处理器1210、视频显示适配器1211、磁盘驱动器1212、输入/输出接口1213、网络接口1214，与存储器1220之间可以通过通信总线1230进行通信连接。

其中，处理器1210可以采用通用的CPU、微处理器、应用专用集成电路(Application Specific Integrated Circuit，ASIC)、或者一个或多个集成电路等方式实现，用于执行相关程序，以实现本申请所提供的技术方案。

存储器1220可以采用ROM(Read Only Memory，只读存储器)、RAM(RandomAccessMemory，随机存取存储器)、静态存储设备，动态存储设备等形式实现。存储器1220可以存储用于控制电子设备1200运行的操作系统1221，用于控制电子设备1200的低级别操作的基本输入输出系统(BIOS)1222。另外，还可以存储网页浏览器1223，数据存储管理系统1224，以及动态图数据存储/读取系统1225等等。上述动态图数据存储/读取系统1225就可以是本申请实施例中具体实现前述各步骤操作的应用程序。总之，在通过软件或者固件来实现本申请所提供的技术方案时，相关的程序代码保存在存储器1220中，并由处理器1210来调用执行。

输入/输出接口1213用于连接输入/输出模块，以实现信息输入及输出。输入输出/模块可以作为组件配置在设备中(图中未示出)，也可以外接于设备以提供相应功能。其中输入设备可以包括键盘、鼠标、触摸屏、麦克风、各类传感器等，输出设备可以包括显示器、扬声器、振动器、指示灯等。

网络接口1214用于连接通信模块(图中未示出)，以实现本设备与其他设备的通信交互。其中通信模块可以通过有线方式(例如USB、网线等)实现通信，也可以通过无线方式(例如移动网络、WIFI、蓝牙等)实现通信。

总线1230包括一通路，在设备的各个组件(例如处理器1210、视频显示适配器1211、磁盘驱动器1212、输入/输出接口1213、网络接口1214，与存储器1220)之间传输信息。

需要说明的是，尽管上述设备仅示出了处理器1210、视频显示适配器1211、磁盘驱动器1212、输入/输出接口1213、网络接口1214，存储器1220，总线1230等，但是在具体实施过程中，该设备还可以包括实现正常运行所必需的其他组件。此外，本领域的技术人员可以理解的是，上述设备中也可以仅包含实现本申请方案所必需的组件，而不必包含图中所示的全部组件。

通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统或系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的系统及系统实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上对本申请所提供的技术方案进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处。综上所述，本说明书内容不应理解为对本申请的限制。

Claims (14)

1.一种动态图数据存储系统，设置于存储设备的执行层，其特征在于，所述系统包括：

数据获取组件，被配置为从图数据中获取待处理的顶点数据和边数据；

顶点存储组件，被配置为利用所述顶点数据对顶点块区域进行顶点块的更新，利用对顶点块区域的更新结果更新顶点块地址数组；其中所述顶点块区域包含各顶点的顶点块，所述顶点块地址数组用以存储顶点对应的顶点块地址信息；

边存储组件，被配置为确定段空间，所述段空间包括边区域；利用所述边数据对所述边数据的起始顶点对应的边区域进行更新。

2.根据权利要求1所述的系统，其特征在于，所述顶点块包括元数据和所述顶点数据中的属性数据；

所述元数据包括顶点块大小信息和顶点块的添加时间信息。

3.根据权利要求1所述的系统，其特征在于，若所述待处理为待添加，则所述顶点存储组件在利用所述顶点数据对顶点块区域进行顶点块的更新时，具体被配置为：若在所述顶点块地址数组中已经存在待添加的顶点对应的顶点块，则在所述顶点块区域添加所述待添加的顶点的顶点块以存储所述待添加的顶点数据，并在该顶点块上增加前向指针，指向该顶点上一版本的顶点块。

4.根据权利要求1所述的系统，其特征在于，若所述待处理为待删除，则所述顶点存储组件在利用所述顶点数据对顶点块区域进行顶点块的更新时，具体被配置为：在所述顶点块地址数组中确定待删除的顶点对应的顶点块，删除该顶点块或标记为失效；

所述边存储组件，进一步被配置为将所述待删除的顶点对应的边数据从所述段空间中删除或标记为失效。

5.根据权利要求1所述的系统，其特征在于，所述边数据包括标签信息；

所述边存储组件在确定段空间时，具体被配置为：利用所述标签信息查询段标签数组，确定所述标签信息对应的段地址信息；依据所述段地址信息确定对应的段空间。

6.根据权利要求1至5中任一项所述的系统，其特征在于，所述段空间还包括段头；

所述边存储组件在利用所述边数据对所述边数据的起始顶点对应的边区域进行更新时，具体被配置为：根据所述段头中包含的各顶点的边指针，在所述段空间中确定所述边数据的起始顶点对应的边区域；利用所述边数据的结束顶点信息和属性信息更新所述起始顶点对应的边区域。

7.根据权利要求6所述的系统，其特征在于，所述段头还包含指向各顶点的时间片段epoch表的指针，所述epoch表包含：在对应epoch添加的边数据在起始顶点对应的边区域中的偏移量；

所述边存储组件进一步被配置为：在利用所述结束顶点信息和属性信息对所述起始顶点对应的边区域进行更新后，依据当前时间确定是否更新所述起始顶点的epoch表。

8.一种动态图数据读取系统，设置于存储设备的执行层，其特征在于，所述系统包括：

事务获取组件，被配置为获取顶点数据的第二读事务信息，所述第二读事务信息包括待查询的顶点信息；

顶点读取组件，被配置为利用所述待查询的顶点信息查询顶点块地址数组，得到所述待查询的顶点信息对应的顶点块地址信息；从所述顶点块地址信息指向的顶点块读取顶点数据；

边读取组件，被配置为确定段空间，所述段空间包括边区域；将所述待查询的顶点信息作为起始顶点，从所述起始顶点对应的边区域中读取边数据。

9.根据权利要求8所述的系统，其特征在于，所述第二读事务还包括时间信息；

所述顶点读取组件在从所述顶点块地址信息指向的顶点块读取顶点数据时，具体被配置为：确定所述顶点块地址信息指向的顶点块，从该顶点块的各版本中确定更新时间小于或等于所述时间信息的版本，从确定出的版本的顶点块中读取顶点数据。

10.根据权利要求8所述的系统，其特征在于，所述段空间还包括段头，所述段头包含指向各顶点的时间片段epoch表的指针，所述epoch表包含：在对应epoch添加的边数据在起始顶点对应的边区域中的偏移量；

所述边读取组件在从所述起始顶点对应的边区域读取边数据时，具体被配置为：依据所述待查询的顶点信息查询所述段头中指向各顶点的epoch表的指针，确定所述待查询的顶点信息对应的epoch表；依据所述epoch表，在所述待查询的顶点信息对应的边区域中确定对应epoch小于或等于所述读事务的时间的边区域；在确定出的边区域中读取边数据。

11.一种动态图数据存储方法，其特征在于，该方法包括：

从图数据中获取待处理的顶点数据和边数据；

利用所述顶点数据对顶点块区域进行顶点块的更新，利用对顶点块区域的更新结果更新顶点块地址数组；

确定段空间，所述段空间包括边区域；利用所述边数据对所述边数据的起始顶点对应的边区域进行更新；

其中所述顶点块区域包含各顶点的顶点块，所述顶点块地址数组用以存储顶点对应的顶点块地址信息。

12.一种动态图数据读取方法，其特征在于，所述方法包括：

获取顶点数据的第二读事务信息，所述第二读事务信息包括待查询的顶点信息；

利用所述待查询的顶点信息查询顶点块地址数组，得到所述待查询的顶点信息对应的顶点块地址信息；从所述顶点块地址信息指向的顶点块读取顶点数据；

确定段空间，所述段空间包括边区域；将所述待查询的顶点信息作为起始顶点，从所述起始顶点对应的边区域中读取边数据。

13.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该程序被处理器执行时实现权利要求11或12所述的方法的步骤。

14.一种电子设备，其特征在于，包括：

一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时，执行权利要求11或12所述的方法的步骤。

Images