***数据库sqlite优化策略

引入问题

在某某公司从事ios开发时一个「某某」app项目,其中用到sqlite进行本地化存储,存储内容为服务端透传的通知消息,获得消息的方式有两种

  1. API获取消息列表
  2. 透传消息(一条一条过来)
    消息结构大致如下
class NotificationEntry: NSObject {
    var msgId:Int! 消息id
    var msgGroup:Int! 消息分组
    var msgType:Int! 消息类型-子分组
    var msgTime:Int? 消息时间戳
    var msgRead:Int! 消息是否已读
    var msgContent:NSDictionary? 消息主体内容
    var contentObj:NSObject? 消息主体内容对象
}

根据msgGroup和msgType 对应不同的消息主体
譬如msgGroup为评论,则msgType分为主评论和回复评论
msgGroup为账户消息,那么msgType分为支付,提现,充值等。

需要实现的需求为

  1. 消息首页显示个分组列表,并显示每个分组的未读数
    2.点击分组,进入另一页显示分组中所有消息(并且将msgType相同的消息再进行一次聚合,点击聚合item才显示聚合中所有消息)
    3.消息首页根据分组排序
    4.具体消息点击可进入相应页面

实现功能,本地使用两张表

let sql_notification_table = "create table if not exists \(TABLE_NAME_NOTIFICATION)(serial integer primary key,userid text,msgid integer,grouptype integer,messagetype integer,content text,msgtime datatime,isread integer,videoId integer,commentId integer)"
    
    let sql_group_table = "create table if not exists \(TABLE_NAME_GROUP)(userid text,groupid integer,message text,unreadcount integer,count integer,latestmsgid integer,serial interger)"

一些问题整理

  • UI上要实现两次聚合针对于msgGroup和msgType

        * 首页数据的聚合依赖sql_group_table表,从中查询即可,但是每次  sql_notification_table的更新需要同时计算并更新sql_group_table表。在程序初始化的时候,通过API获取消息列表时同时更新sql_group_table和sql_group_table即可。每次通过透传收到的消息也需要更新这两张表。 使用sql_group_table表目的是为了减少首页显示时的大量计算。将时间分散在更新sql_group_table表。
    
        * msgType分组通过查询sql_notification_table表实现。
    
  • 数据库的多线程运行

io操作放在后台线程运行,所以我将我的数据库实现为线程安全,使用的是smdb

var fmdbQueue:FMDatabaseQueue!;

self.fmdbQueue.inDatabase({ (db) in
            //do db operation
        })

将所有操作都提交到一个队列中执行

  • 数据增长时效率的问题
    1. 初始化时通过API获取消息列表
    * 数据对象后台实例化
    * 数据库写入优化--使用事务
    
//异步更新Notification表中的items
   self.fmdbQueue.inTransaction({ (db, rollback) in
           db.open()
           db.beginTransaction()
           self.updateNotificationItems(items, db: db, userid: userid)
           db.commit()
           db.close()
       })
2. 展开聚合时有大量数据的展示问题,虽然是在后台线程,不过时间太长依然会影响体验
    * 数据库查询分页,每次取10条
    * 在后台运行查询
  • 数据结构修改后和服务端兼容的问题
    • 数据结构修改后,本地数据库支持升级

// 先判断是否初始化过数据库
let dbCurrentVersion:Int? = readProperties(SK_NOTIFICATION_CURRENT_VERSION) as? Int
if(dbCurrentVersion != nil && dbCurrentVersion >= m_dbMinVersion) {
return;
}
self.dropTables();
self.createTables();
// 设置一个最小版本号,如果低于这个版本,就需要执行升级
saveProperties(SK_NOTIFICATION_CURRENT_VERSION, val: m_dbMinVersion);
```
* 服务端API接口向前兼容,这样解决老客户端数据结构不可用的问题
* 服务端API接口分版本,客户端提示版本不兼容提示用户升级app

  • 由于这块功能多变,所以需要随时应对数据修改和视觉修改
    定义接口

@objc protocol NoticeCommon:class {
func title()->String
optional func cell(tableView: UITableView,row: Int,datas:NSArray,controller:NoticeCellDelegate?)->UITableViewCell
func cellheight(data:NotificationEntry)->CGFloat
func didClick(msgType:Int,data:NotificationEntry,controller:UIViewController)
func createContentObj(val:NSDictionary,msgType:Int)
func getListWithGroup()->NSArray;
func groupId()->Int;
//for set
optional func setcell(tableView: UITableView,row: Int,datas:NSArray,controller:ENoticeSetCellDelegate?)->UITableViewCell
//获取集合数据源
optional func createSet()->NSArray;
//集合cell的高度
optional func setCellHeight(data:NoticeSetEntry)->CGFloat;
//点击集合
optional func doClickSet(data:NoticeSetEntry,controller:UIViewController)
//获取单一集合对应的数据源
//optional func getNotices(getid:Int)->NSArray
}

对于二次聚合类实现这些方法,这样对视觉的修改就集中到一处进行。

class NoticeFactory: NSObject {
class func create(groupid:Int) -> NoticeCommon?
{
if(groupid == GroupTypeAccount)
{
return AccountNoticeUtility()
}
else if(groupid == GroupTypeComment)
{
return CommentNoticeUtility()
}
else if(groupid == GroupTypeAudit)
{
return AuditNoticeUtility()
}
else if(groupid == GroupTypeForward)
{
return ForwardNoticeUtility()
}
else if(groupid == GroupTypeAttend)
{
return AttendNoticeUtility()
}
else if(groupid == GroupTypeLike)
{
return LikeNoticeUtility()
}
else if(groupid == GroupTypeAuthen)
{
return AuthenNoticeUtility()
}
else if(groupid == GroupTypeShare)
{
return ShareNoticeUtility()
}
else if(groupid == GroupTypeSysterm)
{
return SystemNoticeUtility()
}
return nil
}
}

根据group获取对应的对象,新加消息类型时在此处添加即可

* 数据结构调整时暂时不考虑数据迁移问题。服务端保存完整的数据,每次启动都拉取数据。

###在开发中的一些衍生问题的思考
* 通过API获取数据列表时在用tableview显示数据时如避免初始化数据对象时的耗时(列表比较大,数据比较复杂)
  * 拉取条数进行分页,这样在获取数据后进行初始化等应该也能在一个合理可接受范围
  * 将数据结构初始化分散到显示时,由于tableview的重用机制,这个耗时应该是在可接受范围,有待测试
* 如我这个case,如果数据达到几千上万条,在app初始化拉取数据时,API请求耗时+上对象初始化耗时,再加上数据库写入耗时,这个时间应该会很长,这个如何解决?由于我获取到数据后必须要解析并写入数据库,那么API请求时间和初始化对象时间和数据库写入 这三块时间是必须消耗的, 如何解呢?

  * app初始化时拉取服务端数据只在首次打开时执行,以后就不需要再拉取了,因为以后的是通过透传过来的。当然也存在app第一次安装时就存在大量数据的情况(之前用账号使用过导致许多数据存在),这个情况再app打开消息页面时做的和微信一样拉取数据再更新UI。然后显示未读条数。这个体验获取可以接受。增加一个拉取group的API,保证进入消息首页时能看到group分组。 拉取所有数据后再更新本地group。

###其他一些数据库优化策略整理

希望可以相互交流切磋. 附上我的微信号关注我哈
![image.png](https://upload-images.jianshu.io/upload_images/6544957-f4e7defbfae0cffa.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)

你可能感兴趣的:(***数据库sqlite优化策略)