CN102087655A

CN102087655A - 一种能体现人际关系网的网站系统

Info

Publication number: CN102087655A
Application number: CN2009102636364A
Authority: CN
Inventors: 张玉峰
Original assignee: Individual
Current assignee: Individual
Priority date: 2009-12-08
Filing date: 2009-12-08
Publication date: 2011-06-08

Abstract

本发明公开了一种能体现人际关系网的网站系统，涉及到对现有的关系型数据库中SQL语句不擅长搜索关系路径的改进。随着现在各种社交网站、社交软件及社交工具的兴起，这些大型网站通常都有数千万甚至数亿的会员量，这些会员的数据以及会员之间的关系数据通常都保存在关系型数据库中，然而，现有的关系型数据库SQL语句并不擅长于在这样复杂的关系数据中求解两个节点的关系路径。本发明采用将一般数据和节点关系数据分离，以及节点路径搜索步骤也从SQL语句中分离出来的方式，有效的提高了搜索效率，实现了一种能体现人际关系网的网站系统。

Description

一种能体现人际关系网的网站系统

原申请款项

申请日：2009年12月08日

申请号：200910200123.9

发明创造名称：关系型数据库和网状数据结构相结合的关系路径搜索方法

技术领域

本发明涉及一种搜索人际关系路径的方法，特别涉及到对现有的关系型数据库中SQL语句不擅长搜索人际关系路径方法的改进。

背景技术

随着现在各种社交网站、社交软件及社交工具的兴起，这些大型网站通常都有数千万甚至数亿的会员量，假设每个会员和其他100个会员有关联关系(朋友、亲戚、同事或其它关系)，这样海量的数据构建的人际关系网是相当复杂的。挖掘其中会员间的关系路径和关系图(关系图是关系路径的集合)，可以增进人与人之间的信任，具有广泛的意义。并且，依据“六度分割理论”会发现我们距离任何一个人的关系都不远，可以增进社会和谐。

当A和B、C有关联关系，C和D有关联关系，如果我们想求解A和D之间的关系路径，对于像这样简单的数据，很容易就得到路径是A<->C<->D。然而，假设在一个数据库中，任意一个节点和其它任意100个节点有关联关系，当遍历一个节点的第一层关系时，将遍历100个节点，当遍历一个节点的第二层关系时，将遍历100×100＝10000个节点，依次类推，当遍历第6层关系时，将遍历10¹²个节点。依本技术领域人员的公职常识所知，当前绝大部分网站的数据都是保存在关系型数据库中，而关系型数据库是以表为基本数据结构的，其SQL语句并不擅长于此类关系路径的搜索。本发明正是为求解海量数据(百万级以上)库中两个节点的关联关系路径，以及由多条关系路径组成关系图。

发明内容

本发明的目的是实现一种能体现人际关系网的网站系统。突破了由于关系型数据库的结构限制在关系路径搜索上造成的效率低下问题。

为达到上述目的，实现一种能体现人际关系网的网站系统，分为4个步骤：

1)收集数据保存到关系型数据库中。包括一个或者一个以上的保存用户所有资料的关系型数据库[101]，数据库中的用户ID字段是用户会员(这里所指的会员，可以是个人、单位以及其它实体，被称为一个节点)的唯一标示(不重复，能唯一标示一个用户)，使用整型类型的数据，用户的其它资料数据根据相应需求设置。为了突出主题，会员注册资料、登录、加好友等一般性步骤不在此赘述。

2)从关系型数据库中抽取节点关系数据保存成网状数据结构，并实时更新[104]。在内存或硬盘中创建一个用户基本列表[201]，用户基本列表[201]的索引号和用户ID有一个简单的对应关系，互相可以通过加上或减去一个常数计算所得，用户基本列表[201]中保存的成员是用户相应的关系列表句柄。读取关系型数据库中所有的用户ID以及需要参加判断的用户其它数据，分别创建每个用户的关系列表，并将关系列表的句柄存入用户基本列表[201]的相应位置。用户的关系列表中保存的是和此用户有关联关系的用户ID。(如图2所示)

3)在网状数据结构的节点关系数据区中，搜索节点关系路径[105]。需要请求路径关系的应用程序(这里的应用程序可以是运行于前端应用服务器上的应用程序，也可以是运行于终端客户端上的应用程序)把搜索条件发送至服务端，服务端接收到搜索条件[301]，先将源ID和目标ID组合成一个唯一的ID，然后根据这个组合ID和其它的输入条件在关系路径缓存区中搜索[302]。如果没有找到，就依据输入条件，在网状数据结构的节点关系数据区中搜索关系路径[305]，直到完成所有搜索，然后将搜索的结果和相关联的条件保存至关系路径缓存区[306]，以加速下一次的同类搜索。然后将搜索结果发送至请求客户端[307]。(如图3所示)

