PolarDB-X 2.0:使用一个透明的分布式数据库是一种什么体验

PHP守护者
• 阅读 3542

简介: 透明分布式,是PolarDB-X即将发布的能力,它能让应用在使用PolarDB-X的过程中,犹如使用单机数据库一般的体验。与传统的中间件类型的“分布式数据库”相比,有了透明分布式能力的PolarDB-X,不再需要应用考虑分区键的概念,应用可以完全将单机MySQL上开发的建表语句、应用代码直接迁移到PolarDB-X上运行起来。本文将为大家介绍PolarDB-X透明分布式的新体验。

透明分布式,是PolarDB-X即将发布的能力,它能让应用在使用PolarDB-X的过程中,犹如使用单机数据库一般的体验。

与传统的中间件类型的“分布式数据库”相比,有了透明分布式能力的PolarDB-X,不再需要应用考虑分区键的概念,应用可以完全将单机MySQL上开发的建表语句、应用代码直接迁移到PolarDB-X上运行起来。

本文将为大家介绍PolarDB-X透明分布式的新体验。

在PolarDB-X上安装一个WordPress

WordPress是一个开源的博客软件,它使用MySQL作为其数据库。操作是在PolarDB-X上安装一个WordPress,来体验PolarDB-X的透明分布式能力。

我们将遵循简单的三步走:

  1. 不修改DDL直接建表
  2. 不修改应用直接跑起来
  3. 做下压测,做下调优

总结如下:

  • 使用官方的WordPress镜像,不做任何修改,其安装程序就能自动的在PolarDB-X上完成建表、数据初始化等工作,其使用的都是标准的MySQL语法。
  • 对此WordPress进行压测,PolarDB-X的各项监控数据显示,各节点处于的负载、数据量均处于均衡的状态。
  • 通过PolarDB-X提供的SQL分析、DAS等工具,可以方便的找到系统中热点SQL。
  • DBA可以直接通过创建索引、修改数据分布等DDL语句对系统性能做进一步的优化,不需要修改应用。

PolarDB-X实现透明分布式的武器

下面为大家分享下,PolarDB-X是如何实现透明分布式的。

透明数据分区

PolarDB-X是一个典型的Share Nothing的分布式数据库,其简化架构如下:

PolarDB-X 2.0:使用一个透明的分布式数据库是一种什么体验

其核心组件为无状态的计算节点CN,与有状态的存储节点DN。

要了解PolarDB-X的透明分布式能力,首先要了解数据在PolarDB-X上是如何分布的。

在PolarDB-X中,一个表由多个索引组成,包括主键、二级索引等。PolarDB-X会对每个索引进行独立的进行分区,其分区键为索引的key。

例如一个典型的电商场景,订单表,拥有一个主键(id),两个索引(seller_id与buyer_id):

create table orders (
   id bigint, 
   buyer_id varchar comment '买家', 
   seller_id varchar comment '卖家',
   primary key(id),
   index sdx(seller_id),
   index bdx(buyer_id)
)
  • 对于主键索引,会按照id对其进行分区
  • 对于索引sdx,会按照seller_id进行分区
  • 对于索引bdx,会按照buyer_id进行分区

如下图所示:

PolarDB-X 2.0:使用一个透明的分布式数据库是一种什么体验

对索引进行分片之后,PolarDB-X会将这些分片打散到不同的存储节点里,并会按照数据量等信息进行负载均衡,如下图所示:

PolarDB-X 2.0:使用一个透明的分布式数据库是一种什么体验

在PolarDB-X中,建表语句中可以不考虑分区键,PolarDB-X也能自动的对表进行分片与负载均衡。

因此,应用迁移PolarDB-X时,可以将单机MySQL中的建表语句导出,不需要修改直接在PolarDB-X中执行即可。

透明的分布式事务

分布式事务是PolarDB-X中的最重要的基础能力,它广泛的应用于业务内,避免了业务对事务代码进行改造;同时,PolarDB-X内部也用事务来实现索引。

PolarDB-X的分布式事务有以下几个特征:

  1. 与Spanner一样,满足外部一致性这种最强的一致性级别
  2. 语法与MySQL完全兼容,无需对应用进行改造
  3. 行为上支持兼容MySQL的RC与RR级别

PolarDB-X 2.0:使用一个透明的分布式数据库是一种什么体验

