业务场景:几千万数据量的工单表如何快速优化
系统简介
关键表结构与查询
工单表ticket
工单表ticket中的关键字段如下表:
工单表最主要的几个查询语句如下:
客服查询无处理人的工单:“Where assignedUserID = ?”
客服获取分派给自己的工单:“Where status in(…)and assignedUserID = ?”。
客服组长查看自己组的工单:“Where assignedUserGroupID = ?”。
客服查询特定客户的工单:“Where consumerEmail = ?”
业务分析
系统主要业务流程如下:
系统从邮件服务器同步到邮件以后,创建一个工单,createdTime就是工单创建的时间。
客服先去查询无处理人的工单,然后把工单分派给自己。
客服处理工单,每处理一次,系统自动增加一条处理记录。
客服处理完工单以后,将工单状态改为“关闭”。
关键特征:
关闭后的工单,客服查询的概率就很低。
对于那些关闭超过一个月的工单,基本上一年都打开不了几次。
解决思路
基本的思路是增加一个状态:归档。
首先将关闭超过一个月以上的工单自动转为“归档”状态,然后将数据库分为两个区,所有“归档”状态的工单存放在一个区,所有非“归档”状态的工单存放在另外一个区,最后在所有的查询语句中加一个条件,就是状态不等于“归档”。
简单估算一下:客服频繁操作的工单基本上都是1个月内的工单,按照后期一天10万来算,也就是300万的数据,这样数据库的非归档区基本就没什么压力了。
大致方案如下:
新建一个数据库,然后将1个月前已经完结的工单数据都移动到这个新的数据库。这个数据库就叫冷库,因为里面基本是冷数据(当然,叫作归档数据库也可以),之后极少被访问。
当前的数据库保留正常处理的较新的工单数据,这是热库。
这样处理后,因为客服查询的基本是近期常用的数据,大概只有300万条,性能就基本没问题了。即使因为查询频繁,或者几个客服同时查询,也不会再像之前那样出现数据库占满CPU、整个系统几乎宕机的情况了。