4)在关系型数据库中使用SQL语句搜索关系路径节点上的用户的其它资料[106]，并组成呈现方式[107]。在接收到第(3)步搜索的结果之后，发送请求的应用程序可以根据搜索结果的关系路径去关系型数据库服务器上搜索路径中成员的其它数据(比如：姓名、性别等)，然后根据这些信息以及关系路径条数组成相应的呈现方式。比如：如果是一条关系路径，可以呈现成条状的由用户姓名构建的路径；如果是多条关系路径，可以呈现成树状的、网状的或者立体网状的由用户名称构成的关系图。呈现方式可以由美术人员依据需求进行设计，不局限于上述呈现方式。

采用上述方法，从保存用户所有资料的关系型数据库[101]中抽取节点关系数据，以网状结构(如图2所示)保存在某个数据区[102]中，然后使用自定义的算法流程(如图4，是一种实施方案的算法流程)在此节点关系数据区中搜索节点关系路径，这样就避免了关系型数据库中SQL语句不擅长求解两节点关系路径的问题，然后在关系型数据库中搜索关系路径节点上用户的其它资料[106]，最后组成某种形式(条形路径状或者网状)的呈现方式。可以重复步骤(3)和步骤(4)，以完成不同条件的搜索。

本发明的有益效果：

1)从结构特点和理论分析如下：

通常海量的用户数据都被保存在关系型数据库中，在数据库的设计上为了满足数据库的五个范式要求，其中用户关系通常被保存在一张表(假设命为conn)中，假设数据库中有100万个用户数据，每个用户平均和其他任意100个用户有关联关系，这样，关系表conn中保存的数据有1亿条。当搜索某用户的第一层关系时，使用SQL语句要从conn表的1亿条数据中遍历出他的100个关联关系，搜索第二层关系时，他的100个关联关系每一个都要再次从conn表的1亿条数据中遍历，依次类推下去，这是个很庞大的搜索操作。依据本发明的方法，如图2所示网状数据结构的节点关系数据，当搜索ID为2的第一层关系时，根据用户ID和用户基本列表索引号的一一对应关系，直接读取用户基本列表[201]的索引号为2的位置的内容，其内容是ID为2的用户的关系列表的句柄，可以直接定位到ID为2的用户的关系列表，在实际运算中，是个读取指针的操作，依据本技术领域常识，要比关系型数据库中遍历1亿条数据要快的多。用户的关系列表中保存的是和其用户有关联关系的用户ID，依次类推下去，可以根据这些ID快速定位到相应的关系列表(具体算法详见下述的具体实施方式)。依据本技术领域的常识可以很显然的看出，本发明的方法在结构和理论上要比在关系型数据库中搜索关系路径要快的多。

2)从测试数据上分析如下：

本发明中的关系路径搜索方法已在申请人研发的人际关系搜索引擎中得到应用，并进行了与关系型数据库搜索关系路径的比较测试。测试的软硬件环境是“CPU 2.8GHz、内存2G、Windows Server2003操作系统、MySQL数据库、人际关系搜索引擎”；测试的数据环境为，通过随机生成的100万个用户数据，以及每个用户和其他随机的100个用户有好友关系；测试的操作，搜索两个用户的第一条最短关系路径。测试数据结果如下：

从上图的数据可以看出，使用本发明的方法搜索两者之间第1层和第2层的第一条最短关系路径所用的平均时间明显少于MySQL数据库。由于使用关系型数据库在这种数据量级下搜索三层以及三层以上的关系路径时，所消耗的硬件资源及时间资源已经太大，导致不便测试。但从上图中可以看出，使用本发明的方法搜索任意两者间的平均时间已经明显小于MySQL数据的第一层搜索所用的平均时间，由此可以看出，本发明的方法比关系型数据库在人际关系路径的搜索效率上有明显的突破性提高。

附图说明

图1为本发明一种能体现人际关系网的网站系统的主要流程图。

图2为本发明一种能体现人际关系网的网站系统的节点关系网状数据结构示意图。

图3为本发明一种能体现人际关系网的网站系统的一个具体实施方案的路径搜索请求流程图。

