淘宝网数据库架构演变

y_oyo1

贡献于2012-05-26

字数:0 关键词:

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

下载文档,方便阅读与编辑

文档的实际排版效果,会与网站的显示效果略有不同!!

需要 10 金币 [ 分享文档获得金币 ] 1 人已下载

下载文档

相关文档