云栖干货回顾 |“顶级玩家”集结！分布式数据库专场精华解读

本专场是阿里云分布式数据库的年度盛会，多位阿里云分布式数据库领域核心专家以及业界专家进行了专题演讲，内容涵盖分布式 POLARDB（DRDS）、AnalyticDB、OceanBase 多款云上核心分布式数据库产品，涉猎分布式 SQL 引擎、分布式存储引擎、分布式事务等多个方向。

从 DRDS 到分布式 POLARDB—— 云上分布式关系型数据库的演进

阿里云智能数据库产品事业部高级技术专家君瑜为你们分享了DRDS的演进之路。

DRDS设计理念

DRDS诞生于2008年淘宝“去IOE”时代，过去的十多年中，DRDS经历了每一年的“双11”并发挥了重要做用。5年前，DRDS正式商用，目前服务了无数企业的核心应用。

对于任何一个产品而言，它的出现以及能力的变化都与其面向的业务相关。对于DRDS而言，能够粗略地把业务场景分为3类。第一类是DRDS从一开始出现就在解决的面向最终消费者的高并发业务数据库的需求，这也是DRDS可以很好解决的场景。第二种场景就是DRDS上云提供服务以后遇到的企业级数据库需求，它但愿数据库具备综合负载能力、可持续运维和7*24小时稳定性以及并发、计算和存储的扩展性。

现在，解决上述某几个问题的数据库大体可分为三类：

• DRDS以及Sharding On MySQL数据库，主要基于MySQL和分布式计算能力，使得计算存储高度可扩展，风险可控。
• NewSQL数据库，核心特色就是存储与计算分离。
  Cloud Native DB，强调存储可扩展以及全兼容的能力。
• 而经过并发控制、分布式、容灾以及计算这四个维度可以更加深刻剖析数据库能力。
  

目前分布式数据库领域，HTAP很是火，但又太宽泛了。OLAP和OLTP都能作到HTAP，但二者侧重点却不一样。因此DRDS的目标设定为OLTP optional Analysis，即具备稳定的OLTP能力，还能够逐层向外延伸技术能力。

DRDS产品与内核

下图是DRDS的全景图，左边是数据服务部分，右边是产品能力和工具。DRDS以分布式SQL引擎为抓手，并对数据引擎进行了“谨慎”又“大胆”的探索，经过产品、工具和服务构建了商业形态。在产品层面则提供了稳定性、可扩展性、持续可运维和安全可控四个特性。

DRDSOn MySQL实现得很好，但在存储方面则让人“既爱又恨”。所以，在POLARDB上线后的第一时间，阿里云就实现了DRDS On POLARDB。DRDS和POLARDB二者的布局不一样，POLARDB层面侧重一写多读的能力，DRDS层面则侧重事务扩展性。DRDS On POLARDB解决了数据倾斜、主备数据以及RDS数据能力的问题，所以相对比较稳定而且具备面向将来的一些特性。

DRDS标准数据库内核的发展经历了从超高并发用户侧服务逐步转向了企业级应用场景的转变。发生这样转变的驱动力也有三个，即业务场景、经典数据库理论以及Benchmark。DRDS标准数据库内核很是注重分布式的能力，好比OLTP极致算子Pushdown能力、分区键精确裁剪、多种拆分方式、统一架构的2PC和XA分布式事务、全局强一致二级索引、MPP执行引擎技术、OLTP查询加速等。

如何使用 DRDS 支撑超大规模在线核心 OLTP 业务

快狗视频、米读极速版技术负责人吴雄杰为你们分享了米读如何基于DRDS支撑超大规模在线核心OLTP业务。

百分百分成活动的需求和背景

百分百分成活动的目的在于提升日活，活动规则是每日凌晨0点，根据用户昨日阅读有效时长与大盘总时长占比对用户进行分成，看越多分越多。用户只要参与阅读便可获分成资格，要求0点开始实时发放。活动的特色主要有三个：实时性要求高，金币发放量大，写并发高，以及要求高可靠性和强一致性事务能力。

