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则是不断演变跟上信息技术快速变化的浪潮,保持自己在数据库领域的领先地位。谁更值得学习和尊敬呢?!

相关推荐
广州智造4 小时前
OptiStruct实例:3D实体转子分析
数据库·人工智能·算法·机器学习·数学建模·3d·性能优化
技术宝哥7 小时前
Redis(2):Redis + Lua为什么可以实现原子性
数据库·redis·lua
学地理的小胖砸8 小时前
【Python 操作 MySQL 数据库】
数据库·python·mysql
dddaidai1239 小时前
Redis解析
数据库·redis·缓存
数据库幼崽9 小时前
MySQL 8.0 OCP 1Z0-908 121-130题
数据库·mysql·ocp
Amctwd9 小时前
【SQL】如何在 SQL 中统计结构化字符串的特征频率
数据库·sql
betazhou10 小时前
基于Linux环境实现Oracle goldengate远程抽取MySQL同步数据到MySQL
linux·数据库·mysql·oracle·ogg
lyrhhhhhhhh10 小时前
Spring 框架 JDBC 模板技术详解
java·数据库·spring
喝醉的小喵11 小时前
【mysql】并发 Insert 的死锁问题 第二弹
数据库·后端·mysql·死锁
付出不多12 小时前
Linux——mysql主从复制与读写分离
数据库·mysql