图4为本发明一种能体现人际关系网的网站系统的一个具体实施方案的在节点关系数据区中搜索关系路径的流程图。

图5为本发明一种能体现人际关系网的网站系统的一个具体实施方案的服务器部署逻辑结构图。

具体实施方式

本发明关系型数据库和网状数据结构相结合的关系路径搜索方法一个具体的实施方案是：首先从保存用户所有资料的关系型数据库[101]中抽取节点关系数据，以网状结构(如图2所示)保存在某个数据区[102]中，然后使用自定义的算法流程(如图4)在此节点关系数据区中搜索节点关系路径，然后在关系型数据库中搜索关系路径节点上用户的其它资料[106]，最后组成某种形式(条形路径状或者网状)的呈现方式。可以分为两个实施阶段：

第一阶段：创建关系型数据库和抽取关系型数据库中节点关系数据构建节点关系数据区。如图5所示，在逻辑上分为节点关系服务器、数据库服务器、前端应用服务器(在物理上，可能是同一台物理服务器)。

a)数据库服务器采用关系型数据库保存用户的所有资料(比如：用户ID、用户名、性别、年龄、所属组、用户的朋友关系等)。

b)节点关系服务器以网状结构保存节点关系(如图2所示)以及需要参加条件判断的用户其它资料(比如：用户所属组)。用户基本列表[201]中保存的不是用户ID，保存的是其中的用户的关系列表的句柄(这里的句柄根据实现语言的不同，所指的数据类型不同，在C和C++里，指的是指针类型，在C#里指的是引用类型，其共同点就是都能直接指向相对应的关系列表，并且可以快速定位到所指向的关系列表)以及和判断相关的用户其它数据，用户基本列表[201]的索引号和用户ID有个简单的对应关系(比如，索引号等于用户ID加上一个常数，这个常数可以是0，正整数、负整数)。用户的关系列表中保存的是和这个用户的有关联关系的用户ID。举例说明：用户基本列表[201]的索引号和用户ID的差值常数取值为0，那么索引号和用户ID就是一一对应关系，假设接受到输入条件的源ID是2，那么就可以快速定位到列表索引号为2的位置，读取其中的内容是ID为2的用户的关系列表句柄，根据此句柄直接定位到ID为2的用户的关系列表[202]，关系列表[202]中保存的是和ID为2的用户有关联关系的用户ID(比如：如果ID为3的用户和ID为2的用户是朋友关系，就把3保存入ID为2的用户关系列表)。

c)节点关系数据同步[501]，指的是当关系型数据中和节点关系数据区有关系的数据发生添加、删除、修改等更新时，实时通知节点关系服务器更新相关数据。使用SQL语句编写存储过程，响应关系型数据库中添加、删除、修改等事件，调用通讯例程，通知节点关系服务器更新相关数据。节点关系服务器之间的负载均衡和数据库服务器之间的负载均衡，不是本发明要突出的主题，不在此赘述了。

d)前端应用服务器[502]包括Web服务端、应用程序服务端(物理上可以是一台或多台服务器)等，在此层可以处理业务逻辑，接收用户终端的请求，分解业务逻辑，生成搜索关系路径的输入条件，然后将此条件通过Socket、Http或者远程函数调用等通讯机制传给后台的节点关系服务器，搜索关系路径，然后在关系型数据库中搜索路径上的用户的其它资料，生成需要传给用户终端的数据，传给用户终端。

第二阶段：搜索关系路径并组成呈现图。如图1和图5所示，前端应用服务器[502]接收到搜索请求条件[103]，然后在节点关系数据区中搜索节点关系路径[105]，得到节点关系路径后，在关系型数据库中搜索关系路径节点上用户的其它资料[106]，然后把需要传递给用户终端的数据传递给用户终端，用户终端得到相关数据后，组成呈现方式[107](单条路径图或者网状图)等。关系路径搜索部分具体分解为如下步骤(如图3所示)：

1)接收搜索请求条件[301]。输入的条件至少包含源ID和目标ID。除了源ID和目标ID以外的其它条件(比如：所属组、搜索关系层次、搜索多少条路径等)如果没有输入，则使用系统设置的默认值。

2)搜索关系路径缓存区[302]。关系路径缓存区是根据源ID和目标ID的组合为索引保存的搜索历史，同时也保存每条关系路径的搜索条件，关系路径缓存区可以加速搜索。

3)将搜索结果存入临时缓存区[303]。通常请求端和服务端不在同一台计算机上，它们之间采用Socket、Http和远程函数调用等远程通讯机制，将搜索结果存入临时缓存区，可以由其它线程根据不同的通讯机制发送至请求端。