RDS解决方案及痛点

米读在一周内紧急制定了基于RDS的解决方案，该方案基于单读写的RDS实例，并在后面根据用户ID作了分表，该方案上线后当晚就挂掉了。这是由于该方案存在几个很是明显的问题，首先读写并发存在明显瓶颈，没法知足增加需求；其次架构升级能力较差，没法实现升级的无缝衔接；再次，使用和维护成本较高；最后，单实例不具有故障迁移能力，点影响面。

DRDS调研及解决方案

针对于这些痛点，米读团队进行调研后发现DRDS具有符合米读需求的6种主要能力，即强扩展能力、强数据迁移能力、高使用效率、强兼容性、全局惟一ID以及支持链接池。

所以，米读基于DRDS设计了解决方案。业务层中有帐户、金币和好友邀请系统，DB层部署了4个DRDS，每两个DRDS组成“主实例-只读实例”组，每一个功能模块对应一组DRDS，DRDS下面再挂载RDS，这样就将压力分散开来。

对DRDS的将来指望

但愿将来DRDS可以支持读写分离智能切换，而不是业务方本身去建立主实例和只读实例。但愿DRDS可以实现分区表建立的工具化，提高效率。最后但愿DRDS可以进一步提高全局扫描效率问题。

AnalyticDB 海量数据极速分析背后的分布式计算技术解读

阿里云智能数据库产品事业部资深技术专家陈哲为你们解读了AnalyticDB背后的分布式技术。

从历史的演进角度来看，10年前尚未出现大数据的时候，人们使用数据库对数据作一些基本的分析。而当数据库中的数据量增大到必定体量以后出现了瓶颈，此时就出现了Hadoop体系，它帮咱们度过了数据急速膨胀的过程。而现在，Hadoop原生体系出现了必定下滑，其背后是传统的离线数仓已经跟不上业务发展的须要了。业务发展正在经历从大数据向快数据的转变。

上图右侧是AnalyticDB模型图，存储引擎层实现了高性能的适配，可以为不一样的用户带来不一样的体验。总体经过Raft保证高可用，底层存储使用了行列混存。计算引擎层面，可以瞬间弹性扩展至最多2000个Worker，可以提供大规模ETL能力，并可以使用阿里巴巴最新硬件的加速能力。最上层是Multi-Master节点，可以支持弹性扩展。

AnalyticDB采用了MPP+DAG融合模型的执行引擎，这里展开介绍一下。传统MPP模型以Greenplum为表明，Greenplum每一个节点收到的执行计划都是同样的，这样的优势在于能够高效地利用本地存储去打通并作快速计算，可是若是Greenplum超过500个实例的规模，性能就会直线降低。所以，在AnalyticDB里面分为了MPP和DAG模型，可以根据对SQL的判断使用不一样的模型。在执行内部则是Pipeline模型。对于混合负载而言，若是研发写了一个很是糟糕的SQL就会拖慢总体运行速度，所以AnalyticDB作了时间片轮转执行，大大减小了由于慢SQL引发的糟糕状况。

总体的执行过程分为三部分，Pipeline面对的是低延时、高QPS，Stage By Stage面对复杂SQL、高吞吐，统一Runtime支持Operator，而且总体模型是multi-batch结构。

2019年5月份，AnalyticDB经过了TPC的测试，在全部的性能指标方面都排名第一。此外，在Gartner中，AnalyticDB处于Niche Player的角色，并在走向领先的过程中。

DRDS & ADB 携手助力城市公交系统智能化

北京启迪公交科技首席技术专家殷悦为你们分享了如何基于阿里云产品实现城市公交系统智能化。

