CN108595251A - 动态图更新方法、装置、存储引擎接口和程序介质 - Google Patents

Abstract

本公开提供了一种动态图更新方法、装置、存储引擎接口和程序介质。该方法包括：将动态图的图元素分成多个组，各个组之间的图元素各不相同且互相独立；为每个组分别设置一个事务队列；将针对每个组中的图元素的事务放在该组的事务队列中排队，每个事务队列中的事务按照排队的顺序进行图元素操作；响应于非并行性事务对图元素进行操作，将图元素所属的组锁住，禁止其它组的事务队列中的事务进行图元素操作。本公开实施例在保证动态图数据一致性的前提下，提高了存储的动态图的更新速度。

Description

动态图更新方法、装置、存储引擎接口和程序介质

技术领域

本公开涉及计算机存储领域，具体涉及一种动态图更新方法、装置、存储引擎接口和程序介质。

背景技术

具有时序信息的图称为动态图。例如，物联网上每时每刻都有新的节点加入，有旧的节点退出，因此，网联网节点拓扑时时都在变化，可以看作是一个动态图。再例如，如果使用社交应用(例如微信)的用户互相加好友可以看作是在两个用户节点之间建立关系的话，不断有新的好友关系产生，和旧的好友关系取消，用户之间的好友关系拓扑图可以看作是动态图。

在网络应用中，在存储介质中需要存储这种网络拓扑图的不断变化，即存储动态图。但是，网络通常处于高速演化过程。对于这样一个快速的更新速率，如果采用单线程去顺序更新存储的动态图，更新存储的动态图的速率跟不上实际网络更新的速率。如果采用多线程来更新存储的动态图，图数据的一致性无法得到保证。举例来说，两个线程A、B同时更新存储的动态图，线程A要在存储的动态图上去掉一个顶点P(上文的网络节点在动态图中为顶点)，线程B要在存储的动态图上去掉一条边PQ(上文的网络节点之间的关系在动态图中为边)。二者同时操作，但执行必然有先后，如果先去掉了顶点P，在执行去掉边PQ时就会发生错误，因为此时边PQ的一个端点P已经不存在。

为了解决上述问题，只能采取加锁的方式。多线程同时运行时，当一个线程对动态图进行更新时，对动态图或更新的部分进行加锁，防止在这个线程更新时其它线程又来更新，导致错误。当这个线程更新完后，解锁，其它的线程可以进行更新。但是，加解锁带来的开销可能使整个的更新速度比单线程更慢。

发明内容

本公开的一个目的在于在保证动态图数据一致性的前提下，提高存储的动态图的更新速度。

根据本公开实施例的第一方面，公开了一种动态图更新方法，包括：

将动态图的图元素分成多个组，各个组之间的图元素各不相同且互相独立；

为每个组分别设置一个事务队列；

将针对每个组中的图元素的事务放在该组的事务队列中排队，每个事务队列中的事务按照排队的顺序进行图元素操作；

响应于非并行性事务对图元素进行操作，将图元素所属的组锁住，禁止其它组的事务队列中的事务进行图元素操作。

根据本公开实施例的第二方面，公开了一种动态图更新装置，包括：

分组单元，用于将动态图的图元素分成多个组，各个组之间的图元素各不相同且互相独立；

事务队列设置单元，用于为每个组分别设置一个事务队列；

排队单元，用于将针对每个组中的图元素的事务放在该组的事务队列中排队，每个事务队列中的事务按照排队的顺序进行图元素操作；

加锁单元，用于响应于非并行性事务对图元素进行操作，将图元素所属的组锁住，禁止其它组的事务队列中的事务进行图元素操作。

根据本公开实施例的第三方面，公开了一种动态图存储引擎接口，包括：

存储器，存储有计算机可读指令；

处理器，读取存储器存储的计算机可读指令，以执行如上所述的方法。

根据本公开实施例的第四方面，公开了一种计算机程序介质，其上存储有计算机可读指令，当所述计算机可读指令被计算机的处理器执行时，使计算机执行如上所述的方法。

本公开的实施例中，采用多线程来更新存储的动态图。本公开的发明人发现，对存储的动态图进行更新的事务可以分为并行性事务和非并行性事务。对于非并行性事务，其与其它事务同时进行动态图的更新操作，可能会造成动态图数据的不一致。然而，多个并行性事务同时进行动态图的更新操作，是不会造成图数据的不一致的。因此，本公开实施例将动态图的图元素分成多个组，各个组之间的图元素各不相同且互相独立，为每个组分别设置一个事务队列，将针对每个组中的图元素的事务放在该组的事务队列中排队。响应于非并行性事务对图元素进行操作，将图元素所属的组锁住，禁止其它组的事务队列中的事务进行图元素操作。由于只有非并行性事务才会引发动态图数据不一致的问题，因此，只对这部分事务加锁操作，避免了对所有事务加锁带来的更新速度低的问题，又保证了动态图数据一致性。

本公开的其他特性和优点将通过下面的详细描述变得显然，或部分地通过本公开的实践而习得。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性的，并不能限制本公开。

附图说明

通过参照附图详细描述其示例实施例，本公开的上述和其它目标、特征及优点将变得更加显而易见。

图1A-B示出根据本公开一示例实施方式的动态图更新方法应用在微信用户好友关系网络中的场景示意图，其中，图1A示出了更新之前的微信用户好友关系网络，图1B示出了更新之后的微信用户好友关系网络。

图2A-B是根据本公开一示例实施方式的、对图1A-B对应的动态图。

图3示出根据本公开一示例实施方式的动态图更新方法所应用的系统构架图。

图4示出根据本公开一示例实施方式的动态图更新方法的流程图。

图5示出根据本公开一示例实施方式的将事务分配在各个组的事务队列中排队的示意图。

图6示出根据本公开一示例实施方式的非并行性事务按照预定顺序锁住多个组并进行操作的示意图。

图7示出根据本公开一示例实施方式的执行事务的图元素操作时进行时间戳比较的示意图。

图8示出根据本公开一示例实施方式的对于增加图元素的事务确定增加的图元素所属的组的一个示意图。

图9A-B示出根据本公开一示例实施方式按照图元素的邻接关系，将动态图的图元素分成多个组的示意图，其中图9A是按照图元素数目均衡的分组方式的示意图，图9B是按照处理负载均衡的分组方式的示意图。

图10示出根据本公开一示例实施方式的动态图更新方法的流程图。

图11示出根据本公开一示例实施方式的将针对每个组中的图元素的事务放在该组的事务队列中排队的具体流程图。

图12示出根据本公开一示例实施方式的动态图更新方法的流程图。

图13示出根据本公开一示例实施方式的动态图更新方法的流程图。

图14示出根据本公开一示例实施方式的动态图更新方法的流程图。

图15示出根据本公开一示例实施方式的确定事务针对的图元素的组的流程图。

图16示出根据本公开一示例实施方式的将动态图的图元素分成多个组的具体流程图。

图17示出根据本公开一示例实施方式的动态图更新方法的流程图。

图18示出根据本公开一示例实施方式的动态图更新方法的流程图。

图19示出根据本公开一示例实施方式的动态图更新装置的模块图。

图20示出根据本公开一示例实施方式的动态图更新装置的结构图。

具体实施方式

现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些示例实施方式使得本公开的描述将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。附图仅为本公开的示意性图解，并非一定是按比例绘制。图中相同的附图标记表示相同或类似的部分，因而将省略对它们的重复描述。

此外，所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多示例实施方式中。在下面的描述中，提供许多具体细节从而给出对本公开的示例实施方式的充分理解。然而，本领域技术人员将意识到，可以实践本公开的技术方案而省略所述特定细节中的一个或更多，或者可以采用其它的方法、组元、步骤等。在其它情况下，不详细示出或描述公知结构、方法、实现或者操作以避免喧宾夺主而使得本公开的各方面变得模糊。

附图中所示的一些方框图是功能实体，不一定必须与物理或逻辑上独立的实体相对应。可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。

具有时序信息的图称为动态图。例如，物联网上每时每刻都有新的节点加入，有旧的节点退出，因此，网联网节点拓扑时时都在变化，可以看作是一个动态图。再例如，如果使用社交应用(例如微信)的用户互相加好友可以看作是在两个用户节点之间建立关系的话，不断有新的好友关系产生，和旧的好友关系取消，用户之间的好友关系拓扑图可以看作是动态图。

图1A-B示出根据本公开一示例实施方式的动态图更新方法应用在微信用户好友关系网络中的场景示意图。图1A示出了在t_i时刻的微信用户好友关系网络，图1B示出了的t_i时刻之后的t’_i时刻微信用户好友关系网络。在t_i时刻，用户C同时与用户A、D、E、F具有微信用户好友关系，用户D同时与用户C、B具有微信用户好友关系。在t_i-t’_i之间，用户G加入了该网络,同时与用户C、D、E建立了微信用户好友关系，用户A退出了该网络，其与用户C建立的微信用户好友关系就自然不存在了。因此，在t’_i时刻，用户C同时与用户D、E、F具有微信用户好友关系，用户G同时与用户C、D、E具有微信用户好友关系，用户D同时与用户C、B、G具有微信用户好友关系。

另外，图1A-B除了示出每个用户和它们之间的好友关系之外，还示出了每个用户具有属性，属性包括姓名、公司、权限级别、朋友圈设置等。在一些情况下，尽管，用户和用户之间的好友关系没有变化，但用户属性可能更改，用户属性的更改也认为是微信用户好友关系网络发生了变化。

图2A-B是与图1A-B分别对应的动态图。动态图是从节点网络拓扑中抽象出来的图。动态图包括顶点101和连接顶点101的边102。顶点是节点网络拓扑中节点的抽象表示，如图1A-B中的各用户在动态图中抽象成顶点101。边是是节点网络拓扑中节点之间的关系的抽象表示，如图1A-B中的各用户之间的微信好友关系在动态图中抽象成边102。两个顶点101之间有边102就说明在相应的用户之间建立了微信好友关系，两个顶点101之间没有边102就说明在相应的用户之间没有微信好友关系。

动态图的形式化定义如下：

G(t)＝(V(t),E(t)) (0-1)

其中，t表示时序信息，V(t)表示在时间t动态图中的各顶点的状态，E(t)表示在时间t动态图中的各边的状态，G(t)表示在时间t的动态图，其中各顶点、各边的状态除了包括各顶点、各边在动态图中的存在之外，还包括各顶点、各边的属性。属性是指动态图中的顶点或边所对应的网络节点或网络节点关系的重要性质，这些重要性质对于网络节点在网络中的行为有影响。例如，在社交应用好友关系网络中，用户节点(即用户)的朋友圈设置对于社交应用的用户之间的互动产生重要影响(例如用户可以将自己的朋友圈设置成非好友只能展示十张照片等)等。因此，不但网络节点的加入或删除对于整个好友关系网络中的行为有影响，网络节点的属性同样对于整个好友关系网络中的行为有影响。因此，对动态图的更新包括对图元素的加入、去除，还包括图元素属性的增加(Insert)、修改(update)或者删除(remove)。图元素即顶点和边的统称。

图元素从加入到动态图，到从动态图去除的整个过程叫做生存周期。在生存周期内可能会经历各种属性的修改、添加等。可以将图元素的生存周期分割为若干个互不重叠的时间区间：

