2019年一从 DRDS 到分布式 POLARDB— 云上分布式关系型数据库的演进；二 DRDS & ADB 携手助力城市公交系统智能化

个人渣记录仅为自己搜索用

已于 2022-05-10 11:40:11 修改

阅读量767

点赞数

文章标签：数据库 database

于 2022-05-10 11:37:15 首次发布

本文链接：https://blog.csdn.net/fei33423/article/details/124684644

版权

从 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 & ADB 携手助力城市公交系统智能化

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

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

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

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

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

如何使用 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引起的糟糕情况。