淘宝数据库架构演进历程.pdf

《淘宝数据库架构演进历程.pdf》由会员上传分享，免费在线阅读，更多相关内容在工程资料-天天文库。

1、淘宝数据库架构演进历程丹臣/赵林数据架构师2010-11-19提纲淘宝数据库发展的三个阶段用户，商品，交易现在的架构2010双11大促的挑战MySQL源代码研究的一些思路淘宝自主数据库Oceanbase原理介绍淘宝的数据很美丽淘宝数据库发展三阶段SQL语句变化SQL语句复杂程度由繁到简的过程，折射出淘宝数据架构的一些变化。单多表主表复键关杂查联J查询oin询淘宝电子商务网站的特点高并发，PV13亿，光棍节促销PV达到了17亿数据实时性要求高数据准确性要求高大多数页面属于动态网页网站需要大量商

2、品图片展示用户通过搜索引擎，广告，类目导航寻找商品网站读多写少，比例超过10:1卖家相关的数据量较大，比如商品数，评价数业务量快速增长不同的时期，不同的策略正是因为如上的业务特点：早期的淘宝前端应用系统，严重依赖于数据库系统早期单机式的mysql的使用方式，在业务的高速发展下，很快达到瓶颈Mysql迁移到Oracle，并升级到小型机，高端存储后，几年的时间里，满足了淘宝业务快速变化发展的需要。我们的业务发展很快，但我们的技术没有成长数据库里的数据第一，二阶段的单台数据库里，用户，商品，交易等数据都在一起

3、，存在许多的关联查询，应用完全耦合用户收藏商品评价交易连接数问题小型机的内存有限，发现了Oracle数据库有连接数瓶颈，5000个以后相当吃力。太多的应用机器有限的链接池需要数据库连接Oracle数据库中心化，服务化用户，商品，交易三大中心的建设HSF的诞生中心化后面临另一个问题，服务调用者，与服务者之间如何进行远程通信，淘宝HSF诞生HSFAB服服务务数据垂直化应用中心化之后，底层数据库系统按照不同的业务数据进行了一系列的垂直拆分.此类拆分方式具有如下的特点：a.拆分方式简单，只需要把不同的业务数据进行分

4、离b.避免了不同的业务数据读写操作时的相互影响c.该业务内部及其所导致的问题依旧用户商品交易评价问题单库IOPS3w单库连接数已经4k个了，应用还在不断加机器？单库每秒SQL执行次数到4w次Oracle单库事务数2k个搜索dump数据缓慢，DWETL缓慢数据库架构发展新思路异构数据库读写分离原始架构图（08年8月份）:异构的读写分离a.写库为集中式的oracle环境,提供数据安全性保障b.读库使用mysql,采用数据分片，分库分表，每台mysql放少量的数据,单个数据分片内部采用mysql复制机制c.读库的超

5、大memory容量，起到了很好的cache作用，在内存中的数据查询性能远远高于在硬盘上的性能d.oracle到多台mysql按规则复制e.分区键的选择至关重要，尽量让数据访问落在单台数据库上g.利用好当前的高端硬件,保护好自己的投资构建数据查询的高速公路应用到DB的数据写入与查询从双向通行变成了单向通行，通行效率更高，大大避免了相互影响。“借道行驶”的情况不再出现。跨不过去的坎为什么不直接迁到MySQL上面去呢？a.对于核心业务，停机时间有限，宠大的数据无法短时间内迁移b.无法在短时间内完成项目发布过程中的测试c.

6、没有搞过mysql分布式系统，对完全使用MySQL还没有信心大数据量核心业务数据迁移思路采用两步走战略，不仅走得稳，而且走得好：先采用异构的数据库读写分离,将数据复制到目标mysql各结点，不断切换应用相关的读服务到mysql结点上，验证可靠性，机器压力，服务响应时间将写压力从oracle结点迁移到mysql各结点，oracle停止写对于一些不太核心，业务不太复杂，相关影响点不多的数据，可以直接进行迁移。水库模型你的系统可以撑多少？系统余量还有多少？数据库系统余量两轮测试过程，确保上线稳定：底层数据库环境性能，

7、稳定性的基础测试，常用的工具可以采用sysbench,orion,supersmack选择不同的硬件，软件组合，模拟应用的压力测试，要超越当前业务压力的几倍进行，这个压力的幅度可以根据自己的业务增长设计一个合理的值。我们如何做到用数据来说话？靠测试拿数据，不靠经验用数据来说话不同的读服务,不同的读载体淘宝商品的几个主要的查询：a.主键查询通过分布式数据库，以及分布式缓存系统解决b.卖家商品管理类查询，这一类的查询数据量大，并且还有like查询的需求，通过实时搜索解决商品主键卖家查询查询分布式缓存实时搜索分布式数据库注

8、：考虑不同的读载体的技术实现，性能，成本数据修改频率用户登陆事件数据(日志量90%)与用户主数据(日志量10%)分离，不仅要分表，而且要放到不同的数据库集群中,并且作好不同数据等级的容灾处理。用用用户主信息数据库用户户集群户主信信信息息息扩展用户信息扩展数据库集群过度中心化用户中心调用次数，高峰时期达到了每天60亿次，用户