{[t₀,t'₀),[t₁,t'₁),...,[t_n,t'_n)} (0-2)

在上式的任意一个区间内，该图元素没有任何更新，即没有加入、去除，也没有对图元素属性的增加(Insert)、修改(update)或者删除(remove)。一旦发生了上述的任一种更新，就自动跃入下一个区间。例如在t’₀发生了上述的至少一种更新，自动跃入区间[t₁,t’₁),其中t’₀＝t₁；在t’₁发生了上述的至少一种更新，自动跃入区间[t₂,t’₂),其中t’₁＝t₂……在t₀发生的更新是该图元素的加入，在t’_n发生的更新是该图元素的去除。若t’_n取值为∞(INF)，则表示图元素在t_n时刻完成了最近的一次更新。

下面讨论用快照定义图更新。图更新是指动态图中两个时间点之间的所有图元素的更新。

快照S(t_i)是由在t_i时刻存在于动态图G(t)中的所有图元素V(t_i)和E(t_i)组成的静态图，它也称作动态图G(t)在t_i时刻的快照。图更新定义为时间区间[t_i,t'_i)上，针对演化图G(t)发生的所有更新操作序列。如将图更新δGt_i,t’_i应用于图快照S(t_i)，那么就可以得到t’_i时刻的图快照S(t’_i)，其运算如下：

例如，图2A示出了在t_i时刻动态图的快照，图2B示出在t’_i时刻动态图的快照。在t_i时刻到t’_i时刻，图更新δGt_i,t’_i为：增加用户G对应的顶点101，增加用户G的顶点101分别与用户C、D、E的顶点101之间的边102，去除用户A对应的顶点101(用户A对应的顶点101与用户C对应的顶点101之间的边102自然去除)。

如图3右上部分所示，是一个基于各用户的终端105发过来的好友关系更新请求更新的动态图，但动态图并非以图3右上部分进行存储，其是以数据结构存储在存储设备1042中。该数据结构利用日志文件(Log-File)模型。

日志文件模型是一种时序数据的存储模型。它在图存储领域的应用思想是将动态图生存周期内的所有更新活动都以日志形式记录下来，然后再通过起始时刻的图快照S(t₀)与图更新来计算得到演化图生存周期内任意时刻的图状态。这种模型的优点是可以采用高效的存储方式对日志数据进行压缩存储，同时还可以很方便地在日志数据上对动态图执行数据挖掘任务。该模型的形式化定义如下：

其中，表示动态图当前的状态

L表示日志文件的集合

S则表示快照的集合

由于传统的日志模型采用S(t₀)和计算得到生命周期上任一时刻的动态图状态，它的缺陷在于查询距离起始状态较远的时间点时，由于需要将日志中记录的演化活动逐步地应用到起始状态上，直至到达查询时间点，整个检索过程的延时通常都会很高。因此，常见的日志文件模型的实现都是阶段性创建快照，以距离检索时间点最近的快照为起始，来优化整个检索过程。常见的快照创建方式有三种：

1、基于时间(Time-Based)：连续两个快照之间的时间间隔是恒定的；

2、基于操作(Operation-Based)：连续两个快照之间的更新操作数目恒定；

3、基于相似性(Similarity-Based)：相邻两个快照的相似度不超过一个固定的阈值。

图3示出根据本公开一示例实施方式的动态图更新方法所应用的系统构架图。该系统包括网络节点105和动态图存储引擎104。

网络节点105是指网络上进行处理的相对独立的单元，它可以是任何形式的终端，例如手机、PDA、笔记本电脑、车载设备、台式设备等。在社交应用好友关系网络中，它可以是用户终端，例如可以使用社交工具的手机、电脑等。在物联网中，它可以是物联网终端，如摄像头、红绿灯设备、公路进出口闸门等。

动态图存储引擎104一般在服务器侧，是用来跟踪并存储网络的动态改变过程，从而对网络的运行状况进行了解，以便监督网络异常，对网络未来的运行提出建议等的设备。它以动态图的形式存储网络的动态改变。动态图存储引擎104可以由单台计算机或多台联网的计算机实现，也可以由由单台计算机的一部分或多台联网的计算机各自一部分联合实现。例如，它可以采用虚拟机的形式，即从物理机上划分出一部分作为虚拟机，行使动态图存储引擎104的功能，或者从多台物理机上分别划分出一部分作为虚拟机，集体行使动态图存储引擎104的功能。在云环境下，它可以由云环境中的多台分布式计算设备联合实现。

动态图存储引擎104包括存储设备1042和动态图存储引擎接口1041。如上所述，存储设备1042以日志文件模型的形式，存储着对应于网络的拓扑动态变化的动态图。动态图存储引擎接口1041是对存储设备1042上存储的动态图进行更新操作的接口。具体地，它响应于网络节点105的更新请求，对存储设备1042上存储的动态图进行更新操作。例如，当网络节点105增加或去除，或者网络节点105的属性改变等时，网络节点105向动态图存储引擎接口1041发送更新存储设备1042中存储的动态图的请求，由动态图存储引擎接口1041更新存储设备1042中存储的动态图。

在网络应用中，网络通常处于高速演化过程。例如，全国每分每秒都有数十万、数百万个用户在增加或变更微信好友或用户属性。对于这样一个爆炸性的更新速率，如果采用单线程去顺序更新存储的动态图，根本来不及。如果采用多线程来更新存储的动态图，图数据的一致性无法得到保证。举例来说，两个线程A、B同时更新存储的动态图。线程A要在存储的动态图上去掉一个顶点P(上文的网络节点在动态图中为顶点)，线程B要在存储的动态图上去掉一条边PQ(上文的网络节点之间的关系在动态图中为边)。二者同时操作，但执行必然有先后，如果先去掉了顶点P，在执行去掉边PQ时就会发生错误，因为此时边PQ的一个端点P已经不存在。

为了解决上述问题，只能采取加锁的方式。多线程同时运行时，当一个线程对动态图进行更新时，对动态图或更新的部分进行加锁，防止在这个线程更新时其它线程又来更新，导致错误。当这个线程更新完后，解锁，其它的线程可以进行更新。但是，加解锁带来的开销可能使整个的更新速度比单线程更慢。同时，锁冲突也会很大程度上限制线程的并行度。

为了解决这个问题，本公开的发明人认真研究了对图元素的操作种类。在动态图更新中，对图元素的操作包括：对图元素的加入、去除、以及图元素属性的增加、修改或者删除。图元素属性的增加、修改或者删除可以统称为图元素属性的更新。图元素即顶点和边的统称。

对于图元素属性的更新来说，其不会使对图元素的任何其它操作产生错误。首先，两个图元素属性的更新操作不会相互使对方产生错误。如果两个更新操作针对的是对不同的两个图元素属性，操作对象不一样，不会产生一个操作影响另外一个的情况。如果是对同一图元素同一属性的更新，例如，线程A希望将某一图元素的某一属性改变为A1，线程B希望将某一图元素的某一属性改变为A2。由于将事务分配给各线程(后文中的事务队列)是将事务按时间顺序在不同组的队列中排队，如果两个线程同时希望变更同一图元素的同一属性，说明这两个更新同一图元素的同一属性的事务在请求时间上差不多，先执行哪个都有道理。因此，可以忽略这种情况。其次，对图元素属性的更新操作、与增加或去除其它图元素的操作是平行的，完全不产生任何影响。对图元素属性的更新操作、和与该图元素本身的去除操作会产生交叉影响，因为一旦图元素被先去除，将无法更新其属性。但如果属性无法更新，则不执行任何操作，不会象先去除某一顶点，再增加与该顶点相关的边那样产生错误。因此，对于图元素属性的更新来说，其不会使对图元素的任何其它操作产生错误。

其次，对于增加顶点、或去除边的操作来说，其不会使对图元素的任何其它操作产生错误。增加顶点是对现有动态图中没有的顶点进行添加，其不影响现有动态图的任何图元素。更新该顶点的属性的操作表面上可能受到该增加顶点的操作的影响，但更新该顶点的属性的请求一定是在增加该顶点的请求之后发出的，时间上说，不大可能被两个线程同时请求。对于去除边的操作来说，只是将两个顶点之间的一个边取消，不会影响现有动态图中任何一个图元素，包括两个顶点。去除边的操作虽然可能对改变这个边的属性的操作有影响，但即使先去除了边，改变这个边的属性的操作无法执行，但不至于发生错误。

然而，对于去除顶点、增加边这两个操作，同时由多线程并行执行时，会互相之间使对方产生错误。而且，这两个操作中任一个操作，当与其它操作同时被多线程并行执行时，也容易使该其它操作产生错误。首先，对于去除顶点这个操作，当与增加与该顶点相关的边的操作同时被多线程并行执行时，如果先执行了去除顶点这个操作，执行增加与该顶点相关的边的操作，就会发生错误，因为该顶点已不存在，无法增加该边。而且，去除顶点这个操作，当与去除与该顶点相关的边的操作同时被多线程并行执行时，如果先执行了去除顶点这个操作，执行去除与该顶点相关的边的操作，就会发生错误。另外，对于增加边这个操作，当与去除该边的一个顶点的操作同时被多线程并行执行时，如果先执行了去除顶点这个操作，执行增加该边的操作，就会发生错误，因为该顶点已不存在，无法增加该边。而且，增加该边这个操作，当与增加该边的一个顶点的操作同时被多线程并行执行时，必须要先增加该边的一个顶点，如果如果先执行了增加该边的操作，就会发生错误，因为相关的顶点不存在。

因此，发明人得出结论，只要保证执行去除顶点、增加边这两个操作中任一个时，其余的操作不能与它并行执行，就能够在保证图数据的一致性的前提下，利用多线程并行操作，提高存储的动态图的更新速度。本公开中，将去除顶点、增加边这两种操作定义为非并行性事务，将更新图元素的属性、增加顶点、去除边的操作定义为并行性事务。动态图更新中，非并行性事务不能与其它事务并行执行，并行性事务可以与其它事务并行执行。

如图4所示，根据本公开的一个实施例，提供了一种动态图更新方法，其特征在于，包括：

步骤310、将动态图的图元素分成多个组，各个组之间的图元素各不相同，且互相独立；

步骤320、为每个组分别设置一个事务队列；

步骤330、将针对每个组中的图元素的事务放在该组的事务队列中排队，每个事务队列中的事务按照排队的顺序进行图元素操作；

步骤340、响应于非并行性事务对图元素进行操作，将图元素所属的组锁住，禁止其它组的事务队列中的事务进行图元素操作。

下面对这些步骤进行详细描述。

在步骤310中，将动态图的图元素分成多个组，各个组之间的图元素各不相同且互相独立。

如上所述，图元素包括顶点和边。各个组之间的图元素各不相同是指没有一个图元素出现在多组中，并且每个图元素必须分在某一组中。各个组之间的图元素互相独立是指各个组之间的图元素必须是完全独立的图元素，每个组的任何一个图元素必须能单独存在，而不是依赖于另一个其它组的图元素存在。

在一个实施例中，将动态图的图元素分成多个组的方式可以采取随机的方式，即将每个图元素随机地仅分到一个组中。

为了均衡各个组之间的处理负载，可以采取将图元素在多个组之间均分的方式。然而，将图元素在多个组之间数量上均分，并不能保证各组之间处理负载的均衡，因为每个对图元素的事务耗用的时间可能不同，数量上的均分不能实现每组耗用时间的平均。

为了实现各组之间真正耗用时间上的均衡，可以按周期执行本公开实施例的一种动态图更新方法，并利用前一周期每个图元素的处理负载，来确定分组方法，其中各组的处理负载大致均衡。为了方便理解，这一部分内容在后文中详细描述。

将动态图的图元素分成多个组，也可以根据图元素之间的连接关系，将邻近的图元素尽量分到一个组内，这样，使得对于一些对于邻近的图元素一起进行更新的事务，尽量让其针对一个、两个组进行处理并上锁，防止上锁的波及面过大导致更新动态图的整体效率过低。为了方便理解，这一部分内容也在后文详细描述。

如图5所示，动态图中有11个图元素，其中5个顶点、6条边，分别是：顶点0-4、边5-10。将11个元素分成3个组106，即组1、组2、组3。分到组1的图元素有：顶点0、顶点3、边6、边9；分到组2的图元素有：顶点1、顶点4、边5、边7、边10；分到组3的图元素有：顶点2、边8。

在步骤320中，为每个组分别设置一个事务队列。

事务是动态图更新中的不执行时不可再分的基本执行单元。不执行时不可再分是指尽管其有可能分成进一步的步骤，但不执行就不知道进一步的步骤针对的对象、范围等。例如，查询边6的好友类型属性(朋友、家人还是同学等)，这是不可再分的。再例如，更新顶点0的所有满足属性x≥value1的邻接点的属性x为value2。它是可以再细分成进一步的步骤的，但不执行就不知道顶点0的邻接点有哪些，邻接点中属性x≥value1的邻接点有哪些，因此称为不执行时不可再分。该事务的处理流程为：

再例如，对于将顶点0、3、4的优先级属性更新为最高这样一个指令，却是在不执行时也可以分成将顶点0的优先级属性更新为最高、将顶点3的优先级属性更新为最高、将顶点4的优先级属性更新为最高这三个指令的，因此，它不是不执行时不可再分的。它可以细分成多个事务。

事务队列是为每个组维护的事务的队列，队列的顺序就是进行图元素操作的顺序，它可以防止事务对图元素进行操作时的无序。

在步骤330中，将针对每个组中的图元素的事务放在该组的事务队列中排队，每个事务队列中的事务按照排队的顺序进行图元素操作。

在一个实施例中，将针对每个组中的图元素的事务放在该组的事务队列中排队可以按照动态图存储引擎接口1041获取到这些事务的获取时间。例如，动态图存储引擎接口1041在10:41:01获取到一个针对顶点0的事务1，在10:41:04又获取到一个针对顶点3的事务2，由于节点0和节点3都属于组1，则把它们都放在组1中排队。但排队时，由于事务1先于事务2被获取到，因此，在组1的事务队列中，将事务1排在事务2的前面。

在该实施例中，动态图存储引擎接口1041获取到针对图元素的事务，按照获取到这些事务的时间顺序逐一将各个组的事务队列中输送，输送到各个组的事务队列时排在事务队列的末尾。因为，已经存在于该事务队列中的事务一定是动态图存储引擎接口1041先获取到的，获取针对图元素的事务的顺序就是输送到各事务队列的顺序。

然而，在有些情况下，网络节点可能是较早请求了该事务而由于网络传输速度的原因该事务晚于较后请求的事务被动态图存储引擎接口1041接到，这时，该事务排到相应组的事务队列的末尾可能导致后执行。而一些情况下，如果先执行较后请求的事务可能会出现一些不确定的结果。因此，为了在先请求的事务在后执行得到不确定的执行结果，在一个实施例中，如图11所示，步骤330包括：

步骤3301、获取针对图元素的事务，所述事务带有请求时间戳；

步骤3302、确定所述事务针对的图元素所属的组；

步骤3303、按照所述请求时间戳的先后顺序，将所述事务放在确定的组的事务队列中排队。

也就是说，严格按照请求时间，将事务在事务队列中排队。将事务分配到各组的事务队列时，不一定是将事务输送到事务队列的末尾，而是按照请求时间戳的先后顺序重排，即每输送一个事务，重新排一次队。作为重新排队的结果，刚刚输送到事务队列中的事务，可能排到最前面。

下面对这些步骤进行详细描述。

步骤3301、获取针对图元素的事务，所述事务带有请求时间戳。

请求时间戳是作出事务请求的网络节点在请求时在请求中加入的、表明作出请求的时间的标记。

如上所述，事务是动态图更新中的不执行时不可再分的基本执行单元。图3中的动态图存储引擎接口1041在运行中可能接到的并不是一个个事务，因为网络节点105在发出请求时并不会判断其请求执行的指令是不是不执行时不可再分的。因此，图3中的动态图存储引擎接口1041接收到网络节点105的请求时，可以首先判断该请求是否是不执行时不可再分的。如果不是，则将该请求分成不执行时不可再分的基本单元，即事务。这样做的好处在于，在后续的过程中，尽量减少一个事务对多个组的图元素进行操作从而需要锁住多组的情况，尽量降低上锁对更新动态图的整体产生的影响。

因此，在一个实施例中，步骤3301包括：

接收对图元素进行更新的请求，所述请求中带有请求时间戳；

将所述请求分解成事务，所述事务带有与所述请求一致的请求时间戳，所述事务是仅对单个图元素进行操作的任务，或者是对多个图元素进行操作，但所述多个图元素的一部分在操作时才能确定。

在网络节点105加入或退出网络，或者网络节点105建立与取消与网络内其它网络节点105的关系，或者更新自己的属性，或者更新自己与其它网络节点105的关系的属性时，向动态图存储引擎接口1041发送一个请求，在请求中有作出该请求的时刻的时间戳。动态图存储引擎接口1041按照上述不执行时不可再分的原则将该请求分成事务。不执行时不可再分的原则换句话说，是指分成的事务是仅对单个图元素进行操作的任务，或者是对多个图元素进行操作，但所述多个图元素的一部分在操作时才能确定。

例如，对于将顶点0、3、4的优先级属性更新为最高这样一个请求，可以分解成将顶点0的优先级属性更新为最高、将顶点3的优先级属性更新为最高、将顶点4的优先级属性更新为最高这三个仅对单个图元素进行操作的事务。再例如，对于更新顶点0、3、4的所有满足属性x≥value1的邻接点的属性x为value2这样一个请求，可以分解为更新顶点0的所有满足属性x≥value1的邻接点的属性x为value2、更新顶点3的所有满足属性x≥value1的邻接点的属性x为value2、更新顶点4的所有满足属性x≥value1的邻接点的属性x为value2这样三个事务，这三个事务的每一个是对多个图元素进行操作，但所述多个图元素的一部分在操作时才能确定。

在步骤3302中，确定所述事务针对的图元素所属的组。

在一个实施例中，步骤3302包括：

将所述事务放在事务等待列表中排队，所述事务等待列表中的事务按照请求时间戳排队；

从事务等待列表中，按请求时间戳的先后顺序，取事务并确定该事务针对的图元素所属的组。

设置事务等待列表的好处在于，由于确定事务针对的图元素所属的组需要时间，如果获取到针对图元素的事务后，立即确定其所属的组并放入所属的组的事务队列，由于确定时间的存在，会产生较大的时延，影响总体效率。先将事务防在事务等待列表中，再从事务等待列表中取出，放置到事务队列中，便于对事务等待列表中的事务进行协同处理。

在一个实施例中，取事务并确定该事务针对的图元素所属的组包括：由多个线程依次从事务等待列表中取事务，并确定该事务针对的图元素所属的组。

由于该实施例由多个线程依次从事务等待列表中取事务，分别确定该事务针对的图元素所属的组，确定该事务针对的图元素所属的组时可以并行执行，相对于一个一个依次确定事务等待列表中的每个事务针对的图元素所属的组的方案，大大提高了整体处理效率。

例如，由三个线程依次从事务等待列表中各取一个事务，接下来每个线程会同时对其取的事务，同时确定其针对的图元素所属的组，大大提高了确定事务等待列表中的事务针对的图元素所属的组的效率。

在一个实施例中，确定该事务针对的图元素所属的组可以采取查找图元素与组对应关系表的方式。在动态图存储引擎接口1041中维护有一个图元素与组对应关系表，该表中预先存储着动态图中的图元素与其分到的组的对应关系。一旦分组关系发生了变化，动态图存储引擎接口1041立即更新该对应关系表。一旦有新的图元素加入到动态图，将它与一个组设置对应关系(后文中将详细讨论针对一个新的图元素，确定其所属的组)后，动态图存储引擎接口1041立即将该对应关系存储到对应关系表中。一旦有图元素从动态图中去除，动态图存储引擎接口1041立即将相应的对应关系从对应关系表中去除。

下面以图5为例说明上述过程。图5中，事务等待列表包括事务号、图元素、时间戳、内容四个字段。事务号是为获取的事务分配的序号，该序号具有唯一性。图元素是获取的事务针对的图元素。由于事务来源于网络节点的请求，图元素是从网络节点的请求中读出的。在事务是对多个图元素进行操作，但所述多个图元素的一部分在操作时才能确定的情况下，先将能确定的图元素填入事务等待列表中。例如，对于更新顶点0的所有满足属性x≥value1的邻接点的属性x为value2这样一个事务，先将能确定的图元素，即顶点0，填入图元素字段。内容是从请求中确定出的该事务执行的任务。例如，对于查询边6的“好友类型”这样一个属性的事务，其内容是查询“好友类型”属性。对于更新顶点0的所有满足属性x≥value1的邻接点的属性x为value2这样一个事务，内容是更新所有满足属性x≥value1的邻接点的属性x为value2。

假设事务等待列表107中仅放置有“事务号：1；图元素：6；时间戳：0：01:39；内容：查询属性”、“事务号：3；图元素：0；时间戳：0：01:42；内容：去除相邻顶点”这样两个事务，这时动态图存储引擎接口1041获取到“事务号：2；图元素：5；时间戳：0：01:40；内容：查询属性”这样一个事务，该事务的请求时间戳比2号事务晚。这是完全有可能的，因为网络有延迟，请求得早的请求可能比请求得晚的请求后接收到。由于该事务的请求时间戳在1号事务和3号事务的请求时间戳之间，因此，将2号事务放置在事务等待列表107中1号事务和3号事务之间。

在一个实施例中，如果两个事务分别是对同一图元素的更新事务和查询事务，且请求时间戳相同，则在事务等待列表中，将更新事务排在查询事务的前面。

这样做的好处是，确保查询事务查询到的是图元素或图元素的属性的最新结果。如果将查询事务在事务等待列表107中放置在更新事务的前面，则由于查询事务排在前面，会较先进入相应组的事务队列108。如果在事务队列108中仍然遵循先进先出的顺序的话，有可能查询事务先执行，而更新事务后执行。这样，查询事务查询到的结果不是最新结果。其查询到的属性由于之后的更新事务的存在又变化了，该查询结果没有意义。另外，即使在事务队列108中不遵循先进先出的顺序，而是按照请求时间戳重新排队，但如果该事务队列108恰好为空时，则进入该事务队列108的查询事务会一下子执行掉，也会出现类似的问题。

例如，两个事务中一个事务是对顶点0的优先级属性更新成1级，另一个事务是查询顶点0的优先权属性，这时要确保对顶点0的优先级属性更新成1级的事务在事务等待列表中排在查询顶点0的优先权属性的事务的前面。

在一个实施例中，如果两个事务不是分别对同一图元素的更新事务和查询事务，且请求时间戳相同，则在事务等待列表中，该两个事务的顺序可以是任意的。

如果两个事务不是分别对同一图元素的更新事务和查询事务，则该两个事务可能是针对不同图元素的事务，也可以都是针对同一图元素的更新事务，或针对同一图元素的查询事务。如果该两个事务是针对不同图元素的事务，由于其针对的图元素不同，其执行顺序对执行结果没有影响，因此，可以将它们的顺序设置为任意的。如果该两个事务是针对同一图元素的查询事务，查询事务不产生对图元素或其属性的改变，因此，也可以将它们的顺序设置为任意的。如果该两个事务是针对同一图元素的更新事务，其执行顺序会对执行结果有影响，但考虑到其请求时间戳一致，先执行哪一个都有道理，因此，它们的执行顺序也可以是任意的。

按照上述原则，如图5所示，形成的一个事务等待列表107，其目前有10个事务：

“事务号：1；图元素：6；时间戳：0：01:39；内容：查询属性”；

“事务号：2；图元素：5；时间戳：0：01:40；内容：查询属性”；

“事务号：3；图元素：0；时间戳：0：01:42；内容：去除相邻顶点”；

“事务号：4；图元素：3；时间戳：0：01:43；内容：更新属性”；

“事务号：5；图元素：3；时间戳：0：01:43；内容：查询属性”；

“事务号：6；图元素：1；时间戳：0：01:44；内容：去除本身和相邻顶点”；

“事务号：7；图元素：4；时间戳：0：01:44；内容：去除本身和相邻顶点”；

“事务号：8；图元素：0；时间戳：0：01:45；内容：更新属性”；

“事务号：9；图元素：8；时间戳：0：01:45；内容：查询属性”；

“事务号：10；图元素：0；时间戳：0：01:46；内容：查询属性”。

假设有三个线程A、B、C依次从事务等待列表107中取事务，并确定该事务针对的图元素所属的组。例如，事务号1、2、3分别被线程A、B、C取出，事务号4、5、6分别被线程A、B、C取出，事务号7、8、9分别被线程A、B、C取出，事务号10被线程A取出。针对事务号1，线程A根据图元素6查找对应关系表，得到其对应的组是组1；针对事务号2，线程B根据图元素5查找对应关系表，得到其对应的组是组2；针对事务号3，线程C根据图元素0查找对应关系表，得到其对应的组是组1；针对事务号4，线程A根据图元素3查找对应关系表，得到其对应的组是组1；针对事务号5，线程B根据图元素3查找对应关系表，得到其对应的组是组1；针对事务号6，线程C根据图元素1查找对应关系表，得到其对应的组是组2；针对事务号7，线程A根据图元素4查找对应关系表，得到其对应的组是组2；针对事务号8，线程B根据图元素0查找对应关系表，得到其对应的组是组1；针对事务号9，线程C根据图元素8查找对应关系表，得到其对应的组是组3；针对事务号10，线程C根据图元素0查找对应关系表，得到其对应的组是组1。

在步骤3303中，按照所述请求时间戳的先后顺序，将所述事务放在确定的组的事务队列中排队。

在一个实施例中，步骤3303可以包括：将该事务与确定的组的事务队列中的事务，按照请求时间戳重排排队。

在另一个实施例，步骤3303可以包括：

将该事务放在确定的组的事务队列的末尾；

将该事务与该事务队列中排在该事务前一位的事务的请求时间戳进行比较，如果该事务的请求时间戳早于该前一位的事务的请求时间戳，则与该前一位的事务互换，直到该事务的请求时间戳晚于前一位的事务的请求时间戳。

这个实施例相对于每次在事务队列中加入一个事务，就要重新排一次队的实施例，具有很大的好处。这是因为，它没有打乱在事务队列中已经存在的事务的排好的顺序，只是将新加入的事务通过从末尾依次比较的方式，插入到事务队列中一个合适的位置，大大减少了形成新的按请求时间戳排序的队列所用的时间。

在一个实施例中，在该步骤中，如果所属组相同的多个事务的请求时间戳相同，将更新事务排在查询事务的前面。

这样做的好处是，确保查询事务查询到的是图元素或图元素的属性的最新结果。如果将查询事务在同一个事务队列108中放置在更新事务的前面，则由于查询事务排在前面，会先执行。这样，查询事务查询到的结果可能不是最新结果。如果查询事务和更新事务针对的是同一图元素的同一属性，查询事务查询到的属性由于之后的更新事务的存在又变化了，使得该查询结果没有意义。

如果所属组相同的多个事务的请求时间戳相同、又都是查询事务，在一个实施例中，这多个事务的排队顺序可以是任意的，因为查询事务不改变图元素或图元素的属性，它们的执行顺序都最终的结果没有影响。

如果所属组相同的多个事务的请求时间戳相同、又都是更新事务，在一个实施例中，这多个事务的排队顺序也可以是任意的，因为这多个更新事务执行的先后顺序可能会对最后的执行结果有影响，但考虑到它们的请求时间戳一致，无论先执行哪一个都是有道理的，因此，这多个事务的排队顺序可以是任意的。

然而，为了防止在非常接近的时间点发出对同一图元素或同一图元素的同一属性的更新请求的两个网络节点对自己的请求的执行结果都是可预期的，在一个实施例中，可以采取仅接受一个请求的更新，而对另一个请求的发出者发出重请求指示的方式。该方式与上述任意设置其排队顺序且不作任何通知的方式相比，大大提高了网络节点对自己请求的结果的可预期性。即，如果其请求得到了执行，则是理想的情况；万一其请求未得到执行，其至少被通知，然后其可以重复发送请求，来将图元素或其属性更新成其所期望的那样。

因此，在一个实施例中，在该步骤中，如果所属组相同的多个事务的请求时间戳相同、又都是更新事务，只将所述多个事务中的一个放在事务队列中排队，向所述多个事务中的其它事务的请求终端发出重请求指示。

在本公开的一个实施例中，所述请求时间戳为CPU周期级别。这样，可以尽量减少如果所属组相同的多个事务的请求时间戳相同、又都是更新事务，向所述多个事务中的其它事务的请求终端发出重请求指示的情况

如图5所示，将确定所属组为组1的事务“事务号：1；图元素：6；时间戳：0：01:39；内容：查询属性”、“事务号：3；图元素：0；时间戳：0：01:42；内容：去除相邻顶点”、“事务号：4；图元素：3；时间戳：0：01:43；内容：更新属性”、“事务号：5；图元素：3；时间戳：0：01:43；内容：查询属性”、“事务号：8；图元素：0；时间戳：0：01:45；内容：更新属性”、“事务号：10；图元素：0；时间戳：0：01:46；内容：查询属性”放在组1的事务队列中排队。按照时间戳的先后顺序，排队如下：

“事务号：1；图元素：6；时间戳：0：01:39；内容：查询属性”；

“事务号：3；图元素：0；时间戳：0：01:42；内容：去除相邻顶点”；

“事务号：4；图元素：3；时间戳：0：01:43；内容：更新属性”；

“事务号：5；图元素：3；时间戳：0：01:43；内容：查询属性”；

“事务号：8；图元素：0；时间戳：0：01:45；内容：更新属性”；

“事务号：10；图元素：0；时间戳：0：01:46；内容：查询属性”。

其中，事务号4和事务号5的时间戳都是0：01:43，但由于事务号4是更新事务，事务号5是查询事务，因此，将事务号4排在事务号5的前面。

将确定所属组为组2的事务“事务号：2；图元素：5；时间戳：0：01:40；内容：查询属性”、“事务号：6；图元素：1；时间戳：0：01:44；内容：去除本身和相邻顶点”、“事务号：7；图元素：4；时间戳：0：01:44；内容：去除本身和相邻顶点”放在组2的事务队列中排队。但是，事务号6和事务号7的时间戳都是0：01:44，且都是更新事务，因此，仅随机保留其中一个事务，即事务号6，而将事务号7丢弃，同时，向发出事务号7的网络节点发出重请求指示，以便发出事务号7的网络节点认为这一更新事务很重要时，重新发出请求。在组2的事务队列中，

按照时间戳的先后顺序，排队如下：

“事务号：2；图元素：5；时间戳：0：01:40；内容：查询属性”；

“事务号：6；图元素：1；时间戳：0：01:44；内容：去除本身和相邻顶点”。

将确定所属组为组3的事务“事务号：9；图元素：8；时间戳：0：01:45；内容：查询属性”放在组3的事务队列中排队。该事务队列中当前只有该一个事务。

接着，在步骤340中，响应于非并行性事务对图元素进行操作，将图元素所属的组锁住，禁止其它组的事务队列中的事务进行图元素操作。

非并行性事务是指不能与其它事务同时针对同一个组的图元素执行的事务。在一个实施例中，如上所述，它包括去除顶点、增加边中的至少一个。

锁住的含义是指，只允许该非并行性事务对该组中的任何图元素或其属性进行操作，而不允许其它任何事务对该组中的任何图元素或其属性进行操作，直到该组被解锁。它可以有效保证在事务的执行过程中，事务针对的图元素或其属性不会被其它事务同时操作，造成操作异常。不允许其它任何事务对该组中的任何图元素或其属性进行操作包括：不允许该非并行性事务所在的组的其它事务对该组中的任何图元素或其属性进行操作、以及不允许其它组的事务对该组中的任何图元素或其属性进行操作。对于前者，由于在同一组的事务队列中，事务按照排队的顺序进行图元素操作，在一个事务未操作完时另一个事务不得对该组中的图元素或其属性进行操作，这就保证了该组的其它事务不会与该非并行性事务同时，对该组中的图元素或其属性进行操作。因此，在本公开的实施例中，不允许其它任何事务对该组中的任何图元素或其属性进行操作，主要是指后者，即不允许其它组的事务对该组中的任何图元素或其属性进行操作。虽然其它组的事务应主要针对该其它组内的图元素或其属性进行操作，但也不排除有时会操作当前非并行性事务所在的组的图元素。这是因为，如上所述，事务中有一部分事务是对多个图元素进行操作，但所述多个图元素的一部分在操作时才能确定。

如图6所示，当组1的事务队列中开始执行事务号3时，组2的事务队列中开始执行事务号6。事务号3是针对顶点0的事务，内容是去除顶点0的相邻节点。在动态图中查询到，顶点0的相邻顶点为顶点1和3(如图5所示)。顶点3仍然属于组1，而顶点1是属于组2的。可以看出，在执行某些事务的时候，可能事务不仅需要对事务所在的事务队列的组中的图元素进行操作，还有可能需要对其它组的图元素进行操作。在该例中，事务号3是去除顶点的事务，属于非并行性事务。事务号3在执行时，需要对顶点1和3进行操作。顶点1和3所属的组是组1和组2。因此，事务号3在执行时，将组1和组2锁住，然后对顶点1和3进行操作。这样，其它组的事务队列在锁住期间，无法对组1和组2中的图元素进行操作。

类似地，事务号6是针对顶点1的事务，内容是去除顶点1本身和相邻节点。在动态图中查询到，顶点1的相邻顶点为顶点0、2、3、4(如图5所示)。顶点0、3属于组1，顶点1、4是属于组2的，顶点2是属于组3的。因此，事务号6也是一个执行时不仅需要对本组的图元素进行操作，还要对其它组的图元素进行操作的事务。在该例中，事务号6是去除顶点的事务，属于非并行性事务。事务号6在执行时，需要对顶点0-4进行操作。顶点0-4所属的组是组1、组2、组3。因此，事务号6在执行时，将组1、组2、组3锁住，然后对顶点0-4进行操作。这样，其它组的事务队列在锁住期间，无法对组1-3中的图元素进行操作。

这样，产生了一个问题：如图6所示，由于事务号3执行时需要将组1-2锁住，事务号6执行时需要将组1-3锁住，如果在组1的事务队列中的事务号3和组2的事务队列中的事务号6都排到了第一位，都开始执行，其中事务号3先锁住了组1，然后在开始锁组2的时候，发现组2已经被事务号6锁住了，此时事务号3就无法正常执行，而事务号6同样无法正常执行，因为事务号6执行时需要锁住的组1无法锁住。因此，事务号3和事务号6僵持不下，都无法正常执行。

因此，为了避免两个以上非并行性事务同时需要对多个组的图元素进行操作，而各自锁住所述多个组的一部分，造成所述两个以上非并行性事务都无法正常执行，在一个实施例中，步骤340可以包括：如果该非并行性事务对多个组的图元素进行操作，按所述多个组的预定顺序锁住所述多个组。

所述预定顺序为事先指定的顺序。最常见的一种顺序按组号的升序进行锁住。当然，也可以按组号的降序进行锁住。还可以既不按升序，也不按降序，而是按照预先存储的组号序列进行锁住，例如，1-4-3-2-5，表示先尝试锁住组1，然后尝试锁住组4，然后尝试锁住组3，然后尝试锁住组2，然后尝试锁住组5。

按所述多个组的预定顺序锁住所述多个组可以按时序进行。一个时序中，一旦某一事务锁住了某个组，该时序被该事务占有，其它事务无法锁住该组。而在下一个时序，该事务可以尝试锁住预定顺序中的下一组，而其它事务却仍要尝试锁该组，不能去锁下一组。按所述多个组的预定顺序锁住所述多个组的方式，保证了不会发生锁冲突，即两个以上非并行性事务同时需要对多个组的图元素进行操作，而各自锁住所述多个组的一部分，造成所述两个以上非并行性事务都无法正常执行的情况。

例如，在按组号的升序锁住组1-3的情况下，两个事务队列中的第一位的两个事务A、B都想要按照组号的升序锁住组1-3。事务A、B都要先锁住组1。事务A、B中最早开始尝试锁住的一个，例如事务A，在时序1成功锁住了组1，那么时序1被事务A占有，事务B就无法利用时序1锁住组1。接着，在时序2，事务A开始锁组2，事务B却只能重复锁组1，由于组1被事务A锁住未解锁，事务B是无法锁住组1的。而事务B锁不住组1，由于需要遵循升序，也无法去锁组2。因此，事务A很顺利地依次锁住了组1-3，而事务B只能等到事务A解锁组1后，才能依次锁住组1-3。通过这种方式，避免了事务A锁住了组1，而事务B锁住了组2或组3，造成事务A、B都无法正常执行，陷入死循环。

如图6所示，事务号3的执行需要锁住组1-2，事务号6的执行需要锁住组1-3。在时序1，事务号3成功锁住了组1，那么时序1被事务号3占有，事务号6就无法利用时序1锁住组1。接着，在时序2，事务号3开始锁组2，事务号6却只能重复锁组1。由于组1被事务号3锁住未解锁，事务号6是无法锁住组1的。而事务号6锁不住组1，由于需要遵循升序，也无法去锁组2或3。因此，事务号3很顺利地依次锁住了组1-2，而事务号6只能等到事务号3解锁组1后，才能依次锁住组1-3。

如图10所示，在一个实施例中，所述方法还包括：步骤350、响应于该非并行性事务对图元素操作完，解锁图元素所属的组。

解锁的含义就是指解除锁住的状态，即，允许其它任何事务对该组中的任何图元素或其属性进行操作。允许其它任何事务对该组中的任何图元素或其属性进行操作包括：允许该非并行性事务所在的组的其它事务对该组中的任何图元素或其属性进行操作、以及允许其它组的事务对该组中的任何图元素或其属性进行操作。对于前者，由于在同一组的事务队列中，事务按照排队的顺序进行图元素操作，在一个事务操作完时，在事务队列中的下一个事务自然可以对该组中的图元素或其属性进行操作，而在事务操作完后的解锁，就保证了该下一个事务可以对该组中的图元素或其属性进行操作。对于后者，即允许其它组的事务对该组中的任何图元素或其属性进行操作，意思是说，其它组的事务如果在执行过程中需要针对本组的图元素进行操作，允许这种操作。例如，其它组的事务是对该其它组内的某一顶点相邻的顶点的某一属性进行更新，而有一个相邻的顶点正好是本组内的一个顶点，这时，在解锁了本组后，就允许这种操作。

响应于该非并行性事务对图元素操作完，解锁图元素所属的组的意义在于及时释放组，使组中的图元素及时被其它事务操作，提高动态图更新的效率。

在一个实施例中，如图7所示，所述组包括与组中的图元素对应的最近更新时间戳110。如图3所示，图元素在存储设备1042中并非以拓扑图的形式存储的，而是以一定的数据结构存储的。在存储的数据结构中，包括图元素和对应的最近更新时间戳。图7中，最近更新时间戳110是与图元素号对应存储的。最近更新时间戳110是指该图元素最后一次被更新时执行该更新的事务的请求时间戳，并非发生更新的时间。

如图12所示，在将图元素所属的组锁住后，所述方法还包括：

步骤360、将事务的请求时间戳与所述最近更新时间戳进行比较；

步骤370、如果事务的请求时间戳晚于所述最近更新时间戳，才执行事务的图元素操作，并用事务的请求时间戳更新所述最近更新时间戳。

一般来说，将图元素所属的组锁住后，该事务就可以针对锁住的组中的图元素进行操作。但是，如果事务的请求时间戳早于最近更新时间戳，由于最近更新时间戳是图元素最后一次被更新时执行该更新的事务的请求时间戳，说明在当前事务之后请求的事务已经对图元素操作了。这可能是由于网络传输原因，使得后请求的事务先进入事务队列而执行造成的。这时，有可能该事务没有必要执行了，因为在后请求的事务的图元素操作有可能就是为了刷新在先请求的事务的图元素操作。而如果事务的请求时间戳晚于所述最近更新时间戳，这时执行事务的图元素操作则是有必要的。这时，要用事务的请求时间戳更新所述最近更新时间戳，确保最近更新时间戳反映该图元素最后一次被更新时执行该更新的事务的请求时间戳。

如图7所示，组1中有4个图元素：顶点0、顶点3、边6、边9。顶点0的最近更新时间戳为7:14：29，顶点3的最近更新时间戳为7:13：38，边6的最近更新时间戳为7:18：30，边9的最近更新时间戳为7:14：20。这时，组1的事务队列中排在最前面的事务为“事务号：11；图元素：6；时间戳：7:14:30；内容：查询属性”。由于边6的最近更新时间戳为7:18：30晚于该事务的请求时间戳7:14:30，该事务是较先请求的，可能由于网络原因较后到达。在这种情况下，不执行该事务。

因此，设置最近更新时间戳，并且如果事务的请求时间戳晚于所述最近更新时间戳，才执行事务的图元素操作，这样做的好处是，防止图元素更新过程中的不一致性。

在一个实施例中，所述方法还包括：如果事务的请求时间戳早于所述最近更新时间戳，向请求该事务的网络节点发送过期响应消息。

在该实施例中，如果事务的请求时间戳早于所述最近更新时间戳，也就是说，比当前事务晚请求的事务已经对图元素进行了操作，向请求该事务的网络节点发送过期响应消息，以通知请求该事务的网络节点请求过期。如果该网络节点认为再请求一次有必要，其会重新进行请求，此时重新请求的事务的请求时间戳一定会晚于所述最近更新时间戳，因而一定会执行。该实施例的好处在于，通知请求该事务的网络节点，让网络节点根据需要进行重请求或不重请求的处理，在提高更新效率的同时最大满足了用户的体验。

另外，在上述步骤3302中，确定所述事务针对的图元素所属的组采取查找图元素与组对应关系表的方式。但是，如果事务是一个增加新图元素的事务，这时无法通过查找图元素与组对应关系表来确定组。

为了均衡各组之间的处理负载，在一个实施例中，步骤3302包括：如果所述事务是关于增加图元素的事务，将所述图元素确定到当前事务队列最短的组中。

这样做的好处是，当前事务队列最短的组，当前的负载最小，将该图元素确定到该组中，有利于当前的负载平衡。

如图8所示，组1的事务队列中排了6个事务，组2的事务队列中排了2个事务，组3的事务队列中排了1个事务。事务号11是一个新增加顶点11的事务，由于组3的队列最短，将顶点11确定到组3中，同时将事务号11分配到组3的事务队列中排队。

另外，在一个实施例中，还要将所述图元素和该组的对应关系存储到所述图元素与组对应关系表中，以便以后对该图元素进行操作的事务都分配到该组的队列中，实现操作的统一性。

在另一个实施例中，步骤3302包括：如果所述事务是关于增加图元素的事务，将所述图元素确定到当前事务队列执行时间最小的组中。

由于每个事务执行需要的时间不同，例如查询属性的事务需要时间短，更新属性的事务需要时间稍长一些，因此，事务队列的事务数目少，未必处理总时长短。将所述图元素确定到当前事务队列执行时间最小的组中，更有利于均衡各组的处理负载。

在一个实施例中，将所述图元素确定到当前事务队列执行时间最小的组包括：

针对各组的事务队列中的每个事务，基于事务内容，查找事务内容类型与执行时间对应关系表，确定每个事务的执行时间；

基于组的事务队列中每个事务的执行时间，确定组的事务队列执行时间；

将所述图元素确定到事务队列执行时间最小的组中。

在该实施例中，可以预先将事务内容分成事务内容类型，如更新属性、查询属性、增加顶点、增加边、去除顶点、去除边、更新相邻顶点的属性，等等。每种事务内容类型的事务执行起来，用的时间是相同的。预先将事务内容类型与该类型的事务的执行时间相对应地存储到事务内容类型与执行时间对应关系表中。例如，下表是一个事务内容类型与执行时间对应关系表的例子。

事务内容类型	执行时间(ms)
		查询属性	0.1
更新属性	0.2
		增加顶点	0.2
增加边	0.3
		去除顶点	0.4
去除边	0.3
		更新相邻顶点的属性	1.2
更新本身和相邻顶点的属性	1.4
		……	……

如图8所示，对于组1的事务队列中的事务号1，其内容为“查询属性”，查找上述对应关系表，得知执行时间为0.1ms；对于组1的事务队列中的事务号3，其内容为“更新相邻顶点的属性”，查找上述对应关系表，得知执行时间为1.2ms；对于组1的事务队列中的事务号4，其内容为“更新属性”，查找上述对应关系表，得知执行时间为0.2ms；对于组1的事务队列中的事务号5，其内容为“查询属性”，查找上述对应关系表，得知执行时间为0.1ms；对于组1的事务队列中的事务号8，其内容为“更新属性”，查找上述对应关系表，得知执行时间为0.2ms；对于组1的事务队列中的事务号10，其内容为“查询属性”，查找上述对应关系表，得知执行时间为0.1ms。因此，组1的事务队列执行时间＝0.1+1.2+0.2+0.1+0.2+0.1＝1.9(ms)。

对于组2的事务队列中的事务号2，其内容为“查询属性”，查找上述对应关系表，得知执行时间为0.1ms；对于组2的事务队列中的事务号6，其内容为“更新本身和相邻节点属性”，查找上述对应关系表，得知执行时间为1.4ms。因此，组2的事务队列执行时间＝0.1+1.4＝1.5(ms)。

对于组3的事务队列中的事务号9，其内容为“查询属性”，查找上述对应关系表，得知执行时间为0.1ms。因此，组3的事务队列执行时间＝0.1ms。

由于组3的事务队列执行时间最小，将图元素11确定到组3中。

如图13所示，在一个实施例中，所述方法还包括：

步骤375、在执行事务的图元素操作后，记录操作时间；

步骤380、每隔预定时间段，确定每个图元素在该预定时间段的处理负载，该处理负载等于该预定时间段内该图元素的记录的操作时间之和。

在该实施例中，在每个事务操作后，记录操作时间。操作时间是指事务进行操作用的时长。

处理负载是指处理带来的开销，它可以体现为处理所用的时间、处理所用的资源(包括内存)、处理消耗的处理器能力等等。在本实施例中，将预定时间段内(例如规定1天)对图元素的操作时间之和作为在该预定时间段内该图元素的处理负载。单次事务对某一图元素操作的时间越长，在这单次事务中该图元素的处理负载越大；在预定时间段内对某一图元素操作的事务越多，该图元素的处理负载也越大。因此，将预定时间段内对图元素的操作时间之和作为在该预定时间段内该图元素的处理负载，比单纯考量单次事务对图元素操作时间的长短、和单纯考量预定时间段内对图元素操作的事务数目，确定的处理负载更合理。

在该实施例中，步骤3302包括：如果所述事务是关于增加图元素的事务，确定当前每个组的图元素在前一预定时间段的处理负载之和，并将所述图元素确定到所述处理负载最小的组内。

将连续的时间轴划分成一个一个的预定时间段，例如一天。在每个预定时间段，确定每个图元素在该预定时间段的处理负载，该处理负载等于该预定时间段内该图元素的记录的操作时间之和，以供下一时间段使用。在当前时间段使用的是上一时间段每个图元素的处理负载。

该实施例的好处是：当前事务队列最短的组，或者当前事务队列执行时间最小的组，只是反映了当前的各组的负载情况，没有反映在一个时期内的长期状况。实际上，当前事务队列最短的组，或者当前事务队列执行时间最小的组，着眼于一个时期来考虑，其处理负载未必小。该实施例着眼于一个时期来考虑负载最小的组，将增加的图元素确定到一个时期内处理负载最小的组中，从长期的角度均衡了各组的处理负载。另外，由于每隔预定时间段(例如每隔1天)，就会确定每个图元素在该预定时间段的处理负载，也就会重新确定处理负载最小的组。确定的处理负载最小的组会在各个预定时间段不同。因此，该实施例能够反映各组的处理负载的动态变化，实现了动态地将新增加的图元素确定到不同的组。

例如，以预定时间段为1天为例，则每个图的图元素在前一预定时间段的处理负载之和就是图元素在前一天的处理负载之和。以图8为例，组1包括顶点0、顶点3、边6、边9。在前一天，顶点0被4个事务操作，操作时长分别为0.1ms,0.2ms,0.2ms,0.4ms,因此前一天顶点0的处理负载为0.1+0.2+0.2+0.4＝0.9(ms)。在前一天，顶点3被3个事务操作，操作时长分别为0.4ms,0.2ms,0.2ms,因此前一天顶点3的处理负载为0.4+0.2+0.2＝0.8(ms)。在前一天，边6被2个事务操作，操作时长分别为1.2ms,0.1ms,因此前一天边6的处理负载为1.2+0.1＝1.3(ms)。在前一天，边9被3个事务操作，操作时长分别为0.4ms,0.1ms,0.1ms,因此前一天边9的处理负载为0.4+0.1+0.1＝0.6(ms)。因此，前一天，组1的处理负载之和为0.9+0.8+1.3+0.6＝3.6(ms)。

组2包括顶点1、顶点4、边5、边7、边10。在前一天，顶点1被5个事务操作，操作时长分别为0.1ms,0.2ms,0.1ms,0.2ms,0.4ms,因此前一天顶点1的处理负载为0.1+0.2+0.1+0.2+0.4＝1(ms)。在前一天，顶点4被3个事务操作，操作时长分别为0.4ms,0.4ms,0.1ms,因此前一天顶点4的处理负载为0.4+0.4+0.1＝0.9(ms)。在前一天，边5被1个事务操作，操作时长为0.2ms,因此前一天边5的处理负载为0.2ms。在前一天，边7被4个事务操作，操作时长分别为0.4ms,0.1ms,0.1ms,0.1ms,因此前一天边7的处理负载为0.4+0.1+0.1+0.1＝0.7(ms)。在前一天，边10被2个事务操作，操作时长分别为0.4ms,0.2ms,因此前一天顶点1的处理负载为0.4+0.2＝0.6(ms)。因此，前一天，组2的处理负载之和为1+0.9+0.2+0.7+0.6＝3.4(ms).

组3包括顶点2和边8。在前一天，顶点2被3个事务操作，操作时长分别为1.4ms，0.2ms,0.1ms,因此前一天顶点2的处理负载为1.4+0.2+0.1＝1.7(ms)。在前一天，边8被2个事务操作，操作时长分别为1.4ms，1.2ms,因此前一天边8的处理负载为1.4+1.2＝2.6(ms)。因此，前一天，组3的处理负载之和为1.7+2.6＝4.3(ms).

因此，在该例中，组2在前一天的处理负载之和最小，将顶点11确定到组2中。

在另一个实施例中，如图14所示，所述方法还包括：

步骤375、在执行事务的图元素操作后，记录操作时间；

步骤380、每隔预定时间段，确定每个图元素在该预定时间段的处理负载，该处理负载等于该预定时间段内该图元素的记录的操作时间之和；

步骤385、由机器学习模型根据之前每个预定时间段每个图元素的处理负载，对接下来的预定时间段各图元素的处理负载进行预测。

在该实施例中，步骤3302包括：

如果所述事务是关于增加图元素的事务，将所述图元素确定到预测处理负载最小的组内。

机器学习模型可以应用于数据预测。该机器学习模型55事先用大量的图元素处理负载变化曲线样本构成的集合进行训练。图元素处理负载变化曲线样本是指，针对一个图元素，将其在各个预定时间段(例如每天)的处理负载(例如在该天该图元素的操作时间之和)记录下来，描绘成的一条作为样本的曲线。将该曲线样本输入机器学习模型。机器学习模型根据曲线样本中第1、2……i天的处理负载，利用机器学习的方法调整机器学习模型中的各项系数，使得对于曲线样本中第1、2……i天的处理负载，经过机器学习模型的各项系数运算，输出结果为预测的第i+1天的处理负载。然后，与曲线样本中第i+1天的处理负载进行对比。如不一致，调整机器学习模型中的各项系数，使二者一致。然后，机器学习模型再根据曲线样本中第1、2……i、i+1天的处理负载，经过机器学习模型的各项系数运算，输出结果为预测的第i+2天的处理负载。然后，与曲线样本中第i+2天的处理负载进行对比。如不一致，调整机器学习模型中的各项系数，使二者一致。如此反复进行，而对于集合中的每个图元素处理负载变化曲线样本，都这样进行。这样，就不断训练机器学习模型中的各项系数，使机器学习模型根据图元素之前每个预定时间段的处理负载，对接下来的预定时间段该图元素的处理负载进行预测。

在该实施例中，如果所述事务是关于增加图元素的事务，不是将图元素确定到在前一预定时间段的图元素处理负载之和最小的组，而是由机器学习模型根据之前各预定时间段该图元素的处理负载，对本预定时间段各图元素的处理负载进行预测，并将所述图元素确定到预测处理负载最小的组内。这样，就保证了将图元素划分到的组是在本预定时间段内预测处理负载最小的组，相比于将图元素划分到历史上处理负载最小的组，提高了分组精确性，更加有利于各组之间负载的真正均衡。

上述处理负载以处理时间为例进行了说明。但本领域技术人员应当理解，处理负载也可以体现为处理所用的资源(包括内存)、处理消耗的处理器能力等等。例如，在执行事务的图元素操作后，记录占用内存。每隔预定时间段，确定每个图元素在该预定时间段的总占用内存。将图元素确定到在前一预定时间段的所有图元素的总占用内存最小的组。

另外，如图15所示，在一个实施例中，步骤3302包括：

步骤33021、如果所述事务是关于增加边的事务，确定所述边的顶点；

步骤33022、将所述边确定到所述边的顶点之一所属的组中。

在将新图元素确定到一个组中，还有一个需要考量的因素，即尽量保证在动态图中相邻的图元素，尽可能地划到同一个组中。这是因为，有很多诸如“更新顶点X的相邻边的属性Y”、“更新顶点X的相邻顶点的属性Y”、“去掉顶点X和其所有相邻顶点”等事务。如果将相邻的图元素尽可能放在一个组中，有利于这类事务的执行，使这类事务执行时尽可能少锁住一些组，提高动态图的整体更新效率。

因此，在该实施例中，如果所述事务是关于增加边的事务，要尽量将所述边确定到所述边的顶点之一所属的组中。例如，事务是增加边12的事务，其中边12是顶点2和顶点3之间的边。因此，将边12确定到顶点2所属的组，即组3中，或者将边12确定到顶点3所属的组，即组1中。

同理，在另一个实施例中，步骤3302包括：

如果所述事务是关于增加顶点且在该顶点和已有顶点之间增加边的事务，将所述增加的顶点和边确定到所述已有顶点所属的组中。

该事务是增加一个顶点，且在该顶点和已有顶点之间增加边，如果将该顶点和边与已有顶点放在一个组中，可以使得事务执行时尽可能少锁住一些组，提高动态图的整体更新效率。

例如，该事务是增加顶点13，且该顶点13与已有的顶点4之间增加一个边14。顶点4是属于组2的。因此，将顶点13和边14可以一并确定到组2中。

另外，步骤310中，在一个实施例中，将动态图的图元素分成多个组也可以考虑尽量将相邻图元素放到一个组中。这样，有利于诸如“更新顶点X的相邻边的属性Y”、“更新顶点X的相邻顶点的属性Y”、“去掉顶点X和其所有相邻顶点”等事务的执行效率，也使这类事务执行时尽可能少锁住一些组，提高动态图的整体更新效率。

因此，在一个实施例中，步骤310包括：按照所述图元素的邻接关系，将动态图的图元素分成多个组。

如图16所示，在一个实施例中，所述按照所述图元素的邻接关系，将动态图的图元素分成多个组，包括：

步骤3101、确定动态图的图元素数；

步骤3102、用动态图的图元素数除以组数，得到每组平均图元素数；

步骤3103、基于所述每组平均图元素数，将动态图分成所述动态子图，其中每个动态子图是动态图上一个联通的区域，两个相邻动态子图的边界经过边，避开顶点，将经过的边划分为属于两个相邻动态子图之一；

步骤3104、将每个动态子图中的全部图元素，作为一个组。

在该实施例中，不仅考虑将相邻的图元素尽可能划到同一个组中，还考虑到让每个组的图元素数量均衡，它的好处是可以比较好地均衡各组之间的负载。

首先，确定动态图的图元素数，包括动态图的所有顶点数加上边数。然后，用动态图的图元素数除以组数，得到每组平均图元素数。该组数是预定的。该平均图元素数不一定是整数，可能带有小数。如果是整数，则步骤3103中，将动态图分成所述动态子图，使得每个动态子图中包含该整数个图元素。如果是小数，则步骤3103中，将动态图分成所述动态子图，使得每个动态子图中包含的图元素的数目要么是该小数的整数部分，要么是该小数的整数部分+1，但要保证每个动态子图中包含的图元素的数目之和仍然等于该动态图中的图元素数目。

动态子图是动态图上一个联通的区域。联通的区域是指该区域是连在一起的，没有被其它区域隔开。如图9A所示，用两条虚线分成三个区域，三个区域都各自是连在一起的，没有被其它区域隔开，因此是联通的区域。另外，确保两个相邻动态子图的边界从边经过，而不从顶点经过。这样做的好处是，如果顶点在两个组之间，该顶点相关的边就可能归入三个以上组中的一个，增大处理开销。这样，两个相邻动态子图的边界只从边经过，该边最多归入两个组中的一个，处理开销较小。将经过的边划分为属于两个相邻动态子图之一可以采取随机的方式，但在划分的时候要考虑，让动态子图中包含的图元素的数目要么是该小数的整数部分，要么是该小数的整数部分+1，且要保证每个动态子图中包含的图元素的数目之和仍然等于该动态图中的图元素数目。

如图9A所示，对于该动态图，有5个顶点(顶点0-4)和6个边(边6-10)，共11个图元素。划分成3组。11/3＝3.67。因此，可以让二组分别具有4个图元素，1组具有3个图元素。图9A中的两条虚线将动态图分成3个动态子图。左边的虚线经过边5、6、8。为了使组4包含4个图元素，将它们连同顶点0都归入组1。右边的虚线经过边5、6、7、10，其中边5、6已经归入组1，可以将边7、10连同顶点2、3一起归入组3。中间剩下的顶点1、4和边9归入组2。

该实施例的优点在于，可以通过均衡每个组中图元素的数目，达到一定程度的均衡各组之间的负载的目的。

如图13所示，在一个实施例中，该方法还可以包括：

步骤375、在执行事务的图元素操作后，记录操作时间；

步骤380、每隔预定时间段，确定每个图元素在该预定时间段的处理负载，该处理负载等于该预定时间段内该图元素的记录的操作时间之和。

关于步骤375和步骤380，已经在上面详细描述。

在该实施例中，所述按照所述图元素的邻接关系，将动态图的图元素分成多个组，包括：

根据动态图的每个图元素在前一预定时间段的处理负载，将动态图分成所述动态子图，使得每个动态子图中全部图元素在前一预定时间段的处理负载之和均衡，其中每个动态子图是动态图上一个联通的区域，两个相邻动态子图的边界经过边，避开顶点，将经过的边划分为属于两个相邻动态子图之一。

该实施例考虑了让相邻的图元素尽可能分在一个组中，这样，有利于诸如“更新顶点X的相邻边的属性Y”、“更新顶点X的相邻顶点的属性Y”、“去掉顶点X和其所有相邻顶点”等事务的执行效率，也使这类事务执行时尽可能少锁住一些组，提高动态图的整体更新效率。另外，该实施例还同时兼顾了让各个组的处理负载均衡。其采用的方法是，每隔预定时间段(例如每天)，确定各图元素在该预定时间段的处理负载，该处理负载等于该预定时间段内该图元素的记录的操作时间之和。然后，基于根据动态图的每个图元素在前一预定时间段的处理负载，将动态图分成所述动态子图，使得每个动态子图中全部图元素在前一预定时间段的处理负载之和均衡。这可以通过自适应均衡算法实现。

在一个实施例中，将动态图分成所述动态子图，使得每个动态子图中全部图元素在前一预定时间段的处理负载之和均衡，可以包括：

确定动态图的全部图元素在前一预定时间段的处理负载之和；

用该处理负载之和除以组数，得到每组处理负载；

基于所述每组处理负载，将动态图分成所述动态子图，使得利用自适应均衡算法，让每个动态子图中的图元素在前一预定时间段的处理负载之和逼近所述每组处理负载，其中每个动态子图是动态图上一个联通的区域，两个相邻动态子图的边界经过边，避开顶点，将经过的边划分为属于两个相邻动态子图之一。

例如，在以一天内图元素的操作时间之和为处理负载的情况下，图9B的各图元素在前一天处理负载分别为：

动态图的全部图元素在前一天的处理负载之和＝2.1+0.4+2.4+1.2+0.4+0.4+0.4+0.6+0.2+0.4+0.7＝9.2(ms)。

每组处理负载＝9.2/3＝3.07(ms)。

基于上述每组处理负载3.07ms，将动态图分成所述动态子图，在划分时利用自适应均衡算法，让每个动态子图中的图元素在前一天的处理负载之和逼近所述每组处理负载。最后划分的结果是：顶点0、边5、边6、边8分到组1，其前一天处理负载之和＝2.1+0.4+0.4+0.2＝3.1(ms)；顶点2和边10分到组3，其前一天处理负载之和＝2.4+0.7＝3.1(ms)；将顶点1、顶点3、顶点4、边7、边9分到组2，其前一天处理负载之和＝0.4+1.2+0.4+0.6+0.4＝3(ms)。

该实施例的优点是，既考虑了让相邻的图元素尽可能分在一个组中，提高事务的执行效率，也使事务执行时尽可能少锁住组，提高动态图的整体更新效率，也同时兼顾了让各个组的处理负载均衡。

在另一个实施例中，如图14所示，所述方法还包括：

步骤375、在执行事务的图元素操作后，记录操作时间；

步骤380、每隔预定时间段，确定每个图元素在该预定时间段的处理负载，该处理负载等于该预定时间段内该图元素的记录的操作时间之和；

步骤385、由机器学习模型根据之前每个预定时间段每个图元素的处理负载，对接下来的预定时间段各图元素的处理负载进行预测。

关于步骤375、380、385，已经在上面详细描述。

在该实施例中，所述按照所述图元素的邻接关系，将动态图的图元素分成多个组，包括：

根据动态图的每个图元素预测的处理负载，将动态图分成所述动态子图，使得每个动态子图中全部图元素预测的处理负载之和均衡，其中每个动态子图是动态图上一个联通的区域，两个相邻动态子图的边界经过边，避开顶点，将经过的边划分为属于两个相邻动态子图之一。

该实施例将动态图分成所述动态子图，使得每个动态子图中全部图元素预测的处理负载之和均衡，而不是使得每个动态子图中全部图元素在前一预定时间段的处理负载之和均衡。由于预测的处理负载比历史上的处理负载更能代表当前的该图元素的负载情况，因此，该实施例的均衡效果更好，动态图更新的效率更高。

如图17所示，在一个实施例中，所述方法还包括：

步骤375、在执行事务的图元素操作后，记录操作时间；

步骤380、每隔预定时间段，确定每个图元素在该预定时间段的处理负载，该处理负载等于该预定时间段内该图元素的记录的操作时间之和；

步骤390、响应于每个预定时间段结束，按照每个图元素在该预定时间段的处理负载，将动态图的图元素重新分组，使得每个组中全部图元素在该预定时间段的处理负载之和均衡。

步骤375和380前面已经详细描述，故不赘述。

该实施例中，在步骤310分成的组不是一成不变的，而是在每个预定时间段(例如每天)结束后进行调整，即每个预定时间段根据该预定时间段各组的负载情况，重新分组。这样，消除了分好组后，由于有的组中的图元素负载变动较大，使得各组的处理负载又不均衡带来的影响，实现了动态调节各组的负载情况。

在一个实施例中，按照每个图元素在该预定时间段的处理负载，将动态图的图元素重新分组，具体包括：

根据动态图的每个图元素在该预定时间段的处理负载，将动态图重新分成动态子图，使得每个动态子图中全部图元素在该预定时间段的处理负载之和均衡，其中每个动态子图是动态图上一个联通的区域，两个相邻动态子图的边界经过边，避开顶点，将经过的边划分为属于两个相邻动态子图之一。

具体地，在一个实施例中，将动态图重新分成所述动态子图，使得每个动态子图中全部图元素在该预定时间段的处理负载之和均衡，可以包括：

确定动态图的全部图元素在该预定时间段的处理负载之和；

用该处理负载之和除以组数，得到每组处理负载；

基于所述每组处理负载，将动态图重新分成所述动态子图，使得利用自适应均衡算法，让每个动态子图中的图元素在该预定时间段的处理负载之和逼近所述每组处理负载，其中每个动态子图是动态图上一个联通的区域，两个相邻动态子图的边界经过边，避开顶点，将经过的边划分为属于两个相邻动态子图之一。

另外，在该实施例中，响应于每个预定时间段结束，按照每个图元素在该预定时间段的处理负载，将动态图的图元素重新分组后，在各组的事务队列中排队的事务也要随其针对的图元素所属组的变化，而迁移到所属组的事务队列中。

另外，在一个实施例中，所述步骤390包括：

响应于每个预定时间段结束，判断是否当前有组被锁住；

如果判断出当前有组被锁住，等到所有的组都被解锁，才按照每个图元素在该预定时间段的处理负载，将动态图的图元素重新分组。

每个预定时间段结束时，如果没有组被锁住，则可以重新分组并完成在各组的事务队列中的事务的转移。然后，如果在预定时间段结束后，有组被锁住，这时是不适合立即重新分组并完成事务队列中事务的转移的。因为在该组被锁住期间，组中的图元素一旦被重新分到其它组，也应该继续被锁住，但是一个组内一部分图元素被锁住，而另一部分不被锁住，实践中是不可操作的。因此，该实施例中，如果判断出当前有组被锁住，等到所有的组都被解锁，才按照每个图元素在该预定时间段的处理负载，将动态图的图元素重新分组。

如图18所示，在另一个实施例中，所述方法还包括：

步骤375、在执行事务的图元素操作后，记录操作时间；

步骤380、每隔预定时间段，确定每个图元素在该预定时间段的处理负载，该处理负载等于该预定时间段内该图元素的记录的操作时间之和；

步骤385、由机器学习模型根据之前每个预定时间段每个图元素的处理负载，对接下来的预定时间段各图元素的处理负载进行预测；

步骤395、响应于每个预定时间段结束，按照每个图元素在接下来的预定时间段的预测处理负载，将动态图的图元素重新分组，使得每个组中全部图元素的预测处理负载之和均衡。

图18的实施例与图17的实施例的区别在于，图18的实施例中，响应于每个预定时间段结束，按照每个图元素在接下来的预定时间段的预测处理负载，而不是按照每个图元素在该预定时间段的处理负载，将动态图的图元素重新分组。由于重新分组主要是为了下一预定时间段中使用的，预测的处理负载反映的是下一预定时间段中的处理负载，因此，用预测的处理负载进行负载均衡，有利于重新分组后各组的实际均衡效果，也提高动态图更新效果。

关于机器学习模型的训练方法，和由机器学习模型根据之前每个预定时间段每个图元素的处理负载，对接下来的预定时间段各图元素的处理负载进行预测的方法，在前面已经详细描述。

另外，在一个实施例中，还可以对各组的事务队列中排队的长度灵活进行调节。当发现一组的事务队列中排队的事务过多，就重新调整组中包含的图元素，从而实现各组中事务的实时均衡。

在该实施例中，步骤330包括：

在按照所述请求时间戳的先后顺序，将所述事务放在确定的组的事务队列中排队之后，如果有事务队列的长度超过预设长度阈值，从事务队列的长度超过预设长度阈值的组中选取图元素，移入事务队列的长度最短的组。

事务队列的长度是指事务队列中排队的事务的数目。预设长度阈值是指排队的事务的数目的阈值。如果有事务队列的长度超过预设长度阈值，说明该组的事务队列过长，至少说明在当时该组的处理负载偏大。此时，可以从该组中选取图元素，移入事务队列的长度最短的组。当然，相应地，图元素转移后，事务队列中的相应事务也要转移。而且，若干当前有一些组被锁住，要等到所有组都被解锁的情况下，也能够进行这种组的重新分配和相应事务的转移。

如图13所示，在一个实施例中，所述方法还包括：

步骤375、在执行事务的图元素操作后，记录操作时间；

步骤380、每隔预定时间段，确定每个图元素在该预定时间段的处理负载，该处理负载等于该预定时间段内该图元素的记录的操作时间之和。

在该实施例中，从事务队列的长度超过预设长度阈值的组中选取的图元素是该组中在前一预定时间段的处理负载最小的图元素。

从前一预定时间段的处理负载最小的图元素开始转移，其次是前一预定时间段的处理负载次小的图元素，按这样的顺序慢慢进行图元素的转移，避免了转移图元素后，该组的处理负荷又变得过小，防止大的波动发生。

如图19所示，根据本公开的一个实施例，还提供了一种动态图更新装置，包括：

分组单元710，用于将动态图的图元素分成多个组，各个组之间的图元素各不相同而互相独立；

事务队列设置单元720，用于为每个组分别设置一个事务队列；

排队单元730，用于将针对每个组中的图元素的事务放在该组的事务队列中排队，每个事务队列中的事务按照排队的顺序进行图元素操作；

加锁单元740，用于响应于非并行性事务对图元素进行操作，将图元素所属的组锁住，禁止其它组的事务队列中的事务进行图元素操作。

在一个实施例中，所述装置还包括：

解锁单元(未示)，用于响应于该非并行性事务对图元素操作完，解锁图元素所属的组。

在一个实施例中，加锁单元740进一步用于：

如果该非并行性事务对多个组的图元素进行操作，按所述多个组的预定顺序锁住所述多个组。

在一个实施例中，所述图元素包括顶点和边，所述非并行性事务包括去除顶点、增加边中的至少一个。

在一个实施例中，排队单元730进一步用于：

获取针对图元素的事务，所述事务带有请求时间戳；

确定所述事务针对的图元素所属的组；

按照所述请求时间戳的先后顺序，将所述事务放在确定的组的事务队列中排队。

在一个实施例中，所述按照所述请求时间戳的先后顺序，将所述事务放在确定的组的事务队列中排队，具体包括：

如果所属组相同的多个事务的请求时间戳相同，将更新事务排在查询事务的前面。

在一个实施例中，所述按照所述请求时间戳的先后顺序，将所述事务放在确定的组的事务队列中排队，具体包括：

如果所属组相同的多个事务的请求时间戳相同、又都是更新事务，只将所述多个事务中的一个放在事务队列中排队，向所述多个事务中的其它事务的请求终端发出重请求指示。

在一个实施例中，所述组包括与组中的图元素对应的最近更新时间戳。所述装置还包括：

比较单元(未示)，用于将事务的请求时间戳与所述最近更新时间戳进行比较；

图元素操作执行单元(未示)，用于如果事务的请求时间戳晚于所述最近更新时间戳，才执行事务的图元素操作，并用事务的请求时间戳更新所述最近更新时间戳。

在一个实施例中，所述请求时间戳为CPU周期级别。

在一个实施例中，所述确定所述事务针对的图元素所属的组，包括：

如果所述事务是关于增加图元素的事务，将所述图元素确定到当前事务队列最短的组中。

在一个实施例中，所述装置还包括：

记录单元(未示)，用于在执行事务的图元素操作后，记录操作时间；

处理负载确定单元(未示)，用于每隔预定时间段，确定每个图元素在该预定时间段的处理负载，该处理负载等于该预定时间段内该图元素的记录的操作时间之和，

所述确定所述事务针对的图元素所属的组，包括：

如果所述事务是关于增加图元素的事务，确定当前每个组的图元素在前一预定时间段的处理负载之和，并将所述图元素确定到所述处理负载最小的组内。

在一个实施例中，所述装置还包括：

记录单元(未示)，用于在执行事务的图元素操作后，记录操作时间；

处理负载确定单元(未示)，用于每隔预定时间段，确定每个图元素在该预定时间段的处理负载，该处理负载等于该预定时间段内该图元素的记录的操作时间之和；

预测单元(未示)，用于由机器学习模型根据之前每个预定时间段每个图元素的处理负载，对接下来的预定时间段各图元素的处理负载进行预测；

所述确定所述事务针对的图元素所属的组，包括：

如果所述事务是关于增加图元素的事务，将所述图元素确定到预测处理负载最小的组内。

在一个实施例中，所述确定所述事务针对的图元素所属的组，包括：

如果所述事务是关于增加边的事务，确定所述边的顶点；

将所述边确定到所述边的顶点之一所属的组中。

在一个实施例中，分组单元710进一步用于：

按照所述图元素的邻接关系，将动态图的图元素分成多个组。

在一个实施例中，所述按照所述图元素的邻接关系，将动态图的图元素分成多个组，包括：

确定动态图的图元素数；

用动态图的图元素数除以组数，得到每组平均图元素数；

基于所述每组平均图元素数，将动态图分成所述动态子图，其中每个动态子图是动态图上一个联通的区域，两个相邻动态子图的边界经过边，避开顶点，将经过的边划分为属于两个相邻动态子图之一；

将每个动态子图中的全部图元素，作为一个组。

在一个实施例中，所述装置还包括：

记录单元(未示)，用于在执行事务的图元素操作后，记录操作时间；

处理负载确定单元(未示)，用于每隔预定时间段，确定每个图元素在该预定时间段的处理负载，该处理负载等于该预定时间段内该图元素的记录的操作时间之和。

所述按照所述图元素的邻接关系，将动态图的图元素分成多个组，包括：

根据动态图的每个图元素在前一预定时间段的处理负载，将动态图分成所述动态子图，使得每个动态子图中全部图元素在前一预定时间段的处理负载之和均衡，其中每个动态子图是动态图上一个联通的区域，两个相邻动态子图的边界经过边，避开顶点，将经过的边划分为属于两个相邻动态子图之一。

在一个实施例中，所述装置还包括：

记录单元(未示)，用于在执行事务的图元素操作后，记录操作时间；

处理负载确定单元(未示)，用于每隔预定时间段，确定每个图元素在该预定时间段的处理负载，该处理负载等于该预定时间段内该图元素的记录的操作时间之和；

重新分组单元(未示)，用于响应于每个预定时间段结束，按照每个图元素在该预定时间段的处理负载，将动态图的图元素重新分组，使得每个组中全部图元素在该预定时间段的处理负载之和均衡。

在一个实施例中，所述重新分组单元进一步用于：

响应于每个预定时间段结束，判断是否当前有组被锁住；

如果判断出当前有组被锁住，等到所有的组都被解锁，才按照每个图元素在该预定时间段的处理负载，将动态图的图元素重新分组。

在一个实施例中，所述装置还包括：

记录单元(未示)，用于在执行事务的图元素操作后，记录操作时间；

处理负载确定单元(未示)，用于每隔预定时间段，确定每个图元素在该预定时间段的处理负载，该处理负载等于该预定时间段内该图元素的记录的操作时间之和；

预测单元(未示)，用于由机器学习模型根据之前每个预定时间段每个图元素的处理负载，对接下来的预定时间段各图元素的处理负载进行预测；

重新分组单元(未示)，用于响应于每个预定时间段结束，按照每个图元素在接下来的预定时间段的预测处理负载，将动态图的图元素重新分组，使得每个组中全部图元素的预测处理负载之和均衡。

在一个实施例中，所述排队单元进一步用于：

在按照所述请求时间戳的先后顺序，将所述事务放在确定的组的事务队列中排队之后，如果有事务队列的长度超过预设长度阈值，从事务队列的长度超过预设长度阈值的组中选取图元素，移入事务队列的长度最短的组。

在一个实施例中，所述方法还包括：

记录单元(未示)，用于在执行事务的图元素操作后，记录操作时间；

周期性确定单元(未示)，用于每隔预定时间段，确定每个图元素在该预定时间段的处理负载，该处理负载等于该预定时间段内该图元素的记录的操作时间之和，其中，从事务队列的长度超过预设长度阈值的组中选取的图元素是该组中在前一预定时间段的处理负载最小的图元素。

根据本公开实施例的动态图更新方法可以由图3的动态图存储引擎接口1041实现。下面参照图20来描述根据本公开实施例的动态图存储引擎接口1041。图20显示的动态图存储引擎接口1041仅仅是一个示例，不应对本公开实施例的功能和使用范围带来任何限制。

如图20所示，动态图存储引擎接口1041以通用计算设备的形式表现。动态图存储引擎接口1041的组件可以包括但不限于：上述至少一个处理单元810、上述至少一个存储单元820、连接不同系统组件(包括存储单元820和处理单元810)的总线830。

其中，所述存储单元存储有程序代码，所述程序代码可以被所述处理单元810执行，使得所述处理单元810执行本说明书上述示例性方法的描述部分中描述的根据本发明各种示例性实施方式的步骤。例如，所述处理单元810可以执行如图4中所示的各个步骤。

存储单元820可以包括易失性存储单元形式的可读介质，例如随机存取存储单元(RAM)8201和/或高速缓存存储单元8202，还可以进一步包括只读存储单元(ROM)8203。

存储单元820还可以包括具有一组(至少一个)程序模块8205的程序/实用工具8204，这样的程序模块8205包括但不限于：操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。

总线830可以为表示几类总线结构中的一种或多种，包括存储单元总线或者存储单元控制器、外围总线、图形加速端口、处理单元或者使用多种总线结构中的任意总线结构的局域总线。

动态图存储引擎接口1041也可以与一个或多个外部设备700(例如键盘、指向设备、蓝牙设备等)通信，还可与一个或者多个使得用户能与该动态图存储引擎接口1041交互的设备通信，和/或与使得该动态图存储引擎接口1041能与一个或多个其它计算设备进行通信的任何设备(例如路由器、调制解调器等等)通信。这种通信可以通过输入/输出(I/O)接口650进行。并且，动态图存储引擎接口1041还可以通过网络适配器860与一个或者多个网络(例如局域网(LAN)，广域网(WAN)和/或公共网络，例如因特网)通信。如图所示，网络适配器860通过总线830与动态图存储引擎接口1041的其它模块通信。应当明白，尽管图中未示出，可以结合动态图存储引擎接口1041使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、RAID系统、磁带驱动器以及数据备份存储系统等。

通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本公开实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、终端装置、或者网络设备等)执行根据本公开实施方式的方法。

在本公开的示例性实施例中，还提供了一种计算机程序介质，其上存储有计算机可读指令，当所述计算机可读指令被计算机的处理器执行时，使计算机执行上述方法实施例部分描述的方法。

根据本公开的一个实施例，还提供了一种用于实现上述方法实施例中的方法的程序产品，其可以采用便携式紧凑盘只读存储器(CD-ROM)并包括程序代码，并可以在终端设备，例如个人电脑上运行。然而，本发明的程序产品不限于此，在本文件中，可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

所述程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以为但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。

计算机可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质，该可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。

可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于无线、有线、光缆、RF等等，或者上述的任意合适的组合。

可以以一种或多种程序设计语言的任意组合来编写用于执行本发明操作的程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如Java、C++等，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络，包括局域网(LAN)或广域网(WAN)，连接到用户计算设备，或者，可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。

应当注意，尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元，但是这种划分并非强制性的。实际上，根据本公开的实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。

此外，尽管在附图中以特定顺序描述了本公开中方法的各个步骤，但是，这并非要求或者暗示必须按照该特定顺序来执行这些步骤，或是必须执行全部所示的步骤才能实现期望的结果。附加的或备选的，可以省略某些步骤，将多个步骤合并为一个步骤执行，以及/或者将一个步骤分解为多个步骤执行等。

通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本公开实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、移动终端、或者网络设备等)执行根据本公开实施方式的方法。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其它实施方案。本申请旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由所附的权利要求指出。

Claims (15)

1.一种动态图更新方法，其特征在于，包括：

将动态图的图元素分成多个组，各个组之间的图元素各不相同且互相独立；

为每个组分别设置一个事务队列；

将针对每个组中的图元素的事务放在该组的事务队列中排队，每个事务队列中的事务按照排队的顺序进行图元素操作；

响应于非并行性事务对图元素进行操作，将图元素所属的组锁住，禁止其它组的事务队列中的事务进行图元素操作。

2.根据权利要求1所述的方法，其特征在于，在将图元素所属的组锁住后，所述方法还包括：

响应于该非并行性事务对图元素操作完，解锁所述图元素所属的组。

3.根据权利要求1所述的方法，其特征在于，所述将图元素所属的组锁住包括：

如果该非并行性事务对多个组的图元素进行操作，按所述多个组的预定顺序锁住所述多个组。

4.根据权利要求1所述的方法，其特征在于，所述图元素包括顶点和边，所述非并行性事务包括去除顶点、增加边中的至少一个。

5.根据权利要求1所述的方法，其特征在于，所述将针对每个组中的图元素的事务放在该组的事务队列中排队包括：

获取针对图元素的事务，所述事务带有请求时间戳；

确定所述事务针对的图元素所属的组；

按照所述请求时间戳的先后顺序，将所述事务放在确定的组的事务队列中排队。

6.根据权利要求5所述的方法，其特征在于，所述按照所述请求时间戳的先后顺序，将所述事务放在确定的组的事务队列中排队，具体包括：

如果所属组相同的多个事务的请求时间戳相同，将更新事务排在查询事务的前面。

7.根据权利要求5所述的方法，其特征在于，所述按照所述请求时间戳的先后顺序，将所述事务放在确定的组的事务队列中排队，具体包括：

如果所属组相同的多个事务的请求时间戳相同、又都是更新事务，只将所述多个事务中的一个放在事务队列中排队，向所述多个事务中的其它事务的请求终端发出重请求指示。

8.根据权利要求5所述的方法，其特征在于，所述组包括与组中的图元素对应的最近更新时间戳，在响应于非并行性事务对图元素进行操作，将图元素所属的组锁住之后，所述方法还包括：

将事务的请求时间戳与所述最近更新时间戳进行比较；

如果事务的请求时间戳晚于所述最近更新时间戳，才执行事务的图元素操作，并用事务的请求时间戳更新所述最近更新时间戳。

9.根据权利要求5所述的方法，其特征在于，所述确定所述事务针对的图元素所属的组，包括：

如果所述事务是关于增加图元素的事务，将所述图元素确定到当前事务队列最短的组中。

10.根据权利要求5所述的方法，其特征在于，所述方法还包括：

在执行事务的图元素操作后，记录操作时间；

每隔预定时间段，确定每个图元素在该预定时间段的处理负载，该处理负载等于该预定时间段内该图元素的记录的操作时间之和，

所述确定所述事务针对的图元素所属的组，包括：

如果所述事务是关于增加图元素的事务，确定当前每个组的图元素在前一预定时间段的处理负载之和，并将所述图元素确定到所述处理负载最小的组内。

11.根据权利要求1所述的方法，其特征在于，所述将动态图的图元素分成多个组，包括：

按照所述图元素的邻接关系，将动态图的图元素分成多个组。

12.根据权利要求11所述的方法，其特征在于，所述按照所述图元素的邻接关系，将动态图的图元素分成多个组，包括：

确定动态图的图元素数；

用动态图的图元素数除以组数，得到每组平均图元素数；

基于所述每组平均图元素数，将动态图分成所述动态子图，其中每个动态子图是动态图上一个联通的区域，两个相邻动态子图的边界经过边，避开顶点，将经过的边划分为属于两个相邻动态子图之一；

将每个动态子图中的全部图元素，作为一个组。

13.一种动态图更新装置，其特征在于，包括：

分组单元，用于将动态图的图元素分成多个组，各个组之间的图元素各不相同且互相独立；

事务队列设置单元，用于为每个组分别设置一个事务队列；

排队单元，用于将针对每个组中的图元素的事务放在该组的事务队列中排队，每个事务队列中的事务按照排队的顺序进行图元素操作；

加锁单元，用于响应于非并行性事务对图元素进行操作，将图元素所属的组锁住，禁止其它组的事务队列中的事务进行图元素操作。

14.一种动态图存储引擎接口，其特征在于，包括：

存储器，存储有计算机可读指令；

处理器，读取存储器存储的计算机可读指令，以执行权利要求1-12中的任一个所述的方法。

15.一种计算机程序介质，其上存储有计算机可读指令，当所述计算机可读指令被计算机的处理器执行时，使计算机执行权利要求1-12中的任一个所述的方法。