淘宝网数据库架构演变 4 2010
2020-03-01 386浏览
- 1.数据库架构演变（2003-2010） 丁原 dingyuan@taobao.com 日期：2010.06 1
- 2.Agenda • 数据库基本框架 • 数据库架构演变 • 案例：交易核心数据库演变关键点
- 3.Oracle基本框架 Aplication Aplication 出现硬件故障时，物理备库激活成为主 库，替代主库对外提供服务。 逻辑备库主要提供dw使用。 主库 物理备 库 逻辑备 库 Dw 3
- 4.MySQL基本框架 Aplication Aplication Aplication Aplication M-S架构： M-M架构： Master Slave Master Master Slave 4
- 5.Failover的困惑 主备切换如何做到不影响到应用，不需要开发人工干预？ tbtest = (DESCRIPTION = (failover = on ) (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.0.1)(PORT = 1521)) (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.0.2)(PORT = 1521)) ) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = tbtest) ) )
- 6.Rjdbc+自动推送 主备数据库进行独立的管理，配置两个数据源。 数据源中哪一个是活跃的，取决于ConfigServer(配置中心)上的配置。 Configserver：
- 7.Agenda • 数据库基本框架 • 数据库架构演变 • 案例：交易核心数据库演变关键点
- 8.初期架构 2003年： 快速开发 Mysql，pc服务器 oracle Mysql oracle oracle 2004年： 稳定性，高性能 逐步开始采用oracle，小型机， 高端硬件存储 oracle：商品，交易，评价，收藏，用户等（3套oracle环境） 网站迅猛发展，数据库一定要保证高可用性，最稳妥的 方法？ 8
- 9.解决问题 找“老板”投钱 Oracle，小型机，高端硬件存储 9
- 10.垂直拆分 oracle oracle oracle oracleoracle oracle 2008年： 业务迅猛发展，单 台小型机很快就达 到瓶颈，开始进入 大规模垂直拆分 阶段 高可用带来了高成本 Oracle：商品，交易，用户，评价，收藏夹（8-10套数据库） 10
- 11.垂直拆分优缺点 优点： 减少应用之间的耦合 数据库业务单一，可以针对具体的业务类型优化 缺点： 硬件成本，Oracle license费用 垂直扩展可能带来的问题？ 11
- 12.可怕的扩展 3->8套->16套->? 物理主库，物理备库，逻辑备库 oracle，小型机，高端存储，可怕的硬件投入 找“老板”继续投钱 ？ 可怕的成本，可怕的垂直扩展 垂直扩展并没有打破集中式，可怕的集中式 12
- 13.水平拆分 淘宝不断发展，系统压力增长远远超过2倍/每年，新业务不断上 水平拆分？ 线，在好的硬件也很容易达到瓶颈， 问题： 1.需要解决拆分带来的成本问题 2.我们会增加很多服务器，必须要解决可维护性 3.我们也要解决可扩展性 13
- 14.水平拆分 去Oracle 去小型机 去高端存储 Mysql，廉价pc服务器 应用上做容灾，不在过度依赖数据库 依赖硬件 分布式，低成本，可扩展，易维护 14
- 15.他他他 他能搞定一切吗？ 15
- 16.数据库能做什么 1.存数据 2.单条查询（querybyid） 3.多表关联sql查询 4.通过存储过程，函数来处理业务 5.大量数据实时在线分析（sum，count ，group by） 我们对数据库的定位是什么？ 16
- 17.合理的使用技术 数据库尽量只负责保存数据 尽量通过应用服务器来分摊复杂计算（order by、sum、group by、 count..） Isearch（搜索，实时搜索） Tair（基于key value的全内存系统） Tfs（taobao file system） Nosql（ Cassandra 。。。） Bigtable 17
- 18.做合适的事情 18
- 19.Agenda • 数据库基本框架 • 数据库架构演变 • 案例：交易核心数据库演变关键点
- 20.遭遇瓶颈 卖家交易后台管理： 20
- 21.瓶颈在哪儿 1. 模糊查询 2. 大量数据count操作 3. list查询分页查询 4. 查询条件复杂，用户可以动态选择 备注： 交易实时性要求非常高，需要实时展示，不能有延迟 21
- 22.如何解决 这球怎么踢？ 22
- 23.实时搜索 大数据量处理尽量通过搜索来实现。 相比其他的方案，搜索很好的解决了标题的模糊like查询。 Aplication Application isearch 增量dump Db 23
- 24.遭遇新的瓶颈 通过监控平台采集了部分sql的执行量（12小时） 数据库接近4万次/每秒的查询，每个小时在1.5亿次左右，还 在快速增加中。 24
- 25.瓶颈在哪儿 读太多（单台查询，多条查询） 更新量太大，每天将近1亿次的更新 sql执行量增长非常快 备注： 实时性要求非常高 不管是卖家还是买家，肯定不乐意看到付款的成功订单，系统 却显示未付款。 如何解决读？ 25
- 26.可选方案 Tair 实时搜索 通过廉价pc实现读写分离 其他 我们选择了什么？ 26
- 27.读写分离 通过廉价pc实现读写分离 场景： 1.买家查询 2.卖家查询 3.单条id查询 4.关联查询 5.其他查询 拆分如何兼顾、解决多维度查询呢？ 27
- 28.如何解决 两份数据 按照不同维度拆分，承担各自不同的业务场景。 框架： 两份数据+读写分离 28
- 29.现有架构 Aplication Application 主库1 RW RW 主库2 1.引入读库集群 2.采用mysql和廉价pc服务器 3.采用1主多备来分摊读压力 4.业务进行分级 Notify消息机制复制 R R M-1 M-2 M-3 …. M-10 …... S-1 S-2 S-3 S-4 S-10 …... S-15 M-15 M-16 S-16 S2-15 S2-16 29
- 30.小结 垂直拆分 水平拆分 读写分离 对数据库的定位 30
- 31.交流时间
