本专场是阿里云分布式数据库的年度盛会，多位阿里云分布式数据库领域核心专家以及业界专家进行了专题演讲，内容涵盖分布式 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写法，这就涉及到关系代数了。数据库优化器所做的事情就是基于当前计算能力选择更加好的执行逻辑。业界经过四、五十年的发展，在关系代数方面也有非常深厚的沉淀。
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元数据方面都是构建在经过四、五十年的工程和理论基础之上的。在早期，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等资源。
