阿里巴巴分布式数据库服务DRDS研发历程

  • 时间:
  • 浏览:0
  • 来源:大发5分3D_大发5分3D官方

其次针对Join的优化,挑选条件查询数据量少的Join表作为左表(驱动表),降低右表IN查询的次数;在数据量少且变更量少的“广播表”参与的Jion操作,将“广播表”作为驱动表。



单机数据库迁移到分布式数据库要保证的可是我 业务正常运转、平滑过渡、减少运维,整个迁移分为三个白步骤。

单机数据库迁移到DRDS的流程



淘宝DRDS/TDDL是阿里巴巴自主研发的分布式数据库服务。DRDS脱胎于阿里巴巴开源的Cobar分布式数据库引擎,吸收了Cobar核心的Cobar-Proxy源码,实现了一套独立的之类MySQL-Proxy协议的解析端,才能对传入的SQL进行解析和处理,对应用多线程 屏蔽各种繁杂的底层DB拓扑特征,获得单机数据库一样的使用体验,一块儿借鉴了淘宝TDDL富于的分布式数据库实践经验,实现了对分布式Join支持,SUM、MAX、COUNT、AVG等聚合函数支持以及排序等函数支持,通过异构索引、小表广播等处理分布式数据库使用场景下衍生出的一系列问题,最终形成了完整性的分布式数据库方案。

图 5

图 8

分布式事务优化



未来的发展

首先是条件查询优化,DRDS的数据按拆分键进行水平切分,查询中若带上拆分键对于减少SQL在DRDS的执行时间很有意义。查询条件尽量带分库键,就可不才能让DRDS根据分库键的值将查询直接路由到特定的分库,这有有利于处理DRDS做全库扫描。含分库键的条件精度越高,越有有利于提高查询带宽,可是我 能另三个白的优化才能充下发挥分布式架构查询的优势,便于后续查询能力的扩展。

SQL优化是数据库使用和运维的日常操作,分布式数据库针对SQL的优化不仅要考虑磁盘I/O的开销,更要关注网络I/O开销。为了优化SQL执行,其核心的优化思想可是我 减少网络I/O。为此,DRDS会尽量将另三个白DRDS其他层的工作均衡下发到其底层的各个分库(如RDS 等)来做。另三个白就可不才能将另三个白须要走网络的I/O开销转换为单机的磁盘I/O开销,从而提升查询执行带宽。怎么能让,你们歌词 歌词 在使用DRDS时若遇到了慢SQL,则需针对DRDS的特点将适当改写SQL。

智能下核心原则有如下好多个:

数据分片须要挑选三个白分片的拆分纬度,也可是我 数据分布的法律法律法律依据。比如三个白用户订单信息表,不可能 按照订单ID做数据拆分,那末相同订单ID的数据就会被拆分到同三个白数据库存储节点,不可能 按照用户ID做数据拆分,那末同三个白用户的订单就会分布到同三个白数据库存储实例的存储节点。

数据分片

实际业务也总是会面临分布式数据库架构下,数据库事务不可处理出现 跨库执行。跨库事务必然涉及到三个白事务在多个分库上进行事务分支的执行和情况表同步,相比单机事务,分布式跨库事务的吞吐量和延迟会大大增加。而事务涉及的分库越多,事务边界越大,事务的延迟也会相应增加,性能就会出现 线性衰减。

306年另三个白你们歌词 歌词 的核心应用普遍采用Oracle数据库,但随着业务快速发展,淘宝的数据量和访问量急剧增加,数据库出现 严重访问性能问题,意味着着 数据库频繁宕机、业务停滞,即使当时不可能 使用Oracle亚洲最大的RAC集群,单机数据库的扩展能力不可能 达到极限,且须要付出巨大的资金和运维成本,怎么能我应该 们歌词 歌词 基于其他人的实际情况表,逐步过后过后刚开始了了去IOE,研发分布式关系型数据库服务,实现数据库的高扩展和成本可控,目前DRDS不可能 成为你们歌词 歌词 内次责布式数据库的标准,怎么能让对外服务于金融、制造、政府机构、电商、社交等各行业。

DRDS的基础原理可是我 Sharding,也可是我 数据分片。将单机数据库的数据拆分到多个单机数据库上,对外保持逻辑的一致性。后端拆分的数据库为分库,对应的表称为分表,每个分库负责一份数据的读写操作,分散整体访问压力。在系统扩容时,只需水平增加分库数量,并迁移相关数据,即可提高DRDS系统总体容量。

