数据现装
目前项目中的数据存储在mysql数据库中,虽然mysql按照业务域分库(16个),单库256张表。但是表数据量目前300W,每日新增560w,平均每张物理表日新增数据量560W/256=2.18W。每张表数据量上限按照800W条计算,距离每张表的上限需要(800-300)/2.18=229天。
业务还在持续增长,提前对DB做冷热隔离。
前期技术选型
压缩选型 | 压缩比 | 性能 | CPU消耗 |
1/10-1/15 | 一般,只支持insert和select,不支持update | 未知 | |
大约25% | 较差 | 高 | |
25%-50% | 3倍tokudb | 高,5倍于x-engine | |
10%-50% | 和innodb相似(LSM-tree) | 小 |
后期技术调研
直接将数据存储在Hbase或者ES等基于HDFS分布式存储架构中,当数据量持续增长时,如果遇到存储瓶颈直接加机器即可。目前主流的大数据量也按照此方案存储。例如阿里的lindorm(Hbase上做的封装),腾讯的基于ES的一个技术栈(具体叫啥名记不清了)。
隔离方案
全量数据同步方案:
mysql每天会同步数据至数据仓库hive中(odps),考虑到有业务持续写入,减少db的压力,采用离线同步方案,将hive(odps)中的数据采用快照方式同步到Hbase中(lindorm)。
增量数据同步方案:
方案1.采用消费mysql binlog的方式去同步数据至冷库(Hbase)中。
方案2.a.先采用方案1执行。b.当mysql业务数据写成功之后发一条mq消息。c.创建消费者消费此主题消息,写冷库(Hbase)。d.停止a这一步。
如果采用方案1同步增量数据,为了保证数据的安全性和一致性,可以在全量任务开始前就启动增量任务,但是增量任务此时不消费binlog同步数据,将消费binlog的位点前置(早于全量任务开始,或者和全量任务开始时间一致).当全量任务跑完的时间点增量任务开始消费binlog。
如果采用方案2同步增量数据,此方案可能会有重复数据出现,但是Hbase中修改操作也是新增一条数据,每条数据对应一个时间戳做多版本,当查询数据时,会按照时间戳取最新的那条数据。为了节省预算资源和保证数据的安全性,必须采用方案1先执行,然后消费mq,再停止方案1。
注意:为保证全量任务迁移安全,全量任务执行期间,不要往热库写数据。
当数据迁移完成后删除热库(mysql)中100天之后的数据,这样就保证了mysql的空间资源,同时需要对mysql做optimize。
需要分库分表的扫描,然后按照主键id删除数据。
接口改造
逻辑层再加一层路由层,判断数据的创建时间,如果大于90天就请求冷DB,如果小于90天就请求热DB。
测试及其灰度配置
此外 可以在diamond(阿里)或者Apollo(携程)或者wconfig(58)等可配置化平台配置白名单,采用变动推送新配置方式,项目实时读取新配置。通过白名单做测试用。同时在diamond上采用分桶方式在上线之后做灰度百分比,如果一旦发现问题将请求冷DB流量切换至0%,及时回滚。
下面这个是我在diamond上的配置:
{
"experiment": "AHIM_DB_B2C",
"totalBucket": 1000,
"divideType": "cid",
"config": {
"buckets": [{
"startBucket": 0,
"endBucket": -1,
"whiteList": ["111","222","333"],
"bucketType": 1
}],
"defaultBuckets": 0
}
}
可以在代码中加开关控制,有问题随时关闭开关,停止走冷库逻辑