分布式关系数据库RadonDB有哪些优势？

总体来说，MySQL目前的技术架构是一个比较稳定的系统。总体来说，传统的主从复制、半同步、一主多从机，到分库分表，再加上中间件和高可用，看起来这些都是可以玩的花样，所以基于这些我们只能说MySQL的这种使用方式是基于分布式的从CAP的角度来看，一致性（C）、可用性（A）和分区容错性（P）很难同时涵盖。

说实话，我第一次听到这个词的时候感觉很陌生。e 名称 RadonDB。当我打开技术架构图的时候，乍一看似乎并没有什么特别新鲜的地方，所以最初的环境部署和简单的体验其实都是基于挑剔的眼光，提出了一些体验和兼容性方面的小问题。

不过，下午和设计师颜飞以及RadonDB团队深入交流后，我发现这个架构确实很有趣，可以在现有的基础上创造出新的花样。架构模型。 ，而且确实解决了分布式解决方案的基本需求，这是很少见的。

我简单补充一下产品的亮点。

1.首先，整个解决方案旨在开源，并且已经可以在青云的产品线上体验。从部署到使用，整个过程基于云平台完成，基础运维成本非常低。

2.从建筑的角度在架构设计上，RadonDB的设计定位充分利用了MySQL的开源红利。存储节点直接采用MySQL5.7版本，可以将存储和计算任务下沉到MySQL。级别，所以是完全基于MySQL定制的分布式解决方案，架构显得比较轻量级。

3.对于关系型数据库来说，扩容的影响是巨大的。这里RandonDB的实现，上层是基于hash的，存储方式是基于Range的，即一张大表也可以根据分片键值的范围进行水平扩展。比如一张大表是30G，那么如果分成30个分片，那么每片的粒度就是1G。以这个代价，无论是在线DDL还是数据迁移都是粒度相对可控的。我个人最欣赏的是它的弹性扩展的实现。可以基于这样的拆解。该思想基于Redis C中的类似思想lustre基于细粒度槽级数据实现扩展。

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

当然，在其他细节上也做了一些相当不错的改进：

例如，审核日志功能仍然有很多公司可以使用。审计需求

mydumper的定制是基于go的，可以充分利用go的一些优势。

压测工具也是基于go进行了一层定制去吧，从现场开始从高可用测试来看，体验会更好。

当然，在体验过程中，我们也发现了一些需要改进的地方，其中有一些是对di的补充和改进。发布的信息，其中有一些是技术实施方案的建议。我简单提一下两点：

首先，RandonDB的作用其实是一个中间件，类似于ProxySQL、MyCAT等中间件，可以实现基本的SQL转发。未来的分布式事务会考虑到这一点。该设计带来了技术改进。当前SQL Node由一个节点写入，其他节点只读。

对于OLAP业务支持，其实从RadonDB的SQL转发，复杂、聚合的需求可以直接转移到计算节点上。对于计算节点，目前初步设计是采用插件的方式来实现。 ，设计团队最初的想法是引入类似MariaDBcolumnstore的解决方案来实现。我的一个建议是使用类似于 MPP 的方法。毕竟MPP也是一种分布式解决方案，在这种架构模式下会得到充分的运用。存储多副本的优点，比如多副本，我们可以使用一份或者两份副本来满足AP的需求，这样对主库的写侵入最小，并且可以利用当前架构的特点，类似于Greenplum中段节点的作用。

在和RadonDB团队沟通的时候，我发现他们的团队规模其实并不大，但是能够支持这样的产品并快速迭代的能力着实令人印象深刻。

RadonDB 将于 5 月开源。事实上，开源不仅仅是一种产品，更是一种开放的态度。希望RadonDB能给我们的运维工作带来一些新的思路和改进。

感谢您的阅读。以上就是《分布式关系数据库RadonDB有哪些优点》的内容。经过文章的学习，相信大家对分布式关系数据库RadonDB有了一定的了解。我们对这个问题的优点有了更深入的认识，具体用法还需要在实践中验证。在此，小编将为大家推送更多相关知识点的文章，欢迎关注！