开发者社区> 云学习小组> 正文
阿里云
为了无法计算的价值
打开APP
阿里云APP内打开

阿里分布式数据库服务实践

简介:
+关注继续查看


沈询: 阿里巴巴资深技术专家,08年加入阿里巴巴,一直从事阿里分布式数据层方面的研发工作,参与了公司大部分的去IOE工作,具备较多实操经验。目前主要负责淘宝分布式数据层(TDDL),阿里分布式数据库服务(DRDS),阿里分布式消息服务(Notify,MetaQ)的开发和架构设计工作。

经过近一年的运营,阿里巴巴的分布式数据库(DRDS)已经协助电商,电信,银行,政府等多种类型的系统进行过业务分布式改造,在系统实施的过程中,我们碰到和解决了哪些问题? 他们是怎么解决的?背后的思考是什么?未来在何方? 以下来分享下精彩内容。

DRDS简介

起源

DRDS 脱胎于 alibaba的cobra 分布式数据库引擎06年上线使用,在alibaba有近百应用在使用,目前已经开源,DRDS80%的代码出自cobra proxySql解析器,执行流程配置)。

DRDS吸收了taobao TDDL分布式数据库引擎的大量优秀经验和解决方案,08年上线使用,目前在使用的应用近千个,大量实际应用解决方案支持分布式join,支持分布式aggregation (group sum max min),支持异步索引构建,支持Auto sharding ,自动扩容缩容。

从TDDL到DRDS,

DRDS专门针对外部用户进行了配置的重新设计简化了配置操作规范与流程尽可能使得应用像操作一个数据库一样的操作DRDS用户的专业化指导。

场景广泛:互联网应用,企业内大数据应用,政务类应用,物联网应用。

应用场景

应用的业务需求单机已经无法满足,一个RDS数据库的最大实例也无法满足用户的需求,可能遇到容量瓶颈、事务数瓶颈、读取瓶颈,我们就可以考虑使用分布式数据库了。

Scale out(多机水平扩展),使用廉价数据库阵列来满足用户需求—DRDS

优势:更轻量的使用数据库,未来更换的成本小;一次重构,以后基本再无需担心系统瓶颈。劣势:重构迁移需要付出成本;分布式环境下一些查询会被限制不允许执行;完成相同功能需要比单机扩展付出更多成本。

 

 

                                             图1

理想状态就是Scale out 与scale up结合。如图1所示,让系统架构具备scale out的能力,尽可能提升单机利用率,但不要过早过度设计。

 

                                        图2

何时应该选择Sharding方案?图2中的概要图给出了分析。

DRDS功能介绍

分布式MySQL执行引擎

具有非常高的兼容性,MySQL 5.5 的各类复杂查询都能做到,包括复杂的join,复杂的嵌套,复杂的函数。降低了迁移时候的成本。

智能下推的功能,减少网络传输,减少计算量,充分发挥下层存储的全部能力。

智能下推有两个典型的例子,图3为表A 分库分表3个的例子,图4为全表distinct groupby的执行计划的例子。

 

 

   图3

 4

 

弹性扩展

  自动扩容、缩容是另外一个重要功能。如图5DRDS可以做到原来一个库,下一步变成两个库,依然可以扩,对一些特殊需求也可以实现自动化后台迁移,自动扩容缩容。

  5

小表异步广播

  6

  如图6的跨机join的优势是一致性,空间比较节省。劣势是网络消耗和延迟增加。

  7

7小表广播join的优势是性能高,延迟低,网络消耗小,劣势是最终一致性,小表更新量不能太巨大。

DRDS实践

分布式查询优化

最终的目标是让所有请求可以水平扩展,要想达到这个目的,有两个基本的原则:1尽可能让所有查询发生在尽可能少的下层存储节点上,最好是只发生在一台上。将跨网络请求尽可能减少减少并行查询时的机器消耗。2选择的shardingKey要能够让所有存储节点均衡的负载读写请求。系统可以简单加机器来扩展没有系统瓶颈。案例1如图8所示是一个订单的场景,应该选择哪个列作为切分条件?按照买家ID的查询(买家查看自己买了哪些商品)。

 

    8

