淘宝数据库架构演进历程及OceanBase架构PPT学习教案

1、会计学1淘宝数据库架构演进历程及淘宝数据库架构演进历程及OceanBase架构架构第1页/共42页第2页/共42页第3页/共42页多表关联Join单表复杂查询主键查询SQL语句复杂程度由繁到简的过程，折射出淘宝数据架构的一些变化。第4页/共42页n网站读多写少，比例超过10:1n卖家相关的数据量较大，比如商品数，评价数n业务量快速增长第5页/共42页里，满足了淘宝业务快速变化发展的需要。n我们的业务发展很快，但我们的技术没有成长第6页/共42页第一，二阶段的单台数据库里，用户，商品，交易等数据都在一起，存在许多的关联查询，应用完全耦合用户商品交易评价收藏第7页/共42页Oracle数据库太多的

2、应用机器太多的应用机器有限的链接池有限的链接池需要数据库连接需要数据库连接小型机的内存有限，发现了Oracle数据库有连接数瓶颈，5000个以后相当吃力。第8页/共42页第9页/共42页A服务B服务HSF第10页/共42页 c. 该业务内部及其所导致的问题依旧用户商品交易评价第11页/共42页据缓慢，DW ETL缓慢用硬盘来拼IOPS？第12页/共42页480块盘的hdisk，max IOPS 6w注意应用可以接受的IO response time,以及IOPS点。比如3w IOPS以上，会达到20ms以上第13页/共42页第14页/共42页中的数据查询性能远远高于在硬盘上的性能 d. ora

3、cle到多台mysql按规则复制，由TDDL完成 e. 分区键的选择至关重要，尽量让数据访问落在单台数据库上 g.利用好当前的高端硬件,保护好自己的投资第15页/共42页第16页/共42页发布过程中的测试c.没有搞过mysql分布式系统，对完全使用MySQL还没有信心第17页/共42页对于一些不太核心，业务不太复杂，相关影响点不多的数据，可以直接进行迁移。第18页/共42页你的系统可以撑多少？系统余量还有多少？第19页/共42页计一个合理的值。我们如何做到用数据来说话？靠测试拿数据，不靠经验第20页/共42页第21页/共42页DataOnline DataHistory Data商品，交易，评

4、价，物流等数据都有自己的生命周期。通过数据历史迁移，减少在线库的容量，提高在线库的性能。第22页/共42页Online DataDatabaseHistory DataDatabaseOnline Application History Application 数据迁移程序在线库与历史库重要等到级不同,在线库更高同一应用的在线应用与历史应用分离高级别的应用不能直接依赖于低级别的数据库第23页/共42页主键查询卖家查询淘宝商品的几个主要的查询：a.主键查询通过分布式数据库，以及分布式缓存系统解决b.卖家商品管理类查询，这一类的查询数据量大，并且还有like查询的需求，通过实时搜索解决商品分布式缓

5、存分布式数据库实时搜索注：考虑不同的读载体的技术实现，性能，成本第24页/共42页用户信息用户主信息用户信息扩展用户主信息数据库集群用户信息扩展数据库集群第25页/共42页用户中心Tair分布式缓存商品中心交易中心评价中心用户中心调用次数，高峰时期达到了每天60亿次，用户中心的过度中心化问题越来越显著,成为各种操作的关键路径。Mysql集群第26页/共42页用户中心Tair分布式缓存商品中心交易中心评价中心Mysql集群在其它中心中内置可以访问tair的客户端，大部份的读不需要经过用户中心，直接读tair，写需要经过用户中心。第27页/共42页第28页/共42页第29页/共42页活动前，经过了充分的准备与系统评估工作：CDN面临的压力最大，预估流量将会达到280G左右，准备了各个层面的系统降级方案。第30页/共42页第31页/共42页nMySQL比如利用binlog做数据复制第32页/共42页e.Mysql replication并行复制第33页/共42页解决商品，用户，评价，收藏夹等应用向数据仓库，搜索增量同步数据的需求第34页/共42页 a. 支持statement, row两种复制模式 b. 支持按规则复制 c. 支持一定条件下的并行复制 c. 支持checkpoint第35页/共42页杭州青岛other