一种关系网络的计算方法及装置
技术领域
本申请涉及计算机领域,特别是涉及一种关系网络的计算方法及装置。
背景技术
在用户操作平台中,用户及用户相关的介质可以通过用户的操作而关联起来构成关系网络。关系网络在用户操作平台中有很多用处,例如可以利用关系网络来推荐好友,检测用户之间的关联度,进行相关内容的推荐等。此外,通过关联网络还可以对用户的风险性进行扫描,判断特定设备是否可信,或检测某个设备是否专门进行扫号。
现有技术下,将用户、用户介质和用户虚拟介质当作关系网络中的一个个节点,把用户的操作当作节点之间的边,那么关系网络就包含了节点和边,从数学角度抽象,它就是一种图,如图1所示。进一步地,所有关系网络图的集合就叫做森林,如图2所示。
目前,在内存或者存储介质中存储关系网络图时,常用的图表示方法是矩阵表示法(适合密集型图)和邻接表表示法(适合稀疏型图),其中邻接表表示法是一种比较灵活的表示方法,因此比较常用。进一步地,利用关系网络图可以进行图计算,比如,检测第一用户和第二用户在关系网络图中是几度关联的,通常采用的方法是性能较高的广度优先搜索(Breadth First Search,BFS)或深度优先搜索(Depth First Search,DFS)。
现有技术中,已有一些图数据库,可以用来存储关系网络的节点和边信息,并利用图数据库提供的图计算功能进行关系网络计算,例如:neo4j,凯莱(cayley)等。
其中,neo4j是现在相对成熟的图数据库。它主要有两大特征:
其一,将关系网络图中的节点、关系和它们的属性利用双向链表结构保存到三个不同的文件当中;
其二,每次图计算都将计算参数发送到图数据库,图数据库计算结束后返回计算结果。
例如,在一次图计算的过程,如果图计算请求计算100个目标值,那么就需要向neo4j数据库服务器发送100次网络请求,这样较频繁读取磁盘带来大量的网络延时使得效率较低,因此可能无法满足真实的应用环境的需要。
又例如,某平台的关系网络如图1所示(需要指出的是,实际生产中可能会更复杂),假设“用户1”使用“设备1”进行操作,那么这个时候需要对用户1进行风险扫描,此时接收到的扫描请求中包含有多个待确定的目标值,具体为:
目标值1:用户1和设备1是否有过关联(即,两个节点是否连通);
目标值2:设备1和用户1是几层关联(即,设备1节点需要通过几条边才可以到用户1节点);
目标值3:用户1在3层内关联了几个用户;
……
因此,在实际操作过程中,需要按照目标值的数目多次向图数据库请求进行图计算,每次图计算都需要将计算参数发送到图数据库,而且每次计算均需要从请求的起始节点开始进行全图范围的搜索和分析,频繁的读取过程需要大量的网络延时,效率很低。
由此可见,在实际的图计算过程中,主要存在以下两点缺陷:
第一,图计算不灵活。
由于具体的图计算算法是由图数据库已配置好的算法,因此如果对业务有特殊需求时,难以满足实际的需要。
第二,每次图计算都需要较大的网络延时。
第三,由于图计算是由图数据库提供的,因此业务请求图计算时只能发送到图数据库进行计算,而当一次业务操作中需要多次图计算时,每次图计算都需要将计算参数发送到图数据库,较频繁的读取将占用大量网络宽带,代价很高。
此外,现有技术中还提供了另外一种关系网络图的计算方法,即利用图的邻接表表示方法来进行图计算。邻接表是图结构的一种常用表示方法,通过图中的边来存储图的结构。在这种图计算方法中,将关系网络图中节点之间的邻接关系保存在传统关系型数据库、键值(Key-Value,KV)型数据库、文件系统等存储介质中,计算的时候从存储介质中获取图节点间关联关系,进而进行图计算。它也主要有两大特征:
其一,图结构以邻接表的形式存储在存储系统中;
其二,计算时每次只能去查询一层的相邻的节点,然后通过计算后的相邻一层节点的结果再去读取下一层相邻的节点。
例如,以图3为例,可以采用MySQL数据库的表来存储关系网络图的邻接表,具体如表1所示。
表1
一次计算过程,由于每次只能去查询一层的相邻的节点,因此如果某起始节点与多个节点存在关系,且与结束节点之间是多层关联,那么则需要多次的查询数据,带来大量的网络和磁盘读写负载,造成工作效率低下,不能完全满足应用环境中对图计算的需要。
因此,这种方法也存在两点主要缺陷:
第一、图计算过程中需要多次读取数据。
在进行图计算时,由于保存的是邻接表的数据,因此只能根据起始节点加载与它直接相邻的节点数据,计算完与起始节点直接相邻的节点后,如果需要往下计算,那么需要通过与起始节点直接相邻的节点再去存储介质中读取下一层节点的数据。所以,一次网络计算可能会涉及到多次网络消耗和持久化存储介质读取消耗。
第二、业务处理时间过长。
由于一次网络计算可能涉及多次持久化介质(如硬盘)的读取操作,而通常情况下常用的持久化存储介质,比如磁盘、网络,相对较慢,所以涉及越多次的持久化介质读取,就会消耗更多的时间。
现如今,互联网对关系网络图的计算需求越来越大,但是在现有技术下,图计算需要多次通过磁盘和/或网络读取数据,效率较低。而在正常的业务场景中,一次业务请求中常包含多个网络图计算,这就导致现在的图数据库或者邻接表存储方式所支持的图计算方法难以满足实际应用环境的需求。
发明内容
本申请实施例提供一种关系网络的计算方法,用以解决现有技术中图计算需要多次通过磁盘和/或网络读取数据造成应用效率较低的问题。
本申请实施例提供的具体技术方案如下:
一种关系网络的计算方法,包括:
接收用户的计算请求,并获取计算请求中包含的至少一个请求目标值;
分别确定至少一个请求目标值所关联的节点,并获取对应每一个节点预设的子图网络标识ID,以及根据获得的子图网络ID获取相应的子图网络关联信息,子图网络关联信息用于描述归属于同一子图的节点及节点间的关联关系;
根据获得的子图网络关联信息对至少一个请求目标值进行计算处理。
这样,可以将网络图森林划分为连通的网络子图,然后将网络子图中的所有关联信息保存在一起。在进行网络关系实时计算时,可以针对多个计算目标值,一次读取一个子图网络数据进行多次图计算,也可以一次读取多个子图网络数据进行多次图计算,且读取数据量控制在合理范围内,进而极大地提高了图计算的效率,提高了关系网络计算在传统数据库支持下的计算性能。
较佳的,分别确定至少一个请求目标值所关联的节点,并获取对应每一个节点预设的子图网络标识ID,以及根据获得的子图网络ID获取相应的子图网络关联信息,子图网络关联信息用于描述归属于同一子图的节点及节点间的关联关系,以及根据获得的子图网络关联信息对至少一个请求目标值进行计算处理,包括:
若同一请求目标值关联至少两个节点,且至少两个节点对应相同子图网络ID,则直接获取对应子图网络ID预设的子图网络关联信息,并采用获得的子图网络关联信息对同一请求目标值进行处理;
若存在至少两个请求目标值关联的节点对应同一子图网络ID,则直接获取同一子图网络ID对应的子图网络关联信息,并采用获得的子图网络关联信息对至少两个请求目标值进行合并处理;
采用这样的合并目标值处理方法,使得在图计算过程中能够实现一次读取一个子图网络数据进行多次图计算。
若存在至少两个请求目标值且至少两个请求目标值关联的节点分别对应不同的子图网络ID,则分别获取对应每一个子图网络ID对应的子图网络关联信息,并采用获得的每一个子图网络关联信息分别对相应的请求目标值进行处理。
采用这样的目标值处理方法,使得在图计算过程中能够实现一次读取多个子图网络数据进行多次图计算。
较佳的,在预处理阶段,进一步包括:
应用服务器根据保存的用户历史操作记录筛选出指定类型的节点,再依据用户历史操作记录中记载的用户操作内容在各个节点之间建立关联关系,生成关系网络;
应用服务器依据各个节点之间的关联关系将关系网络划分为若干子图,其中,各个子图之间无关联关系,且每一个子图中的节点是唯一的,以及归属于同一子图中的任意两个节点之间能够连通。
较佳的,应用服务器依据各个节点之间的关联关系将关系网络划分为若干子图,包括:
对应关联网络中的每一条边分别记录相应的起始节点、终止节点以及节点间关联关系;
将起始节点和终止节点归属于同一子图网络中,并设置子图网络标识ID,其中,若同一节点出现在两条边中,则将这两条边归属于同一子图网络中;
记录每一个子图网络ID和相应子图中每一个节点之间的映射关系,以及记录每一个子图网络ID和对应的子图网络关联信息,子图网络关联信息中包含有相应子图内的每一条边所表征的起始节点、终止节点和节点间关联关系。
较佳的,将起始节点和终止节点归属于同一子图网络中,并设置子图网络标识ID,其中,若同一节点出现在两条边中,则将这两条边归属于同一子图网络中,包括:
若对应起始节点和终止节点均未记录子图网络ID,则对应起始节节点和终止节点创建一个新的子图网络ID;
若对应起始节点记录有子图网络ID,而对应终止节点未记录子图网络ID,则将终止节点的子图网络ID设置为起始节点的子图网络ID;
若对应起始节点未记录子图网络ID,而对应终止节点记录有子图网络ID,则将起始节点的子图网络ID设置为终止节点的子图网络ID;
若对应起始节点和终止节点记录的子图网络ID不一致,则将终止节点归属的子图网络中所有节点的子图网络ID均设置为起始节点的子图网络ID。
一种关系网络的计算装置,包括:
获取单元,用于接收用户的计算请求,并获取计算请求中包含的至少一个请求目标值;
处理单元,用于分别确定至少一个请求目标值所关联的节点,并获取对应每一个节点预设的子图网络标识ID,以及根据获得的子图网络ID获取相应的子图网络关联信息,子图网络关联信息用于描述归属于同一子图的节点及节点间的关联关系;
计算单元,用于根据获得的子图网络关联信息对至少一个请求目标值进行计算处理。
这样,可以将网络图森林划分为连通的网络子图,然后将网络子图中的所有关联信息保存在一起。在进行网络关系实时计算时,可以针对多个计算目标值,一次读取一个子图网络数据进行多次图计算,也可以一次读取多个子图网络数据进行多次图计算,且读取数据量控制在合理范围内,进而极大地提高了图计算的效率,提高了关系网络计算在传统数据库支持下的计算性能。
较佳的,分别确定至少一个请求目标值所关联的节点,并获取对应每一个节点预设的子图网络标识ID,以及根据获得的子图网络ID获取相应的子图网络关联信息,子图网络关联信息用于描述归属于同一子图的节点及节点间的关联关系,以及根据获得的子图网络关联信息对至少一个请求目标值进行计算处理,处理单元和计算单元具体用于:
若同一请求目标值关联至少两个节点,且至少两个节点对应相同子图网络ID,则直接获取对应子图网络ID预设的子图网络关联信息,并采用获得的子图网络关联信息对同一请求目标值进行处理;
若存在至少两个请求目标值关联的节点对应同一子图网络ID,则直接获取同一子图网络ID对应的子图网络关联信息,并采用获得的子图网络关联信息对至少两个请求目标值进行合并处理;
采用这样的合并目标值处理方法,使得在图计算过程中能够实现一次读取一个子图网络数据进行多次图计算。
若存在至少两个请求目标值且至少两个请求目标值关联的节点分别对应不同的子图网络ID,则分别获取对应每一个子图网络ID对应的子图网络关联信息,并采用获得的每一个子图网络关联信息分别对相应的请求目标值进行处理。
采用这样的目标值处理方法,使得在图计算过程中能够实现一次读取多个子图网络数据进行多次图计算。
较佳的,进一步包括:
预处理单元,用于:
根据保存的用户历史操作记录筛选出指定类型的节点,再依据用户历史操作记录中记载的用户操作内容在各个节点之间建立关联关系,生成关系网络;
依据各个节点之间的关联关系将关系网络划分为若干子图,其中,各个子图之间无关联关系,且每一个子图中的节点是唯一的,以及归属于同一子图中的任意两个节点之间能够连通。
较佳的,应用服务器依据各个节点之间的关联关系将关系网络划分为若干子图时,预处理单元具体用于:
对应关联网络中的每一条边分别记录相应的起始节点、终止节点以及节点间关联关系;
将起始节点和终止节点归属于同一子图网络中,并设置子图网络标识ID,其中,若同一节点出现在两条边中,则将这两条边归属于同一子图网络中;
记录每一个子图网络ID和相应子图中每一个节点之间的映射关系,以及记录每一个子图网络ID和对应的子图网络关联信息,子图网络关联信息中包含有相应子图内的每一条边所表征的起始节点、终止节点和节点间关联关系。
较佳的,将起始节点和终止节点归属于同一子图网络中,并设置子图网络标识ID,其中,若同一节点出现在两条边中,则将这两条边归属于同一子图网络中时,预处理单元具体用于:
若对应起始节点和终止节点均未记录子图网络ID,则对应起始节节点和终止节点创建一个新的子图网络ID;
若对应起始节点记录有子图网络ID,而对应终止节点未记录子图网络ID,则将终止节点的子图网络ID设置为起始节点的子图网络ID;
若对应起始节点未记录子图网络ID,而对应终止节点记录有子图网络ID,则将起始节点的子图网络ID设置为终止节点的子图网络ID;
若对应起始节点和终止节点记录的子图网络ID不一致,则将终止节点归属的子图网络中所有节点的子图网络ID均设置为起始节点的子图网络ID。
附图说明
图1为本申请背景技术中关系网络图示意图1;
图2为本申请背景技术中关系网络图森林;
图3为本申请背景技术中关系网络图示意图2;
图4为本申请实施例中关系网络计算流程图;
图5为本申请实施例中应用服务器结构示意图。
具体实施方式
为了解决现有技术中图计算需要多次通过磁盘和/或网络读取数据造成应用效率较低的问题。
本申请实施例中,应用服务器可以根据用户历史操作记录生成关系网络,并将关系网络划分为若干子图。
具体为:用户将操作请求发送到应用服务器后,应用服务器通常会保存用户历史操作记录,一条用户历史操作记录了用户的一次操作,在一次操作中会涉及到多种类型的节点,但是特定的关系网络通常只关心若干种类型的节点。应用服务器提取出用户历史操作记录后,会从用户历史操作记录中筛选出指定类型的节点,再依据用户历史操作记录中记载的用户操作内容在各个节点之间建立关联关系,以生成关系网络;接着,应用服务器会依据节点间关联关系将关系网络划分为若干子图,其中,各个子图之间无关联关系,且每个子图中的节点是唯一的,以及归属于同一子图中的任意两个节点之间能够连通。
具体的,在进行子图划分时,应用服务器对应关联网络中的每一条边分别记录相应的起始节点、终止节点以及节点间关联关系;然后,将起始节点和终止节点归属于同一子图网络中,并设置子图网络ID,其中,若同一节点出现在两条边中,则将这两条边归属于同一子图网络中,接着,记录每一个子图网络ID和相应子图中每一个节点之间的映射关系,以及记录每一个子图网络ID和对应的子图网络关联信息,该子图网络关联信息中包含有相应子图内的每一条边所表征的起始节点、终止节点和节点间关联关系。具体划分规则将在后续实施例中介绍。
例如,下面这个操作:张三(账号类型节点)在IP为12.22.33.4(IP类型节点)的电脑1(设备类型节点)上,使用信用卡1(卡类型节点)支付了一笔账单。这个操作中涉及到了4个不同类型的节点,但是假设构建的关系网络中只关心账号类型节点、设备类型节点和卡类型节点,而不关心IP类型节点。那么在关系网络的数据处理过程中,应用服务器只需要筛选出特定类型的节点,而不需要对所有节点进行记录。因此,关系网络数据处理过程中的一个操作就是从用户历史操作记录中筛选出所需的节点。
通过上述的方法可以将所有用户历史操作记录抽象成关系网络。在由关系网络构成的图森林中,如图2所示,进一步地可以将其划分为一个个的子图。这里的子图是指图森林中的一个连通图,而所谓连通图就是指图中任何两个节点都有路径可以连通,比如图森林中的三个图都是连通图,但是森林就不是连通图,因为用户1和用户6之间不联通。于是,就可以将图森林看做是由若干的子图构成。每个子图中的节点都是唯一的,即如果同一个节点出现在不同子图中,那么,需要将这两个子图进行合并。
对于每一条用户历史操作记录,根据关系网络需要,获取特定类型的节点,并将它们两两组合构建为关系网络边列表。这里获取的特定类型的节点内容包括节点类型和节点值。构建关系网络边的每一行信息包括:起始节点(起始节点类型、起始节点值)、终止节点(终止节点类型、终止节点值)和节点间关联关系。
需要指出的是,关系网络边有两种选择,由业务系统自定义,可以设计为有向边,也可以设计为无向边,
例如,对于一条用户历史操作记录,“用户1”在“设备1”上使用“信用卡1”进行操作1。根据上述的方法,将节点两两组合,构建出关系网络边列表。表2为有向关系网络边列表,表3为无向关系网络边列表。
表2
表3
进一步地,在上述的关系网络边列表构建完成之后,将关系网络边的起始节点和终止节点划分到同一个子图中,即对应起始节点和终止节点记录同一个子图网络ID,再把这种对应关系保存在节点表中。这里的节点表的每一行记录包括节点(节点类型,节点值)和该节点所在的子图网络ID。
例如,根据上述的关系网络边列表,应用服务器可以将“用户1”、“设备1”、“信用卡1”和相应子图网络ID之间的映射关系创建到下面的节点表中,具体如表4所示。
表4
节点类型 |
节点值 |
子图 |
网络ID |
用户 |
用户1 |
子图 |
网络1 |
信用卡 |
信用卡1 |
子图 |
网络1 |
设备 |
设备1 |
子图 |
网络1 |
具体的,在建立节点表的过程中,需要将在关系网络边获取的起始节点和终止节点保存到同一个子图中,即让它们拥有相同的子图网络ID,具体包括以下几种情况:
如果起始节点和终止节点都没有子图网络ID,则创建一个新的子图网络ID,并将起始节点和终止节点的子图网络ID保存到节点表中。
如果起始节点有子图网络ID,而终止节点没有子图网络ID,则设定终止节点的子图网络ID为起始节点的子图网络ID,并保存到节点表中。
如果起始节点没有子图网络ID,而终止节点有子图网络ID,则设定起始节点的子图网络ID为终止节点的子图网络ID,并保存到节点表中。
如果起始节点和终止节点的子图网络ID不一样,则修改终止节点所在子图网络中所有节点的子图网络ID为起始节点的子图网络ID,并保存至节点表中。
例如,用户1和设备1同属一个子图1,子图网络ID为ID_1,用户2和用户3同属一个子图2,子图网络ID为ID_2,现在用户2在设备1上进行了注册,以用户2为起始节点,设备1为终止节点,则将设备1的子图网络ID修改为ID_2,同时也需将用户1的子图网络ID修改为ID_2,修改后两个子图合并为一个子图,子图网络ID为ID_2。
如果起始节点的子图网络ID和终止节点的子图网络ID相等,则重复上述的判断直到关系网络边列表中的所有关系网络边都已经处理。
又例如,使用MySQL(优选的用分布式存储系统(Hadoop Database,HBase)等KV数据库,这里用MySQL是为了便于描述)来存储图2中三个子图的节点到子图网络ID的映射的节点表,如表5所示。
表5
节点类型 |
节点值 |
子图网络ID |
用户 |
用户1 |
子图网络1 |
用户 |
用户2 |
子图网络1 |
设备 |
设备1 |
子图网络1 |
用户 |
用户3 |
子图网络2 |
用户 |
用户4 |
子图网络2 |
设备 |
设备5 |
子图网络2 |
用户 |
用户6 |
子图网络3 |
设备 |
设备7 |
子图网络3 |
更进一步地,还需要根据节点和子图网络ID的映射关系,将关系网络边依据子图网络ID进行归并,生成子图网络关联信息,并对归并后的子图网络关联信息进行序列化,在序列化完成之后将子图网络ID和序列化后的子图网络关联信息保存到子图网络表。这里的子图网络表包括子图网络ID和子图网络关联信息集合序列化后的数据。
例如,根据节点和子图网络ID的对应关系,将关系网络边依据子图网络ID进行归并,假设使用MySQL(优选的用HBase等KV数据库,这里用MySQL是为了便于描述)来储存数据,那么对图2所示的关系网络图森林进行上述的操作,则可以得到下面的结构如表6所示。
表6
子图网络ID |
子图网络(子图网络关联信息或子图网络信息) |
子图1 |
用户1,设备1,登录;用户2,用户1,关注;用户2,设备1,注册 |
子图2 |
用户3,用户4,关注;用户3,设备1,登录 |
上面的描述方法是双向关系,存储了子图网络ID和子图关联信息的映射关系。
又例如,在节点表生成之后,如表4所示,用户历史操作记录中“用户1”、“设备1”和“信用卡1”已经在一个子图网络中,具有相同的子图网络ID,现在由其所对应的表3中的关系网络边进行归并并按要求进行序列化。在上文中,节点的类型使用中文,但是为了便于描述,实际应用中,会将节点类型定义为4字节的int类型数值。下面的序列化格式只是其中一种方式,这里的序列化格式完全由业务所需来决定,也可以采用通用的序列化方法,如Java语言序列化,Json序列化等。
每条边的序列化格式如表7所示:
表7
边之间的字节数据归并拼接在一起如表8所示:
表8
边1序列化字节数据 |
边2序列化字节数据 |
边3序列化字节数据 |
通过上述的过程就完成了由用户历史操作记录生成的关系网络,并将关系网络划分为子图的全过程。
在上述的子图划分和相应的数据存储完成之后,进一步地,参阅图4所示,本申请以如下的具体实施例为例,对关系网络计算的流程进行详细的说明。
步骤400:接收用户的计算请求,并获取计算请求中包含的至少一个请求目标值。
步骤410:分别确定至少一个请求目标值所关联的节点,并获取对应每一个节点预设的子图网络标识ID,以及根据获得的子图网络ID获取相应的子图网络关联信息,子图网络关联信息用于描述归属于同一子图的节点及节点间的关联关系。
若同一请求目标值关联至少两个节点,且至少两个节点对应相同子图网络ID,则直接获取对应子图网络ID预设的子图网络关联信息,并采用获得的子图网络关联信息对同一请求目标值进行处理;
若存在至少两个请求目标值关联的节点对应同一子图网络ID,则直接获取同一子图网络ID对应的子图网络关联信息,并采用获得的子图网络关联信息对至少两个请求目标值进行合并处理;
例如,一个关系网络计算请求里面包含了3个关系网络计算的目标值:
目标值1:用户1在一层关联里关联了几个用户类型的节点;
目标值2:用户5在两层关联里关联了几个设备类型的节点;
目标值3:用户1和用户2在关系网络图中最短路径层数。
若在节点表中,用户1的子图网络ID为ID1,用户5的子图网络ID为ID2,那么,目标值1和3所对应的节点所属子图网络ID相同,于是可以将它们的目标值进行合并分为一组,目标值2分为一组;
若存在至少两个请求目标值且至少两个请求目标值关联的节点分别对应不同的子图网络ID,则分别获取对应每一个子图网络ID对应的子图网络关联信息,并采用获得的每一个子图网络关联信息分别对相应的请求目标值进行处理。
此外,还有一种特殊情况,若同一请求目标值关联至少两个节点,且至少两个节点对应不同子图网络ID,则获取对应其中一个子图网络ID预设的子图网络关联信息;或者,分别获取对应其中每一子图网络ID预设的子图网络关联信息;或者不需要获取对应节点的子图网络关联信息,直接根据子图网络ID即可以确定两个节点之间不存在关联关系。
例如,目标值为用户1和用户2在关系网络图中最短路径层数。如果用户1和用户2所对应的子图网络ID不相同,那么这时可以选择用户1或用户2所对应的子图网络ID的子图网络关联信息中的一个进行计算,也可以对两个子图网络ID所对应的子图关联信息都进行计算。因为用户1和用户2不在同一个子图中,因此即使任选其中一个子图进行计算,也能够确定两者之间不存在关联关系,同理,将两个子图都计算一遍,也会发现两者之间不存在关联关系。再者,两个节点所对应的子图网络标识ID不相同,说明两个节点不连通,即不关联,因为不同的子图的节点之间是不连通的。可见,无论使用哪一种计算方式,都可以得到相同的结果。
步骤420:根据获得的子图网络关联信息对至少一个请求目标值进行计算处理。
对于子图网络ID所对应的的子图网络关联信息集合序列化后的数据,在计算过程中可以进行反序列化,还原出子图网络关联信息集合,此外还可以进一步还原出由关系网络边集合构建的有向或无向关系网络边列表。
根据对所有目标值的分组结果,可以通过一次读取某一子图网络关联信息,进行多次图计算,计算完成后返回所有目标值的计算结果。此外还可以按照用户自定义的图计算方法进行计算,与图数据库的固定计算方法相比,更加灵活,符合实际应用的需要。
对于获取的计算请求只包含一个目标值的情况,根据请求目标值所关联的节点获取对应每一个节点预设的子图网络标识ID,根据获得的子图网络ID获取相应的子图网络关联信息,再根据获得的子图网络关联信息对该请求目标值进行计算处理。与现有技术相比,对应只包含一个目标值的情况,采用本申请的方法也具有显著的有益效果。采用本申请的方法无需对整个关系网络图森林进行搜索,只需找到对应的子图网络ID即可,省去了对关系网络数据库的繁琐的搜索过程。此外,根据找到的子图网络ID获取相应的子图网络信息,一次读取子图网络关联信息就可以完成对该请求目标值的计算处理,相比需要多次读取且每次只能读取相邻节点的办法,效率显著提高。当然,本申请优选的应用场景是在多目标值的处理过程中,在多目标值的处理过程中,更加凸显本申请的优势和长处,采用本申请的方法能极大地提高图计算的效率。
采用本申请提供的实施例,可以将网络图森林划分为连通的网络子图,然后将网络子图中的所有关联信息保存在一起。在进行网络关系实时计算时,可以针对多个计算目标值,一次读取一个子图网络数据进行多次图计算,也可以一次读取多个子图网络数据进行多次图计算,且读取数据量控制在合理范围内,进而极大地提高了图计算的效率。提高了关系网络计算在传统数据库支持下的计算性能。
基于上述实施例,参阅图5所示,本申请实施例中,应用服务器(即关系网络的计算装置),包括获取单元50、处理单元51和计算单元52,其中,包括:
获取单元50,用于接收用户的计算请求,并获取计算请求中包含的至少一个请求目标值;
处理单元51,用于分别确定至少一个请求目标值所关联的节点,并获取对应每一个节点预设的子图网络标识ID,以及根据获得的子图网络ID获取相应的子图网络关联信息,子图网络关联信息用于描述归属于同一子图的节点及节点间的关联关系;
计算单元52,用于根据获得的子图网络关联信息对至少一个请求目标值进行计算处理。
较佳的,分别确定至少一个请求目标值所关联的节点,并获取对应每一个节点预设的子图网络标识ID,以及根据获得的子图网络ID获取相应的子图网络关联信息,子图网络关联信息用于描述归属于同一子图的节点及节点间的关联关系,以及根据获得的子图网络关联信息对至少一个请求目标值进行计算处理,处理单元51和计算单元52具体用于:
若同一请求目标值关联至少两个节点,且至少两个节点对应相同子图网络ID,则直接获取对应子图网络ID预设的子图网络关联信息,并采用获得的子图网络关联信息对同一请求目标值进行处理;
若存在至少两个请求目标值关联的节点对应同一子图网络ID,则直接获取同一子图网络ID对应的子图网络关联信息,并采用获得的子图网络关联信息对至少两个请求目标值进行合并处理;
若存在至少两个请求目标值且至少两个请求目标值关联的节点分别对应不同的子图网络ID,则分别获取对应每一个子图网络ID对应的子图网络关联信息,并采用获得的每一个子图网络关联信息分别对相应的请求目标值进行处理。
较佳的,进一步包括:
预处理单元,用于:
根据保存的用户历史操作记录筛选出指定类型的节点,再依据用户历史操作记录中记载的用户操作内容在各个节点之间建立关联关系,生成关系网络;
依据各个节点之间的关联关系将关系网络划分为若干子图,其中,各个子图之间无关联关系,且每一个子图中的节点是唯一的,以及归属于同一子图中的任意两个节点之间能够连通。
较佳的,应用服务器依据各个节点之间的关联关系将关系网络划分为若干子图时,预处理单元具体用于:
对应关联网络中的每一条边分别记录相应的起始节点、终止节点以及节点间关联关系;
将起始节点和终止节点归属于同一子图网络中,并设置子图网络标识ID,其中,若同一节点出现在两条边中,则将这两条边归属于同一子图网络中;
记录每一个子图网络ID和相应子图中每一个节点之间的映射关系,以及记录每一个子图网络ID和对应的子图网络关联信息,子图网络关联信息中包含有相应子图内的每一条边所表征的起始节点、终止节点和节点间关联关系。
较佳的,将起始节点和终止节点归属于同一子图网络中,并设置子图网络标识ID,其中,若同一节点出现在两条边中,则将这两条边归属于同一子图网络中时,预处理单元具体用于:
若对应起始节点和终止节点均未记录子图网络ID,则对应起始节节点和终止节点创建一个新的子图网络ID;
若对应起始节点记录有子图网络ID,而对应终止节点未记录子图网络ID,则将终止节点的子图网络ID设置为起始节点的子图网络ID;
若对应起始节点未记录子图网络ID,而对应终止节点记录有子图网络ID,则将起始节点的子图网络ID设置为终止节点的子图网络ID;
若对应起始节点和终止节点记录的子图网络ID不一致,则将终止节点归属的子图网络中所有节点的子图网络ID均设置为起始节点的子图网络ID。
从对已有装置的介绍可以知道,关系网络的计算装置可以分为两大流程:预处理流程和计算流程,其中预处理流程指预处理单元,计算流程包括获取单元、处理单元和计算单元。所以在每一次的关系网络计算流程中,宏观上可以把两个流程的顺序理解为,先预处理流程,后计算流程,上文也是按这种顺序介绍的详细实施过程,但是从严格上来说,两个流程是相互独立的。
例如,在执行计算流程进行计算时,突然收到一个用户操作更新,则执行相应的预处理流程,在这里计算流程和预处理流程可以同时进行不会互相影响。接收到新的用户历史操作记录后可立即触发预处理流程,但是本申请优选的是定时触发预处理流程的方法,比如每天执行一次关系网络构建。
综上所述,本申请实施例中,将网络图森林划分为连通的网络子图,然后将网络子图中的所有关联信息保存在一起。在进行网络关系实时计算时,针对一个计算目标值的情况,无需对整个关系网络图森林进行搜索,只需找到对应的子图网络ID即可,省去了对关系网络数据库的繁琐的搜索过程,此外,无需多次读取操作,只需一次读取子图网络关联信息就可以完成对该请求目标值的计算处理,图计算效率显著提高;针对多个计算目标值的情况,可以对目标值进行归并处理,一次读取一个子图网络数据就进行多次图计算,也可以一次读取多个子图网络数据进行多次图计算,且读取数据量控制在合理范围内,进而极大地提高了图计算的效率,提高了关系网络计算在传统数据库支持下的计算性能。
本领域内的技术人员应明白,本申请的实施例可提供为方法、系统、或计算机程序产品。因此,本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
尽管已描述了本申请的优选实施例,但本领域内的技术人员一旦得知了基本创造性概念,则可对这些实施例作出另外的变更和修改。所以,所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。
显然,本领域的技术人员可以对本申请实施例进行各种改动和变型而不脱离本申请实施例的精神和范围。这样,倘若本申请实施例的这些修改和变型属于本申请权利要求及其等同技术的范围之内,则本申请也意图包含这些改动和变型在内。