共计 7345 个字符，预计需要花费 19 分钟才能阅读完成。
本文由微信客户端技术团队工程师“Jon”分享，原题“Windows 微信：音讯数据库架构演进”，有较多订正。
1、引言
本文分享的是，微信客户端团队基于对微信用户日常应用场景和数据分析，通过拆散重要和非重要数据、采纳牢靠的分库策略等，对微信 Windows 端 IM 本地数据库的架构进行的优化和革新，并最终失去一个具备良好实际成果的技术改造计划。
以下是相干技术文章，有趣味的读者能够一并浏览：
微信客户端 SQLite 数据库损坏修复实际
微信挪动端的全文检索优化之路
微信挪动端的全文检索多音字问题解决方案
微信 iOS 端的最新全文检索技术优化实际微信本地数据库破解版(含 iOS、Android)，仅供学习钻研 [附件下载]
学习交换：
- 挪动端 IM 开发入门文章：《新手入门一篇就够：从零开发挪动端 IM》
- 开源 IM 框架源码：https://github.com/JackJiang2…（备用地址点此）
（本文已同步公布于：http://www.52im.net/thread-40…）
2、背景阐明
微信的 Windows 客户端自 2014 年上线以来，用户数稳步增长。随着工夫的一直推移，很多用户本地积攒的音讯量越来越大。
最后的本地 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 分库革新
基于以上剖析，首先把公众号音讯划分进来，存到独自的一个数据库，跟用户的一般音讯隔离，同时也能够大幅缩小一般音讯数据库的体积。
基于日常应用场景的剖析，大部分老数据读取的频率很低，所以应该进步最近一段时间的读写效率。对于上述这种状况，咱们采取了以工夫和空间动静划分数据库的计划。初始默认值是每个数据库寄存半年的音讯，超过工夫之后新建一个数据库寄存。对于大部分应用场景，咱们只须要读写最新的数据库就能够满足需要，如果须要浏览更早的音讯，能够再关上之前的数据库进行读取。除了工夫维度，咱们还思考了空间维度的划分：如果半年内音讯一般音讯规模超过阈值，也会新建一个数据库进行存储，让每个数据库大小和数据规模不至于太大，能晋升最近一段时间音讯的读写效率。
5.3 建设音讯索引
对于最宽泛的应用场景——查看每一个聊天的音讯，这种场景须要对每一个聊天会话建设一个索引。这里的索引计划咱们参考了安卓端：行将每一个聊天转换成一个数值型的 ID，从而缩小每条索引的长度，进步索引的读写效率。（对于微信的挪动端 SQLite 残缺数据库构造，能够参考：《微信本地数据库破解版(含 iOS、Android)，仅供学习钻研 [附件下载]》）
除此之外，咱们还对一些常常拜访的内容，独自提取成为一个字段，并且减少索引。比方音讯的子类型（这个在老数据库中是一个序列化字段），它没有索引，但这个字段常常须要用到，所以独自提出成为一列，并且加上索引，为音讯按类型查找提供方便。
5.4 音讯体积优化
IM 中音讯显然总是会越来越多的，但如何可能在不影响读写效率的同时，缩小 / 压缩音讯数据的体积，也是咱们的优化方向。从下面的数据看，局部音讯体积较大，曾经超过了数据库每页的大小（Page Size）。数据库是按页存储数据的，Page Size 是数据库一页可能包容的数据。如果一条数据，一个页放不下，就须要用到溢出页，把多进去放不下的数据放到溢出页中，溢出页能够有多个。这时候，如果读取这条数据，就须要把溢出页也全副读出来，会减少 IO 的耗费。如果压缩数据，可能把音讯体压缩到一个页能放得下，缩小溢出页的应用，是能够减少 IO 性能的。SQLite 数据库溢出页构造：
(上图援用自书籍《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)
然而压缩须要占用 CPU 资源，这里抉择一种可能均衡性能和压缩率的算法是要害。通过比照压缩算法的 Benchmark，并且对音讯体压缩性进行实测，最终抉择了一个高性能压缩算法：lz4。
通过对测试帐号的数据分析，不同类型的音讯体大小差别较大。一般来说：文本音讯的长度不会特地大，然而网页卡片类型的音讯，体积会较大。因为不同的音讯长度，取得的压缩率不一样，太短的文本长度，压缩起来并没有意义。所以通过音讯体长度、压缩、，压缩性能的剖析，最终确定对网页卡片等进行压缩，在较低性能耗费的前提下，综合压缩率可达到 40%，缩小了 IO 次数。
5.5 进步健壮性
如果数据库文件因为内部起因产生损坏，则会对体验造成较大影响。升高损坏率和缩小损坏带来的数据损失，也是咱们改良的方向。依照工夫维度划分数据库之后，相当于把音讯按工夫扩散存储。最新的数据库负责读写最近的音讯，其余的数据库只须要依据需要反对浏览查看音讯。对于老数据库而言：能够做到按需加载，从而缩小了对数据库的读写，也缩小了这些数据库损坏的几率。一旦有数据库呈现损坏，即便无奈复原，也不会所有音讯全副失落，只会失落该数据库对应时间段的音讯，这也能够缩小局部数据库损坏带来的损失。在晚期应用的单数据库架构中，因为数据会越攒越多，数据库体积会继续变大，很难去做备份。
分库之后，每个数据库体积变小，因此数据库备份变得更为可行。因为最新的数据库存在频繁的音讯读写，产生损坏的概率远高于老数据库，所以这里对最新的一个数据库做定期的备份。默认配置下，咱们每距离一段时间会对最新的数据库进行一次备份，该备份是最新的一个数据库的残缺拷贝。若最新的数据库在读写时产生损坏，会先尝试从备份数据恢复。若复原胜利，则最多失落从备份到复原这段时间的数据，进一步升高损坏造成的损失。
6、优化比照
通过比照，对于一个在测试帐号中原始的音讯数据库，压缩后大小能够缩小靠近一半，同时溢出页数和须要应用溢出页的记录数缩小也超过一半。
对于读写性能，比照压缩前，压缩后的读取和解压缩性能比之前有靠近 10% 的晋升。
7、将来瞻望
后续咱们微信客户端团队将持续钻研数据库修复相干的实际，继续关注数据库相干的性能数据，晋升可靠性，打造更好的用户体验！
附录：更多大厂 IM 文章汇总
[1] 微信团队原创技术文章：
《微信朋友圈千亿访问量背地的技术挑战和实际总结》
《IM 全文检索技术专题(二)：微信挪动端的全文检索多音字问题解决方案》
《微信团队分享：iOS 版微信的高性能通用 key-value 组件技术实际》
《微信团队分享：iOS 版微信是如何避免特殊字符导致的炸群、APP 解体的？》
《微信团队原创分享：iOS 版微信的内存监控零碎技术实际》
《iOS 后盾唤醒实战：微信收款到账语音揭示技术总结》
《微信团队分享：视频图像的超分辨率技术原理和利用场景》
《微信团队分享：微信每日亿次实时音视频聊天背地的技术解密》
《微信团队分享：微信 Android 版小视频编码填过的那些坑》
《IM 全文检索技术专题(一)：微信挪动端的全文检索优化之路》
《企业微信客户端中组织架构数据的同步更新计划优化实战》
《微信团队披露：微信界面卡死超级 bug“15。。。。”的前因后果》
《月活 8.89 亿的超级 IM 微信是如何进行 Android 端兼容测试的》
《一篇文章 get 微信开源挪动端数据库组件 WCDB 的所有！》
《微信客户端团队负责人技术访谈：如何着手客户端性能监控和优化》
《微信后盾基于工夫序的海量数据冷热分级架构设计实际》
《微信团队原创分享：Android 版微信的臃肿之困与模块化实际之路》
《微信后盾团队：微信后盾异步音讯队列的优化降级实际分享》
《微信团队原创分享：微信客户端 SQLite 数据库损坏修复实际》
《微信 Mars：微信外部正在应用的网络层封装库，行将开源》
《如约而至：微信自用的挪动端 IM 网络层跨平台组件库 Mars 已正式开源》《开源 libco 库：单机千万连贯、撑持微信 8 亿用户的后盾框架基石 [源码下载]》
《微信新一代通信安全解决方案：基于 TLS1.3 的 MMTLS 详解》
《微信团队原创分享：Android 版微信后盾保活实战分享(过程保活篇)》
《微信团队原创分享：Android 版微信后盾保活实战分享(网络保活篇)》
《Android 版微信从 300KB 到 30MB 的技术演进(PPT 讲稿) [附件下载]》
《微信团队原创分享：Android 版微信从 300KB 到 30MB 的技术演进》
《微信技术总监谈架构：微信之道——大道至简(演讲全文)》
《微信技术总监谈架构：微信之道——大道至简(PPT 讲稿) [附件下载]》
《如何解读《微信技术总监谈架构：微信之道——大道至简》》
《微信海量用户背地的后盾零碎存储架构(视频 +PPT) [附件下载]》
《微信异步化革新实际：8 亿月活、单机千万连贯背地的后盾解决方案》
《微信朋友圈海量技术之道 PPT [附件下载]》
《微信对网络影响的技术试验及剖析（论文全文）》
《一份微信后盾技术架构的总结性笔记》
《架构之道：3 个程序员成就微信朋友圈日均 10 亿发布量[有视频]》
《疾速裂变：见证微信弱小后盾架构从 0 到 1 的演进历程（一）》
《疾速裂变：见证微信弱小后盾架构从 0 到 1 的演进历程（二）》
《微信团队原创分享：Android 内存透露监控和优化技巧总结》
《全面总结 iOS 版微信降级 iOS9 遇到的各种“坑”》
《微信团队原创资源混同工具：让你的 APK 立减 1M》
《微信团队原创 Android 资源混同工具：AndResGuard [有源码]》
《Android 版微信安装包“减肥”实战记录》
《iOS 版微信安装包“减肥”实战记录》
《挪动端 IM 实际：iOS 版微信界面卡顿监测计划》
《微信“红包照片”背地的技术难题》
《挪动端 IM 实际：iOS 版微信小视频性能技术计划实录》
《挪动端 IM 实际：Android 版微信如何大幅晋升交互性能（一）》
《挪动端 IM 实际：Android 版微信如何大幅晋升交互性能（二）》
《挪动端 IM 实际：实现 Android 版微信的智能心跳机制》
《挪动端 IM 实际：iOS 版微信的多设施字体适配计划探讨》
《IPv6 技术详解：基本概念、利用现状、技术实际（上篇）》
《IPv6 技术详解：基本概念、利用现状、技术实际（下篇）》
《微信多媒体团队访谈：音视频开发的学习、微信的音视频技术和挑战等》
《腾讯技术分享：微信小程序音视频技术背地的故事》
《微信多媒体团队梁俊斌访谈：聊一聊我所理解的音视频技术》
《腾讯技术分享：微信小程序音视频与 WebRTC 互通的技术思路和实际》
《微信技术分享：微信的海量 IM 聊天音讯序列号生成实际（算法原理篇）》
《微信技术分享：微信的海量 IM 聊天音讯序列号生成实际（容灾计划篇）》
《微信团队分享：Kotlin 渐被认可，Android 版微信的技术尝鲜之旅》
《社交软件红包技术解密(二)：解密微信摇一摇红包从 0 到 1 的技术演进》
《社交软件红包技术解密(三)：微信摇一摇红包雨背地的技术细节》
《社交软件红包技术解密(四)：微信红包零碎是如何应答高并发的》
《社交软件红包技术解密(五)：微信红包零碎是如何实现高可用性的》
《社交软件红包技术解密(六)：微信红包零碎的存储层架构演进实际》
《社交软件红包技术解密(十一)：解密微信红包随机算法(含代码实现)》
《微信团队分享：极致优化，iOS 版微信编译速度 3 倍晋升的实际总结》
《IM“扫一扫”性能很好做？看看微信“扫一扫识物”的残缺技术实现》
《微信团队分享：微信领取代码重构带来的挪动端软件架构上的思考》
《IM 开发宝典：史上最全，微信各种性能参数和逻辑规定材料汇总》
《微信团队分享：微信直播聊天室单房间 1500 万在线的音讯架构演进之路》
《企业微信的 IM 架构设计揭秘：音讯模型、万人群、已读回执、音讯撤回等》
《IM 全文检索技术专题(四)：微信 iOS 端的最新全文检索技术优化实际》
《微信团队分享：微信后盾在海量并发申请下是如何做到不解体的》
《微信 Windows 端 IM 音讯数据库的优化实际：查问慢、体积大、文件损坏等》
更多同类文章 ……
[2] 微信背地的技术故事：
《技术往事：微信估值已超 5 千亿，雷军曾有机会收编张小龙及其 Foxmail》
《腾讯开发微信花了多少钱？技术难度真这么大？难在哪？》
《开发往事：深度讲述 2010 到 2015，微信一路风雨的背地》
《开发往事：微信千年不变的那张闪屏图片的由来》
《开发往事：记录微信 3.0 版背地的故事（距微信 1.0 公布 9 个月时）》
《一个微信实习生自述：我眼中的微信开发团队》
《微信七年回顾：历经多少质疑和差评，才配领有明天的弱小》
《前开创团队成员分享：盘点微信的前世今生——微信胜利的必然和偶尔》
《即时通讯守业必读：解密微信的产品定位、翻新思维、设计法令等》
《[技术脑洞] 如果把 14 亿中国人拉到一个微信群里技术上能实现吗？》
《那些年微信开发过的鸡肋性能，及其带给咱们的思考》
《读懂微信：从 1.0 到 7.0 版本，一个支流 IM 社交工具的进化史》
《专访马化腾：首次开谈个人经历、治理心得、技术创新、微信的诞生等》
《一文读懂微信之父张小龙：失败蠢才、颠覆者、独裁者、兽性操控师》
更多同类文章 ……
[3] 阿里巴巴的技术分享：
《阿里钉钉技术分享：企业级 IM 王者——钉钉在后端架构上的过人之处》
《古代 IM 零碎中聊天音讯的同步和存储计划探讨》《阿里技术分享：深度揭秘阿里数据库技术计划的 10 年变迁史》《阿里技术分享：阿里自研金融级数据库 OceanBase 的艰苦成长之路》《来自阿里 OpenIM：打造安全可靠即时通讯服务的技术实际分享》《钉钉——基于 IM 技术的新一代企业 OA 平台的技术挑战(视频 +PPT) [附件下载]》《阿里技术结晶：《阿里巴巴 Java 开发手册(规约)- 华山版》[附件下载]》《重磅公布：《阿里巴巴 Android 开发手册(规约)》[附件下载]》《作者谈《阿里巴巴 Java 开发手册(规约)》背地的故事》《《阿里巴巴 Android 开发手册(规约)》背地的故事》《干了这碗鸡汤：从理发店小弟到阿里 P10 技术大牛》《揭秘阿里、腾讯、华为、百度的职级和薪酬体系》《淘宝技术分享：手淘亿级挪动端接入层网关的技术演进之路》《难得干货，揭秘支付宝的 2 维码扫码技术优化实际之路》《淘宝直播技术干货：高清、低延时的实时视频直播技术解密》《阿里技术分享：电商 IM 音讯平台，在群聊、直播场景下的技术实际》《阿里技术分享：闲鱼 IM 基于 Flutter 的挪动端跨端革新实际》《阿里 IM 技术分享(三)：闲鱼亿级 IM 音讯零碎的架构演进之路》《阿里 IM 技术分享(四)：闲鱼亿级 IM 音讯零碎的牢靠投递优化实际》《阿里 IM 技术分享(五)：闲鱼亿级 IM 音讯零碎的及时性优化实际》《阿里 IM 技术分享(六)：闲鱼亿级 IM 音讯零碎的离线推送达到率优化》《阿里 IM 技术分享(七)：闲鱼 IM 的在线、离线聊天数据同步机制优化实际》《阿里 IM 技术分享(八)：深度解密钉钉即时消息服务 DTIM 的技术设计》
（本文已同步公布于：http://www.52im.net/thread-40…）
