阿里云知识产权 阿里云drds手册( 三 )


虽然SQL是兼容的,但是分布式SQL执行算法与单机SQL的执行算法却完全不同,原因也很简单,网络通信的延迟比单机内通信的延迟大得多 。举个例子说明一下,我们有份文件要从一张纸A上誊写到另外一张纸B上,单机系统就好比两张纸都在同一个办公室里,而分布式数据库则就像是一张纸在北京,一张纸在杭州 。
自然地,如果两张纸在同一个办公室,因为传输距离近,逐行誊写的效率是可以接受的 带到杭州去处理,明显更简单一些 。这就是分布式数据库特别强调吞吐调优的原因,只要是涉及到跨机的所有查询,都必须尽可能的积攒一批后一起发送,以减少系统延迟提高带来的不良影响 。
按需数据库集群平滑扩缩
DRDS允许应用按需将新的单机存储加入或移出集群,DRDS则能够保证应用在迁移流程中实现不停机扩容缩容 。
图4 DRDS按需进行平滑扩缩
在内部的数据库使用实践中,这个功能的一个最重要应用场景就是双11了 。在双11之前,我们会将大批的机器加入到我们的数据库集群中,抗过了双11,这批机器就会下线 。
当DRDS来到云上,我们发现双11其实不仅仅只影响阿里内部的系统 。在下游的各类电商辅助性系统其实也面对巨大压力 。在双11前5天,网聚宝的熊总就找到我说,担心撑不过双11的流量,怕系统挂 。于是我们就给他介绍了这个自动扩容的功能怎么用,他买了一个月的数据库,挂接在DRDS上 。数据库能力立刻翻倍,轻松抗过了双11,也算是我印象比较深刻的一个案例了 。
因为我们完全无法预测在什么时间点系统会有爆发性的增长,而如果在这时候系统因为技术原因不能使用,就会给整个业务带来毁灭性的影响,风口一旦错过,就追悔莫及了 。我想这就是云计算特别强调可扩展能力的原因吧 。
小表广播
小表广播也是我们在分布式数据库领域内最常用的工具之一,他的核心目的其实都是一个——尽可能让查询只发生在单机 。
让我们用一个例子来说明,小表广播的一般使用场景 。
图5 小表广播场景
图5中,如果我想知道买家id等于0的用户在商城里面买了哪些商品,我们一般会先将这两个表join起来,然后再用where平台名=”商城” and buyerID = 0找到符合要求的数据 。然而这种join的方式,会导致大量的针对左表的网络I/O 。如果要取出的数据量比较大,系统延迟会明显上升 。
这时候,为了提升性能,我们就必须要减少跨机join的网络代价 。我们比较推荐应用做如下处理,将左表复制到右表的每一个库上 。这样,join操作就由分布式join一下变回到本地join,系统的性能就有很大的提升了,如图6所示 。
图6
分布式事务套件
在阿里巴巴的业务体系中存在非常多需要事务类的场景,下单减库存,账务,都是事务场景最集中的部分 。
而我们处理事务的方法却和传统应用处理事务的方案不大一样,我们非常强调事务的最终一致性和异步化 。利用这种方式,能够极大地降低分布式系统中锁持有的时间,从而极大地提升系统性能 。
图7 DRDS分布式事务解决套件
这种处理机制,是我们分布式事务能够以极低成本大量运行的最核心法门 。在DRDS平台内,我们将这些方案产品化,为了DRDS的分布式事务解决套件 。
利用他们,能够让你以比较低的成本,实现低延迟,高吞吐的分布式事务场景 。


以上关于本文的内容,仅作参考!温馨提示:如遇健康、疾病相关的问题,请您及时就医或请专业人士给予相关指导!

「四川龙网」www.sichuanlong.com小编还为您精选了以下内容,希望对您有所帮助: