23ai DGPDB,Oracle资源池战略的最后一块拼图

Oracle对资源池是有执念的!

在我看来,这种执念一方面是应用架构的微服务化,数据库被拆分的越来越小,而服务器的硬件能力是不断提升的,CPU核心数、内存和存储的容量都按照摩尔定律在不断增加,这就使得数据库服务器资源使用率长期维持在一个非常低的水位;另一方面来源于当今科技发展对资源精细化管理的需求,尤其是虚拟化、容器化技术的发展,让精细化资源管理变得触手可及。但数据库是个强一致性的节点,如何更好的实现这一点,是数据库厂商不断探索和追求的目标。

今天我们梳理了Oracle的资源池路线,看看Oracle数据库是如何从传统的多进程架构演变成适应云时代数据库精细化管理需求的。

11g 资源池

11g时代,Oracle Cloud Control产品中提供了一个资源管理门户 -- Oracle Cloud Self Service Portal,利用这个门户可以将多个数据库或集群构建成资源池。为了满足不同业务系统的需求,可以采用不同的设备构建多种级别的资源池,比如Exadata资源池,用于高性能分析系统;普通X86资源池,用于支持中等压力的业务系统。当业务系统需要数据库资源,即可从不同的资源池中分配需要的资源。

由于架构上的限制,11g资源池只能支持数据库级和Schema两个级别,Schema资源隔离能力较弱,大多数用户并不愿意将多个业务系统的数据放在同一个数据库中;而如果采用数据库级的资源池,本质上就是新建了一个数据库,和手工创建一个独立的数据库,并没有什么差别。因此使用11g资源池的用户非常有限,即使是在一套集群上创建了多个数据库,用户也没把它称为是资源池。

随着微服务架构的流行,一套应用系统可能被拆分为多个数据库来支持。一方面,单个数据库消耗的资源显著下降,很多用户的服务器资源利用率不到10%;另一方面,Oracle新建一个数据库需要多出一组实例(一大堆的后台进程),这也使得管理成本明显增加。

因此Oracle的多实例单数据库的架构,在这个追求快速弹性扩缩容的时代,多少显得有些格格不入。

12c 多租户

12c中引入了多租户架构,一个容器数据库(Container Database, CDB)中可以容纳多个可插拔数据库(Pluggable Database, PDB)。虽然说从架构上CDB相当于是原来的独立数据库,但Oracle期望CDB作为数据库的容器,PDB作为最小的数据库单位,可以在不同的CDB之间便利的迁出和迁入。当应用需要新的数据库资源时,只需要一条命令在CDB中创建出新的PDB即可交付使用。

这种使用方式,大家是否有些似曾相识,事实上MySQL和SQL Server等数据库一直就是这种架构,Oracle兜兜转转走了一大圈的"弯路",似乎又回到了"原点"。不过Oracle毕竟是商业数据库的头牌,相比于MySQL,PDB更像是一个独立的数据库,在不同CDB之间的迁移更加方便;相比于SQL Server,PDB的内存、CPU和I/O资源隔离更加彻底,彼此之间可以最大程度上不受干扰。

当使用多租户将多个独立数据库作为迁入PDB之后,企业用户却发现一个尴尬的问题 -- 容灾切换只能以CDB级别来进行,这就意味着如果一个PDB业务需要做容灾切换,整个CDB上的数据库都得配合,这是完全不可接受的。虽然可以用冗余CDB来进行中转,但是和传统切换方式相比更加繁琐,切换耗时也更长,很多用户并不愿意接受这种方案。

因此容灾切换的不便,成为12c资源池推广路上最大的绊脚石。

23ai DGPDB

2022 年 7 月,Oracle在 21.7版本引入了PDB级Data Guard特性(简称:DGPDB),这个多租户新的Data Guard特性将用来替代传统的CDB架构层的Data Guard,用户即可以部署CDB层的Data Guard,也支持更灵活的PDB层Data Guard(在每个PDB上配置、维护和独立的Switchover、Failover操作)。

PDB层的Data Guard保护的是单个PDB,而不是整个CDB。在这个架构中,主备两端的CDB都是Primary角色,运行在CDB上的PDB即可以是Primary也可以是Standby,PDB级的Primary和Standby构成一组Data Guard。

这个架构最大的好处就是容灾切换不再需要CDB级的整库切换,可以从PDB级别来进行。将更多的选择权还给用户,是一个产品成熟不断成熟的标志,从这个意义上来说,有了DGPDB,Oracle的资源池技术已经成熟!

虽然在21.7中已经支持这项技术,但21c是创新版本,国内企业用户很少使用这个版本,所以这篇文章的标题我用的是"23ai DGPDB",相信在当前节能增效的大背景下,这个新功能会是用户选择23ai作为数据库资源池的重要推手。

总结

先天架构上的限制使得早先的Oracle数据库并不适合做资源池,但是用户对资源池化、资源弹性需求不断增强。从11g之前的实例隔离和Schema隔离,到12c的多租户,Oracle并没有放弃对资源池技术革新的努力。直到23ai DGPDB,Oracle的资源池技术已经成熟,值得企业用户推广使用。

条条大路通罗马,有的人家就住在罗马!有些数据库生来就是云原生,Oracle则是不断演变跟上信息技术快速变化的浪潮,保持自己在数据库领域的领先地位。谁更值得学习和尊敬呢?!

相关推荐
hogenlaw几秒前
Oracle从入门到放弃
数据库·oracle
卡兰芙的微笑14 分钟前
get_property --Cmakelist之中
前端·数据库·编辑器
Z_W_H_26 分钟前
【PostgreSQL】安装及使用(Navicat/Arcgis),连接(C#)
数据库·postgresql
豆姐姐33 分钟前
金九银十,分享一波用例设计、数据库、编程笔试题!
自动化测试·数据库·测试用例·软件测试面试
计算机程序设计开发35 分钟前
计算机毕业设计公交站点线路查询网站登录注册搜索站点线路车次/springboot/javaWEB/J2EE/MYSQL数据库/vue前后分离小程序
数据库·vue.js·spring boot·课程设计·计算机毕业设计
evanYang_1 小时前
Spring Boot配置文件敏感信息加密
spring boot·后端·oracle
waterHBO1 小时前
ER 图 Entity-Relationship (ER) diagram 101 电子商城 数据库设计
数据库
青云交1 小时前
大数据新视界 --大数据大厂之Kubernetes与大数据:容器化部署的最佳实践
数据库·kubernetes·容器编排·资源管理·大数据处理·扩展性、故障恢复·存储持久化·监控、日志管理、性能提升
liangbm32 小时前
MATLAB系列07:输入/输入函数
开发语言·数据库·笔记·matlab·函数·自定义函数·matlab函数
skate2 小时前
达梦disql支持上翻历史命令-安装rlwrap
数据库