Online DDL

PolarDB-X支持类型丰富的Online DDL,这里介绍一些有代表性的DDL类型。

索引维护

与单机MySQL的索引有所差异,PolarDB-X的索引均为全局索引,包含以下几种类型:

  • 普通索引
  • 唯一索引
  • 聚簇索引

其中聚簇索引是PolarDB-X相对于MySQL的一种新类型的索引,它会包含表中的所有列,从而避免了回表的代价。

PolarDB-X中对索引的创建都通过DDL来完成,并且都是Online的,不会阻塞业务。

例如:

创建一个普通的索引:CREATE INDEX idx1 ON t1(name)
创建一个聚簇的索引:CREATE CLUSTERED INDEX idx1 ON t1(name)

INSTANT ADD COLUMN

加列操作是业务中最为常见的DDL类型。在MySQL中,加列操作的耗时是与数据量相关的(MySQL8.0中在表的最后面加列是INSTANT的)。

在PolarDB-X中,在任意位置加列都是INSTANT的,这个代表加列操作为恒定的秒级耗时,与数据量无关,不会对业务产生任何影响。

分区调整

PolarDB-X支持4种表的分布策略,Hash、Range、List、Broadcast。由于Hash能避免连续写入的热点,PolarDB-X默认使用Hash策略,大多数情况下,此策略能够很好的满足系统的性能需要。

但是如果业务在运行期间,希望选择合适的分区策略来提升系统性能,在PolarDB-X中可以方便的通过DDL语句进行调整,PolarDB-X会按照新的分区策略重新组织表的数据。

例如:

  • 修改表的分区策略为Hash:ALTER TABLE t1 PARTITION BY HASH(name)
  • 修改表的分片数为32:ALTER TABLE t1 PARTITION BY HASH(name) PARTITIONS 32
  • 将表变为广播表:ALTER TABLE t1 BROADCAST
  • 修改表的分区策略为RANGE:ALTER TABLE t1 PARTITION BY RANGE(id)

任意两种分区策略之间都可以通过DDL语句进行转换:

PolarDB-X 2.0:使用一个透明的分布式数据库是一种什么体验

回填速度自适应

想必很多同学有过这样的经验:一个超大的表进行DDL操作,由于数据量比较大,这个DDL操作无法在一天内完成,为了避免对业务影响,人肉在白天业务高峰期来临的时候,调整参数,降低DDL的回填速度,晚上在业务高峰期结束后,提高DDL的回填速度。

PolarDB-X中的回填,会根据当前的系统负载,自动调节速度。

例如:

PolarDB-X 2.0:使用一个透明的分布式数据库是一种什么体验

PolarDB-X 2.0:使用一个透明的分布式数据库是一种什么体验

在这个例子中,分了四个阶段:

  1. 开始没有业务负载,DDL回填速度上升到25W行/s
  2. 业务负载开始上升,DDL回填速度迅速下降到13W行/s
  3. 业务TPS稳定在1W5,DDL回填速度稳定在13W行/s
  4. DDL结束后,业务TPS稳定在1W6

从这个例子中,我们可以看到PolarDB-X DDL的回填速度会自动根据业务负载进行调整,并且DDL期间,对业务的TPS影响很小。

让Online更Online

为了进一步减少DDL期间对业务的影响,PolarDB-X还使用了多项技术,例如:

我们会在今后的文章里详细介绍这些技术的细节。

总结

PolarDB-X的透明分布式能力,将极大的减少应用从单机数据库迁移分布式数据库的成本。同时,我们未来也会让它变得更透明,我们正在做的一些事情包括:

  • 更精细的调度策略
  • 热点数据的可视化展示,与SQL审计分析联动的智能诊断
  • 在有全局索引的情况下,支持分区级的truncate
  • 数据的按时间滚动、清理
  • 等等

原文链接
本文为阿里云原创内容,未经允许不得转载。

