这篇文章主要讲解了“分布式关系型数据库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实现的。
当然还有些其他的细节方面也做了一些蛮不错的改进:
比如审计日志的功能其实对于很多公司来说还是有审计需求的
mydumper的定制,是基于go来实现的,能够充分利用go的一些优势
压测工具也是基于go做的一层定制,从现场的高可用测试来看,体验会好一些。
当然在体验的过程中也发现了一些待改进的地方,有些是显示信息的补充和改进,有些则是技术实现方案上的建议等。我简单提两点:
首先,RandonDB的角色其实就是一个中间件,类似ProxySQL,MyCAT之类的中间件,能够实现基本的SQL转发,这里考虑到给以后的分布式事务设计带来技术改进,目前的SQL Node是一个节点写入,其他节点是只读的。
对于OLAP的业务支持,其实从RadonDB的SQL转发,对于复杂,聚合的需求就可以直接下沉到计算节点,对于计算节点,目前的初步设计是使用插件的方式来实现,设计团队的初步设想是引入MariaDB
columnstore类似的方案来实现,我有一个建议是也可以采用类似MPP的方式,毕竟MPP也是分布式方案的而一种,在这种架构模式下就会充分用到存储多副本的优势,比如多个副本,我们可以利用其中的一个或者两个的副本来满足AP的需求,这样对于主库的写入侵入性是最小的,而且能够发挥当前架构的特点,类似免费主机域名Greenplum中的segment节点的角色。
和RadonDB的团队交流中发现,他们的团队规模其实不大,但是支撑起来这样一个产品,能够快速迭代出来,着实让人佩服。
RadonDB会在5月份开源发布,其实开源的不只是产品,还是一种开放的态度,希望RadonDB能够给我们的运维工作中带来一些新的思路和改进。 感谢各位的阅读,以上就是“分布式关系型数据库RadonDB有哪些优点”的内容了,经过本文的学习后,相信大家对分布式关系型数据库RadonDB有哪些优点这一问题有了更深刻的体会,具体使用情况还需要大家实践验证。这里是云技术,小编将为大家推送更多相关知识点的文章,欢迎关注!
这篇文章给大家分享的是有关OGG在RAC上如何安装配置的内容。小编觉得挺实用的,因此分享给大家做个参考,一起跟随小编过来看看吧。 免费主机域名 此次试验是为了某省电力公司OGG初始化模拟演练。演练过程分为两篇博客记录全过程。第一篇是安装配置,主要介绍OGG在源…