登录 / 注册
IT168技术开发频道
IT168首页 > 技术开发 > 技术开发技术 > 正文

开源了!RadonDB数据库核心技术与实现详解

2018-05-15 17:29    it168网站 原创  作者: 老鱼 编辑: 覃里

  【IT168 技术】本文根据张雁飞老师在2018年5月10日【第九届中国数据库技术大会(DTCC)】现场演讲内容整理而成。

开源了,RadonDB数据库核心技术与实现详解
张雁飞 Array | QingCloud 数据库高级技术专家

  张雁飞 Array | QingCloud 数据库高级技术专家,TokuDB内核贡献者、维护者,TokuDB企业级热备工具作者。曾就职于阿里云数据库内核团队,目前为青云QingCloud数据库团队负责人,主导新一代分布式数据库产品——RadonDB的设计与研发。

开源了,RadonDB数据库核心技术与实现详解

  摘要:随着数据规模的逐步扩大,存储和运维成本逐渐增加,企业对数据库的要求也逐渐提高。有人认为以MySQL为代表的传统数据库已经过时,不能满足数据爆炸时代企业的要求;以NoSQL为代表的新型数据库仍有局限性,不具备ACID特性,很难满足企业对核心业务数据的严苛需求。此次分享的RadonDB是一款将分布式一致性协议Raft与MySQL相结合的新一代分布式关系型数据库。RadonDB的最大特点是结合两类数据库的优点,让DBA无缝地从传统的、单机时代的MySQL过渡到云原生的、无限扩展的分布式关系型数据库。

  分享大纲:

  1、 可扩展

  2、 高可用

  3、 强一致

  4、 易部署

  5、 MyNewSQL

  RadonDB架构图

  RadonDB定位是新一代分布式关系数据库,在今天这个云计算快速发展的时代,我们更愿意称它是一个云原生数据库,云原生数据库的天然属性是分布式、可扩展、高可用、强一致。下面的MyNewSQL,是因为我们把MySQL和NewSQL融合起来,来满足以上的几个特性。

开源了,RadonDB数据库核心技术与实现详解

  这是RadonDB的架构图,我们可以看到,主要分上下两层,上层是一个分布式的SQL层,它由多个SQL节点组成,负责用户请求和申请分布式的执行制定计划。下层是存储层,这个存储层与其他NewSQL不一样的地方是,我们用的MySQL,可以看每个虚线框里都是三副本的MySQL。它们之间的高可用,我们使用了NewSQL里面比较流行的Raft一致性算法。这个后面会有详细的介绍。右下角是一个计算节点,这个稍后也会介绍,这就是RadonDB整个的架构图。

  Distributed SQL

  下面,看一下分布式的SQL层,SQL层的职责可以看下面这个图。

开源了,RadonDB数据库核心技术与实现详解

  当中一个请求到来之后,SQL层会把这个请求解析成分布式的执行计划,然后,把这个SQL在后端的存储层并行的执行。而且它还会进行二次运算,就是Orderby/limit/groupby/aggration/join….等等。它还是一个无中心化的设计,部署起来比较方便,容易扩展,这是整个SQL层的一个设计。

  Storage Nodes

  再看存储层,存储层是RadonDB里一个比较新颖的设计,也是我们定位为在新一代分布式数据库的一个原因。

开源了,RadonDB数据库核心技术与实现详解

  存储层,每个副本都是一个MySQL,因为MySQL不光有计算能力,还有存储能力。如果单单是一个KV的话,计算能力就比较弱一些,这是我们目前存储层使用MySQL的一个考量。整个存储层,由多个存储节点组成,每一个存储节点都是由三副本的MySQL组成,副本是通过Raft协议进行选主,然后再结合MySQL的自身的一套机制完成高可用。

  副本高可用

  接下来,我们看一下副本高可用。副本高可用其实有几个比较大的挑战。

