第1页
淘宝数据库架构演进历程
丹臣/赵林
数据架构师
2010-12-12
第2页
提纲
淘宝数据库发展的三个阶段
用户，商品，交易现在的架构
2010双11大促的挑战
MySQL源代码研究的一些思路
淘宝自主数据库Oceanbase原理介绍
第3页
淘宝的数据很美丽
第4页
淘宝数据库发展三阶段
第5页
SQL语句变化
多表关联Join
单表复杂查询
主键查询
SQL语句复杂程度由繁到简的过程，折射出淘宝数据架构的一些变化。
第6页
淘宝电子商务网站的特点
高并发，PV13亿，光棍节促销PV达到了17亿
数据实时性要求高
数据准确性要求高
大多数页面属于动态网页
网站需要大量商品图片展示
用户通过搜索引擎，广告，类目导航寻找商品
网站读多写少，比例超过10:1
卖家相关的数据量较大，比如商品数，评价数
业务量快速增长
数据实时性要求高
数据准确性要求高
大多数页面属于动态网页
网站需要大量商品图片展示
用户通过搜索引擎，广告，类目导航寻找商品
网站读多写少，比例超过10:1
卖家相关的数据量较大，比如商品数，评价数
业务量快速增长
第7页
不同的时期，不同的策略
正是因为如上的业务特点：
早期的淘宝前端应用系统，严重依赖于数据库系统
早期单机式的mysql的使用方式，在业务的高速发展下，很快达到瓶颈
Mysql迁移到Oracle，并升级到小型机，高端存储后，几年的时间里，满足了淘宝业务快速变化发展的需要。
我们的业务发展很快，但我们的技术没有成长
MySQL到Oracle,PC server到IBM小型机的迁移，极大的提升了数据库的处理能力，在高端存储的帮助下，IO能力也得到了极大的提升，使大家能够在较长一段时间内，集中精力做业务，数据库系统能够快速响应业务发展的各种需求
小型机硬件不断升级，高端存储不断扩展，Oracle商业软件费用增加，公司面临成本压力，我们的技术没有得到提升
再好的硬件也有极限，集中式始终存在要命的扩展问题，整个系统出现IOPS，连接数等各种瓶颈
随着公司的发展，各类技术人才开始汇集，我们可以有所作为
第8页
数据库里的数据
第一，二阶段的单台数据库里，用户，商品，交易等数据都在一起，存在许多的关联查询，应用完全耦合
用户
商品
交易
评价
收藏
第9页
连接数问题
Oracle数据库
太多的应用机器
有限的链接池
需要数据库连接
小型机的内存有限，发现了Oracle数据库有连接数瓶颈，5000个以后相当吃力。
第10页
中心化，服务化
用户，商品，交易三大中心的建设
第11页
HSF的诞生
中心化后面临另一个问题，服务调用者，与服务者之间如何进行远程通信，淘宝HSF诞生,数据库一些OLTP join问题解决。
A服务
B服务
HSF
第12页
数据垂直化
应用中心化之后，底层数据库系统按照不同的业务数据进行了一系列的垂直拆分.此类拆分方式具有如下的特点：
a. 拆分方式简单，只需要把不同的业务数据进行分离
b. 避免了不同的业务数据读写操作时的相互影响
c. 该业务内部及其所导致的问题依旧
用户
商品
交易
评价
第13页
问题
单库IOPS 3w
单库连接数已经4k个了，应用还在不断加机器？
单库每秒SQL执行次数到4w次
搜索dump数据缓慢，DW ETL缓慢
单库连接数已经4k个了，应用还在不断加机器？
单库每秒SQL执行次数到4w次
搜索dump数据缓慢，DW ETL缓慢
用硬盘来拼IOPS？
第14页
一台高端存储的处理能力
480块盘的hdisk，max IOPS 6w
注意应用可以接受的IO response time,以及IOPS点。比如3w IOPS以上，会达到20ms以上
注意应用可以接受的IO response time,以及IOPS点。比如3w IOPS以上，会达到20ms以上
第15页
数据库架构发展新思路
异构数据库读写分离原始架构图（08年8月份）:
第16页
异构的读写分离
a. 写库为集中式的oracle环境,提供数据安全性保障
b. 读库使用mysql, 采用数据分片，分库分表，每台mysql放少量的数据,单个数据分片内部采用mysql复制机制
c. 读库的超大memory容量，起到了很好的cache作用，在内存中的数据查询性能远远高于在硬盘上的性能
d. oracle到多台mysql按规则复制，由TDDL完成
e. 分区键的选择至关重要，尽量让数据访问落在单台数据库上
g.利用好当前的高端硬件,保护好自己的投资
第17页
构建数据查询的高速公路
应用到DB的数据写入与查询从双向通行变成了单向通行，通行效率更高，大大避免了相互影响。“借道行驶”的情况不再出现。
第18页
跨不过去的坎
为什么不直接迁到MySQL上面去呢？
a. 对于核心业务，停机时间有限，宠大的数据无法短时间内迁移
b.无法在短时间内完成项目发布过程中的测试
c.没有搞过mysql分布式系统，对完全使用MySQL还没有信心
a. 对于核心业务，停机时间有限，宠大的数据无法短时间内迁移
b.无法在短时间内完成项目发布过程中的测试
c.没有搞过mysql分布式系统，对完全使用MySQL还没有信心
第19页
大数据量核心业务数据迁移思路
采用两步走战略，不仅走得稳，而且走得好：
先采用异构的数据库读写分离,将数据复制到目标mysql各结点，不断切换应用相关的读服务到mysql结点上，验证可靠性，机器压力，服务响应时间
将写压力从oracle结点迁移到mysql各结点，oracle停止写
对于一些不太核心，业务不太复杂，相关影响点不多的数据，可以直接进行迁移。
第20页
水库模型
你的系统可以撑多少？系统余量还有多少？
第21页
数据库系统余量
两轮测试过程，确保上线稳定：
底层数据库环境性能，稳定性的基础测试，常用的工具可以采用sysbench, orion, supersmack
选择不同的硬件，软件组合，模拟应用的压力测试，要超越当前业务压力的几倍进行，这个压力的幅度可以根据自己的业务增长设计一个合理的值。
我们如何做到用数据来说话？靠测试拿数据，不靠经验
第22页
数据库系统余量
第23页
数据生命周期之历史迁移
Data
Online Data
History Data
商品，交易，评价，物流等数据都有自己的生命周期。通过数据历史迁移，减少在线库的容量，提高在线库的性能。
第24页
在线与历史应用分离
Online Data
Database
Database
History Data
Database
Database
Online Application
History Application
数据迁移程序
在线库与历史库重要等到级不同,在线库更高
同一应用的在线应用与历史应用分离
高级别的应用不能直接依赖于低级别的数据库
同一应用的在线应用与历史应用分离
高级别的应用不能直接依赖于低级别的数据库
第25页
商品访问框架
主键查询
卖家查询
淘宝商品的几个主要的查询：
a.主键查询通过分布式数据库，以及分布式缓存系统解决
b.卖家商品管理类查询，这一类的查询数据量大，并且还有like查询的需求，通过实时搜索解决
a.主键查询通过分布式数据库，以及分布式缓存系统解决
b.卖家商品管理类查询，这一类的查询数据量大，并且还有like查询的需求，通过实时搜索解决
商品
分布式缓存
分布式数据库
实时搜索
注：考虑不同的读载体的技术实现，性能，成本
第26页
用户
用户登陆事件数据(日志量90%)与用户主数据(日志量10%)分离，不仅要分表，而且要放到不同的数据库集群中,并且作好不同数据等级的容灾处理。
用户信息
用户主信息
用户信息扩展
用户主信息数据库集群
用户信息扩展数据库集群
第27页
过度中心化
用户中心
Tair分布式缓存
商品中心
交易中心
评价中心
用户中心调用次数，高峰时期达到了每天60亿次，用户中心的过度中心化问题越来越显著,成为各种操作的关键路径。
Mysql集群
第28页
用户中心中的读写分离
用户中心
Tair分布式缓存
商品中心
交易中心
评价中心
Mysql集群
在其它中心中内置可以访问tair的客户端，大部份的读不需要经过用户中心，直接读tair，写需要经过用户中心。
第29页
交易的读写分离框架
主库按照买家拆分，读库按照卖家拆分。
第30页
一些难题
数据库集群自动扩展仍然是个难题，但是是可以忍受的，底层数据库集群经过评估，扩展的频率并不高。
MySQL DDL操作不便，锁表，对写操作影响较大，为了减少影响，分了比较多的表，进一步加重了维护的负担。
其它。。。
第31页
光棍节大促
活动前，经过了充分的准备与系统评估工作：CDN面临的压力最大，预估流量将会达到280G左右，准备了各个层面的系统降级方案。
第32页
一个小意外
Dataguard+mirror redo对写的影响比较大，临时删除远程的redo member解决这个问题
第33页
MySQL源代码研究
我们主要从两方面着手：
MySQL内部，源代码熟悉，性能优化，新增功能
MySQL外部，比如利用binlog做数据复制
MySQL内部，源代码熟悉，性能优化，新增功能
MySQL外部，比如利用binlog做数据复制
第34页
MySQL源代码研究
内部新增的一些功能：
a.给innodb动态加数据文件
b.禁止新连接
c.表的访问统计
d.Innodb ssd加速
e.Mysql replication并行复制
a.给innodb动态加数据文件
b.禁止新连接
c.表的访问统计
d.Innodb ssd加速
e.Mysql replication并行复制
第35页
MySQL Binlog解析数据复制中心
解决商品，用户，评价，收藏夹等应用向数据仓库，搜索增量同步数据的需求
第36页
MySQL Binlog解析数据复制中心
C client端特性：
a. 支持mysql master,slave主备切换，获取binlog不受影响
b. 自动重连主机
c. 支持checkpoint, 支持断点续传binlog
Java端复制代码特性：
a. 支持statement, row两种复制模式
b. 支持按规则复制
c. 支持一定条件下的并行复制
c. 支持checkpoint
第37页
异地多数据中心的数据同步
杭州
青岛
other
第38页
异地多数据中心的数据同步
除了oracle dataguard,master-slave replication数据复制，我们还有其它哪些可选方案？
第39页
淘宝自主数据库Oceanbase
动态数据与静态数据进行分离,动态数据采用集中式，静态数据存放与服务采用分布式
设计了一个宽表，冗余数据，将离散型IO合并成连续型IO
每晚动态数据，与静态数据合并一次
将首先在收藏夹应用上试点
设计了一个宽表，冗余数据，将离散型IO合并成连续型IO
每晚动态数据，与静态数据合并一次
将首先在收藏夹应用上试点
第40页
总结
架构就是用一些简单的道理，去解决问题
对多种技术，业务特征，细节都要有所了解，考虑周全
识别系统的主要问题，花80%的精力去解决80%的问题
架构都是有时效性的，需要不断探索或者接受新的思路
第41页
Follow me
Taobao dba 团队blog
http://www.taobaodba.com/
我的blog subject: Data & Architecture
http://zhaolinjnu.blog.sohu.com/
我的新浪微博:丹臣
http://t.sina.com.cn/zhaolinjnu
我的msn:
echo_lin@hotmail.com
第42页
Questions ?