北京启迪公交科技股份有限公司的主要业务是基于北京公交集团的人、车、场地等资源和数据资源进行数据开发，以提供丰富多样的信息服务以及出行服务。从2018年6月至今，启迪主要作的事情就是北京公交的扫码乘车。北京的状况与其余城市不一样，乘客上、下车时都须要扫码，相似地铁的计费方式但更加复杂。而北京公交是全球最大的单体公交公司，内部组织结构极为复杂，而且北京公交业务自己和特征也很是复杂。所以，启迪的业务须要适配各类特征。

想要改变业务首先要理解业务，理解业务的第一步就是感知全部信息。智慧公交感知网络会利用物联网平台将车载设备产生的数据统一接入数据中心，并利用数据中心作在线交易和大数据分析，这部分就会涉及到DRDS、ADB和TSDB的使用。首先要完成交易类型的工做，其次才能够对数据进行高实时性的分析。只有把服务元素信息集合到一块儿以后，才能进行综合式分析和业务洞察。须要构建服务元素之间的关联性，利用关联性了解业务情况，最终推进产品形态的创新。从而更好地匹配客户需求和服务供给，进而提高企业效益。

启迪目前运营车辆达24000辆，日支付行为达1600万，每秒支付峰值达1500，车载POS日设备心跳上报达到8900万条。交易处理方面，经普遍评估，启迪选择了阿里云DRDS，这是由于DRDS拥有通过阿里“双11”验证过的能力，而且具备极致的拓展能力和完善管控能力。

启迪之因此选择阿里云的产品来实现业务目标，是由于更但愿将主要精力放在业务层面，而不是基础设施上。阿里云产品提供了成熟的技术、开箱即用的能力和完整的生态，所以可以帮助启迪实现数据上云驱动将来公交。

分布式关系型数据库服务DRDS 新一代内核技术揭秘

阿里云智能数据库产品事业部高级技术专家，分布式数据库服务DRDS内核技术负责人楼江航为你们揭秘了DRDS 新一代内核技术。

DRDS总体介绍

DRDS采用的是基于MySQL的Share Nothing分库分表架构，是典型的存储与计算分离的模式。存储层依赖于MySQL，而且在阿里云上具备高可用性保障和扩容能力。计算层是无状态的，基于SLB可以实现较好的扩展性。结合以上两点，解决了MySQL存储计算的能力问题。

以下是DRDS内核架构的细节图。总体来看，DRDS内核能够分为MySQL网络接入层、解析层、优化层、计划层和执行器层。从右侧细节能够看出，DRDS内核相似于MySQL的SQL引擎的实现。总结而言，DRDS内核是面向关系代数的SQL引擎。

内核技术关键点

(1)关系代数

前面提到RDS内核是面向关系代数的SQL引擎，那么什么是关系代数呢？其实and、or、join都叫作关系代数，针对于一样想要的结果可能有不一样的SQL写法，这就涉及到关系代数了。数据库优化器所作的事情就是基于当前计算能力选择更加好的执行逻辑。业界通过4、五十年的发展，在关系代数方面也有很是深厚的沉淀。

SQL进入DRDS以后会首先进入解析器会转成AST，AST通过Validator会返回对应的表是否具备权限以及表列关系是否合理，以后转成关系算子树，也是优化器主要工做的对象。优化器会结合统计信息和RBO和CBO的一些优化将其转成物理执行计划。物理执行计划包含所需的数据存储位置，以及访问的串并行特征等。DRDS会经过SQL与MySQL进行交互，也会经过RPC与NewSQL进行交互。

(2)DRDS优化器设计

DRDS的优化是RBO+CBO两阶段的过程。RBO是面向规则的启发式处理方式，CBO则是基于统计信息进行智能决策。DRDS基于MySQL Sharding的架构，具备分片的特征同时具备存储与计算分离以后网络所带来的开销。所以，DRDS优化器会引入Partition-Aware的思路来解决由于分片和网络所带来的需求。随着上云过程当中，用户对复杂SQL的需求愈来愈强烈，DRDS在HTAPWorkload里面也作了大量的优化。此外，DRDS优化器总体采用了Volcano/Cascades风格。

