默认
打赏 发表评论 0
想开发IM:买成品怕坑?租第3方怕贵?找开源自已撸?尽量别走弯路了... 找站长给点建议
微信Windows端IM消息数据库的优化实践:查询慢、体积大、文件损坏等
微信扫一扫关注!

本文由微信客户端技术团队工程师“Jon”分享,原题“Windows微信:消息数据库架构演进”,即时通讯网有较多修订。


1、引言


本文分享的是,微信客户端团队基于对微信用户日常使用场景和数据分析,通过分离重要和非重要数据、采用可靠的分库策略等,对微信Windows端IM本地数据库的架构进行的优化和改造,并最终得到一个具备良好实践效果的技术改造方案。

cover-opti.png

以下是相关技术文章,有兴趣的读者可以一并阅读:


2、背景说明


微信的Windows客户端自2014年上线以来,用户数稳步增长。随着时间的不断推移,很多用户本地积攒的消息量越来越大。

0.png

最初的本地IM数据库设计秉着遵循“简单易用、方便管理”的原则,把用户收到的所有消息都统一存放在用户当前客户端本地的“同一个SQLite数据文件中”。

(作者注:微信不会保存聊天记录,聊天内容只存储在用户手机、电脑等终端设备上。)

3、当前问题


由于初期这套本地数据库设计方案的短板,随着目前微信使用越来越广泛、消息堆积越来越多,从而逐渐暴露出了许多技术问题。

3.1问题1:数据查询慢


随着使用时间的推移,数据也逐渐增多,当数据量越来越庞大:

  • 1)数据库的查询和插入效率会受到影响;
  • 2)即使消息数据库存在索引,索引的查询效率也随之下降。

从文件系统的角度,数据库文件是逐页增长的。因为长时间的使用微信会使得消息量的逐步累积,让数据库体积逐渐增长,也会导致碎片化更严重,这在机械硬盘下,也会进一步影响读写效率。

对用户最直观的影响就是——切换聊天变得很卡,这个问题对于重度用户尤甚,甚至会出现点击聊天就卡顿的情况。

3.2问题2:存储文件大


随着时间的推移,消息量的逐步累积,数据库存储文件的体积也是越来越大,显著占用用户存储空间。

3.3问题3:磁盘文件损坏


磁盘文件意外损坏也有可能导致数据丢失。

因为所有消息都放到一个数据库文件,就类似把所有鸡蛋放在一个篮子。

数据库文件也可能会因为存储坏道、电脑意外断电、sqlite自身bug等原因导致数据库文件发生损坏。如果发生损坏时,有可能导致用户丢失消息数据。即使有DB恢复机制,也无法保证能恢复出所有历史记录。

当这种情况发生时,对用户影响十分大,因为聊天记录可能没了

PS:微信移动端也有类似困扰,有兴趣可以阅读《微信客户端SQLite数据库损坏修复实践》。

4、原因分析


4.1概述


上述数据库存储文件变大和查询变慢的问题,都是由于消息数据的不断增多引起。

但消息数的增长是无法避免的,那么有没有办法控制增长速度,并且控制数据库的大小?

我们从两个方向进行分析:消息情况、日常使用场景

4.2分析1:消息情况


微信里的IM消息可分为三大类:

  • 1)单人聊天消息;
  • 2)群聊消息;
  • 3)以及订阅号/服务号消息(统称为公众号消息)。

按消息的重要性来说:

  • 1)单聊/群聊消息:这是用户的私人消息,被删除或者丢失无法恢复,对用户损失最大;
  • 2)公众号的消息:因为只要关注了公众号,都可以拉取阅读,属于公共消息,所以对用户来说重要性稍低。

按消息的大小来说:

  • 1)基于对测试帐号的消息大小数据分析,我们发现:占总条数比例不高的公众号消息,占用了超过一半的数据库空间;
  • 2)经过对测试帐号消息类型的分析:网页卡片类消息是公众号消息的主要类型,其平均消息体大小是文本消息的几十倍。

