数据库管理-第318期 未来是否需要RAC架构（20250427）

数据库管理-第318期 未来是否需要RAC架构（20250427）

作者：胖头鱼的鱼缸（尹海文）
Oracle ACE Pro: Database
PostgreSQL ACE Partner10年数据库行业经验
拥有OCM 11g/12c/19c、MySQL 8.0 OCP、Exadata、CDP等认证
墨天轮MVP，ITPUB认证专家
圈内拥有“总监”称号，非著名社恐（社交恐怖分子）公众号：胖头鱼的鱼缸
CSDN：胖头鱼的鱼缸（尹海文）
墨天轮：胖头鱼的鱼缸
ITPUB：yhw1809。
除授权转载并标明出处外，均为“非法”抄袭

在最近几年的国产数据库发展中，分布式数据库一度成为主流，但是在最近2-3年中我们看到了数据库架构的一些变化，其中一些分布式数据库开始出现存算分离的变体，有一些数据库也开始推出基于共享存储设备的类似于Oracle RAC的架构，其中还有数据库甚至从一开始就把类RAC架构作为卖点。那么作为集中式数据库的典型高级架构，RAC架构在未来是否还有市场，我们得从几个维度去看。

1 数据特性

在很多业务场景中，数据是天然相关联且实时变动的，比如运营商中的基础网络信息，这里面不单单是网络链路的数据，其中还包含各式各样的网络设备，而这些设备本身就有较多且较长的数据需要记录，和网络链路一样，设备的许多性能、状态等数据也是实时动态变化的。
对于数据结构来说，从最上层的省级网关开始，一路往下到你的终端设备（网线或4G/5G接入），网络链路会经过非常多网络设备才能抵达目的地。为了实现稳定与高可用，网络链路会根据经过网络设备的负载与健康情况进行负载均衡与故障转移。这就导致了本来该单一的网络链路会出现很多的可能性，且链路复杂度会随着经过网络设备数量（涉及层数和单层数量）增加而增加。以树形结构类比，从树干到叶子可能就有多条可用的枝杈路线来输送养分，每一层的枝杈还是交叉关联的，形成一个典型的动态树形网状结构。
在我看来这样的数据结构对数据库带来了以下的挑战：

• 本身海量的基础数据记录
• 需要支持每行记录的实时更新
• 因实时动态特性数据无法被有效缓存

如果我们尝试用数据分片的方式来解决这个场景，会发现，如果我们要查询一条到最末端设备的链路故障，因为有负载均衡/故障转移的存在，无论以哪种方式分片（地市区县、设备层级、随机等），都会出现全局跨分片查询的出现，如果是热点区域，对网络的压力会非常大。
那么在我看来，使用高性能共享存储解决IO压力的RAC架构是解决这种数据结构需求的优秀方案，数据是一个整体，仅需简单分区、优化即可实现不俗性能表现。也许有人会说，图数据库也能解决，但是我们首先要解决图数据库中顶点大数据量存储以及顶点和边的高频更新操作相关的问题。

2 硬件崛起

2.1 计算能力

单颗CPU的核心数轻松破百，据说下代AMD EPYC最高将来到单Socket拥有384 Cores，单机也可以拥有海量的计算资源。

2.2 内存

单机内存已经可以按TB计算，常用数据几乎可以被缓存在内存中，内存不再是单机瓶颈。

2.3 IO能力

以三星目前最新的PCIe 5.0 NVMe SSD 9100Pro为例，其拥有14700/13400MB/s的顺序读写带宽以及1850k/2600k的随机读写IOPS，现在SSD的IO能力可以说是超乎你想象。

3 实现难点

