一种即时通信领域的终端数据库构建方法与流程

本发明涉及即时通信领域，具体涉及一种即时通信领域的终端数据库构建方法。

背景技术：

即时通信，指的是一种基于互联网的即时交流消息的业务，也称为“实时通信”，简称为im。允许两人或多人使用网络实时的传递文字消息，文件，语音和视频交流。

在当前各种桌面设备，移动设备普及的情况下，及时通信领域的市场需求爆炸性地增长，软件和应用数量也大幅度的增长。但是实际使用中好的产品却不多，大部分产品使用体验较差，或者是开始安装使用的时候体验较好，使用一段时间后系统越来越慢，体验变差。

造成这样的现象一部分是由于网络io没处理好，这个会涉及到服务器部分，终端开发人员没办法完全解决；一部分是磁盘io没有处理好，也就是终端缓存数据没有处理好。由于现在终端缓存的结构化数据基本都在本地数据库存储，实际上是数据库处理的问题，这个就在终端可以处理好。

在工程应用中，提高数据库效率的方法基本上都是增加索引，或者分表的方法。但是具体到某个领域，又有不同的特点。不同领域的软件或者应用有不同的业务特点，同一领域的产品又有不同的功能侧重点，所以设计一套即时通信领域的高效本地缓存数据库处理方法成为一个重要的课题。

现有的终端数据库大多采用的处理方法是用损失缓存数据的方法或者不分类别，不优化处理等不成熟的方法。但是，这样最终会造成系统的整体效率不高，使用人员的体验不好。

也有一些软件/应用使用了数据库优化方法，但是也存在不少问题：1.优化手段单一，常规的办法就是加索引，由于没有根据实际业务分类，随着数据量的增大常会出现越使用越慢的情况；2.进行分表优化，缺乏系统的方法论，全靠开发人员的经验，影响工作的交接，常会出现数据不同步，资源浪费的情况。

技术实现要素：

本发明的目的在于，为解决上述技术问题，提供一种可以在大数据量的情况下，保证系统的整体效率的即时通信领域的终端数据库构建方法。

为解决上述技术问题，本发明采用如下的技术方案：一种即时通信领域的终端数据库构建方法，步骤包括：将数据库涉及的各种数据分为系统信息数据库、群成员数据库和聊天消息数据库；所述系统信息数据库中信息包括最近联系人、好友、个人设置、系统配置和群组；所述群成员数据库中信息包括群成员信息和群成员时间戳；所述聊天消息数据库中的信息包括聊天消息。

如前述的即时通信领域的终端数据库构建方法，用于存储所述系统信息数据库中信息的数据表放在一个单独数据库中，在系统运行时可以缓存到内存中，也可以直接操作数据库。

如前述的即时通信领域的终端数据库构建方法，所述群成员数据库包括群成员信息表，用于存储所述群成员信息，所述群成员信息的名称根据群的唯一id来动态生成；所述群成员信息表个数与群个数相同。

如前述的即时通信领域的终端数据库构建方法，对所述群成员信息的进行读取时，可以根据群的唯一id找到群成员数据库表，读取只在所述群成员数据库表上进行。

如前述的即时通信领域的终端数据库构建方法，所述群成员数据库还包括群成员时间戳表，用于记录各个群成员时间戳信息。

如前述的即时通信领域的终端数据库构建方法，所述聊天消息数据库包括：当前消息数据库和历史存档数据库；所述聊天消息包括:当前消息和历史存档消息；并分别存储于所述消息数据库和历史存档数据库的消息表中，所述消息表的名称根据聊天对象的唯一id动态生成。

如前述的即时通信领域的终端数据库构建方法，所述当前消息数据库和历史存档数据库的消息表均包括联系人消息表及群消息表。

如前述的即时通信领域的终端数据库构建方法，所述当前消息数据库的联系人消息表及群消息表存储的消息数量具有上限阈值，在所述消息数量大于所述阈值时，删除较早的消息，保持所述联系人消息表及群消息表里的条目数不大于所述阈值。

如前述的即时通信领域的终端数据库构建方法，在有新消息到来的时候先写当前消息数据库，后写历史存档数据库。

与现有技术相比，本发明通过将数据库涉及的各种数据分为系统信息数据库、群成员数据库和聊天消息数据库；所述系统信息数据库中信息包括最近联系人、好友、个人设置、系统配置和群组；所述群成员数据库中信息包括群成员信息和群成员时间戳；所述聊天消息数据库中的信息包括聊天消息，使用该方法能大大降低即时通信应用/软件的终端开发难度，减少开发时间，降低开发的资金、时间成本；能够显著提高及时通讯应用/软件的执行效率，降低能耗提高用户的使用体验；在使用后期终端聊天数据备份维护的时候，使用存档数据库进行备份，不影响当前数据库继续提供快速的读写服务，便于备份维护。