点赞
收藏
评论区
推荐文章
美凌格栋栋酱 美凌格栋栋酱
6个月前
Oracle 分组与拼接字符串同时使用
SELECTT.,ROWNUMIDFROM(SELECTT.EMPLID,T.NAME,T.BU,T.REALDEPART,T.FORMATDATE,SUM(T.S0)S0,MAX(UPDATETIME)CREATETIME,LISTAGG(TOCHAR(
Jacquelyn38 Jacquelyn38
4年前
2020年前端实用代码段,为你的工作保驾护航
有空的时候,自己总结了几个代码段,在开发中也经常使用,谢谢。1、使用解构获取json数据let jsonData  id: 1,status: "OK",data: 'a', 'b';let  id, status, data: number   jsonData;console.log(id, status, number )
赵亦华 赵亦华
2年前
你必须知道的国产数据库-阿里数据库oceanbase
众所周知,虽然原生分布式数据库有着各种先天优势,但是在落地的过程中也面临着两方面的挑战:一方面,在大家的印象中,原生分布式数据库主要适用于大型企业或者大型应用场景,而小型企业使用单机更具性价比。但是一旦部署了单机,如果后续业务量巨大,再进行架构调整,会进一步增加部署的难度。
Wesley13 Wesley13
3年前
1、ShardingSphere基本概念
1基本概念什么是ShardingSphere1)一套开源的分布式数据库中间件解决方案2)有三个产品:ShardingSphereJDBC、ShardingSphereProxy、ShardingSphereSidecar3)定位为关系型数据库中间件,合理在分布式环境下使用关系型数据库
Stella981 Stella981
3年前
Nginx + lua +[memcached,redis]
精品案例1、Nginxluamemcached,redis实现网站灰度发布2、分库分表/基于Leaf组件实现的全球唯一ID(非UUID)3、Redis独立数据监控,实现订单超时操作/MQ死信操作SelectPollEpollReactor模型4、分布式任务调试Quartz应用
Wesley13 Wesley13
3年前
mysql中时间比较的实现
MySql中时间比较的实现unix\_timestamp()unix\_timestamp函数可以接受一个参数,也可以不使用参数。它的返回值是一个无符号的整数。不使用参数,它返回自1970年1月1日0时0分0秒到现在所经过的秒数,如果使用参数,参数的类型为时间类型或者时间类型的字符串表示,则是从1970010100:00:0
Easter79 Easter79
3年前
Twitter的分布式自增ID算法snowflake (Java版)
概述分布式系统中,有一些需要使用全局唯一ID的场景,这种时候为了防止ID冲突可以使用36位的UUID,但是UUID有一些缺点,首先他相对比较长,另外UUID一般是无序的。有些时候我们希望能使用一种简单一些的ID,并且希望ID能够按照时间有序生成。而twitter的snowflake解决了这种需求,最初Twitter把存储系统从MySQL迁移
Easter79 Easter79
3年前
TiDB 4.0 为解决热点问题做了哪些改进?
作者:李坤热点问题概述一直以来,TiDB的数据访问热点问题,是用户比较关注的问题。为什么这个问题如此突出呢?这其实是“分布式”带来的结构效应。单机数据库由于只有一个节点,是不存在热点问题的(因为性能的上限就是单机的处理能力),而分布式数据库集群存在多个节点,在达到存储扩展、读写能力扩展的目的上,我们希望大量的读写压力能够平摊在每个节点
Wesley13 Wesley13
3年前
DRDS 柔性事务漫谈
_摘要:_ 在阿里巴巴,“柔性事务”已经是重构分布式事务的标准方法,覆盖了商品、交易、支付各个大规模应用场景,并且经受了双十一的考验。DRDS 是阿里云提供的一款分布式数据库产品,它的原型是在阿里内部使用了10年的数据库中间件TDDL。DRDS在TDDL提供的数据切分和SQL路由能力上,强化了分布式查询,事务和水平扩容能力。
为什么mysql不推荐使用雪花ID作为主键
作者:毛辰飞背景在mysql中设计表的时候,mysql官方推荐不要使用uuid或者不连续不重复的雪花id(long形且唯一),而是推荐连续自增的主键id,官方的推荐是auto_increment,那么为什么不建议采用uuid,使用uuid究
Vitess全局唯一ID生成的实现方案 | 京东云技术团队
为了标识一段数据,通常我们会为其指定一个唯一id,比如利用MySQL数据库中的自增主键。但是当数据量非常大时,仅靠数据库的自增主键是远远不够的,并且对于分布式数据库只依赖MySQL的自增id无法满足全局唯一的需求。因此,产生了多种解决方案,如UUID,Sn