怎么能让分布式SQL引擎主要目标是实现与单机数据库SQL引擎的完整性兼容,实现SQL的智能下推。才能智能分析SQL,解挥发什么SQL可不才能直接下发,什么SQL须要进行优化改造,优化成什么样,以及路由到什么实例节点上执行,充下发挥数据库实例的完整性能力,减少网络之间的数据传输量,最终对不同实例处理后的絮状结果数据进行聚合计算返回给应用调用方。这可是我 分布式SQL引擎的智能下推功能。



当数据表被拆分为多个分库分表时,数据在分库分表的分布规则就固定了。怎么能让通常数据的业务使用场景非常繁杂,不可能 数据的查询纬度和数据拆分分布的规则一致,单条SQL会在三个白分库分表上执行;不可能 数据的查询使用纬度和数据拆分分布的规格不一致,单条SQL就很有不可能 在多个分库分表上执行,出现 跨库查询,跨库查询会增加网络I/O的成本,查询带宽必然下降。

分布式数据库的事务和SQL查询优化的逻辑是一样的原则,尽量让事务在单库中执行,才能在单库中执行,才可不才能在保持事务ACID特征的一块儿,还能线性地扩展事务能力。其他单库事务通常称为“强事务”。

DRDS/TDDL的功能特征

基于以上原则实现的SQL引擎,就可不才能做到服务能力线性扩展。比如三个白简单的AVG操作,对于其他比较初级的分布式数据库模型而言,常见做法是把AVG直接下发到所有的存储节点,另三个白造成的结果可是我 语法兼容,语意不兼容,最终拿到的是错误结果。而DRDS的智能下推引擎,对SQL的语法做充分的语意兼容性适配,针对AVG操作,才能由引擎将逻辑AVG SQL解析优化为SUM和COUNT的SQL怎么能让进行下推,由底层的数据库实例节点完成SUM和COUNT计算,充分利用底层节点的计算能力,在引擎层将各个存储节点的SUM和COUNT结果聚合计算,最终计算出AVG。这可是我 三个白非常典型的案例,在分布式数据库模型下,多数据表的Join操作,归并排序的兼容性非常繁杂,下文会针对典型的场景解析TDDL/DRDS怎么后能 处理分布式场景下的具体问题。

分布式Join和小表广播



图 4

使用场景

图 7

为了保证数据并完整性都是的安全,便于扩容回滚,在路由规格切换完成后,迁移前后的逻辑分库数据还会进行实时同步,直到业务确认后,才可清理原有分库数据。

DRDS的整体架构

淘宝TDDL研发历史和背景

弹性扩展

平滑扩容

对于其他大数据量OLAP的场景,对于单个Server节点的内存资源需求高时,也可通过提升单个Server节点的规格,做到垂直的能力扩展。

DRDS作为分布式数据体系中的数据库服务后边层,未来会适配更多底层存储引擎,在充分利用底存储节点的计算能力的一块儿,优化并完整性都是服务的计算能力,处理OLAP场景,成为才能完整性覆盖OLTP和OLAP以及其他其他数据库服务场景的完备的分布式数据库服务体系。一块儿完备分布式数据库逻辑层的运维支持和分布式强一致事务的支持。

针对LIMIT OFFSET、COUNT句子,DRDS实际SQL执行是依次将OFFSET另三个白的记录数据读取出来,并丢弃,只保留OFFSET另三个白的数据,另三个白当OFFSET非常大时,读取的数据记录数很少,带宽也很低,不可能 OFFSET另三个白的数据读取须要执行絮状的磁盘I/O读取操作。优化法律法律法律依据是将SQL优化为对key的OFFSET读取和IN操作三个白步骤,先读取OFFSET另三个白的记录key,内存中缓存什么key,怎么能让再通过IN查询获取完整性的记录信息,另三个白会大大减少磁盘I/O,带宽提升非常明显。



遇到跨库事务,通常的实践优化法律法律法律依据是通过“最终一致”事务保证事务执行的吞吐量。“最终一致”事务的原理是优先保证核心事务分支的正向执行,怎么能让保存事务后边情况表,其他事务分支异步执行,执行完成后达到最终的事务一致,处理跨库事务时间序列执行阻塞,提升事务吞吐量。如图8所示,事务3和事务5是跨库事务,事务分支先在左边库进行,异步的事务分支在右边分库执行,分别在其他人所在的分库顺序执行,最终达到事务一致性。

图 6