开源了,RadonDB数据库核心技术与实现详解

  第一个挑战,怎么快速选主?

  第二个挑战,选出新的主后,数据怎么快速地回放?

  第三个挑战,数据回放完,数据怎么保证不丢失? RadonDB是怎么解决的?

  对于第一个挑战,我们使用了Raft协议,大家要知道,Raft协议主要干两件事,第一个就是选主,第二个是数据同步。在RadonDB里只使用Raft进行选主,当主挂掉之后,我们使用Raft选出新的主,然后数据同步。我们是基于MySQL原生的FGTID机制和并行复制这些特性进行快速回放。

  保证数据不丢失,我们还是基于MySQL,并使用了MySQL的Semi-Sync机制,当用户写到主副本时,首先,它要到达一个从副本,从副本收到之后,再反馈给客户端,这样就时刻地保证了一个从副本与主副本的数据完全一致,从节点被选入新的主节点,保证了这个数据不丢失。

  当选入新的主节点之后,RadonDB的Log 并行复制还是基于MySQL的机制,并行复制,快速地回放,这就等于实现了把Raft选主和Log 并行复制结合。原生态Raft协议里这两个,Raft Log并行回放是比较困难的,但是,我们结合MySQL就很好地完成了。而且,这三个副本是一个无中心化的设计,只要我们可达,它的部署比较灵活。

  扩容

  RadonDB的底层是全部基于MySQL,所以在扩容的时候也比较方便,因为MySQL有一套工具和机制。

开源了,RadonDB数据库核心技术与实现详解

  在RadonDB里,每一个大表被分成了很多个小表,这样,我们优先扩容小表,会选一些热度高的小表进行漂移,漂移的机制是先全量,全量时,我们记住当时的一个位点,就是MySQL里Binlog位点,全量之后,我们再追这个增量,也是基于(GTID)这种机制。这样,前端业务基本上没有影响的情况下,完成了小表在物理机之间的动态漂移,当然你也可以制定一些规则,比较灵活。

  分布式事务

  RadonDB支持分布事务,还是基于MySQL原生XA机制来完成的。所以,大家可以看到RadonDB这上面能力跟MySQL很好地结合起来。

开源了,RadonDB数据库核心技术与实现详解

  大家可以看到上图,其实MySQL Xa机制总共有5个步骤,但是到RadonDB里,我们进行了抽象,就是进行了封装。我们实现了快照的隔离级别,实现了Snapshot Isolation事务隔离级别。

  Binlog

  另外,RadonDB支持Binlog,大家可能认为一个分布式数据库,就是里面需要放一些海量的数据,但数据一旦进入你的分布数据库,怎么能出来?就比较麻烦,因此, RadonDB提供一个Binlog机制,就是让数据能快速的同步处理。

  OLTP + OLAP

  比如说,我们有一个OLAP的集群,可设置为RadonDB的Binlog,Binlog是实时地更新,这就完成了一个异构化的过程和数据流出,而且是实时的。

  大家也看到,在刚才的架构图里,右下角有一个计算节点,其实,我们的计算节点就是通过这种机制跟RadonDB的数据进行同步。这样,就把OLTP和OLAP结合了起来,当用户一个比较复杂的查询到达RadonDB之后,RadonDB会根据SQL的模式发到TP节点还是AP节点,前端的用户是没有感知的,这就做到了一些资源的隔离。当然了,这也有一个缺点,数据可能是两份,但目前,我们是通过异构化、列式存储来进行的,高压缩做这种机制。

  审计日志

  另外,RadonDB还提供了一些审计日志这些功能,为了方便大家对业务进行一些审计,而且审计机制还可以定位一些慢查询SQL,因为分布式的数据库,节点比较多,所以定位一个SQL会比较复杂,有了审计日志,大家可以定位一些慢的SQL。

  备份和恢复

  RadonDB提供了一整套备份和恢复的工具,可以让用户快速地把数据流进去,流出来,比原生的要快很多。

  性能


开源了,RadonDB数据库核心技术与实现详解

  这是我们做的一个新的对比,可以看到,RadonDB在四个节点跟单机的MySQL的一个对比,基本上,性能是单机的三倍,但延迟只是1/3,性能明显提升,这就是分布式数据库的威力。而且这个性能基本上是可以横向扩展的。

  RadonDB还提供了一些可调用的参数,让外面的监控可以很好地调用,这是RadonDB比较灵活的一个地方,可以根据定制让前端或者产品线调用。

  监控

  另外,RadonDB提供了一个全链路的监控,通过它,分布式就不再是个黑盒子。

开源了,RadonDB数据库核心技术与实现详解

  mysql> show processlist;

  第一条命是,MySQL常用的,表示用户的链接到RadonDB的状态。

  mysql> show txnz;

  第二个命令是,分布式事务在哪个阶段执行,耗时多少,这个都可以很清楚地看到。

  mysql> show queryz;

  最后一个命令,具体哪些子句落到哪些节点,甚至耗时多少,比如说,某个节点有一些问题,都可以从这个上面反映出来,比较灵活。

  • IT168企业级IT168企业级
  • IT168文库IT168文库

扫一扫关注

编辑推荐
首页 评论 返回顶部