RBO方面，SQL Writer引入了Rule的核心理念，实现了最小原子化以及编排和分组。在算子下推方面，在DRDS里面为了屏蔽用户对物理表的感知就引入了逻辑表，并引入了LogicalView算子节点来替换TableScan，LogicalView包含对MySQL多张物理表的访问，这样就将算子下推变成了LogicalView如何和现有的运算符作关系代数的转化。

CBO方面会有统计信息的概念，除此以外会将Rule评估变成优先队列，使得在有限时间内作出尽量多的优化。统计信息整体能够分为三层，底层叶子节点表明数据表的统计信息，分支节点是Cardinality的估算，再上一层就是Cost模型。CBO中另一个重要能力就是Join Reorder，这是针对复杂SQL所必须的能力。

(3) DRDS执行器设计

DRDS的事务处理是基于MySQL 5.7的XA实现的，并在常规的2PC的事务管理基础之上作了优化，作了2PC事务减枝。索引是用空间换时间的解决方案，DRDS有了分布式事务的加持以后，会在用户写主表的同时，根据分布式事务默认地更新索引表，保证主表和索引表之间的数据一致性，其次会在执行SQL的时候基于代价在查询主表和查询索引中进行选择。此外，还引入了Online DDL，可以支持COVERING语法。而对于全局索引而言，自己也有必定代价，因此也须要进行控制。随着用户对于复杂查询的诉求愈来愈强烈，DRDS也在内核层面支持了Parallel Query的能力。

总结和展望

不管是NewSQL仍是Sharding，其都要解决分布式中的四个主要问题，便可靠的存储、分布式事务、分布式查询以及GMS元数据。针对存储而言，DRDS依赖于MySQL，而MySQL自90年代至今在TP领域深耕近30年，拥有良好的背书。而DRDS在分布式事务、分布式查询以及GMS元数据方面都是构建在通过4、五十年的工程和理论基础之上的。在早期，DRDS对外呈现的更可能是以中间件形态，而通过多年的沉淀和积累，DRDS已经在按照标准数据库内核从新定义Sharding技术了。

传统数据库架构和基于DRDS架构分享

汇付天下资深数据库DBA赵怀刚为你们分享了如何从传统数据库转向DRDS架构。

为何从传统数据库转向DRDS

传统关系型数据库已经发展通过了40多年，其在企业级特性、执行效率、数据库生态及资源层面已经很是成熟。可是关系型数据库在设计之初并无考虑扩展性。所以，当使用传统关系型数据库遇到以上问题以后通常会进行垂直升级，增长资源配置，用更强的硬件能够在必定的时间内可以提高数据库的容量和性能，但不能解决全部的业务场景，而且成本很是昂贵。

相比传统数据库，DRDS在水平扩展和成本方面具备明显优点，但在可维护性方面较为复杂。DRDS现在已经可以提供数据生命周期管理、多种存储类型、多可用区、SQL审计以及数据恢复等企业级数据库特性。

DRDS应用实践探索

DRDS很是重要，所以在应用以前作了压力测试、功能测试、稳定性测试以及业务验证。通过测试发现DRDS在响应时间、吞吐量等指标上的表现很好，在业务验证时将一些试点项目接入到DRDS上并不断总结经验，造成规范并完善架构。通过长时间的测试验证，发现DRDS更加适合混合顺序写密集场景如订单、日志、流水等数据。

验证完成以后就着手进行迁移，这个过程分为了数据迁移和流量迁移两部分。数据迁移完成以后须要作一致性校验，以后再进行流量迁移。

DRDS提供了两种类型的只读实例，即分析型和并发型，能够根据不一样的场景进行选择。总体架构也会遇到一些问题，好比在不断发展过程当中须要对实例规格进行不断升级，升级过程当中可能会存在30秒闪断，底层存储节点升级会致使DRDS集群不可用。这些问题对于7×24小时的业务而言依旧不够友好，所以对于架构进行了改进。将单个DRDS集群拆分红多个，经过智能网关作流量转发、负载均衡，将流量路由到不一样的DRDS集群。