DRDS/TDDL是典型的水平扩展分布式数据库模型,区别于传统单机数据库share anything架构,DRDS/TDDL采用share nothing架构,share nothing架构核心思路利用普通的服务器,将单机数据拆分到底层的多个数据库实例上,通过统一的Proxy集群进行SQL解析优化、路由和结果聚合,对外暴露简单唯一的数据库链接。整体架构如图1所示,所含DRDS服务模块、DRDS管控模块、配置中心、监控运维、数据库服务集群、域名服务模块。

DRDS的分布式架构采用平滑扩容的法律法律法律依据来处理上述问题,通过增加更多的底层数据库实例来完成整体集群扩容。

分布式SQL优化

数据库的扩容是数据库运维的常见操作,当数据库的数据存储容量过低时,传统的单机数据库须要提升单机的存储空间来支持更大的数据写入量,而随着数据量膨胀,同样的SQL查询句子,查询的基础数据量增加必然会降低查询带宽;一块儿随着数据量增加,数据库的访问压力通常也会成倍提升,造成单机数据库连接数到达极限,此时单机数据库就须要通过升级硬件规格,使用磁盘阵列,使用高端的存储介质设备和更高端的小型机服务器来承载数据量和访问量的增加,其他过程会伴随絮状的数据迁移,为了保证数据的一致性通常须要停机数据迁移,对业务影响较大。

扩容过程实际是物理数据迁移的过程,引擎层按照分库迁移后的逻辑先在物理节点上建立新的分库,怎么能让保留三个白时间点进行全量的数据迁移。完成全量迁移后,过后过后刚开始了了基于先前保留的时间点进行增量的数据追赶。当增量数据追赶到两边的数据几乎一致时,对数据库进行瞬时停写,将最后的数据追平,引擎层进行分库逻辑的路由切换,路由规则切换完成后就完成了核心的扩容逻辑,整个切换过程在毫秒级别完成。

多机器用水平扩展模型使用絮状廉价的PC-Server,通过阵列的法律法律法律依据来实现数据库的水平扩容,优势在于成本更低,不可能 不须要淘汰老设备和系统,不须要频繁迁移数据,须要时,只需扩容服务集群规模。

单机扩展模型和硬件资源强绑定,普遍采用升级单机硬件能力的法律法律法律依据,实现数据库服务能力扩展,比如另三个白采用MySQL单机数据库,遇到访问瓶颈时更换磁盘,访问量更高时就须要考虑使用Oracle的商用处理方案、高端的存储设备、高端小型机,也可是我 IOE架构,甚至升级IOE设备,以换取更高的扩展和服务能力,其他过程就会所处设备升级和数据迁移的成本。

来源:51CTO

分布式数据库的数据有规律地存储在多个底层存储实例上,数据物理存储的变化会造成与原生的数据库引擎不兼容,单机数据库所有的数据读取、写入、计算完整性都是单一的物理机上执行,数据情况表维持在单机上,主要的性能消耗在于磁盘的数据读取;而分布式架构下,数据和情况表须要在多个数据库实例之间以及底层实例和Proxy之间进行传输,这会造成网络I/O消耗,而网络I/O对性能造成消耗相较于本地磁盘I/O和本地计算的性能开销而言要大得多。

分布式MySQL执行引擎

图 3

使用分布式多机模型也须要付出一定成本,分布式数据库的架构与单机数据库的逻辑和物理分布所处比较大差异,怎么能让须要将单机数据库的数据迁移到分布式架构模型之下,也可是我 Sharding的数据分片过程,其他过程涉及数据的分布式逻辑设计、数据库迁移和SQL的优化改造,当然其他迁移一次性的,当架构迁移完成另三个白,就不需要再关心数据库扩容和数据迁移问题,不可能 分布式数据库的服务层不可能 集成了扩容功能,架构上支持水平能力扩展。

DRDS通常使用的Join算法基于Nested Loop,对于Join的左右三个白表,首先从Join的左表(驱动表)取出数据,怎么能让将所取出数据中Join列的值装下 去 右表并进行IN查询,从而完成Join过程。怎么能让,Join的左表数据量越少,DRDS对右表做IN查询就次数就越少,不可能 右表的数据量也很少或建有索引,则Join的带宽快一点 。故而在DRDS中,Join驱动表的挑选对于Join的优化非常重要。

分布式引擎的职责所含SQL解析、优化、执行和合并三个白流程,如图4所示。

拆分纬度的挑选非常重要,一般来说要根据实际业务的场景挑选拆分键,总体指导原则是尽量保证每三个白数据库节点的数据量和负载更均衡,单条SQL操作尽量落到单个数据库节点执行,不同SQL的查询落到不同的数据库节点。另三个白可不才能减少多个节点之间的网络传输,保持分布式查询的带宽,均衡负载的一块儿也便于扩展。

