ITPub博客

分布式关系型数据库RadonDB体验归来

原创 MySQL 作者:jeanron100 时间:2018-04-28 00:08:36 1 删除 编辑

前段时间收到吴老师的邀请,是参加青云QingCloud分布式数据库(RadonDB)的一个技术体验活动,从今天的技术体验来算,收获还是很多的,大家相聊甚欢,交流了很多工作中和工作之外的想法,原来那些我们看起来难走的路大家都曾经走过。

总体来说MySQL方向的目前的技术架构是一种看起来相对稳定的体系,一般来说传统的主从复制,半同步,一主多从,到分库分表,加上中间件,高可用,好像可玩的花样就差不多这些了,所以基于这些我们只能说MySQL的这种使用方式是基于分布式架构,从CAP的角度来看,一致性(C),可用性(A),分区容忍性(P)方面很难都占全。

说实话,最开始听到RadonDB这个名字感觉很陌生,打开技术架构图,猛一看看好像没有什么特别的新意,所以开始的环境部署和简单体验其实是带着一种挑剔的眼光来看的,提出一些体验和兼容性的小问题。

但是随着下午和设计师雁飞和RadonDB团队的深入交流,发现这个架构确实很有意思,能够在已有的架构模式下玩出新的花样,而且确实解决了分布式方案的基本需求,很难得。

我来简单补充下产品里面的亮点。

1.首先整个一套方案都是打算开源的,目前在青云的产品线中已经可以体验。从部署到使用,整个过程都是基于云平台来完成,基础运维的成本很低。

2.从架构设计的角度来说,RadonDB的设计定位充分利用了MySQL的开源红利,存储节点是直接使用MySQL5.7的版本,可以把存储计算的任务下沉到MySQL层面,所以他是一套完全基于MySQL定制的分布式方案,架构方式看起来比较轻量级。

3.对于关系型数据库来说,要实现扩容影响面是很大的。RandonDB在这里的实现,上层是基于hash,存储模式是基于Range,即一个大表也可以根据片键值的范围横向扩展,比如一个大表是30G,那么如果是分为30个分片,那么没一片的粒度就是1G,在这种代价下,做online DDL还是数据的迁移都是相对来说可控的粒度,我个人最欣赏的就是它在弹性扩容上的实现方式,能够基于这种拆分思想,借鉴参考了Redis Cluster里面类似的思想,根据细粒度的slot级别的数据来实现扩容。

4.在高可用上面值得一提的是一个独立的工具MySQL Plus,这款工具可以基于5.7版本以上的GTID来满足原来MHA所做的事情,然后基于半同步保证了数据的完整性,目前的整个一套方案都是基于Raft实现的。

当然还有些其他的细节方面也做了一些蛮不错的改进:

  1. 比如审计日志的功能其实对于很多公司来说还是有审计需求的

  2. mydumper的定制,是基于go来实现的,能够充分利用go的一些优势

  3. 压测工具也是基于go做的一层定制,从现场的高可用测试来看,体验会好一些。

当然在体验的过程中也发现了一些待改进的地方,有些是显示信息的补充和改进,有些则是技术实现方案上的建议等。我简单提两点:

首先,RandonDB的角色其实就是一个中间件,类似ProxySQL,MyCAT之类的中间件,能够实现基本的SQL转发,这里考虑到给以后的分布式事务设计带来技术改进,目前的SQL Node是一个节点写入,其他节点是只读的。

对于OLAP的业务支持,其实从RadonDB的SQL转发,对于复杂,聚合的需求就可以直接下沉到计算节点,对于计算节点,目前的初步设计是使用插件的方式来实现,设计团队的初步设想是引入MariaDB columnstore类似的方案来实现,我有一个建议是也可以采用类似MPP的方式,毕竟MPP也是分布式方案的而一种,在这种架构模式下就会充分用到存储多副本的优势,比如多个副本,我们可以利用其中的一个或者两个的副本来满足AP的需求,这样对于主库的写入侵入性是最小的,而且能够发挥当前架构的特点,类似Greenplum中的segment节点的角色。

和RadonDB的团队交流中发现,他们的团队规模其实不大,但是支撑起来这样一个产品,能够快速迭代出来,着实让人佩服。

RadonDB会在5月份开源发布,其实开源的不只是产品,还是一种开放的态度,希望RadonDB能够给我们的运维工作中带来一些新的思路和改进。

请登录后发表评论 登录
全部评论

注册时间:2012-05-14

  • 博文量
    1667
  • 访问量
    14183517