数据持久化：微信数据库组件--WCDB

WCDB（WeChat DataBase）

WCDB是微信团队开源的支持Android,也支持iOS,那当然也是会支持macOS的一个移动端数据库框架，FMDB估计做iOS的99.99%的都知道，是在SQLite的基础上封装的移动数据库框架，WCDB是微信团队提供一个高效、易用、完整的移动端存储方案。 它包含三个模块：

  1、WCDB-iOS/Mac
  2、WCDB-Android
  3、数据库损坏修复工具WCDBRepair

数据库对比

数据库名称	WCDB	FMDB	coreData	Realm
优点	高效、易用、完整	基于sqlite开发，易用，容易上手	苹果内建框架，和Xcode深度结合，可以很方便进行ORM	key-value的实现直接易懂，像使用NSDictionary一样使用Realm。并且ORM彻底，省去了拼装Object的过程
缺点	包比较大	需要大量的写sql语句，需要自己拼接Object，过程繁琐	稳定性也堪忧，很容易crash；多线程的支持也比较鸡肋	耦合性较高，Realm要求类继承RLMObject的基类。key-value数据库对较为复杂的查询场景也比较无力

可见，各个方案都有其独特的优势及劣势，没有最好的，只有最适合的。

微信团队的愿景

• 高效；增删改查的高效是数据库最基本的要求。除此之外，我们还希望能够支持多个线程高并发地操作数据库，以应对微信频繁收发消息的场景。

• 易用；这是微信开源的原则，也是WCDB的原则。SQLite本不是一个易用的组件：为了完成一个查询，往往我们需要写很多拼接字符串、组装Object的胶水代码。这些代码冗长繁杂，而且容易出错，我们希望组件能统一完成这些任务。

• 完整；数据库操作是一个复杂的场景，我们希望数据库组件能完整覆盖各种场景。包括数据库损坏、监控统计、复杂的查询、反注入等。

WCDB基本特性

• 易用 ：WCDB支持一句代码即可将数据取出并组合为object。

- (Province *)getProvinceObjectWithProvinceId:(NSInteger)provinceID {

    //从数据库表中取出1行数据并组合成Province 对象，后面可加where，或者orderby ,limit条件限制

   Province *province = [self.database getOneObjectOfClass:Province.class fromTable:@"province" where:Province.provinceID == provinceID];

    return province;
}

• 高效：WCDB通过框架层和sqlcipher源码优化，使其更高效的表现。

根据官方性能报告显示：WCDB和FMDB比较：读操作两者的性能差不多，但是在写操作和批量事务的时候，WCDB表现的非常优越，性能分别优于FMDB 28% 和 180% 。

• 完整：WCDB覆盖了数据库相关各种场景的所需功能。

  1、加密：WCDB提供基于SQLCipher的数据库加密。

  2、损坏修复：WCDB内建了Repair Kit用于修复损坏的数据库。

  3、反注入：WCDB内建了对SQL注入的保护。

性能数据

官方给出了Demo和benchmark，用户比较FMDB和WCDB两者的性能，供开发者参考。本次测试的数据样本有30万条。

原始数据和macOS的数据请参考：Benchmark原始数据

Benchmark基于以下原则进行：

1. 所有测试都在同一个设备上进行，并且设备不同时进行其他高性能损耗的任务。

2. 测试的样本量“足够大”，以避免误差导致结果相差较大。

3. 所有测试均在Release且不连接Xcode调试的状态下进行。

4. 每个benchmark取5次与平均值的误差不超过±5%的结果。

5. 数据库完全关闭后再打开进行测试，以避免缓存影响结果。

基本操作

1.1 Read

读操作性能测试：该测试为从数据库中取出所有数据，并拼装为object。

读性能.png

1.2 Write

写操作性能测试：该测试为将object的数据不断插入到数据库中（不使用事务）。

写性能.png

1.3 Batch Write

批量写操作性能测试：该测试为将object的数据批量插入数据库（使用事务）。

批量写.png

WCDB写操作和批量写操作的性能分别优于FMDB 28% 和 180% ，而读操作则劣于FMDB 5% 。

对于读操作，SQLite速度很快，因此封装层的消耗会占比较多。FMDB只做了最简单的封装， 而WCDB还包括ORM、WINQ等操作，因此执行的指令会比FMDB多，从而导致性能稍差于FMDB。但WCDB也通过一些优化手段减少这种差距。例如，通过IMP指针调用函数、部分操作No-ARC等等。

而写操作，WCDB也做了许多针对性的优化。例如，WAL模式下写入操作触发checkpoint时，不立即执行checkpoint，而是由一个checkpoint线程来完成，从而减少单次操作的耗时等等。

多线程

2.1 Multithread Read-Read

多线程读操作性能测试：该测试同时启动两个线程，分别从数据库中取出所有数据，并拼装为object。

多线程读.png

2.2 Multithread Read-Write

多线程读写操作性能测试：该测试同时启动两个线程，一个线程从数据库中取出所有数据，并拼装为object；另一个将object的数据批量插入到数据库中。

多线程读写.png

2.3 Multithread Write-Write

多线程写操作性能测试：该测试同时启动两个线程，分别将object的数据批量插入数据库。

多线程写.png

WCDB的多线程读写操作性能优于FMDB 62% ，而多线程读操作基本与FMDB持平。

FMDB在多线程写测试中，直接返回错误SQLITE_BUSY，因此无法比较。而基于SQLite的机制，WCDB的多线程写操作实质也是串行执行，但不会出错导致操作中断。

加密

3.1 Cipher Read

加密数据库读操作测试：该测试基于Baseline Read，并将数据库改为加密数据库。

加密读.png

3.2 Cipher Write

加密数据库写操作测试：该测试基于Baseline Write，并将数据库改为加密数据库。

加密写.png

加密操作分别会对读和写增加 28% 和 26% 的性能损耗。

3.3 Sync Write

数据库同步写操作测试：该测试基于Baseline Write，并在每次写入都同步等待完全写入到磁盘，即增加以下配置：

• PRAGMA synchronous=FULL

• PRAGMA checkpoint_fullfsync=1

• PRAGMA fullfsync=1

同步写.png

同步写操作会大幅降低写操作的性能，但对于数据稳定有很强的保护作用，能够降低 50% 的数据库损坏率。推荐对重要的数据库开启。