4)判断是否完成请求条件[304]。比如，输入的条件是搜索两个节点间6层以内的5条关系路径，如果上述步骤只搜索到3条，没有完成搜索条件，则将条件传入下一个步骤(5)。

5)在节点关系数据区中搜索关系路径[305]。为更详细说明，此步骤搜索又分为如下子步骤(如图4所示)：

子步骤①：接收输入条件[401]。输入的条件至少包含源ID和目标ID，在除了源ID和目标ID以外的其它条件(比如：所属组、搜索关系层次、搜索多少条路径等)没有输入时，使用系统设置的默认值。

子步骤②：将源ID压入路径栈[402]。路径栈是一种保存在全局访问区的后进先出的数据结构，在进行迭代搜索时，保存在路径栈中的ID按先后顺序排列正是要搜索的关系路径。

子步骤③：根据源ID直接定位到用户基本列表[201]中相应位置，并取出此用户的用户关系列表的句柄[403](节点关系数据结构如图2所示)。

子步骤④：根据上述句柄，直接定位到相应的用户关系列表[404](节点关系数据结构如图2所示)。

子步骤⑤：如图4所示，从判断当前用户关系列表是否已经完全遍历[405]->按顺序读取当前用户关系列表中下一个用户的资料[406]->判断当前取出的用户ID和目标ID是否一致[407]->判断是否满足其它的输入条件[408]->读取路径栈，计算关系路径，并将关系路径存入临时缓存区[409]->判断是否搜索完成要求的条数或者满足其它退出条件[410]->判断当前用户关系列表是否已经完全遍历[405]，这是一个循环过程。按顺序遍历访问当前用户关系列表(当前用户关系列表，是指在此层次迭代搜索中子步骤④所得到的用户关系列表)，当找到符合条件的ID时，读取路径栈，计算关系路径，并将关系路径存入临时缓存区。在循环中，判断是否搜索完成要求的条数或者满足其它退出条件[410]，满足则退出。

子步骤⑥：完成子步骤⑤之后，判断当前正在搜索的层是否达到用户设定或系统设定的最大搜索层数[411]，如果否，进入子步骤⑦；如果是，进入子步骤⑧。

子步骤⑦：重新遍历当前用户关系列表，以当前用户关系列表中的ID代替源ID，其它条件不变，进入下一层进行迭代搜索[412]。

子步骤⑧：判断当前正在搜索的层是否是第一层[413]，如果是，则退出；如果否，则弹出路径栈中当层的源ID，返回上一层迭代搜索[414]。

6)将步骤(5)搜索的结果存入临时缓存区，同时存入关系路径缓冲区[306]。

7)将临时缓存区中的搜索结果发送至请求端[307]。根据选择的通讯机制，同步方式或者异步方式将搜索结果发送至请求端。

上述实施方案中，充分发挥了关系型数据库的SQL语句搜索和网状数据结构的关系路径搜索的优势。并且，如图1所示，在节点关系数据区中搜索节点关系路径[105]，在关系型数据库中搜索关系路径节点上用户的其它资料[106]，其中关联的是“节点关系路径”，所以，可以依据系统需求针对上述关系路径搜索算法进行优化，甚至替换，只要得到“节点关系路径”，就能在关系型数据库中搜索关系路径节点上用户的其它资料[106]。这种设计被认为是松耦合的。

由测试数据，使用本发明方法搜索任意两者间第一条最短路径所用的平均时间是0.113秒，每秒大概响应9条请求，每天一台服务器可以响应77.76万次请求。本发明为实现一种能体现人际关系网的网站系统提供了切实可行的方法和实施方案。

Claims

1.一种能体现人际关系网的网站系统，包括：

1)一个或多个用于保存用户资料的关系型数据库；

2)一个或多个用于保存用户节点关系数据的节点关系数据区；

3)用于搜索用户间关系路径的搜索模块；

4)用于组成人际关系路径或人际关系网的呈现模块。

2.如权利要求1所述，一种能体现人际关系网的网站系统，其特征是：包括一个或多个用于保存用户节点关系数据的节点关系数据区。

3.如权利要求1所述，一种能体现人际关系网的网站系统，其特征是：包括用于搜索用户间关系路径的搜索模块。

4.如权利要求1所述，一种能体现人际关系网的网站系统，其特征是：包括用于组成人际关系路径或人际关系网的呈现模块。