酷应用

十年数据库「老兵」眼中的 RadonDB

百家作者：QingCloud 2018-05-03 15:48:12

本文是来自一线 Oracle DBA 杨建荣在 RadonDB 体验会后的分享笔记。

凭借近十年的数据库开发和运维经验，杨建荣在 DBA 运维、架构设计、扩容以及高可用等方面，给出了针对分布式关系型数据库 RadonDB 的客观评价。

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

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

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

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

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

首先整个一套方案都是打算开源的，目前在青云的产品线中已经可以体验。从部署到使用，整个过程都是基于云平台来完成，基础运维的成本很低。
从架构设计的角度来说，RadonDB 的设计定位充分利用了 MySQL 的开源红利，存储节点是直接使用 MySQL 5.7 的版本，可以把存储计算的任务下沉到 MySQL 层面，所以他是一套完全基于 MySQL 定制的分布式方案，架构方式看起来比较轻量级。
对于关系型数据库来说，要实现扩容影响面是很大的。RadonDB 在这里的实现，上层是基于 hash，存储模式是基于 Range,即一个大表也可以根据片键值的范围横向扩展，比如一个大表是 30G，那么如果是分为 30 个分片，那么没一片的粒度就是 1G, 在这种代价下，做 online DDL 还是数据的迁移都是相对来说可控的粒度，我个人最欣赏的就是它在弹性扩容上的实现方式，能够基于这种拆分思想，借鉴参考了 Redis Cluster 里面类似的思想，根据细粒度的 slot 级别的数据来实现扩容。
在高可用上面值得一提的是一个独立的工具 MySQL Plus，这款工具可以基于 5.7 版本以上的 GTID 来满足原来 MHA 所做的事情，然后基于半同步保证了数据的完整性，目前的整个一套方案都是基于 Raft 实现的。

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

比如审计日志的功能其实对于很多公司来说还是有审计需求的。
mydumper 的定制，是基于 go 来实现的，能够充分利用 go 的一些优势。
压测工具也是基于 go 做的一层定制，从现场的高可用测试来看，体验会好一些。

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

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

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