win7有多少慢
(win7很慢)
本文由微信客户端技术团队工程师Jon分享，原题Windows微信：新闻数据库架构的演变，有更多的修订。
1、引言本文分享了基于微信用户日常使用场景和数据分析的微信客户端团队，通过分离重要和非重要数据，采用可靠的库分配策略Windows端IM本地数据库的架构进行的优化和改造，并最终得到一个具备良好实践效果的技术改造方案。
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。
对比压缩算法Benchmark，测量消息体压缩性，最终选择高性能压缩算法：lz4。
通过对测试帐户的数据分析，不同类型的消息体大小差异较大。
一般来说：文本信息的长度不会特别大，但网页卡类型的信息会更大。由于消息长度不同，压缩率不同，文本长度过短，压缩毫无意义。
因此，通过对消息体长度、压缩和压缩性能的分析，最终确定压缩网页卡。在低性能消耗的前提下，综合压缩率可达40%，降低IO次数 。5.5 提高健壮性
若数据库文件因外部原因损坏，则对体验影响较大。减少损坏率和数据损失也是我们改进的方向。
按照时间维度划分数据库之后，相当于把消息按时间分散存储。最新数据库负责阅读和撰写最新消息，其余数据库只需支持浏览和查看消息。
对于老数据库：按需加载可以减少数据库的读写库的读写一旦数据库损坏，即使无法恢复，也不会丢失所有消息，只会丢失数据库对应时间段的消息，这也可以减少部分数据库损坏造成的损失。
在早期使用的单数据库架构中，数据库体积会继续增大，很难备份，因为数据会越来越多。分库后，每个数据库体积变小，数据库备份变得更加可行。由于最新数据库经常读写新闻，损坏的概率远高于旧数据库，因此最新数据库定期备份。
默认配置下，我们每隔一段时间就会备份最新的数据库，这是最新数据库的完整副本。如果最新数据库在读写过程中损坏，请尝试从备份数据中恢复。如果恢复成功，最多将从备份到恢复的数据丢失，进一步减少损坏造成的损失。6、优化对比
相比之下，对于测试帐户中的原始新闻数据库，压缩后的大小可以减少近一半，溢出页数和需要使用溢出页面的记录也可以减少一半以上。
与压缩前相比，压缩后的读取和解压缩性能比以前提高了近10%。7、未来展望
随后，我们的微信客户端团队将继续研究数据库修复的实践，继续关注与数据库相关的性能数据，提高可靠性，创造更好的用户体验！
以下是相关技术文章，感兴趣的读者可以一起阅读：微信客户端SQLite微信移动终端全文检索优化之路微信移动终端全文检索多音字问题解决方案iOS最新全文检索技术优化实践微信本地数据库破解版(含iOS、Android)，仅供学习和研究[下载附件]
学习交流：- 开源IM框架源码：https://github.com/JackJiang2011/MobileIMSDK(此备用地址)(本文已同时发表:http://www.52im.net/thread-4034-1-1.html）- 移动端IM开发入门文章：《新手入门一篇就够：从零开发移动端IM》