分布式数据库设计原则建议

在作分库分表以前，须要按照业务模型对交易型数据进行简单划分，能够将数据划分为流水型、状态型、配置型。流水型数据量大而且相对独立，适合水平分片表。状态型数据带有状态而且生命周期长，适合垂直分片表。配置型数据量比较小，而且是读多写少，所以适合全局广播表。作分库分表拆分的时候有三点原则，即拆分字段要有固定性、分离性和伸缩性。分库分表的设计最终是为了达到线性扩展的目标，能够根据逻辑QPS和物理QPS的比值是否接近1来判断。

分布式数据库DRDS核心诉求有三点，即透明可扩展、强大的HTAP能力以及全面支持在线DDL。

深刻解读 OceanBase企业级数据库的分布式技术
蚂蚁金服OceanBase 资深技术专家韩富晟为你们深度解读了OceanBase背后的分布式技术。

金融科技的基础设施

数据库行业正在经历从传统数据库向分布式数据库迁移的过程。分布式数据库理论早在上世纪80年代就已经提出，通过30年的发展逐步被应用各个行业中。如今和过去的不一样在于，之前数据库以硬件为中心，而现在数据中心出现了大量标准化的廉价服务器，数据库正在转变为以软件为中心，这致使架构选择和输出方式的不一样。

而在将来，分布式数据库必定会成为各个金融以及非金融机构的选择，也但愿OceanBase可以在这一过程当中帮助企业解决更多的问题。

OceanBase新版本特性

目前，OceanBase 2.2版本即将对外发布，该版本在Oracle兼容性、事务处理能力以及性能方面都有了较大程度的提高。OceanBase 2.2版本实现了Oracle经常使用数据类型的全兼容，对于各类函数、表达式、视图、字典、存储过程以及部分系统包都可以支持。减小了迁移过程当中的再次开发工做，能够甚至作到无缝迁移。

分区管理是大数据量或者长期数据管理过程当中一个很重要的功能。OceanBase依赖分区能力在分布式系统作数据扩展，它彻底继承了Oracle等数据库的分区方式，本次新增的功能能够帮助企业更加方便地管理分区数据。

OceanBase2.2版本提供了新的SQL计划管理能力，当SQL已经生成的计划发生变动的时候能够以灰度可验证的方式进行变动，只有表现比原有计划更优秀时才会实现计划变动，以保证业务的稳定性。

OceanBase2.2提供了更加完善的分布式事务支持能力，如可串行化隔离级别的能力、savepoin/rollback to以及外键约束等。

OceanBase 2.2在性能方面也有长足的进步，OLTP业务性能最高可以提高50%，OLAP业务性能最高能提高100%。在今年的“双11”， OceanBase将帮助蚂蚁金服节省约50%的机器资源。此外，OceanBase 2.2还提供了等保三级的安全能力，并可以支持更多的字符集以及窗口函数等。

在服务企业数据库的过程当中，OceanBase从最开始自主研发到如今已通过走了9年时间，相较于Oracle、DB2，OceanBase还很年轻，可是有信心能够帮助企业更好地解决业务问题，实现从传统数据库架构向分布式数据库架构的转型。

分布式存储引擎X-Engine 的探索之路

阿里云智能数据库产品事业部高级技术专家王剑英为你们介绍了分布式存储引擎 X-Engine 的探索之路。

阿里巴巴的技术挑战

阿里巴巴体量很是大，每一年双11面量的流量洪峰更大，双11当天的销售额会达到平时的数十倍，而且在零点那一刻积蓄了大量的流量，会达到平时的100倍以上，此时数据库面对的巨大压力。这也是阿里巴巴从Oracle转向MySQL以及后续的RDS和DRDS的缘由。虽然能够不停地扩展拆库，将流量切散，但最终仍是要提高单机的能力。所以，阿里作单机数据库引擎的动机就是解决流量洪峰的负载问题。此外，由于阿里的体量巨大，因此会产生大量的数据积累，所以须要更方便地快速读取索引，这也是一个巨大的挑战。

