在淘宝,有一个业务
系统
,在一年半以前,这个业务系统很小,访问量很低,相关的表跟核心
数据库
放在一起,后来由于产品升级,新产品的许多功能很受会员的喜爱,会员大量使用,很快就对核心数据库造成了相当程度的IOPS冲击与威胁,也迅速消耗着核心存储的空间,为了不影响淘宝的核心业务,我们将此业务相关的表迁移出了核心库,创建了一个独立的ORACLE数据库,这种拆分数据库的方式,就是大家常说的
垂直拆分
。
这种拆分方式,对上层业务应用程序变动很小,只是需要改一下 数据库连接 而已。尽管数据库独立了,但从本质上来讲,并没有优化这个业务的数据库。在新的数据库里,此产品仍然在高速发展,每天都制造着大量的数据,表和索引越来越大,存储空间达到了T级。由于此业务访问的离散性,对存储IOPS消耗极高,占用了大量的宝贵的存储资源。为了减少这种消耗,我们首先在业务层面进行了优化,拿掉了一些不必要的产品功能,并加入了一些限制,控制了一部份不正常的数据增长;在数据库层面,通过观察 SQL ,发现了应用程序中可以改进的业务逻辑以及进行必要有索引调整;还有对有些业务点加上适当的前端的Cache策略。通过以上的改进,在一定程度上缓解了整个系统的压力。
对整个系统的根本性改造,我们一直在探索。对于技术出身的我们来说,一个小小的xx业务系统,占用了这么多的昂贵的存储硬件资源与ORACLE软件资源,心里总有一些不平静,要去改造它。而且这个业务系统仍然在不断的膨胀,好几个表的数据都超过了十亿级,进行索引调整的难度越来越大,对于前端业务的不断变化,这种调整又是必须的。采用集中式的ORACLE数据库方式,在前期,会在相当程度上减少前端应用程序的复杂性,但到了一定的规模过后,你会发现你要付出的代价也会呈指数级的增长,可维护性在逐渐降低。而且在这种高IOPS,高并发的情况下,数据库也会很容易出问题。
从去年开始,taobao开始在一些小系统上采用MySQL数据库( 数据库迁移 ),但使用的方式跟ORACLE并没有什么不同。搭建master-slave主从复制结构( 读写分离 ),应用程序访问master,slave只起到接管的作用。为了改造这个业务系统,采用这么简单的结构是不行的。我们确立了几点目标,第一搭建一个 分布式集群 ;第二集群采用廉价的PC;第三实现读写分离,slave也要承担一定的业务读;第四是用内存来支撑IOPS,不是硬盘。对于此项目业务的数据库,根据什么规则做 sharding(水平分区) ,又是摆在我们面前一个问题?在做这个架构设计的时候,我们sharding的原则,是要保证大量的访问都是在单库上完成的,不需要跨库merge与sort。我们确立了基本方案过后,联合开发与架构,细化了设计方案,在几个月前,开始了这场攻坚。
因为是要对大表做数据的水平拆分,将数据拆分到多个数据库上,有几个重要的问题需要思考:
1.怎么把在ORACLE中几十亿的数据按规则迁到 mysql 集群中;
2.如何产生主键唯一值;
3.大表根据规则拆成小表,分区键是哪列,拆分粒度是多少?每个库多少表?
4.如何解决这么多库这么多表的路由问题;
5.如何解决跨库的merge与sort;
6.如何对连接进行管理;
7.如何做数据订正;
8.我们需要开发哪些集群管理工具,比如说建表工具;
9.集群遇到停电怎么办?
10.如何对集群中的数据进行历史迁移?
11.尽管集群采用廉价的PC,但具体采用何种PC,差别还是挺大的,如何平衡集群的规模与可管理性方面的问题?
12.集群对机房电力的消耗与机柜占用问题?
在项目进行期间,DBA团队先后进行了几次数据迁移测试,在 数据仓库 与SA团队的帮助下,尽管经历了一些困难与挑战,但最终这些问题,大都一一解决。这个项目先后进行了三次程序发布,发布期间平滑迁移数据32亿条左右,感谢负责此项目的DBA同事们与可敬可爱的开发工程师们。这个项目,也使得我们的分布式中间件有了进一步的发展与完善,大大减化了上层业务系统开发的复杂度,不必关心下层业务数据的存放逻辑,感谢架构团队的精益求精。
项目发布后,经过观察,各库不管是master与slave,负载基本相同,但集群中各库负载基本上都在6以上,稍微有点偏高。进行了一些 SQL 调化,主要是索引调整后,负载降到2以下。说起索引调整,这也是第一次对这么大的mysql集群做DDL,做一次大概需要好几个小时。这个时间消耗,超过了自己的预期。
项目一期已经完成,二期很快又会启动,如果你想不断挑战自我,实现自我价值,加入淘宝DBA团队,这里有一流的环境,成为一名优秀的mysql DBA指日可待。
这种拆分方式,对上层业务应用程序变动很小,只是需要改一下 数据库连接 而已。尽管数据库独立了,但从本质上来讲,并没有优化这个业务的数据库。在新的数据库里,此产品仍然在高速发展,每天都制造着大量的数据,表和索引越来越大,存储空间达到了T级。由于此业务访问的离散性,对存储IOPS消耗极高,占用了大量的宝贵的存储资源。为了减少这种消耗,我们首先在业务层面进行了优化,拿掉了一些不必要的产品功能,并加入了一些限制,控制了一部份不正常的数据增长;在数据库层面,通过观察 SQL ,发现了应用程序中可以改进的业务逻辑以及进行必要有索引调整;还有对有些业务点加上适当的前端的Cache策略。通过以上的改进,在一定程度上缓解了整个系统的压力。
对整个系统的根本性改造,我们一直在探索。对于技术出身的我们来说,一个小小的xx业务系统,占用了这么多的昂贵的存储硬件资源与ORACLE软件资源,心里总有一些不平静,要去改造它。而且这个业务系统仍然在不断的膨胀,好几个表的数据都超过了十亿级,进行索引调整的难度越来越大,对于前端业务的不断变化,这种调整又是必须的。采用集中式的ORACLE数据库方式,在前期,会在相当程度上减少前端应用程序的复杂性,但到了一定的规模过后,你会发现你要付出的代价也会呈指数级的增长,可维护性在逐渐降低。而且在这种高IOPS,高并发的情况下,数据库也会很容易出问题。
从去年开始,taobao开始在一些小系统上采用MySQL数据库( 数据库迁移 ),但使用的方式跟ORACLE并没有什么不同。搭建master-slave主从复制结构( 读写分离 ),应用程序访问master,slave只起到接管的作用。为了改造这个业务系统,采用这么简单的结构是不行的。我们确立了几点目标,第一搭建一个 分布式集群 ;第二集群采用廉价的PC;第三实现读写分离,slave也要承担一定的业务读;第四是用内存来支撑IOPS,不是硬盘。对于此项目业务的数据库,根据什么规则做 sharding(水平分区) ,又是摆在我们面前一个问题?在做这个架构设计的时候,我们sharding的原则,是要保证大量的访问都是在单库上完成的,不需要跨库merge与sort。我们确立了基本方案过后,联合开发与架构,细化了设计方案,在几个月前,开始了这场攻坚。
因为是要对大表做数据的水平拆分,将数据拆分到多个数据库上,有几个重要的问题需要思考:
1.怎么把在ORACLE中几十亿的数据按规则迁到 mysql 集群中;
2.如何产生主键唯一值;
3.大表根据规则拆成小表,分区键是哪列,拆分粒度是多少?每个库多少表?
4.如何解决这么多库这么多表的路由问题;
5.如何解决跨库的merge与sort;
6.如何对连接进行管理;
7.如何做数据订正;
8.我们需要开发哪些集群管理工具,比如说建表工具;
9.集群遇到停电怎么办?
10.如何对集群中的数据进行历史迁移?
11.尽管集群采用廉价的PC,但具体采用何种PC,差别还是挺大的,如何平衡集群的规模与可管理性方面的问题?
12.集群对机房电力的消耗与机柜占用问题?
在项目进行期间,DBA团队先后进行了几次数据迁移测试,在 数据仓库 与SA团队的帮助下,尽管经历了一些困难与挑战,但最终这些问题,大都一一解决。这个项目先后进行了三次程序发布,发布期间平滑迁移数据32亿条左右,感谢负责此项目的DBA同事们与可敬可爱的开发工程师们。这个项目,也使得我们的分布式中间件有了进一步的发展与完善,大大减化了上层业务系统开发的复杂度,不必关心下层业务数据的存放逻辑,感谢架构团队的精益求精。
项目发布后,经过观察,各库不管是master与slave,负载基本相同,但集群中各库负载基本上都在6以上,稍微有点偏高。进行了一些 SQL 调化,主要是索引调整后,负载降到2以下。说起索引调整,这也是第一次对这么大的mysql集群做DDL,做一次大概需要好几个小时。这个时间消耗,超过了自己的预期。
项目一期已经完成,二期很快又会启动,如果你想不断挑战自我,实现自我价值,加入淘宝DBA团队,这里有一流的环境,成为一名优秀的mysql DBA指日可待。