[发明专利]一种社交网络中用户信息存储和查找的方法和装置

说明书

技术领域

本发明涉及社交网络技术领域，尤其涉及一种社交网络中用户信息存储和查找的方法和装置。 

背景技术

在目前以通讯录为基础的社交网络中，好友关系的来源主要采自用户的手机通讯录，据可靠统计，大概每个用户平均拥有的联系人数量为200个，而系统需要针对这某一个用户，存储他的通讯录好友关系，这样就是200条记录/用户。

目前对于这样的数据处理，通常采用的数据库设计原则来为单库单表，这样的设计是比较直接直观，但是对于海量的数据处理查询，均会有一定的瓶颈和限制性，比如查询延迟，反映缓慢，严重甚至导致数据库崩溃，数据异常丢失。

关于上述海量数据查询瓶颈与限制性，试验如下：

假设以中等规模的社交网络人数粗算为100万用户，根据用户匹配规则，单个用户查询量，也为对应的200个号码/人，预计每个用户在一个月内需要重新扫描一次用户关系，则平均每秒钟需要扫描的用户为，1000000用户/30天/24小时/60秒=23.14个用户，就是说平均每秒需要处理23.14个查询请求，处理需要查询的号码特征为23.14*200=4628条/秒（实际中，100万用户不可能全部为活跃用户，但是计算值为平均值，峰值实际数值有可能为计算值的2-3倍，因此根据系统设计最大化原则，此计算公式是合理的）。根据计算数值，在查询峰值时会对一般服务器部署情况的数据库造成压力。另外通常关系型数据库（如mysql）在单表数量达到1000万时即会有数据查询能力下降的表现，如果照前面所述有两亿条数据量，那么查询效率将非常低效。同时，在有索引的情况下，更新操作也将变的极为困难。

在此领域通常做法是将数据扫描后存储入服务器某一数据库，然后进行单一表查找。这将存在两个技术问题，一是整体扫描及传送用户数据，将造成用户使用设备暂时性的占用资源过大，同时网络传输困难，容易丢失部分数据；二是存在单一库单一表中的数据在数据量过大时（如亿级别）查找匹配将变的异常困难，速度慢且消耗大量资源。

发明内容

本发明的目的在于提出一种社交网络中用户信息存储和查找的方法和系统，能够为基于手机号码的朋友关系存储及匹配提高可靠的内容支撑。

为达此目的，本发明采用以下技术方案：

一种社交网络中用户信息存储和查找的方法，包括以下步骤：

A、将用户信息数据输入到shard引擎；

B、shard引擎根据内部分散规则将所述用户信息数据分散到数据库分别存储；

C、社交网络服务器收到用户信息查询指令后，将所述查询指令转发给shard引擎；

D、shard引擎通过内建机制向对应的数据库进行查询，取得查询结果；

E、社交网络服务器对查询结果进行整合后返回。

步骤B中，通过并行方式将所述用户信息数据分散到数据库分别存储。

步骤D中，shard引擎通过内建机制，并行向对应的数据库进行查询。

一种社交网络中用户信息存储和查找的系统，包括输入装置、shard引擎、数据库、服务器和终端，输入装置与shard引擎连接，shard引擎与数据库连接，shard引擎与服务器连接，服务器与终端连接，其中，

输入装置用于将用户信息数据输入到shard引擎；

shard引擎用于根据内部分散规则将输入装置发来的用户信息数据分散到数据库分别存储，并用于接收服务器发来的用户信息查询指令，通过内建机制向对应的数据库进行查询，取得查询结果，发送给服务器；

数据库用于存储用户信息数据；

服务器用于接收终端发来的用户信息查询指令，转发给shard引擎，并用于接收shard引擎发来的查询结果，对查询结果进行整合后返回给终端；

终端用于向服务器发送用户信息查询指令，并用于接收服务器发来的查询结果。

数据库为不少于2个数据库。

采用了本发明的技术方案，为终端提供了可靠的数据存取速度，通过实现类SQL语句支持，减少了系统从原有模式迁移到新模式的复杂度，隐藏了底层实现，不需要了解实现原理，减少使用复杂度，同时提供的类mysql接口，使其对各种语言做到了最大的兼容。

附图说明

图1是本发明具体实施方式中用户信息存储和查找的系统结构示意图。

图2是本发明具体实施方式中用户信息存储和查找的流程图。

具体实施方式

下面结合附图并通过具体实施方式来进一步说明本发明的技术方案。