分享到

Windows微信：消息数据库架构演进

科技 2023-2-2 09:20 549人浏览 0人回复

收藏分享邀请

摘要

作者：Jon，来自微信客户端团队本文基于微信用户日常利用场景 & 数据分析，「通过分离重要 / 非重要数据、接纳可靠的分库计谋等」，对微信数据库架构举行优化 & 改造，并终极得到一个具备实践精良效果的改造方案

作者：Jon，来自微信客户端团队

本文基于微信用户日常利用场景 & 数据分析， 「通过分离重要 / 非重要数据、接纳可靠的分库计谋等」 ，对微信数据库架构举行优化 & 改造，并终极得到一个具备实践精良效果的改造方案。

背景说明

微信 for Windows自2014年上线以来，用户数稳步增长。随着时间的不停推移，用户积攒的消息量越来越大。最初的数据库设计秉着 「遵照简单易用，方便管理」 的原则，把用户收到的所有消息都统一存放在用户当前客户端当地的 「同一个数据文件中。」

(注：微信不会保存聊天记载，聊天内容只存储在用户手机、电脑等终端装备上。)

目前问题

该方案随着目前微信利用越来越广泛、消息越来越多而渐渐袒暴露许多问题：

问题1：慢

随着利用时间的推移，数据也渐渐增多，数据库的查询和插入效率会受到影响；即使消息数据库存在索引，当数据量越来越庞大，索引的查询效率也随之下降。
从文件系统的角度，数据库文件是逐页增长的。因为长时间的利用微信会使得消息量的渐渐累积，让数据库体积渐渐增长，也会导致碎片化更严峻，这在机械硬盘下，也会进一步影响读写效率。

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

问题2：大

随着时间的推移，消息量的渐渐累积，数据库体积也是越来越大，占用用户存储空间。

问题3：磁盘文件损坏

磁盘文件意外损坏也有可能导致数据丢失。因为所有消息都放到一个数据库文件，就雷同把所有鸡蛋放在一个篮子。数据库文件也可能会因为存储坏道、电脑意外断电、sqlite自身bug等原因导致数据库文件发生损坏。假如发生损坏时，有可能导致用户丢失消息数据。即使有DB恢复机制，也无法包管能恢复出所有汗青记载。

当这种情况发生时，对用户影响十分大， 「因为聊天记载可能没了！」

原因分析

上述变大和变慢的问题， 「都是由于消息数据的不停增多引起。」 但消息数的增长是无法避免的，「那么有没有办法控制增长速率，而且控制数据库的巨细？」

我们从两个方向举行分析：消息情况、日常利用场景

分析1：消息情况

消息分类

用户消息可分为三大类：单人聊天，群聊，以及订阅号/服务号消息（统称为公众号消息）。

从重要性区分：

单聊和群聊消息：用户的私人消息，被删除或者丢失无法恢复，对用户丧失最大；
公众号消息：因为只要关注了公众号，都可以拉取阅读，属于公共的消息，以是对用户来说重要性稍低。

消息巨细

基于对测试帐号的消息巨细数据分析，我们发现，占总条数比例不高的公众号消息，占用了凌驾一半的数据库空间。
颠末对测试帐号消息类型的分析，网页卡片类消息是公众号消息的主要类型，其均匀消息体巨细是文本消息的几十倍。

分析2：日常应用场景分析

众所周知，我们日常利用微信，都是收发消息，或者浏览最近的消息。对于更早的消息，我们一样平常很少会自动去浏览。越早的消息，浏览的概率越低，以是在大多数场景下，我们要让最常访问的消息，不受老数据的影响。

办理方案

针对上述问题 & 联合分析，从以下方面对微信数据库的架构举行演进 & 优化：

分库改造
建立消息索引
消息体积优化
提高数据库结实性

1. 分库改造

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

