日增亿级数据存储：BOSS直聘历史库实现规模化降本

BOSS 直聘的业务场景主要是通过数据库对招聘过程中的聊天记录信息进行存储，数据量极大，且每天都有 5 亿到 10 亿的增量数据。和招聘相关聊天记录往往呈现流水型特征，写入一段时间后即不会再次访问或更新，写多读少。

面对快速增长的在线数据，尤其是访问频率很低甚至为 0 的历史聊天记录，其占用的在线业务库的存储空间达到 PB 级别，造成了大量硬件资源浪费，堆高了企业的 IT 成本。同时，随着数据量的增加，在线数据库体积臃肿、查询效率逐步降低，给后续数据变更、扩展造成阻碍。

需要对历史聊天记录进行冷热数据分离。热数据所在的在线库是多个 MySQL 集群，采用分库分表的方式，每月定期清理过期数据，滚动写入历史归档库，需要一款高压缩能力，并且针对写多读少场景有很好性能的数据库来存储历史归档数据。

1. 日增数据库量大，存储成本高
   1. 对BOSS直聘每天聊天记录信息进行存储，数据量极大，且每天都有 5 亿到 10 亿的增量数据。
2. 数据量增加，在线库体积臃肿，导致查询效率差
   1. 随着数据量的增加，在线数据库体积臃肿、查询效率逐步降低，给后续数据变更、扩展造成阻碍
3. 分库分表业务复杂度高、维护成本高
   1. 在线库目前使用的是 MySQL，在 MySQL 中进行分库分表明显比在分布式数据库中使用单表的业务复杂度要高很多，而且数据一致性难以保证，当多个数据表或数据库之间的数据关联较为复杂时，维护数据的一致性难度也会增加很多
4. 数据库扩容麻烦，无法动态扩容
   1. MySQL集群采用分库分表模式，无法平滑实现集群的扩容，扩容操作对业务都有一定影响，并且存在一定的风险

1. 高级压缩技术
   1. 利用OceanBase对历史数据的编码和通用压缩技术，将原本历史聊天数据进行压缩，解决历史数据量大，导致在线库臃肿、查询性能变慢问题，大幅降低IT成本。
2. 高兼容性，数据平滑同步
   1. OceanBase 对 MySQL 实现了完善的兼容，从MySQL数据库同步归档数据到OceanBase，不需要做任何修改即可完成数据的迁移同步，减少对DBA的工作量以及数据迁移的风险。
3. 自研DTS，实现数据归档
   1. 在线库是主从结构的 MySQL，用于存储热数据，一般是最近一个月内的用户聊天记录；历史库是几个由 OCP 接管的 OceanBase 集群。每个月会通过自研的 DTS 工具从 MySQL 在线库定期归档过期数据到通 OceanBase 搭建的历史库。