当前位置:   article > 正文

sqlite优化简单分析_sqlite 性能

sqlite 性能


前言

SQLite 原本就是一款轻型的数据库,面向轻量级应用或者安卓应用等的使用场景。轻量级的设定也注定他并发读写性能不高,如果有高并发的要求更应该选择 mysql 等数据库。


一、sqlite 的读写性能

说起读写性能,大家都喜欢拿 QPS 和 TPS 说事,那我们就简单了解下 sqlie 的这两个指标

测试环境:

硬件参数
CPU8核,Intel® Xeon® CPU E5-2430 0 @ 2.20GHz
内存16G
磁盘SDD
系统Linux 2.6.32

综合别人的测试数据,我下面说个大概的值,详细的测试结果与分析,请参考原本连接:

https://blog.csdn.net/zhaofuguang/article/details/91881115
https://blog.csdn.net/zhaofuguang/article/details/91881541

单纯写入的 TPS :60
单纯读取的 QPS :5W
WAL模式,读写比例 500:1 下: 读并发 = 6.94w 、 写并发 = 138

原例子中,有单行事务和多行事务同时提交的测试,我这里就忽略了,因为在实际使用场景下,大多是利用 mybatis 等 ORM 框架来操作数据库,这时一般是根据业务一个事务一个事务的执行,很少同时提交这么多语句的事务。

有些不太了解 sqlite 的小伙伴就有疑惑了,为什么读性能都去到每秒几个w了,但是写性能却只有可怜的每秒几十?

因为 sqlite 的设定是同一时刻只能有一个线程去进行写操作。

二、sqlite 优化

sqlite 作为一款嵌入式的数据库,没有集群等高端操作,所以性能优化也只是相对默认配置的提升,想高性能的请选用其他数据库

1.关键参数

Synchronous (设置磁盘的同步模式)

参数值说明
0 或 off不进行同步。写入数据后传递给操作系统完成
1 或 normalsqlite2的默认值,在关键磁盘操作的每个序列后同步。有小概率在断电等场景导致数据库损坏
2 或 fullsqlite3的默认值,在每个关键磁盘操作后同步。频繁刷盘,性能较差,安全性高,不会损坏数据库文件

journal_mode (设置日志文件的存储方式,影响事务的rollback操作)

参数值说明
DELETE默认模式,事务结束时,日志文件删除
TRUNCATE日志文件被阶段为零字节长度
PERSIST日志文件保留在原地,但头部被重写,标明日志不再有效
MEMORY日志记录在内存中,而不是磁盘
OFF不保留任务日志
WAL修改不直接写入数据库文件中,而是直接一个WAL的文件中,若事务失败,WAL记录被忽略;若事务成功,随后在某个checkpoint时间点写回数据库

cache_size (设置缓存值)

参数值说明
2000默认缓存大小。表示 sqlite 一次存储在内存中的数据库文件页数

2.性能优化

如果你的使用场景是读多写少,并且对数据安全性要求相对没那么高,你可以:

  1. 将 Synchronous 设置为 off,可以大大提高写入性能
  2. 将 journal_mode 设置为 WAL ,该模式下,读写可并发执行,不会互相阻塞,但写之间仍然是单进程串行
  3. 把 cache_size 缓存值根据你机器内存的大小适当调大

3.数据安全性优化

如果你对数据的安全性有一定要求,你可以:

  1. 将 Synchronous 设置为 normal,该模式下,在保证安全性基础下,写性能也有一定的提升
  2. journal_mode 同样可以使用 WAL模式,cache_size 也可以适当把缓存调大

总结

欢迎指出我的错误!

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/菜鸟追梦旅行/article/detail/636387
推荐阅读
相关标签
  

闽ICP备14008679号