方案三：冷热分离，HBase做冷库
方案二确实能解决写操作慢和热数据慢的问题，但仍然存在诸多不足。
用户查询冷数据的速度依旧很慢，虽然查询冷数据的用户比例很低。
冷数据库偶尔会告警。
归档工单的使用场景
对于归档的工单，与客服沟通后发现，基本只有以下几个查询动作：
根据客户的邮箱查询归档工单。
根据工单ID查出该工单所有的处理记录。
HBase的表结构设计
工单表
系统有根据客户邮箱获取工单记录的需求，所以可以将邮箱名放到RowKey中，这样以后查询特定邮箱的工单时只需要扫描RowKey，而不需要扫描列的值，速度将大大加快。所以RowKey设计为·［customeremail］［ticketID］。
但是customeremail是不可控的，可能很长，导致RowKey很长。如果RowKey很长，就会占用很多存储空间，所以也要控制RowKey的长度。最终的RowKey是［MD5（customeremail）］［ticketID］，前面的邮箱名长度是16字节，后面的工单ID是固定长度。
使用这样的设计后，如果想要根据邮箱查找工单，可以使用正则过滤器的rowFilter，通过类似于“abc@mail.com****”的过滤字符串找出abc@mail.com的所有工单。
同时，为了应对可能出现的根据最后处理人或者处理小组查找归档工单的需求，还给assignedUserID等以后可能搜索的字段增加了二级索引。
工单处理记录表
工单处理记录表的设计上，并没有单独为其增加HBase的表，而是将每个工单下面的处理记录全部序列化成一组JSON数据，保存在一个ColumnKey中。