为什么要去Oracle
现在好像是个互联网公司好像都在谈去IOE,也有人问过我们,去IOE到底有什么受益?我们公司为什么要去IOE呢?当然实际情况是因为我们上层领导决定的,所以我们都热火朝天的干起来了,就跟我们当时为什么将已经开发的系统从MySQL数据库改成Oralce一样,都是上层领导决定的。对此我只能哈哈哈了。
但是我有自己的思考,为什么我们要去Oracle呢?对我们到底会带来什么受益呢?我个人觉得对于大型互联网公司用MySQL替代Oracle的原因有这样一些。
大规模部署成本可大幅度降低
因为大型互联网公司往往存储非常大规模的数据,数据库的读写流量也往往巨大,有数以千计的各种应用都需要用到数据库,这样购买硬件、软件license的成本巨大,随着业务不断发展,部署规模不断增加,我们的成本也将持续增加,这个帐应该很简单,不必细算。因此从成本考量我们是动力去做这个改造的。
但是我觉得规模可控范围之内的企业级应用,并且数据价值极高的业务,比如典型的银行,他们还依旧会选择使用Oracle更加合适。
有财力养MySQL专家团队可以搞定一切
由于互联网的集中化部署和维护的特点,使得我们开发和运维团队的价值较高,因此大规模互联网公司有财力聘请专门的MySQL专家技术团队,这些专家可以把MySQL的使用、部署、运维、原理源码都搞得非常透彻,他们有能力搞定MySQL出现的一切问题,他们可以针对自己公司的需求对MySQL做各种类型的定制和扩展,让数据库更加符合自己的需求,使用起来更加顺手,与系统内部的技术体系结合得更加机密,比如云平台、自动化运维系统等等。
当然这还因为MySQL是开源的,结构简单,代码量相对少,这样专家团队能够更容易的驾驭MySQL。
那为什么很多中小企互联网公司也使用MySQL呢?那是因为MySQL的简单、开源免费、开放,这符合小公司的很多特点,对于一些价值不高的数据存储来说也没有多大问题,而且中小互联网公司的数据刚开始的价值都不太高,所以他们会选择他。
所以,对于从可行性角度考虑我们是可以使用MySQL作为自己的主要数据存储服务器的。
改造前的架构
我们要改造的系统是一个核心的业务系统,它是提供实时生成的业务系统,对于系统的稳定性要求高,每天产生的数据量也较大。目前Oracle数据库服务器的情况是这样的架构。
当天系统数据架构存在的问题有这些:
- 共享的Oracle数据库集群,多个大型互联网系统之间的耦合性非常重。一损俱损,一荣俱荣。
- 业务发展迅速,要求支持单日数据量1亿,当前数据架构可扩展性受限。
- 公司整体技术战略迁移到MySQL。MySQL的运维力量大大增加。
- Oracle的小型机无法迁移到新的机房。
因此诸多重要因素决定了我们必须迁移到基于MySQL的分布式数据架构上。
改造后的架构
从图中可以看出,过渡期Oracle和MySQL两个库是同时共存的,两个库是一个互为准备的关系,主库的数据写入会异步写入到从库上去。
上述为改造后的数据架构的全貌,主要由这些要点。
- 业务操作日志类数据迁移到Canssandra中。
- mysql分库按照冷热库分开。
- 热库分为256片,分布在多个MySQL实例上。
改造之后的好处有这些。
- 核心业务库的压力大幅度下降,可以承担更多的业务量。
- 核心业务库具备了较强的可扩展性,能够支持更多的业务量。
- 冷库压力不大可以共享,冷热分离可以分开优化。
架构改造的挑战
1.物流核心的业务系统,系统的可用性不能有任何影响。
2.共有81张业务表有待迁移,工程量巨大。
3.有1张表4亿数据,4张1多条数据,这些核心业务数据迁移到MySQL后需要做分库。
4.分库后的跨库join,跨库事务无法实现的问题需要解决。
5.下游的监控报表平台、大数据平台的数据接入需要调整。
架构改造设计和实现
选择分库实现方案
分库策略设计
全局id生成
跨库join解决方案
跨库事务解决方案
平滑切换方案
数据同步方案