淘宝数据库架构演进历程和OceanBase架构.pptVIP

一些难题 数据库集群自动扩展仍然是个难题，但是是可以忍受的，底层数据库集群经过评估，扩展的频率并不高。 MySQL DDL操作不便，锁表，对写操作影响较大，为了减少影响，分了比较多的表，进一步加重了维护的负担。 其它。。。 MySQL到Oracle,PC server到IBM小型机的迁移，极大的提升了数据库的处理能力，在高端存储的帮助下，IO能力也得到了极大的提升，使大家能够在较长一段时间内，集中精力做业务，数据库系统能够快速响应业务发展的各种需求 小型机硬件不断升级，高端存储不断扩展，Oracle商业软件费用增加，公司面临成本压力，我们的技术没有得到提升 再好的硬件也有极限，集中式始终存在要命的扩展问题，整个系统出现IOPS，连接数等各种瓶颈 随着公司的发展，各类技术人才开始汇集，我们可以有所作为 * 淘宝数据库架构演进历程 丹臣/赵林 数据架构师 2010-12-12 提纲 淘宝数据库发展的三个阶段 用户，商品，交易现在的架构 2010双11大促的挑战 MySQL源代码研究的一些思路 淘宝自主数据库Oceanbase原理介绍 淘宝的数据很美丽 淘宝数据库发展三阶段 SQL语句变化 多表关联Join 单表复杂查询 主键查询 SQL语句复杂程度由繁到简的过程，折射出淘宝数据架构的一些变化。 淘宝电子商务网站的特点 高并发，PV13亿，光棍节促销PV达到了17亿 数据实时性要求高 数据准确性要求高 大多数页面属于动态网页 网站需要大量商品图片展示 用户通过搜索引擎，广告，类目导航寻找商品 网站读多写少，比例超过10:1 卖家相关的数据量较大，比如商品数，评价数 业务量快速增长 不同的时期，不同的策略 正是因为如上的业务特点： 早期的淘宝前端应用系统，严重依赖于数据库系统 早期单机式的mysql的使用方式，在业务的高速发展下，很快达到瓶颈 Mysql迁移到Oracle，并升级到小型机，高端存储后，几年的时间里，满足了淘宝业务快速变化发展的需要。 我们的业务发展很快，但我们的技术没有成长 数据库里的数据 第一，二阶段的单台数据库里，用户，商品，交易等数据都在一起，存在许多的关联查询，应用完全耦合 用户 商品 交易 评价 收藏 连接数问题 Oracle数据库 太多的应用机器 有限的链接池 需要数据库连接 小型机的内存有限，发现了Oracle数据库有连接数瓶颈，5000个以后相当吃力。 中心化，服务化 用户，商品，交易三大中心的建设 HSF的诞生 中心化后面临另一个问题，服务调用者，与服务者之间如何进行远程通信，淘宝HSF诞生,数据库一些OLTP join问题解决。 A服务 B服务 HSF 数据垂直化 应用中心化之后，底层数据库系统按照不同的业务数据进行了一系列的垂直拆分.此类拆分方式具有如下的特点： a. 拆分方式简单，只需要把不同的业务数据进行分离 b. 避免了不同的业务数据读写操作时的相互影响 c. 该业务内部及其所导致的问题依旧 用户 商品 交易 评价 问题 单库IOPS 3w 单库连接数已经4k个了，应用还在不断加机器？ 单库每秒SQL执行次数到4w次 搜索dump数据缓慢，DW ETL缓慢 用硬盘来拼IOPS？ 一台高端存储的处理能力 480块盘的hdisk，max IOPS 6w 注意应用可以接受的IO response time,以及IOPS点。比如3w IOPS以上，会达到20ms以上 数据库架构发展新思路 异构数据库读写分离原始架构图（08年8月份）: 异构的读写分离 a. 写库为集中式的oracle环境,提供数据安全性保障 b. 读库使用mysql, 采用数据分片，分库分表，每台mysql放少量的数据,单个数据分片内部采用mysql复制机制 c. 读库的超大memory容量，起到了很好的cache作用，在内存中的数据查询性能远远高于在硬盘上的性能 d. oracle到多台mysql按规则复制，由TDDL完成 e. 分区键的选择至关重要，尽量让数据访问落在单台数据库上 g.利用好当前的高端硬件,保护好自己的投资 构建数据查询的高速公路 应用到DB的数据写入与查询从双向通行变成了单向通行，通行效率更高，大大避免了相互影响。“借道行驶”的情况不再出现。 跨不过去的坎 为什么不直接迁到MySQL上面去呢？ a. 对于核心业务，停机时间有限，宠大的数据无法短时间内迁移 b.无法在短时间内完成项目发布过程中的测试 c.没有搞过mysql分布式系统，对完全使用MySQL还没有信心 大数据量核心业务数据迁移思路 采