而在实际数据库场景中,总是有其他源信息表,数据量较小,更新频度也很低,什么表不需要拆分,之类什么源信息表通常采用单表模式,单表模式下三个白逻辑表的数据统一存储在三个白分库中,通常存储在“0”库,将什么表定义为“小表”,而其他业务数据量大、更新频率高的表仍旧采用分库分表的拆分模式。那什么“小表”和分库分表进行Join时,基于Nested Loop算法的原则,小表作为Join的驱动表会大大减少右表的IN查询次数,一块儿DRDS提供的小表广播功能,通过数据实时克隆qq好友好友,将“小表”的全量数据和增量变更实时克隆qq好友好友到分库分表上,将跨库的Join转化为单机Join操作,减少Server节点的计算,降低数据在多个底层实例之间的传输,Jion的带宽提升会非常明显。

在分布式架构下的多个数据表Jion,不可能 参与Join的多表数据切分纬度不同,数据则按照不同的拆分纬度分散在不同的数据库实例上,Join操作不可能 产生跨多个物理分库的Join,就须要进行多个底层实例的絮状数据传输,SQL的执行带宽就得才能保证,怎么能让要参与Join操作的数据表要尽量保持拆分纬度统一,让Join操作尽量所处在单机上,减少跨库Join。不可能 才能保持拆分纬度的统一,所处跨库Join操作,那末原则可是我 尽量减少Join操作的输出传输。

本文作者:艾乐强

异构索引

通过分布式集群管理模块实现对集群节点的管控。在数据安全和服务可用性方面,通过低效的数据同步系统,实现数据库的扩容和数据库实例的主备数据同步。一块儿依赖实例监控模块和HA模块实现主备的监控和自动化容灾切换。作为性性性性成熟期期期是什么是什么 图片 是什么的分布式数据库产品,TDDL也具备完善的运维管控系统,才能实现分布式数据库多实例之间的配置管理、变更,以及各种数据同步、扩容等任务管理,降低运维成本。



分布式场景下的Join操作和单机不同,单机数据的Jion操作所处在单机上,不所处内部管理网络数据传输。



TDDL/DRDS采用服务和存储分离的架构,DRDS实例服务层通过集群法律法律法律依据部署,由多个服务节点构成三个白服务实例,通过负载均衡以及域名服务对外提供服务,多个服务节点之间无情况表同步,平均负载处理用户请求。服务集群处理能力过低时,可随时扩充服务节点,增加服务处理能力。同样,业务低谷期也可适当降低集群规模,做到弹性的服务能力扩展。

图 2

分布式数据库核心诉求在于处理单机数据库的瓶颈,单机数据库在使用过程中不可处理会遇到数据库容量、连接数、事务数、读性能瓶颈,突破什么瓶颈的并完整性都是通用的处理模型是单机垂直扩展scale up模型和水平扩展scale out模型。

处理其他问题的思路还是分布式数据库的一贯原则,让SQL执行在单库上完成,实际采用的法律法律法律依据可是我 用“空间换带宽”的方案,也可是我 将同一份数据表,冗余存储多份,按照不同的业务使用场景进行拆分,保持拆分纬度和使用纬度统一,而多份数据之间会实时数据克隆qq好友好友以处理数据一致性问题,这可是我 “异构索引”方案。当然异构索引表才能无限制滥用,越多的异构索引表会影响同步带宽,对源数据表造成同步压力。

图 1

平滑扩容的前提是用户须要按照前述的分库分表逻辑,将逻辑数据库拆分为多个物理分库,不同的分库落在不同的底层物理数据库机器上。分库分表的数量通常建议用户预估未来3-5年的数据量增长情况表,按照其他数据量计算总体数据应该拆分为好多个个分库,不可能 单个分库的数据量通常会有三个白建议值,超过其他阈值就会造成单个节点性能下降。有了具体的分库数量后,就可不才能按照分库的逻辑将数据拆分到不同的存储实例节点上,当承载分库的物理数据库机器出现 容量和连接数过低等瓶颈问题时,就可不才能新增物理数据库节点,将原有的分库迁移到新的物理数据库节点上,实现整体逻辑数据库的扩容。

整个扩容过程对上层的业务访问几乎无感知,是完整性平滑的扩容,但仍需注意扩容的操作尽量挑选在数据库访问,尤其是写入的低谷期进行,处理切换时越多的数据追赶时间。

异构索引是DRDS提升分布式查询带宽的处理方案之一,才能处理分布式场景下数据拆分纬度和数据查询使用纬度不一致意味着着 的低效问题。

最佳实践