附图说明

图1为本发明方法流程示意图；

图2为本发明中加载系统信息数据库流程图；

图3为本发明中加载群成员数据库流程图；

图4为本发明中加载群成员数据库流程图。

下面结合附图和具体实施方式对本发明作进一步的说明。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。

本发明实施例1，如图1所示，所述系统信息数据库中信息包括最近联系人、好友、个人设置、系统配置和群组；用于存储所述系统信息数据库中信息的数据表放在一个单独文件数据库中，可命名为main_db；

系统信息数据库中文件因为数量不大，在系统运行中可以缓存到内存中，也可以直接操作数据库，对系统的性能及体验影响不大；

再建立群成员数据库gmber_db；群成员数据库中信息包括群成员信息和群成员时间戳；

群成员数据库中的群成员信息表，表的名称可以根据群的唯一id来动态生成。比如群的唯一id为10000，群成员表的名称可以命名为gbr_10000_tbl。有多少个群，就有多少张群成员信息表；

群成员数据库中的群成员时间戳表，用于记录各个群成员时间戳信息；

及时通讯中对群成员信息的读取得时候，可以根据群的唯一标识找到数据库表，读取只在这张表上进行，操作数据集较小，并且不影响其他群的读写操作；

再建立聊天消息数据库msg_db，oldmsg_db。msd_db为当前消息数据库，oldmsg_db为历史存档数据库；

msg_db里面只有一种表，就是消息表，表的名称可以根据聊天对象的唯一id来动态生成；

聊天对象分为人和群，如果人和群的id是同一体系，比如聊天对象的id为10000，消息表的名称可以命名msg_10000_tbl；

如果人和群的id不是同一体系，比如群的id为10000，群消息表的名称可以命名为msg_1_10000_tbl，人的id为10000，人消息表的名称可以命名为msg_2_10000_tbl。

msg_db和oldmsg_db数据库结构一样，表名和表的数量都一样；

msg_db里面的表存储的消息有数量上限，可以设置一个最大消息数阈值，适用的大部分场景是使用者需要快速查看最近聊天信息记录的场景，由于每张表中的数据量小，所以可以快速的进行检索；

oldmsg_db里面存储是在本地产生的全部历史信息，表的命名方式和msg_db相同，表的数量也相同；

msg_db表里有一最大消息数阈值，当里面的消息数量大于这个阈值的时候，删除较早的消息，保持每张表里的条目数不大于该阈值。

由于消息读的次数和读时候的体验远远大于写消息的时候，所以有新消息到来的时候先写msg_db里的当前表，后写oldmsg_db的历史表。

应用/软件在认证通过后，如图2所示，加载系统信息数据库流程：先从服务器加载数据的时间戳，再根据本地时间戳和服务器时间戳进行比对，先加载系统信息数据库，最后保存数据到main_db中。

如图3所示，加载群成员数据库：首先在群组表里找到群group_1，获取群成员时间戳，如果群成员时间戳表不存在，则建立数据库gmber_db，建立群成员表gbr_1_tbl，比对本地时间戳和网络时间戳，更新群gbr_1_tbl的成员数据表。

如图4所示，加载群成员数据库：在群group_1中发送消息，网络接口调用成功后，产生消息msg1，判断消息数据库msg_db是否存在，如果不存在，则建立数据库msg_db。判断msg_g1_tbl是否存在，如果不存在，则再建立表msg_g1_tbl表，并将聊天数据msg1插入msg_g1_tbl表；

判断历史数据库oldmsg_db是否存在，如果不存在，则建立数据库oldmsg_db。判断oldmsg_db是否存在表msg_g1_tbl，如果不存在，则建立表msg_g1_tbl。然后将消息数据msg1插入msg_g1_tbl；

最后判断msg_g1_tbl表的数据量是否大于消息阈值5000条，如果大于该阈值，则批量删除消息到2000条，保留最近的2000条。

在需要查看群group_1的最新10条消息记录时，判断msg_db是否存在，如果不存在，返回。如果存在，判断消息表msg_g1_tbl是否存在，如果不存在，返回。如果存在，到msg_g1_tbl查询消息记录，由于单表数据库量不超过5000条，使用的sqlite数据库基本查询在毫秒级返回。

以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应所述以权利要求的保护范围为准。