比较YugabyteDB 和Oracle 数据库的最大可用性
弗兰克- 皮切特 [翻译 hudson]
2022年8月25号
当从Oracle移植到PostgreSQL时, 主要的考量不是SQL特性—因为 PostgreSQL 对许多应用已经足够好， 而且有一个活跃的社区推动新特性。 最大的问题是Oracle管理员期望从他们的关键数据库中实现的高可用性 (HA)。 PostgreSQL升级需要停机 ,而且PostgreSQL 的保护会涉及到数据丢失。 然而Oracle因其具有多可用性选项, 长期以来一直可以避免数据丢失和停机 。
好消息是 YugabyteDB 可以交付和 PostgreSQL相同的 SQL 特性, 但同时具有弹性和可伸缩性。这保证了你的数据库可以实现最高级别的保护而没有额外的复杂性。
发现单体数据库和云原生数据库之间一对一的差异是困难的。 因此在本文中, 我们会比较YugabyteDB 和 Oracle (基于RAC, Data Guard) 的可用性目标。 首先,我们将检查每种数据库可能的选项。
YugabyteDB 和 Oracle 可用性选项
Oracle
Oracle 是一个单体数据库。 所有会话数据都必须写到同一个地方—存放行数据的当前版本的数据块 。 Oracle所有版本都实现了如下四个特性 以支持更好的弹性（在硬件错误情形) 并增加可用性 (在软件升级情形)。
- Oracle RMAN (恢复管理器) 管理联机备份, 侦测问题, 在磁盘损坏或者故障时恢复数据。 数据虽然受到保护，但需要很长的恢复时间 (RTO—恢复时间目标—通常以小时或者天数计)。 通过备份归档日志减少了数据丢失 (RPO—恢复时点对象—通常以小时计 )。 通过附加的硬件可能会降低这个时间 ，比如 ZRLA—零数据丢失恢复套件。
- Oracle RAC (实时应用集群) 运行在特定的集群感知层(CRS)之上，允许多个服务器在不产生脑裂情况下打开同一个数据库。 但这并不能应对磁盘故障， 而且只有非常有限的补丁滚动升级功能，前提是这些补丁不改变数据库。 为什么是这样呢？因为它仍然是一个共享的单体数据库。 然而因为它能够应对服务器故障和有限的扩容能力，所以提供高可用性服务。 这种高可用受距离限制 ，因为缓存和磁盘是共享的，同时也受性能限制，因为需要在节点间交换数据块。 RTO 和RPO 是很小 ，但这是服务器而不是数据库的考量。 和 ASM组合 (自动存储管理 )后, 虽可提供磁盘冗余 ,却也受上述相同限制(同一可用区内的集群)。
- Oracle Data Guard（数据卫士） 通过流方式向备用库进行物理复制。它向备份一样保护数据库, 但在激活时可减少恢复时间 （相比恢复）。Data Guard 最初为灾难恢复（DR）设计, 其异步特性 (ASYNC) 可减少对主库的冲击 ，但在故障切换过程中会有数据库丢失。 在网络延迟允许情况下, Data Guard也支持同步复制（SYNC）以避免数据丢失(RPO=0)。 通过一个额外的观察者启用 FSFO (Fast Start Failover)后, 故障切换过程无需人工干预 , 减少RTO 至数分钟。 通过另外一个额外选项 (ADG—活动数据卫士) ，备库可用于某些操作 (只读会话，增量备份等等)。 然而所有备库场地, 即使是被动的,都必须具有所有选项许可授权。他们有可能在受限的CPU中运行以节省成本，直到需要被激活, 但这又增加了RTO。
- Oracle GoldenGate 是一个流式事务性的逻辑复制解决方案。 唯一一个提供多主 (活动-活动)设置。 但是正因为是逻辑层面的复制, 需要小心细致的设计以避免复制冲突和模式改变 。 它可以填补HA空白 , 包括联机升级，且对大多数关键应用，无需深度的设计和监控即可实现双向复制 。
这四种特性都归于 Oracle’s MAA (最大可用性架构) 的不同保护级别和价格 (青铜/白银/黄金/白金)。 我们将把这每一个级别和 YugabyteDB 进行比较。
YugabyteDB
YugabyteDB 是一个分布于多个服务器上单个一致的数据库，这些服务器只共享网络。 通过Raft协议建立复制 , 并应用于两层间的分布式数据和事务 :
- YSQL—SQL处理层
- DocDB—分布式键值对(KV)存储
在这里, Yugabyte 组合了物理复制和逻辑复制的优点 ，对YSQL而言它是物理复制，因为它包含重做日志和行变化日志(WAL)。 对 DocDB而言它是逻辑复制，因为LSM树是对键值而不是SST文件的物理位置建立索引。
一种独特的技术能够保护数据从服务器崩溃 ,磁盘故障,网络分区或者整个数据中心丢失, 可用区丢失,或者云区域丢失等多种错误中恢复。
由于它是分布式的，所有节点都是活动的，因此滚动升级中无需停机, 另外因为数据是以仅追加方式保存的 WAL 和 SST文件, 当写完一个块后, 它就永远不会改变了(和 Oracle或者 PostgreSQL的B-树或者堆表结构相反,这些结构的现存的数据块会持续不断的修改 )。在后台压缩过程中校验检查和以后 , SST文件就不会损坏了,因为它们是不可写的。
因为 YugabyteDB 是云原生的, 特别为云环境进行了设计，云环境任何部分都可能失败,必须在没有人工干预情况下快速恢复。
通过使用通用技术(Raft 日志和MVCC KV变更)，YugabyteDB 在同步集群基础上提供异步复制, 在不影响写性能情况下拓展了可伸缩性 。
这些包括只读复制副本 (用于报表生成, 与Oracle 活动数据卫士的应用类似) 和 xCluster (用于报表生成和灾难恢复 ,与 Oracle GoldenGate 应用类似)。
当我们比较 Oracle 和 YugabyteDB时, 需要考虑每一个 Oracle MAA 级别 (其每一个级别在数据库基础上都有唯一的可用性选项 ) 和单个YugabyteDB 数据库, 在YugabyteDB 中，复制、分片、集群感知都是内建能力。 最好和最简单的方式是通过下表进行比较
数据库比较
比较 YugabyteDB 和 Oracle MAA 级别:
| YugabyteDB | Oracle 数据库最大可用性架构 | ||||
|---|---|---|---|---|---|
| 🚀 YugabyteDB | 🥉 MAA 青铜 | 🥈 MAA 白银 | 🥇 MAA 黄金 | 💰 MAA 白金 | |
| 主要目标 | 云原生弹性 | 备份 | 青铜 + HA | 白银+ DR | 黄金 + 多主 |
| HA/DR 产品 | YugabyteDB 核心内建 | RMAN | RAC | RAC + Data Guard (ADG) | RAC + DG + GoldenGate |
| RPO(恢复点目标 ) | 0 ( 得益于quorum同步复制,无数据丢失) | 分钟级 (归档日志备份) | 和青铜级相同 (无额外保护 ) | 0 (同步模式) | 如无滞后秒级 |
| RTO(恢复时间目标) | Raft leader重新选择需要 3秒 (+TCP 超时时间 ，如果需要重新连接 | 小时到天( 依据数据库规模) | 秒级(服务器崩溃 , 但无数据库保护) | 分钟级,具备 FSFO (同步模式) | 如无冲突秒级 (双向复制) |
| 坏块侦测 | 在后台压缩过程自动检查和修复 | RMAN 检测 + 手工 blockrecover | 无额外保护 | 自动检查坏块丢失 | 无附加保护 |
| 联机升级 | 零停机 | 大版本需几分钟到几小时 | 可以滚动升级某些小版本 (操作系统 ,补丁 ) | 接近零停机时间 ，通过临时逻辑复制备库 | 是, 如果配置双向复制 |
| 人为错误 | 快照调度 | 闪回数据库 , Snapshot Standby, 日志挖掘 , 闪回查询, 闪回事务 dbms_rolling, dbms_redefinition, ASM | |||
| 联机 DLL | 开发中 | 无事务DDL, 但支持 EBR (基于重定义的编辑) | |||
| 多活 | 是, 跨越整个集群的分布式和 ACID. 附加的异步读复制副本 ,和跨集群逻辑复制也是可能的 , | 无, 数据库服务器很少宕机 (如果一年中服务器启动大于10天就必须获得许可 ) | 仅在互联和共享磁盘结构中 (同一数据中心 ), 是 | 无. 通过ADG选项可以读备库 , 但不具备 ACID，不能够写 | 是, 如果双向复制配置为无ACID保证，且 基于手工或者规则消解冲突 |
| 应用连续性 | 通过 HA 代理或者智能驱动, 应用可能会重启动某些查询或者立即重新连接 | CMAN (proxy) | 透明切换且保证事务 | ||
| 复杂性 | 无 (内建集群复制 ) | 低 | 高 | 中等(相对 RAC而言) | 高(和所有逻辑复制一样 ) |
| 价格 (软件) | 免费开源 | 企业版 (50K/CPU) | EE + 50% (RAC 选项) | EE + RAC + 25% (ADG 选项) | EE + RAC + ADG + 75% (100% 但包含 ADG ) |
需要更多的技术信息? 让我们挖掘分布式SQL 复制有何不同
YugabyteDB 将数据和事务处理分布到不同数据库节点上,这些节点都是平等的，存储它们自己的数据库分片（shards 或者 tablets)和复制副本. 每个 tablets 服务器都能够过滤行和列，将改变应用到本存储。
相反, Oracle RAC 移动数据 (数据库块)到处理节点，象典型的单体数据库一样工作，会话进程直接写到缓冲池。这种机制仅在象Extdata 数据库一体机的内部互联网以及 Oracle 云基础架构这种低网络延迟环境才可能。在无共享的公有云环境，其他云提供商既不保证低网络延迟, 也不能够扩充至多台计算机。 使用Oracel ASM 扩展 RAC 集群到多个失败区域是可能的——在一个延伸的集群中——但又一次,仅限于低延迟的网络环境。
所有这些都发生在一个物理数据库中。尽管可以通过Data Guard将其镜像到其他可用区,但所有数据文件的必须是相同的,从一个比特到一个比特,而且只有一个节点是活动的。 进一步，如果要配置多活, 你可能需要加 GoldenGate。而且多活配置只有在有效处理复杂的复制冲突或者在应用层面分片才有可能。 结论是 必须组合所有技术才能够提供最大可用性。
Oracle MAA 组合了Oracle公司在过去30年商业RDBMS发展中开发或者购买的一些非常棒的技术。 随着WEB应用和云架构的的兴起, 无共享的数据库 (NoSQL 和 NewSQL) 已经成为可伸缩性标准。 复制和分片是谷歌 Spanner 这类分布式SQL的基础, 而不是在SQL数据库上又增加一大堆额外的选项。
YugabyteDB 通过分离无状态的SQL层简化了该设置 (PostgreSQL后端, 也是DocDB的客户端) :
- 自动对表和索引进行分片
- 将各种操作(写,锁,二级索引维护,读,表达式,和聚合下推) 作为KV对分发到DocDB中tablet各成员中。
不像传统的数据库，YugabyteDB高可用和高性能并不是一个额外的组件。 相反, 它只需要设置一个简单复制因子,外加一些可选的在数据库层面或者表空间层面映射云提供商,区域和区的信息。 这就是为什么上述表格中 YugabyteDB 只有一列而 Oracle MAA 有四列。
结论
Yugabyte 为用户提供 PostgreSQL 兼容性,以及通常只有在商业数据库才具有的所有高可用特性。 这些特性是 YugabyteDB 核心的一部分,而且完全开源。
当考虑项目移植时，本文和比较表格应有助于你理解 Oracle MAA 选项是如何对应 YugabyteDB’s 内建特性的 。
关于YugabyteDB’s的弹性机制是如何保证在云中断情形下应用连续的更多的一些见解，请参阅如下最近的客户案例:
