分布式关系型数据库RadonDB有哪些优点

这篇文章主要讲解了“分布式关系型数据库RadonDB有哪些优点”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习“分布式关系型数据库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能够给我们的运维工作中带来一些新的思路和改进。

感谢各位的阅读，以上就是“分布式关系型数据库RadonDB有哪些优点”的内容了，经过本文的学习后，相信大家对分布式关系型数据库RadonDB有哪些优点这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是亿速云，小编将为大家推送更多相关知识点的文章，欢迎关注！