最早接触 iOS 开发了解到的第一个缓存数据库就是 SQLite,后面一直也以 SQLite 作为中坚力量使用,以前没有接触到比较大量数据的读写,所以在性能优化方面关注不多,这次对一个特定场景的较多数据批量读写做了一个性能优化,使性能提高了十倍。
大致应用场景是这样:
每次程序启动会从服务器拉取一些数据,对本地数据库两个表进行同步更新,不存在就写入,存在就更新其字段。数据少的时候几十条,多的上千条。
由于缓存的数据可能会存在异步同时读写,所以做了一个后台同步队列,所有的缓存数据库操作都在这个队列里面,然后我监控了一下写数据库的关键代码执行耗时,一千条数据更新到数据库就能耗时 30 秒之久,磁盘写入在 1.5M/s 浮动, 虽然没有卡主线程,这个消耗即使在后台也是不可容忍的。
核心的数据库操作大概是这样的
for 1000 : { Select -> Update Or Insert Select -> Update Or Insert }
由于牵涉到两张表,所以会有两次,经过测试,Select 一次几乎没有多少消息,可是 Update 或者 Insert ( [FMDatabaseQueue executeUpdate:] ) 就消耗大了,因为会写入磁盘,然后想到是不是可以把所有的 SQL 语句拼接起来,最后只想一次;再后来想到 SQLite 不是有事务 ( Transaction ) 嘛,于是尝试了一下利用 FMDB 的事务操作,在循环开始前 [db beginTransaction] ,循环结束 [db commit],包起来就行了。
增加事务之后的大概逻辑:
beginTransaction for 1000 : { Select -> Update Or Insert Select -> Update Or Insert } commit
测试效果非常好,整个耗时从 30 秒下降到了2.8 秒左右,仅仅增加了两行代码。
总结:
踩过的坑,走过的坎,都是以后的经验
虽然利用事务取巧来提高了性能,但是这样做其实并不安全,好在所属场景对这部分数据绝对一致要求不是太高。
模拟器和真机有时候测试并不能重现同一个问题,因为所属架构、CPU、硬盘都不一样,所以性能测试最好还是以真机为准。该问题测试的时候在模拟器上很多问题都没有,因为硬盘比真机读写速度要高,所以避免了很多问题,测试的时候也就没有发现。
数据库设计设计的时候得多考虑考虑,多想想以后怎么扩展,怎么升级,读写的时候性能怎么样
SQLite,性能优化
免责声明:本站文章均来自网站采集或用户投稿,网站不提供任何软件下载或自行开发的软件! 如有用户或公司发现本站内容信息存在侵权行为,请邮件告知! 858582#qq.com
稳了!魔兽国服回归的3条重磅消息!官宣时间再确认!
昨天有一位朋友在大神群里分享,自己亚服账号被封号之后居然弹出了国服的封号信息对话框。
这里面让他访问的是一个国服的战网网址,com.cn和后面的zh都非常明白地表明这就是国服战网。
而他在复制这个网址并且进行登录之后,确实是网易的网址,也就是我们熟悉的停服之后国服发布的暴雪游戏产品运营到期开放退款的说明。这是一件比较奇怪的事情,因为以前都没有出现这样的情况,现在突然提示跳转到国服战网的网址,是不是说明了简体中文客户端已经开始进行更新了呢?
更新日志
- 群星2013-青春缤纷辑压箱宝大公开3CD2[新加坡限量版][WAV整轨]
- 林育群.2013-BalladShow(日本版)【环球】【WAV+CUE】
- 陈加洛.1992-痛到感觉不到【宝丽金】【WAV+CUE】
- 群星.2023-宿命之敌电视剧原声带【韶愔音乐】【FLAC分轨】
- 東京事変-大発見[FLAC+CUE]
- 椎名林檎-三文ゴシップ[FLAC+CUE]
- 2024年08月04日
- 裘德《裘德「最后的水族馆」演唱会LIVE》[320K/MP3][228.89MB]
- 裘德《裘德「最后的水族馆」演唱会LIVE》[24bit 48kHz][FLAC/分轨][2.08G]
- 基因三重奏《如果你什么都不说 音乐会现场录音》[320K/MP3][145.37MB]
- 孟庭苇.1996-月亮说话(2020环球24KGOLD限量版)【上华】【WAV+CUE】
- 群星.1997-新艺宝优质音响系列·国语精选监听版【新艺宝】【WAV+CUE】
- 阿桑.2005-寂寞在唱歌(星外星引进版)【华研国际】【WAV+CUE】
- 基因三重奏《如果你什么都不说 音乐会现场录音》[FLAC/分轨][287.43MB]
- 蔡题谦《我爱你,却依然要看你走》[320K/MP3][88.65MB]