案例2如图9所示的过程就是数据的切分,应该选择哪个列作为切分条件?按照买家ID的查询(买家查看自己买了哪些商品);按照卖家ID的查询(卖家查看自己卖了哪些商品。

  9

10表达了异构复制,数据通过后台自动化逻辑复制过去,建立一个新的全表索引。

 10

案例三如图11所示,在原来表里加了type,关联两个表,但这两个表不在一台机器上,遇到这种场景就需要如图12所示的小表异步广播。

  11

  12

 

事务的分布式优化

  事务的分布式优化的目标是完整的事务支持,既要支持ACID,又可按需无限拓展。然而这种模型是不可能实现的。

那么我们该怎么办呢?优化事务的最重要的手段就是从强一致到最终一致。把这种情况拟人化场景为:李雷家住长江头,梅梅家住长江尾,日日思君不见君,送只玫瑰表心意。李雷希望(ACID):花别丢了,送不到给我退回来(原子性,A);花能瞬时送到梅梅家(强一致性和强隔离性,C&I);花别在路上坏了(D)。其中瞬时就是当李雷去检查的时候,要么花在李雷那,要么花在韩梅梅那。

实现方案一:李雷做火车到长江尾,亲手交给了梅梅。方案二:李雷将花交给邮递员邮递员做飞机把花送给韩梅梅李雷电话打了一天,韩梅梅都没接邮递员把花交给韩梅梅韩梅梅接起电话,告诉李雷收到花。方案二就是强一致,它的优势是编程模型简单,不用考虑邮递员运输中的各种并发问题。它的劣势是并发性能低,李雷一天都不用干活了。

真的遇到这种情况时,我们该采用最终一致进行优化,上述情景大体不变,更改为李雷打电话韩梅梅告诉他还没收到,李雷就去做了其他事情。最终一致的优势是无阻塞情况,并发性能好。劣势复杂度略高,需要考虑玫瑰已经发出,但对方还没收到的情况应该如何处理。

  图13展现了单机和分布式事务情况。所以我们建议结合最终一致和强一致,单机可以使用强一致,跨机建议使用最终一致。

  图13

 

 

从单机存储到DRDS迁移流程

迁移的目标是:保证业务线上正常运转;平滑过渡;减少运维。

迁移的步骤有三步:SETP1:读写在原来的单机数据库;数据通过“愚公数据迁移平台”写入云上DRDSSETP2:验证云上数据是否正确;验证云上DRDS是否能够很好的应对读流量压力。SETP3:夜间,停写几分钟;读写切换到DRDS;数据通过“愚公数据迁移平台”写回到云下单机数据库。



                                                                                              PPT下载地址:http://club.alibabatech.org/resource_detail.htm?topicId=156

 

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
阿里数据仓库实践分享
数据仓库,是为企业所有级别的决策制定过程,提供所有类型数据支持的战略集合。它是单个数据存储,出于分析性报告和决策支持目的而创建。为需要业务智能的企业,提供指导业务流程改进、监视时间、成本、质量以及控制。
13574 0
深入理解数据库的分布式事务以及解决方案
1、什么是分布式事务 分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。
621 0
分布式数据库事务故障恢复的原理与实践 | OceanBaseDev
本文根据 OceanBaseDev Meetup#1 上海站分享整理,本次活动针对分布式数据库的分布式事务以及落地实践展开具体分享。
0 0
分布式事务数据库安全技术指南
很多朋友对前段时间“删库跑路”事件应该还记忆犹新吧, 不仅如此近期的数据泄露问题也是从出不穷, 数据库作为企业核心业务系统的基础设施部分更是重中之重, 热璞数据库HotDB 结合企业数十年的技术沉淀以及在实战中的经验,以用户的视角打造的这份安全技术指南,跟各位一起分享: 一:用户管理 数据库应支持用户身份认证,并确保用户标识具有唯一性,且用户的身份认证信息应进行加密存储,宜采用不可逆加密算法; 用户的口令应具有复杂度要求,长度应少于8位,并包含英文字母大小写、特殊字符及阿拉伯数字等组合,且系统运维管理用户应定期修改登陆口令; 宜设置超时时间,登录用户在超时时间内无操作则自动结束会话; 宜及
0 0
阿里巴巴数据库分库分表的实践(2)
阿里巴巴数据库分库分表的实践(2)
0 0
阿里巴巴数据库分库分表的实践(3)
阿里巴巴数据库分库分表的实践(3)
0 0
阿里巴巴数据库分库分表的实践(4)
阿里巴巴数据库分库分表的实践(4)
0 0
+关注
云学习小组
一群热爱技术的朋友们在云栖社区组成的学习小组!
文章
问答
文章排行榜
最热
最新
相关电子书
更多
云原生分布式数据库 PolarDB技术深度解密
立即下载
阿里巴巴云原生实践 15 讲
立即下载
《阿里巴巴云原生实践 15 讲》
立即下载