基于日常利用场景的分析，大部门老数据读取的频率很低， 「以是应该提高最近一段时间的读写效率」 。对于这种情况，我们接纳了 「以时间和空间动态划分数据库」 的方案。初始默认值是每个数据库存放半年的消息，超逾期间之后新建一个数据库存放。对于大部门利用场景，我们只必要读写最新的数据库就可以满意需求，假如必要浏览更早的消息，可以再打开之前的数据库举行读取。

除了时间维度，我们还考虑了空间维度的划分。假如半年内消息平凡消息规模凌驾阈值，也会新建一个数据库举行存储，让每个数据库巨细和数据规模不至于太大，能提升最近一段时间消息的读写效率。

2. 建立消息索引

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

这里的索引方案我们参考了安卓端：「即将每一个聊天转换成一个数值型的ID，从而减少每条索引的长度，提高索引的读写效率」。除此之外，我们还对一些经常访问的内容，单独提取成为一个字段，而且增长索引。比如消息的子类型，这个在老数据库中是一个序列化字段，没有索引；但这个字段经常必要用到，以是单独提出成为一列，而且加上索引，为消息按类型查找提供方便。

3. 消息体积优化

消息总是会越来越多的，如何能够不影响读写效率的同时，减少 & 压缩体积，是我们的优化方向。

从上面的数据看，部门消息体积较大，已经凌驾了数据库每页的巨细(Page Size)。数据库是按页存储数据的，Page Size是数据库一页能够容纳的数据。假如一条数据，一个页放不下，就必要用到溢出页，把多出来放不下的数据放到溢出页中，溢出页可以有多个。这时间，假如读取这条数据，就必要把溢出页也全部读出来，会增长IO的消耗。「假如压缩数据，能够把消息体压缩到一个页能放得下，减少溢出页的利用，是可以增长IO性能的」。

数据库溢出页布局(泉源：《The Definitive Guide to SQLite》)

但是压缩必要占用CPU资源，这里选择一种能够平衡性能和压缩率的算法是关键。

颠末对比压缩算法的Benchmark，而且对消息体压缩性举行实测， 「终极选择了一个高性能压缩算法：lz4 」 。

颠末对测试帐号的数据分析，不同类型的消息体巨细差异较大，一样平常来说，文本消息的长度不会特殊大，但是网页卡片类型的消息，体积会较大。由于不同的消息长度，获得的压缩率不一样，太短的文本长度，压缩起来并没有意义，以是颠末消息体长度，压缩率，压缩性能的分析，终极确定对网页卡片等举行压缩，在较低性能消耗的条件下， 「综合压缩率可到达40%，减少了IO次数」 。

4. 提高结实性

假如数据库文件由于外部原因发生损坏，则会对体验造成较大影响。降低损坏率和减少损坏带来的数据丧失，也是我们改进的方向。

按照时间维度划分数据库之后， 「相当于把消息按时间分散存储」 ，最新的数据库负责读写最近的消息，其余的数据库只必要根据需求支持浏览查看消息。对于老数据库而言，可以做到按需加载，从而减少了对数据库的读写，也减少了这些数据库损坏的几率。一旦有数据库出现损坏，即使无法恢复，也不会所有消息全部丢失，只会丢失该数据库对应时间段的消息，这也可以减少部门数据库损坏带来的丧失。

在早期利用的单数据库架构中，由于数据会越攒越多，数据库体积会连续变大，很难去做备份。分库之后，每个数据库体积变小，因而数据库备份变得更为可行。因为最新的数据库存在频仍的消息读写，发生损坏的概率远高于老数据库，以是这里对最新的一个数据库做定期的备份。「默认设置下，我们每间隔一段时间会对最新的数据库举行一次备份，该备份是最新的一个数据库的完整拷贝」。若最新的数据库在读写时发生损坏，会先实验从备份数据恢复。若恢复乐成，则最多丢失从备份到恢复这段时间的数据，进一步降低损坏造成的丧失。