【参天引擎】华为参天引擎内核架构专栏开始更新了,多主分布式数据库的特点,类oracle RAC国产数据开始出现了

2023-12-14 11:41:42

cantian引擎的介绍

?专栏内容

  • 参天引擎内核架构
    本专栏一起来聊聊参天引擎内核架构,以及如何实现多机的数据库节点的多读多写,与传统主备,MPP的区别,技术难点的分析,数据元数据同步,多主节点的情况下对故障容灾的支持。

  • 手写数据库toadb
    本专栏主要介绍如何从零开发,开发的步骤,以及开发过程中的涉及的原理,遇到的问题等,让大家能跟上并且可以一起开发,让每个需要的人成为参与者。
    本专栏会定期更新,对应的代码也会定期更新,每个阶段的代码会打上tag,方便阶段学习。

?开源贡献

个人主页我的主页
管理社区开源数据库
座右铭:天行健,君子以自强不息;地势坤,君子以厚德载物.

前言

国内数据库的发展如火如荼,每年的各种大会都会听到好消息,今年除了数据库本身的各种技术演进之外,华为发布了参天引擎,而且是做为数据库的一种基座形式,也就是所有数据库可以在参天引擎基础上,构建形成多主分布式架构的数据库系统,这也就是它叫引擎的目的。

本专栏就来详细聊一聊参天引擎内部架构,以及如何适配参天引擎。

概述

据华为官网发布的新闻,题为:华为宣布CANTIAN引擎开源,携手共建数据库存储新生态,已经有万里数据库适配完成,万里数据库是基于mysql,也就是说mysql与参天引擎结合成功,达到了分布式数据库集群,基于共享存储的多主效果。

华为在数据库方向上开源了GuassDB之后,又宣布开始了参天引擎,这又是什么神器呢,今天我们就一起来看一看。

cantian引擎是什么

随着数据库国产化的推进,基础模型的数据库大多都与国外品牌有了对标产品,比如说主从,延伸出来的一主多从,读写分离等,已经很成熟,也有很多中间键可以应用开源数据库mysql,postgresql都有类型部署模式;

还有MPP模式,也就是元数据在master节点,通过切片将实际数据放在worker节点,已经有开源的citus, greenplum等数据库支持;

但是对于数据库巨头oracle的 oracle RAC产品对标产品一直没有进展,也就是说它还不能被很好的替代。

oracle RAC主要特点是高可用,不是其它一些模型能达到了,而华为cantian引擎的出现,就是干了这么一件事,可以对标oracle RAC了。

基于共享存储的架构

oracle RAC其实是一种基于共享存储的分布式集群架构,从上图可以看到,集群中的每个数据库节点都访问同一份相同的数据,同时每个数据库节点都可以进行读写操作,比如两个节点上同时可以对同一张表进行插入数据操作。

这种架构模型下,集群中一个节点故障后,其它节点完全可以接管所有业务。

参天引擎的目标是让数据库具有“分布式架构+集中式体验”的多主架构数据库,它通过client,server, 存储三层,将传统单机数据库,如mysql,postgresql与client进行结合,从而改造成多主的分布式集群式数据库。

换句话说,参天引擎可以是一种标准服务,只要数据库系统与client进行改造对接后,就可以使用server,存储层,这样就可以支持多主的分布式架构。

多主分布式架构的特点

oracle RAC类型的共享存储下的分布式数据库,有什么特点,或者它的优势在那里呢?

在历年的oracle RAC白皮书中反复提到这几个特性,而且对它们进行持继的更新演进,当然也是多主分布式架构的最核心特点。

高可用

集群中的多个节点完全对称,也就是任意两个节点是一模一样的,这就是说业务可以运行在任意节点上,真实使用时只是通过负载均衡将业务分散到了各节点上,使负载达到了均衡。

各节点对称,这一特性使得当任意节点故障时,业务可以立马转移到其它节点上,这与主从架构,MPP架构完全不同。

主从架构中,只有主具有处理所有业务的能力,从节点具有处理只读业务的能力,当主节点故障时,需要重新选主,再进行业务切换;

而MPP架构中,特点区分更加明显,它具有两个节点角色,对于master角色的节点,只存储元数据,也即数据分布信息,它的高可用一般也采用一主多从的形式,故障时处理与主从是一样的;而对于worker角色的节点,它们存储了一部分分片的数据,它们一般通过多副本机制达到冗余备份的高可用,故障节点的数量不能超过副本数量,副本越多管理成本越高。