其实对于实现数据库的类RAC架构最大的难点就是节点的缓存交互与多读多写。
试想一下，如果集群中每个节点都缓存几乎相同的数据，那么全局缓存的数据其实和单机可在内存中缓存的数据量大差不差，而且全局数据一致性的维护除了需要将数据写入磁盘外，还要横向在节点间同步相同的缓存数据。似乎有点费力不讨好，在Oracle RAC中每一份数据在全局仅缓存在一个节点上，根据是否开启DRM功能，缓存的数据会固定在某个节点并通过私有网络以复制使用的方式提供跨节点数据查询（DRM关），或者根据负载和数据需求在节点间移动（DRM开）。那么缓存了哪些数据、缓存的数据在哪个节点、数据关联不同节点缓存该如何传输等问题都是需要重点解决的。Oracle通过GI和DB结合ASM、Global Cache、Cache Fusion等功能、特性定义了RAC集群的标准。
而在多读多写这块就需要考虑到的是全局事务一致性的问题。在Oracle RAC中主要通过全局事务与锁管理、闩锁、实例级redo与undo结合等功能、特性实现，使得RAC在有确保数据安全的情况下也发挥出了出色的性能。
另一方面，对于RAC集群来说，访问数据库也是一个难点，在之前的文章中《数据库管理-第302期 国产类RAC架构数据库网络连接路径（20250314）》也提到过国内的类RAC架构数据库不是依赖数据库本身来实现负载均衡与故障识别转移，而主要是通过数据库专属驱动来实现的，对应用有一定侵入性。对比Oracle RAC则是使用集群scanIP和节点VIP组合实现的负载均衡与故障识别转移，对数据库连接驱动几乎无要求，应用把数据库当做单节点来使用，数据库维护也相对简单。

4 存储

对于RAC集群来说，共享存储是非常重要的一部分，这里就可以一般分类为集中共享存储和分布式共享存储，从字面意思就能知道：

• 集中共享存储：也就是一般所说的传统的硬盘柜，主要通过RAID实现高可用，依托于对内存、非易失性内存、高性能SSD、大容量磁盘的组合使用，实现性能与容量的平衡；存储的扩展主要通过增加硬盘柜通过内联方式实现；一般使用专用的存储链路连接设备与服务器进行交互，更加高效稳定
• 分布式共享存储：顾名思义，多台机器使用本机存储资源通过网络组合成一套共享存储，一般来说节点间与服务器使用存储都使用标准网络进行联通交互，IO性能即依赖于节点本身的存储性能，也依赖于网络性能

按照另一个角度来看有专业商用存储也有DIY存储，在讨论这个之前我们先回到SSD，这里还是需要说几件事情：

• 单机NVMe SSD的RAID实现较难，在大规模集群中应用成本较高
• 企业级SSD也无法完全避免0E（即媒体和数据完整性错误（Media and Data Integrity Errors））的出现，单机使用一般不会定期检查SSD健康度，虽然企业级SSD有机制可以尽可能减小0E带来的影响，但是0E一旦出现就可能造成数据损坏且这一过程是不可逆的

专业存储除了自带几乎所有组件的高可用冗余，其内部包含了一套完整的软件逻辑，比如磁盘IO分布和介质生命周期管理，数据因器件老化静默损坏的提前修复，精细化任务调度减少IO抖动等，更不用说还有完整的可视化报表和维护管理工具等，从根源上避免类似于SSD 0E带来的一系列问题。而DIY出来的存储，无论是集中还是分布式存储都依赖于硬件的组合能力，一般使用开源存储软件的稳定性与功能性也远低于专用存储，其使用与维护难度也较高。

那么我认为在当前情况对SSD的使用的最佳实践反而是很多人眼中“过时”了的专业共享存储设备。回到硬件本身，前面也说到了单机有足够的CPU和内存资源，专业存储提供优秀的IO能力、海量存储池、极高安全性与稳定性，不过分依赖网络，那么对应而来的RAC架构是不是可以理解为一种比较优秀的数据库架构。
再次提及Oracle Exadata，如果专业存储再与数据库适配，提供IO层面的计算能力，那么RAC的优点将进一步扩展提升。

总结

RAC作为优秀的数据库架构是一定会被需要的，依托优秀硬件和专业存储，有着出色的性能和稳定性，集中式的数据库使用方式也更适合一些特定和绝大多数的业务场景。
老规矩，知道写了些啥。