YugabyteDBとOracle データベースの可用性比較
Oracleから PostgreSQLに移行する場合において、主な懸念はSQL機能ではありません。なぜなら、PostgreSQLは多くのアプリケーションに十分対応でき、新しい機能を推進する活発なコミュニティがあるからです。代わりに、最大の問題は、Oracle管理者が非常に重要なデータベースに期待するようになっている高可用性 (HA) を実現することです。PostgreSQLのアップグレードにはダウンタイムが必要であり、PostgreSQLによるデータ保護にはデータの損失が伴います。しかし、Oracleには、複数の可用性オプションがあるため、データ損失とダウンタイムを回避してきた長い歴史があります。
幸いなことに、YugabyteDB は、復元性とスケーラビリティのために構築されたエンジン上で、PostgreSQLと同じSQL機能を提供します。これにより、複雑さを増すことなく、データベースで利用できる最高レベルのデータ保護を実現できます。
従来のモノリシックなデータベースとクラウドネイティブなデータベースとの違いを1対1でマッピングすることは困難です。そこで、この記事では、可用性を目的としてYugabyteDBとOracle (RAC、Data Guard) の比較をします。
まず、各データベースで利用可能なオプションを見ていきましょう。
YugabyteDBとOracleの可用性オプション
Oracle
Oracleはモノリシックデータベースです。すべてのセッションは、1つの場所 (行を保存するブロックの現在のバージョン) に書き込む必要があります。バージョン全体を通じて、Oracle は次の 4 つの機能を実装して、復元性 (ハードウェア障害の場合) と可用性の向上 (ソフトウェア アップグレードの場合) を提供しています。
- Oracle RMAN (Recovery Manager) は、オンラインバックアップを管理し、問題を検出し、ディスクの破損や障害が発生した場合に復元します。データは保護されていますが、長い復旧時間が必要です。RTO(目標復旧時間) は、数時間または数日単位で予想されます。アーカイブログをバックアップすることで、データの損失を減らします。RPO(目標復旧時点)は通常時間単位で予想されます。これは、ZRLA (Zero Data Loss Recovery Appliance) などのハードウェアを追加すると、さらに低くなる可能性があります。
- Oracle RAC (Real Application Cluster)は特定のクラスタウェア (CRS) の上にあり、複数のサーバーがスプリットブレインなしで同じデータベースを提供することができます。ただし、これはディスク障害から保護するものではなく、データベースを変更しない程度に限られた数のパッチ適用を可能とするローリングアップグレードのみを実現できます。その原因はRAC自体が共有モノリシックデータベースであるからです。ただし、サーバー障害から保護し、限定的なスケールアウトが可能であるため、高可用性サービスを提供できます。これは、キャッシュとディスクが共有されるため距離のによって制限があるのと、ノード間でブロックが交換されるためパフォーマンスの制限があります。 RTOとRPOは最小限ですが、これはデータベースではなくサーバーの問題です。 ASM (Automatic Storage Management) と組み合わせることで、同じ制限内 (同じ可用性ゾーン内のクラスター) でディスクの冗長性が提供されます。
- Oracle Data Guardは、スタンバイデータベースへストリーミングする物理レプリケーションです。バックアップのようにデータベースを保護しますが、アクティブ化が必要な場合の復元時間も短縮します。当初は障害復旧 (DR) 用に設計されており、プライマリへの影響を軽減するために非同期レプリケーション (ASYNC) を使用しますが、フェイルオーバーの場合にはデータが失う可能性があります。ネットワーク遅延が小さい場合、Data Guardは同期レプリケーション（SYNC）でレプリケートしてデータ損失を回避することもできます (RPO=0)。オブザーバーを追加してFSFO (ファストスタート フェイルオーバー) を有効にすると、フェイルオーバーに人間の介入が不要になり、RTOを数分に短縮されます。追加のオプション (ADG — Active Data Guard) を使用すると、スタンバイ データベースを一部の操作 (読み取り専用セッション、増分バックアップなど) に使用できます。ただし、すべてのスタンバイサイトは、パッシブであっても、すべてのオプションでライセンスを取得する必要があります。コストを削減するためにアクティブ化する必要があるまで、限られた CPU で実行される場合がありますが、これにより RTO が増加します。
- Oracle GoldenGateは、トランザクションのロジカルレプリケーションをストリーミングするソリューションです。マルチマスター (アクティブ-アクティブ) セットアップを提供するのはこれだけですが、ロジカルレベルであるため、レプリケーションの競合やスキーマの変更を避けるために慎重な設計が必要です。徹底した設計と監視により、最も重要なアプリケーションに必要なオンラインアップグレードや双方向レプリケーションといったHA 機能のギャップを埋めることができます。
これらの 4 つの機能は、OracleのMAA(Maximum Availability Architecture) の傘下にあり、さまざまなレベル (ブロンズ/シルバー/ゴールド/プラチナ) のデータ保護 (および価格設定) を提供しています。
次に、上記の各レベルを YugabyteDBと比較して行きます。
YugabyteDB
YugabyteDBは、複数のサーバーに分散された単一の一貫性データベースであり、ネットワークのみを共有します。レプリケーションは Raftプロトコルに組み込まれており、下記の2つのレイヤーでデータとトランザクションを分散するために使用されます。
- YSQL — SQL 処理レイヤー
- DocDB — 分散キーバリューストレージ
ここで、Yugabyteは物理レプリケーションとロジカルレプリケーションの両方の利点を組み合わせます。行変更 (WAL) のREDOログが含まれているため、YSQL にとっては物理的です。 SSTファイル内の物理的な場所ではなく、LSMツリー内のキーにインデックス付けされているため、DocDBにとってはロジカルです。
独自のテクノロジーにより、サーバーのクラッシュ、ディスク障害、ネットワークパーティション、またはデータセンター、アベイラビリティゾーン、またはクラウドリージョンの完全な損失から保護します。
すべてのノードがアクティブな状態で分散されるため、ローリングアップグレード中にダウンタイムは発生しません。また、データは追加専用のWALおよび SSTファイルに保存されるため、ブロックが書き込まれると、そのブロックは変更されません (既存のブロックが継続的に変更されるOracleまたはPostgreSQLのBツリーやヒープテーブルとは対照的です)。バックグラウンドの圧縮でチェックサムが検証されると、SSTファイルは変更不可になるため、後で破損することはありません。
YugabyteDBはクラウドネイティブであるため、どの部分でも障害が発生する可能性があり、人間の介入なしに迅速に復旧する必要があるクラウド環境向けに特別に設計されています。
YugabyteDB は、書き込みに影響を与えずにスケーラビリティを拡張するために、一般的なテクノロジ (RaftログとMVCCキー値の変更) を使用して、同期クラスター上で非同期レプリケーションも提供します。これには、リードレプリカ (レポート用、Oracle Active Data Guardと同様の使用法) および xCluster (レポートまたはディザスタリカバリ用、Oracle GoldenGateと同様の使用法) が含まれます。
OracleとYugabyteDBを比較するときは、レプリケーション、シャーディング、およびクラスタリングがk基本機能として備わっている単一のYugabyteDBデータベースに対して、すべてのOracle MAAレベル (それぞれがデータベースの上に独自の可用性オプションを持っていること) を考慮する必要があります。これを行う最も簡単な方法は、以下の表を使用することです。
データベースの比較
YugabyteDB と各 Oracle MAA レベルの比較を以下にまとめます:
もっと技術的な情報を知りたいですか？分散型SQLレプリケーションの違いを理解しましょう
YugabyteDBは、データとトランザクション処理をデータベースノードに分散します。データベースノードはすべて対等で、それぞれのシャード（タブレット）とレプリカ（タブレットピア）を保存します。行や列のフィルタリング、変更の適用などは、ストレージの隣で各タブレットサーバーによって行われる。
これに対し、Oracle RACではデータ（データベースブロック）を処理ノードに移動し、一般的なモノリシックデータベースのように処理できるようにする。ここでは、セッションの処理は、共有バッファプールに直接書き込まれる。これは、Exadataデータベース・マシンやOracle Cloud Infrastructure内部のインターコネクトのような低遅延ネットワークでのみ可能です。他のパブリッククラウドプロバイダーではサポートされていませんし、シェアードナッシングクラウドで複数のマシンにスケールアウトすることもできません。RACクラスタを複数の障害領域に拡張することは、Oracle ASMを使用してストレッチクラスタで可能ですが、これも低レイテンシネットワークに限定されます。
これらはすべて、1 つの物理データベースで行われます。Data Guardを使用して別のAvailability Zoneにミラーリングすることもできますが、すべてのデータファイルはビット単位で同じであり、アクティブなのは1つのサイトのみです。さらに可用性を高めるには、GoldenGateを追加する必要があります。このアクティブ-アクティブ構成は、複雑なレプリケーションの競合処理またはアプリケーションのシャーディングが設計されている場合にのみ可能です。そのため、最大の可用性を実現するには、あらゆるテクノロジーを組み合わせる必要があります。
Oracle MAAは、過去30年間の商用RDBMSの成長を通じてオラクルが開発した、あるいは買収した優れた技術を組み合わせています。Web アプリケーションとクラウド基盤の台頭により、シェアードナッシングデータベース（NoSQL と NewSQL）はスケールアウトの標準となりました。レプリケーションとシャーディングは、SQLデータベースの上に多くのオプション機能を追加していくものではなく、Google Spannerに基づく分散SQLにおいては基礎となります。
YugabyteDBは、ステートレスSQLレイヤー（DocDBのクライアントでもあるPostgreSQLバックエンド）を以下の方法で分離することで、この設定を簡素化します。
- テーブルとインデックスをタブレットに自動的にシャーディング
- 操作（書き込み、ロック、セカンダリインデックスのメンテナンス、読み取り、式、集約プッシュダウン）をDocDBのタブレット・ピアにキー-バリューペアとして分散
YugabyteDBにおける高可用性と高パフォーマンスは、従来のデータベースのように追加コンポーネントで実現するものではありません。シンプルなレプリケーション・ファクターの設定と、オプションにてクラウドプロバイダー、リージョン、ゾーンに対応するデータベースまたはテーブルスペースレベルで宣言された配置情報の設定で実現されます。上記の比較表で、YugabyteDBが1列しかなく、Oracle MAAが4列もあるのはこのためです。
まとめ
YugabyteDBは、ユーザーにPostgreSQLとの互換性を提供するだけではなく、通常は商用データベースにしかない高可用性機能をすべて提供します。これらはYugabyteDBのコアの一部であり、完全にオープンソースです。
この記事と比較表は、移行プロジェクトを検討する際に、Oracle MAAオプションがYugabyteDBの固有機能にどのようにマッピングされるかを理解するのに役立つはずです。
YugabyteDBの耐障害性がクラウド停止時のアプリケーション継続性をどのように保証しているかについての詳細は、最近の顧客事例をご覧ください。
- How Plume Handled Billions of Operations Per Day Despite an AWS Zone Outage
- How a Fortune 500 Retailer Weathered a Regional Cloud Outage with Yugabyte DB
この比較は、2022年7月にYugabyteのDeveloper AdvocateであるFranck Pachotによって書かれたものです。Franckは、Oracle Databaseに関する20年のコンサルティング経験（Oracle Certified Master、Oracle ACE Director）、「Oracle Database 12c Release 2 Multitenant」（Oracle Press社）の共著者です）。
両データベースの今後のリリースにより、機能が変更される可能性があります。
本記事は、The Distributed SQL Blogsにて2022年8月25日に公開されたComparing the Maximum Availability of YugabyteDB and Oracle Databaseを翻訳および一部訳注を追加しております。最新情報は英語版の記事を参照してください。
今年で4回目となる年次イベントDistributed SQL Summitが2022年9月14日に開催されます。ぜひご登録ください！
