Loading [MathJax]/jax/input/TeX/config.js
首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >专栏 >Windows微信:消息数据库架构演进

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

作者头像
微信终端开发团队
发布于 2022-08-31 07:10:11
发布于 2022-08-31 07:10:11
1.8K0
举报

作者: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. 提高健壮性

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

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

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

优化对比

经过对比,对于一个在测试帐号中原始的消息数据库,「压缩后大小可以减少接近一半,同时溢出页数和需要使用溢出页的记录数减少也超过一半」

对于读写性能,对比压缩前,压缩后的读取和解压缩性能比之前「有接近10%的提升」

展望

后续我们微信客户端团队将继续研究数据库修复相关的实践,持续关注数据库相关的性能数据,提升可靠性,打造更好的用户体验!

想了解更多「微信客户端技术及开发经验」,请关注「微信客户端技术团队公众号」

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2022-08-30,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 WeMobileDev 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
暂无评论
推荐阅读
编辑精选文章
换一批
五年沉淀,微信全平台终端数据库WCDB迎来重大升级!
WCDB 是微信团队开源的一款基于 SQLite 的终端数据库。自 2017 年 6 月开源以来,它在业界得到了广泛认可并被大量应用,迄今已经推出了十多个版本。在这个过程中,WCDB 一直保持良好的向后兼容性,不断完善原有接口的细节并添加新功能。
微信终端开发团队
2024/04/09
2K1
五年沉淀,微信全平台终端数据库WCDB迎来重大升级!
微信团队开源的终端数据库WCDB有什么优势?
今天看到微信团队的一篇文章,说是自家的开源的终端数据库WCDB进行了重大升级 原文章在这里,感兴趣的朋友们可以围观一下:《五年沉淀,微信全平台终端数据库WCDB迎来重大升级》
小小鱼儿小小林
2024/05/25
5040
微信团队开源的终端数据库WCDB有什么优势?
MySQL 数据库备份(完全备份与恢复)
随着办公自动化和电子商务的飞速发展,企业对信息系统的依赖性越来越高,数据库作为信息系统的核心,担当者重要的角色 数据库备份,是在数据丢失的情况下,能及时恢复重要数据,防止数据丢失的一种重要手段 一个合理的数据库备份方案,能够在数据丢失时,有有效地恢复数据,而且也需要考虑技术实现难度和有效地利用资源
全栈程序员站长
2022/08/28
19.5K0
MySQL 数据库备份(完全备份与恢复)
微信 SQLite 数据库修复实践
微信终端开发团队
2017/08/04
9.5K5
微信 SQLite 数据库修复实践
微信移动端数据库组件 WCDB 系列:数据库修复三板斧(二)
微信终端开发团队
2017/07/21
4.4K0
微信移动端数据库组件 WCDB 系列:数据库修复三板斧(二)
微信移动端数据库组件WCDB系列(二) — 数据库修复三板斧
本文来自:微信移动客户端开发团队公众号(WeMobileDev) 前言 长久以来SQLite DB都有损坏问题,从Android、iOS等移动系统,到Windows、Linux 等桌面系统都会出现。由于微信所有消息都保存在DB,服务端不保留备份,一旦损坏将导致用户消息被清空,显然不能接受。 我们即将开源的移动数据库组件 WCDB (WeChat Database),致力于解决 DB 损坏导致数据丢失的问题。 之前一篇文章《微信 SQLite 数据库修复实践》介绍了微信对SQLite数据库修复以及降低损坏率的
腾讯Bugly
2023/04/23
2K0
微信移动端数据库组件WCDB系列(二) — 数据库修复三板斧
达梦数据库 解决 错误号: -2401 错误消息: 第1 行附近出现错误: 数据库文件路径[/data/DAMENG/TEMP.DBF]错误
本文将详细解析达梦数据库(DM)中常见错误之一:“错误号 -2401,错误消息:第1行附近出现错误:数据库文件路径[/data/DAMENG/TEMP.DBF]错误”。通过对错误原因的分析与解决方法的全面解读,为小白用户提供深入、易懂的解决方案。并且,在文末还有我的联系方式,方便大家交流技术问题。
默 语
2025/05/21
1950
达梦数据库 解决 错误号: -2401 错误消息: 第1 行附近出现错误: 数据库文件路径[/data/DAMENG/TEMP.DBF]错误
存储瘫痪抢救Oracle数据库案例
本次分享的案例是关于HP FC MSA2000存储瘫痪抢救Oracle数据库的案例,故障存储整个存储空间由8块硬盘组成,其中7块硬盘组成一个RAID5的阵列,剩余1块做成热备盘使用。由于RAID5阵列中出现2块硬盘损坏,而此时只有一块热备盘成功激活,因此导致RAID5阵列瘫痪,上层LUN无法正常使用。 由于存储是因为RAID阵列中某些磁盘掉线,从而导致整个存储不可用。因此接收到磁盘以后先对所有磁盘做物理检测,检测完后发现没有物理故障。排除物理故障后对数据全部备份后在进行进一步的分析。 【故障分析】 1、分析故障原因 由于前两个步骤并没有检测到磁盘有物理故障或者是坏道,由此推断可能是由于某些磁盘读写不稳定导致故障发生。因为HP MSA2000控制器检查磁盘的策略很严格,一旦某些磁盘性能不稳定,HP MSA2000控制器就认为是坏盘,就将认为是坏盘的磁盘踢出RAID组。而一旦RAID组中掉线的盘到达到RAID级别允许掉盘的极限,那么这个RAID组将变的不可用,上层基于RAID组的LUN也将变的不可用。目前初步了解的情况为基于RAID组的LUN有6个,均分配给HP-Unix小机使用,上层做的LVM逻辑卷,重要数据为Oracle数据库及OA服务端。 2、分析RAID组结构 HP MSA2000存储的LUN都是基于RAID组的,因此需要先分析底层RAID组的信息,然后根据分析的信息重构原始的RAID组。分析每一块数据盘,发现4号盘的数据同其它数据盘不太一样,初步认为可能是hot Spare盘。接着分析其他数据盘,分析Oracle数据库页在每个磁盘中分布的情况,并根据数据分布的情况得出RAID组的条带大小,磁盘顺序及数据走向等RAID组的重要信息。 3、分析RAID组掉线盘 根据上述分析的RAID信息,尝试通过北亚RAID虚拟程序将原始的RAID组虚拟出来。但由于整个RAID组中一共掉线两块盘,因此需要分析这两块硬盘掉线的顺序。仔细分析每一块硬盘中的数据,发现有一块硬盘在同一个条带上的数据和其他硬盘明显不一样,因此初步判断此硬盘可能是最先掉线的,通过北亚RAID校验程序对这个条带做校验,发现除掉刚才分析的那块硬盘得出的数据是最好的,因此可以明确最先掉线的硬盘了。 4、分析RAID组中的LUN信息 由于LUN是基于RAID组的,因此需要根据上述分析的信息将RAID组最新的状态虚拟出来。然后分析LUN在RAID组中的分配情况,以及LUN分配的数据块MAP。由于底层有6个LUN,因此只需要将每一个LUN的数据块分布MAP提取出来。然后针对这些信息编写相应的程序,对所有LUN的数据MAP做解析,然后根据数据MAP并导出所有LUN的数据。 【数据恢复过程】 1、解析修复LVM逻辑卷 分析生成出来的所有LUN,发现所有LUN中均包含HP-Unix的LVM逻辑卷信息。尝试解析每个LUN中的LVM信息,发现其中一共有三套LVM,其中45G的LVM中划分了一个LV,里面存放OA服务器端的数据,190G的LVM中划分了一个LV,里面存放临时备份数据。剩余4个LUN组成一个2.1T左右的LVM,也只划分了一个LV,里面存放Oracle数据库文件。编写解释LVM的程序,尝试将每套LVM中的LV卷都解释出来,但发现解释程序出错。 仔细分析程序报错的原因,安排开发工程师debug程序出错的位置,并同时安排高级文件系统工程师对恢复的LUN做检测,检测LVM信息是否会因存储瘫痪导致LMV逻辑卷的信息损坏。经过仔细检测,发现确实因为存储瘫痪导致LVM信息损坏。尝试人工对损坏的区域进行修复,并同步修改程序,重新解析LVM逻辑卷。 2、解析VXFS文件系统 搭建环境,将解释出来的LV卷映射到搭建好的环境中,并尝试Mount文件系统。结果Mount文件系统出错,尝试使用“fsck –F vxfs” 命令修复vxfs文件系统,但修复结果还是不能挂载,怀疑底层vxfs文件系统的部分元数据可能破坏,需要进行手工修复。 3、修复VXFS文件系统 仔细分析解析出来的LV,并根据VXFS文件系统的底层结构校验此文件系统是否完整。分析发现底层VXFS文件系统果然有问题,原来当时存储瘫痪的同时此文件在系统正在执行IO操作,因此导致部分文件系统元文件没有更新以及损坏。人工对这些损坏的元文件进行手工修复,保证VXFS文件系统能够正常解析。再次将修复好的LV卷挂载到HP-Unix小机上,尝试Mount文件系统,文件系统没有报错,成功挂载。 4、检测Oracle数据库文件并启动数据库 在HP-Unix机器上mount文件系统后,将所有用户数据均备份至指定磁盘空间。所有用户数据大小在1TB左右。 使用Oracle数据库文件检测工具“dbv”检测每个数据库文件是否完整,发现并没有错误。再使用北亚Oracle数据库检测工具,发现有部分数据库文件和日志文件校验不一致,安排北亚工程师对此类文件进行修复
北亚数据安全与救援
2021/11/15
7520
微信团队分享:微信直播聊天室单房间1500万在线的消息架构演进之路
本文由微信开发团队工程师“ kellyliang”原创发表于“微信后台团队”公众号,收录时有修订和改动。
JackJiang
2021/03/08
2.7K0
业务核心数据库架构演变——权衡取舍的艺术
LCS 是一个基于 Python Django 框架的项目,业务核心是物流订单的履约过程,包括连接上游和第三方物流服务的创建订单、轨迹与运费更新。在部署上,LCS 依据业务所在的市场不同,应用层分市场部署,并使用各自市场对应的数据库。在项目起步初期,这些不同市场的数据库共用同一套物理集群,共享内存和磁盘空间,在资源上看,是足以应付初期流量的。
Shopee技术团队
2021/09/02
7780
业务核心数据库架构演变——权衡取舍的艺术
SQL Server 数据库设计
SQL Server 系统数据库在安装软件时自动创建,用于协助系统共同完成对数据库的操作;也是数据库运行的基础;
剑指工控
2021/11/09
2.8K0
SQL Server 数据库设计
sql server数据库置疑_数据库置疑什么原因
1、SQL Server所在分区空间是否足够,数据库文件大小是否达到最大文件限制,FAT32事务格式只支持4G以内的文件?
全栈程序员站长
2022/09/24
1.7K0
将 SQL Server 数据库恢复到不同的文件名和位置
一、概述 RESTORE ... WITH MOVE 选项允许您恢复数据库,但也可以指定数据库文件(mdf 和 ldf)的新位置。如果您要从该数据库的备份还原现有数据库,则不需要这样做,但如果您要从具有不同文件位置的不同实例还原数据库,则可能需要使用此选项。 RESTORE ... WITH MOVE 选项将让您确定数据库文件的名称以及创建这些文件的位置。在使用此选项之前,您需要知道这些文件的逻辑名称以及 SQL Server 的位置。 如果已经存在另一个使用您尝试还原的相同文件名的数据库并且该数据库处于联
IT大咖说
2022/08/26
1.5K0
将 SQL Server 数据库恢复到不同的文件名和位置
架构设计-数据库篇
之前我们讲过架构设计的一些原则,和架构设计的方法论,今天我们谈谈高性能数据库集群的设计与应用。
架构狂人
2023/08/16
4010
架构设计-数据库篇
在数据库系统中遇见"存储技术飞跃"会怎样?
* 对大表做数据拆分,先做垂直拆分(按业务拆分,将不同业务的字段拆分到不同的表、或不同的数据库、甚至不同的实例中),然后做水平拆分(对于无法继续拆分字段的表,如果数据量仍然大到影响性能,则可能还需要以不超过1000W行数据量的标准继续对大表执行拆分,即就是我们常说的数据分片)
老叶茶馆
2020/09/23
6990
在数据库系统中遇见"存储技术飞跃"会怎样?
SQLite优化实践:数据库设计、索引、查询和分库分表策略
SQLite是一款轻量级的嵌入式数据库,广泛应用于各种场景,如桌面应用程序、移动应用和物联网设备。尽管SQLite本身具有良好的性能和易用性,但在实际应用中,仍然需要我们对数据库进行优化,以提高查询速度和数据处理能力。本文将从数据库设计、索引优化、查询优化和分库分表等方面,详细介绍SQLite优化的实践方法。
陆业聪
2024/07/23
1.3K0
SQLite优化实践:数据库设计、索引、查询和分库分表策略
微信团队分享:微信直播聊天室单房间1500万在线的消息架构演进之路
本文由微信开发团队工程师“ kellyliang”原创发表于“微信后台团队”公众号,收录时有修订和改动。
JackJiang
2021/03/06
8100
典型数据库架构设计与实践 | 架构师之路
本文,将介绍数据库架构设计中的一些基本概念,常见问题以及对应解决方案,为了便于读者理解,将以“用户中心”数据库为例,讲解数据库架构设计的常见玩法。
Javen
2018/08/21
6480
典型数据库架构设计与实践 | 架构师之路
MySQL数据库常见报错案例与错误代码说明
这种情况是不能打开 cdb_forums.MYI造成的,引起这种情况可能的原因有:
非著名运维
2022/06/22
2.3K0
MYSQL数据库常用知识整理
MySQL[是一个开放源码的小型关联式数据库管理系统,开发者为瑞典MySQL AB公司。目前MySQL被广泛地应用在Internet上的中小型网站中。由于其体积小、速度快、总体拥有成本低,尤其是开放源码这一特点,许多中小型网站为了降低网站总体拥有成本而选择了MySQL作为网站数据库。]
明哥的运维笔记
2019/01/30
1.4K0
推荐阅读
相关推荐
五年沉淀,微信全平台终端数据库WCDB迎来重大升级!
更多 >
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档