4.3分析2:日常应用场景分析


众所周知,我们日常使用微信,都是收发消息,或者浏览最近的消息。对于更早的消息,我们一般很少会主动去浏览。

越早的消息,浏览的概率越低。

所以:在大多数场景下,我们要让最常访问的消息,不受老数据的影响。

5、解决方案


5.1概述


针对前述问题并结合上述分析,我们从以下方面对微信Windows端本地SQLite数据库的架构进行了演进和优化。

涉及的主要优化内容和手段有:

  • 1)分库改造;
  • 2)建立消息索引;
  • 3)消息体积优化;
  • 4)提高数据库健壮性。

下面我们将逐一详细介绍。

5.2分库改造


基于以上分析,首先把公众号消息划分出去,存到单独的一个数据库,跟用户的普通消息隔离,同时也可以大幅减少普通消息数据库的体积。

基于日常使用场景的分析,大部分老数据读取的频率很低,所以应该提高最近一段时间的读写效率

对于上述这种情况,我们采取了以时间和空间动态划分数据库的方案。初始默认值是每个数据库存放半年的消息,超过时间之后新建一个数据库存放。对于大部分使用场景,我们只需要读写最新的数据库就可以满足需求,如果需要浏览更早的消息,可以再打开之前的数据库进行读取。

除了时间维度,我们还考虑了空间维度的划分:如果半年内消息普通消息规模超过阈值,也会新建一个数据库进行存储,让每个数据库大小和数据规模不至于太大,能提升最近一段时间消息的读写效率。

1.png

5.3建立消息索引


对于最广泛的使用场景——查看每一个聊天的消息,这种场景需要对每一个聊天会话建立一个索引。

这里的索引方案我们参考了安卓端:即将每一个聊天转换成一个数值型的ID,从而减少每条索引的长度,提高索引的读写效率。(关于微信的移动端SQLite完整数据库结构,可以参考:《微信本地数据库破解版(含iOS、Android),仅供学习研究 [附件下载]

除此之外,我们还对一些经常访问的内容,单独提取成为一个字段,并且增加索引。比如消息的子类型(这个在老数据库中是一个序列化字段),它没有索引,但这个字段经常需要用到,所以单独提出成为一列,并且加上索引,为消息按类型查找提供方便。

5.4消息体积优化


IM中消息显然总是会越来越多的,但如何能够在不影响读写效率的同时,减少/压缩消息数据的体积,也是我们的优化方向。

从上面的数据看,部分消息体积较大,已经超过了数据库每页的大小(Page Size)。

数据库是按页存储数据的,Page Size是数据库一页能够容纳的数据。如果一条数据,一个页放不下,就需要用到溢出页,把多出来放不下的数据放到溢出页中,溢出页可以有多个。

这时候,如果读取这条数据,就需要把溢出页也全部读出来,会增加IO的消耗。「

如果压缩数据,能够把消息体压缩到一个页能放得下,减少溢出页的使用,是可以增加IO性能的

SQLite数据库溢出页结构:
2.png
(上图引用自书籍《The Definitive Guide to SQLite》第308页)

PS:The Definitive Guide to SQLite这本书的电子版我也给你找到了,请从下面附件处下载:
The Definitive Guide to SQLite (2nd edition, 2010)-52im.net.pdf.zip (3.61 MB , 下载次数: 10 , 售价: 1 金币)

即时通讯网 - 即时通讯开发者社区! 来源: - 即时通讯开发者社区!

上一篇:同一个账号,手机端和web端同时在线时,只有一个端能收到消息下一篇:IM跨平台技术学习(二):Electron初体验(快速开始、跨进程通信、打包、踩坑等)

本帖已收录至以下技术专辑

推荐方案
打赏楼主 ×
使用微信打赏! 使用支付宝打赏!

返回顶部