并且阿里的淘宝、天猫等业务的交易数据访问频次也有明显的特征，订单的大量访问出如今交易后的两三天内，大部分订单在7天以后将再也不被访问，若是将冷热数据混合一块儿将不利于性能提高和服务器资源的使用。综上所述，阿里巴巴面对着巨大流量洪峰和巨大数据量的挑战。

X-Engine引擎的技术特色

以前AliSQL使用InnoDB引擎，而InnoDB存在扩展性瓶颈。X-Engine引擎则采用了LSM-Tree架构，并进行了创新。在架构最上层提供了高度并发的事务处理流水线，中间实现了无锁内存表Memtable。此外，为了解决读写冲突，X-Engine将每一个Meta信息做为一个独立版本。X-Engine对于磁盘存储层也进行了总体重构，而且还引入了FPGA做为硬件加速器。

X-Engine从新设计了事务提交的流程，在事务提交的时候为了避免让太多的线程等待，会开辟一组等待队列，事务会在队列中抢夺成为Leader，借此消减请求。X-Engine还实现了多阶段流水线，在Log Buffering和Log Flushing中间设置检测变量，所以不存在等待。磁盘延迟很高可是吞吐很大，可让整个流水线流动起来。这样就保证事务提交执行过程之中的每一步都没有等待和睡眠唤醒过程，使得系统吞吐量很是高。

X-Engine在数据结构方面也作了一些创新，在内存索引方面实现了多版本的Memtable来存储新增长的数据。此外，还对于Block Cache的结构进行了优化，下降了缓存失效率。而且为了使得对于热点数据读取更快，X-Engine还增长了Row Cache，提升了热点行的查询性能。

依靠前面提到对X-Engine的改造，和RocksDB进行性能对比效果以下所示，能够看出X-Engine具备较大的性能提高。

在作Slimming Compactions时存在两个约束，CPU资源和IO消耗。为了解决上述问题，X-Engine将Extent分为四种类型，即Merge、Reuse、Split和Copy，这样可以在很大程度上缓解Compactions的压力。

分析数据发现CPU上有不少很短的二级索引，在单机存储里面效果很差，因而X-Engine引入了新硬件FPGA。正常状况下，计算资源会在前台的用户处理和后台的Compactions之间分配，增长了FPGA以后，后台任务所有交由FPGA处理，而解析、事务执行、加锁等任务所有交给前台线程。这样就不存在后台扰动，进而避免了性能抖动，从而提供了稳定的性能。

RDS MySQL (X-Engine)服务

X-Engine引擎默认集成在RDS 8.0版本中的，其属于和InnoDB同等的引擎，只须要在建立表时指定便可。X-Engine属于事务存储引擎，优势在于节省空间、更好的写入性能以及冷热数据分离。对比而言，InnoDB具备较好的Range Scan性能以及更好的兼容性。

X-Engine可以节省空间，在Link-Bench以及淘宝、天猫交易订单库数据库的对比下，相比InnoDB可以节省3到5倍空间。在阿里巴巴内部，使用RDS X-Engine，淘宝交易信息、钉钉消息信息以及图片空间的Meta信息分别节省了67%、84%和86%的存储空间。由于LSM-Tree是写优化的，所以RDS X-Engine可以得到极好的写性能，不只单线程比InnoDB表现更好，在多线程场景下也具备更好的表现。

POLARDB MySQL (X-Engine)服务

X-Engine除了在公有云上提供服务，将来也会走向私有云。X-Engine会接入到POLARDB的Share Everything架构中来，得到存储空间的动态扩展能力，而且方便在与全局数据不冲突的只读节点上进行数据分析。X-Engine和POLARDB结合以后，将会更好地利用FPGA等资源。

本文做者：Roin123

原文连接

本文为云栖社区原创内容，未经容许不得转载。