sqlite性能优化之路-配置优化

测试环境

初始数据

不做任何优化的场景下,sqlite性能达到 100 ~ 120 qps左右。这样的一个数值,在客户端场景下,已经足以满足大部分需求。

但对于服务端的sdk,根据业务场景也许用来记录服务端的行为日志等操作。由于服务端处数据量处理能力远远大于客户端,因此 100 ~ 120 的qps就显得相形见绌。因此有了下面的优化思路。

Synchronous设置

synchronous 获取或设置当前磁盘的同步模式,该模式用于控制SQLite写入磁盘的时机。

通过上述可以看到,sqlite3默认采用最安全也是最慢的方式来刷盘写入数据库。如果我们业务中对

数据丢失的情况不是太敏感,而更关注于性能,我们可以设置为OFF。

当设置为OFF后,写入性能可提高3倍。大约提升到 300 的 qps

journal_mode设置

journal_mode 获取或设置控制日志文件如何存储和处理的日志模式。

journal,为的是数据库事务的rollback操作。

数据库begin trans写入时,首先写入journal文件中,commit操作时,根据journal-mode来处理journal日志文件。

若在commit之前由于断电等原因造成无法commit,当再次启动时,通过journal文档做回滚操作,保证数据库的完整性和一致性。

WAL机制:修改不直接写入数据库文件中,而是直接一个WAL的文件中,若事务失败,WAL记录被忽略;若事务成功,随后在某个checkpoint时间点写回数据库。

优点

读写可完全并发执行,不会互相阻塞(但写之间不能并发) - 测试过程读写不能并发执行

WAL多数情况下都有更好性能(因为无需写入两个文件 - journal和数据文件)

磁盘IO行为更容易被预测

缺点

每个数据库现在对应3个文件:.db,-wal,*-shm

当写入数据达到GB级别,数据库性能下降

必须要sqlite 3.7.0版本以上版本才支持

为了避免读取的数据不一致,查询时也需要读取WAL文件,并记录一个结尾标记(end mark)。这样的代价就是读取会变得稍慢,但是写入会变快很多。要提高查询性能的话,可以减小WAL文件的大小,但写入性能也会降低。 需要注意的是,低版本的SQLite不能读取高版本的SQLite生成的WAL文件,但是数据库文件是通用的。这种情况在用户进行iOS降级时可能会出现,可以把模式改成delete,再改回WAL来修复。

关于WAL性能,曾经有人测试与写内存性能差距不大。

当journal_mode设置为WAL后,写入性能可提高4倍,大约提升到400 的 qps

若同时设置两个参数,写入性能提升至10000以上的qps

  • 发表于:
  • 原文链接:http://kuaibao.qq.com/s/20180512G19YOF00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。

同媒体快讯

扫码关注云+社区

领取腾讯云代金券