按照oracle RAC最新的版本,这个故障处理的能力已经非常丝滑,可以达到事务级别的转移,这在其它两个架构,由于架构的限制很难做到。

在这里插入图片描述

业务连续性的用户体验,这在一些关键应用中体现非常重要,这里借用oracle rac技术白皮书中的一张图来说明。

扩展性

当然对于多主架构,集群中增加一个节点,业务负载就可以立即分担;同样减少一个节点时,对应业务负载也可以转移到剩余节点上。有点像现在的云部署的感觉,通过自动化的控制,完全可以按照业务负载调整资源的使用情况。

当然,这在其它架构也是很难达到的。

应用无修改

经过几年的数据库国产化后,这一点体验比较深刻,现在都会支持单机,主从,MPP部署,但这三种都需要应用能够做一些适配,尤其MPP部署,需要这种应用的业务要完全适合此种架构,就有很多限制,比如复杂联合查询就要特别当心了,最好提前能够整改了。

而对于多主分布式架构,这些情况都不存在,不需要区分只读,读写业务,也不需要担心SQL的不支持,单机部署也开发正确,在多主分布式架构下就是可以的;

这大大简化了业务应用的开发,同时对于业务应用架构设计的成本也降低了,不需要对每种数据库的限制深入了解。

多主分布式架构的技术难点

多主的分布式架构为什么迟迟在国内没有大的推进呢,它主要有几大技术难点,每个难度都是一个重量型的开发,所以对企业,尤其是资本业讲,很难在短期得到收益。

数据库元数据的同步

对于多主的分布式系统,最先面临的就是元数据的多机同步,数据库也是一样,在多写的情况下,每个节点都会产生元数据,需要实时同步。

数据库分布式锁

多节点如果访问同一数据元素时,需要进行加锁,那这个锁不再是单机系统下的某个内核变量,而是要扩展到分布式下多节点间的锁,在多节点起到加锁互斥的效果。当然在分布式下有很多实践,但是数据库这样高频使用场景下,如何能提高性能是不得不考虑的问题。

多节点事务一致性

数据库概念专栏,分享并发控制的可串行化相关内容,那些都是单机架构下的,如何在多节点时做到事务的并发一致性,需要将封锁,时间戳,有效性确认几种方式扩展到多节点。

其中事务号,也就是事务时间戳的实现,就有好几种方式,如时钟,统一分发的序号等等。

多写下的恢复

多个节点都可以写入数据,那么故障时,如何恢复,数据的一致性又如何保障呢?

比如两个节点修改了数据,它们的先后顺序的确定,单机也是由日志的时间戳方式进行排序,而多机时,如何使用统一的日志,那竞争必然加大。

数据库概念专栏中对于恢复,分享了几种技术,如redo, checkpoint等,那对于redo,checkpoint都需要日志先落盘,或者对日志进行回收处理,在多节点间如何保障日志先于数据落盘。

多机共享文件系统

当然以上各点都是对于数据库来讲的,对于基于共享存储的多主分布式架构,还有一个重要的技术难点,就是文件系统。

假如多个节点同时对一个表文件进行写入,或者扩展,传统的ext4,xfs肯定是不行的,多节点各自部署在独立的服务器上,对应着多个操作系统,各自的文件系统元数据是不交互的,此时就会混乱。

而对于分布式文件系统,一般都会将元数据缓存在客户端,也就是每个使用者的机器上,会导致更新不及时。

参天引擎可以做什么

从华为官方发布的消息来看,已经与厂商合作适配成功了,也达到了多主分布式集群的效果,从其它媒体发布的消息来看,测试的数据还是不错。

目前看起来对于mysql进行了适配,另一个主流开源数据库postgresql还没有看到消息,其它也没有看到更多介绍的文档。

既然开源了,那接下来我们就从源码角度看看,参天引擎可以做什么,拿postgresql来适配的话,难度会有多少。

结尾

非常感谢大家的支持,在浏览的同时别忘了留下您宝贵的评论,如果觉得值得鼓励,请点赞,收藏,我会更加努力!

作者邮箱:study@senllang.onaliyun.com
如有错误或者疏漏欢迎指出,互相学习。

文章来源:https://blog.csdn.net/senllang/article/details/134915474
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。