OceanBase Cloudクラウドデータベースは現在、シングルデータセンター（2ノード）構成、シングルデータセンター（3ノード）構成、二つのデータセンターによるデプロイメント、および複数のデータセンターによるデプロイメントの4種類のデプロイプランをサポートしています。
概念の紹介
- フル機能レプリカ：フル機能レプリカは通常レプリカとも呼ばれ、略称はFULLまたはFで、RedoLog、MemTable、SSTableなど、すべての完全なデータと機能を有しています。フル機能レプリカにはロールの概念があり、データパーティションにもLeaderとFollowerのロールがあります。Leaderは主に外部への書き込みサービスと強整合性読み取りサービスを提供し、弱整合性読み取りサービスも提供できます。Followerは外部への弱整合性読み取りサービスを提供し、Leaderに障害が発生した場合には迅速に切り替わって外部へのサービスを提供することができます。
- アービトレーションサービス：OceanBaseデータベースはアービトレーションサービス（Arbitration Service）、略称Aをサポートしています。アービトレーションサービスはテナントのログストリームに対応するアービトレーションメンバーを管理しており、アービトレーションメンバーには以下の特徴があります。詳細についてはアービトレーションサービスの概要をご参照ください。
- 選挙、Paxos Prepare、メンバーグループ変更の投票にのみ参加し、ログ多数派投票（Paxos Accept）には参加しません。
- ログを格納せず、MemTableやSSTableがないため、リソース（帯域幅/メモリ/ディスク/CPU）の消費が極めて少ないです。
- プライマリとして選出されてサービスを提供することはできません。
OceanBase Cloudのさまざまなデプロイプランでは、異なるタイプのレプリカとアービトレーションサービスを1つまたは複数のゾーンにデプロイします。
フラグシップ版クラスタインスタンス
フラグシップ版インスタンスは、コンピューティングとストレージを分離したアーキテクチャを採用しており、同一クラスタ内にさまざまなワークロードタイプのテナントを作成できます。これにより、「1つのクラスタで複数のワークロードを処理する」統合環境を実現します。Oracle互換モード、MySQL互換モード、HBase API互換モード、Table API互換モードをサポートしており、トランザクション処理、リアルタイム分析、大規模データの格納・アクセスなど、複数の処理要件が混在する複雑なビジネスシナリオに対応できます。
アーキテクチャ概要
デプロイ方式：2レプリカ構成（推奨）および1レプリカ構成をサポートしており、ビジネス要件に応じて柔軟に選択できます。
マルチワークロード対応：同一クラスタ内に、OLTP（トランザクション処理）型、KV（Key-Value）型、OLAP（分析処理）型など、異なるワークロード向けのテナントを作成できます。これにより、システム構成を簡素化し、運用管理の負荷を軽減できます。また、各テナントはリソースが分離されているため、ワークロード間の影響を抑制できます。
コンピューティング・ストレージ分離：コンピューティングリソースとストレージリソースを個別に拡張できます。また、性能要件に応じてローカルキャッシュを柔軟に調整できます。データは同一リージョン内のマルチAZ冗長ストレージに保存され、高い可用性とデータ信頼性を確保します。2レプリカ構成では、RPO=0（データ損失ゼロ）およびRTO 8秒未満（8秒以内の高速フェイルオーバー）を実現します。
コスト最適化：コスト効率の高いストレージメディアを活用し、保持対象のデータを1コピーで管理します。また、実際の使用量に応じた従量課金方式を採用しているため、事前にストレージ容量を確保する必要がありません。さらに、高度なデータ圧縮技術により、ストレージコストを削減できます。
一元管理：監視、アラート、バックアップ、リカバリなどの運用管理機能を一元化し、システム管理の複雑さを大幅に軽減します。また、テナントごとに独立したパラメータ設定やリソース管理を行うことができます。
トランザクション型インスタンス
トランザクション型インスタンスの共有ストレージアーキテクチャは、注文アーカイブ、取引データのコールドスタンバイ、金融業界の監査、ログアーカイブなどのシナリオに適しています。書き込みが多く読み取りが少ない、単一インスタンスで単一テーブルのデータ量が膨大というビジネス特性を持ち、通常は数百TBからPBレベル以上に達します。書き込みRTには敏感ではなく、書き込みトラフィックに絶対的なピークがなく常に安定しています。データの一貫性には敏感ですが、読み取りRTはコアTP系ビジネスと比べて大きな差はありません。効率的な少数のシンプルなトランザクション型クエリをサポートする必要があります。また、トランザクション型インスタンスの共有ストレージアーキテクチャを選択する際には、以下の特性にも注意する必要があります：
ストレージの拡張性：増加し続けるデータ量を処理でき、ストレージアーキテクチャを調整する必要がありません。ストレージ容量は大量データの保存の可拡張性と、オンラインデータベースのデータの効率的かつ継続的なインポートに対応する能力が必要です。
ストレージコスト：大量のデータによりストレージコストが急激に増加するため、より経済的なストレージ媒体でより多くのデータを保存する必要があります。
クエリパフォーマンス：履歴データへのアクセス頻度は低いものの、特定のシナリオでは履歴データのクエリRTがオンラインデータのクエリRTに近いものである必要があります。
アーキテクチャの説明
デプロイ方法：2レプリカ（推奨）と1レプリカのデプロイモードをサポートしています。
ストレージとコンピューティングの分離：極めて柔軟に、コンピューティングとストレージはそれぞれ独立して拡張できます。ローカルキャッシュはパフォーマンスを保証するために独立して調整可能です。全量データは同一リージョンの冗長ストレージモードを採用し、データの安全性と信頼性を保証します。2レプリカモードではRPO = 0、RTO < 8秒を保証します。
コストの優位性：より低コストなストレージ媒体を使用した上で、全量データを1部のみ保存し、実際の使用量に応じて課金します。事前にストレージ容量を割り当てる必要がなく、Shared-Nothingアーキテクチャと同等の高圧縮率を備えています。
ログの独立性：Paxosに基づく独立したログストレージサービスで、コンピューティングノードから分離されています。
分析型インスタンス
分析型インスタンスの共有ストレージアーキテクチャは、Ad hocクエリ、BIレポート、多次元分析、リアルタイム分析、ユーザープロファイリング、指標計算、リアルタイムリスク管理などのシナリオに適しています。同一のプラットフォームがオンラインクエリとオフライン計算の統一された機能を提供し、データ量が膨大でPBレベル以上をサポートする必要があります。リアルタイム計算、ミリ秒/秒単位の高効率なクエリパフォーマンスをサポートし、外部データレイク（ODPS、Hiveなど）や他のデータソースとの連携分析も可能です。計算リソースとストレージリソースは必要に応じて弾力的に拡張可能で、より細分化されたリソース利用とコスト削減を実現します。また、分析型インスタンスの共有ストレージアーキテクチャを選択する際には、以下の特性にも注意が必要です：
複雑なアーキテクチャ：従来のオフラインデータウェアハウスとオンラインリアルタイム分析では、複数の技術スタックを維持する必要があるため、技術的難易度と運用コストが上昇します。
ストレージコスト：データレイクの台頭とデータウェアハウスとの統合により、大量データストレージ容量の拡張性が求められる一方で、ストレージコストも急激に増加しているため、大量のデータをより経済的なストレージ媒体で保存する必要があります。
クエリパフォーマンス：特に多次元集計や複雑な計算を伴う大規模データセットでは、クエリパフォーマンスと応答の即時性に対する要求が高くなります。
アーキテクチャの説明
デプロイ方法：分析型インスタンスは主に単一レプリカデプロイモードを採用しており、独立したログサービスに基づきAZ間のディザスタリカバリ機能を実現し、RPO = 0、RTO分単位を保証し、ビジネスのコスト削減を極限まで推進します。
高性能：列指向ストレージに基づき集計操作を高速化し、演算子と式のベクトル化形式への対応によりベクトル化実行エンジンの性能を大幅に向上させます。マテリアライズドビューは、柔軟なリフレッシュ戦略とリアルタイムマテリアライズドビューによりクエリパフォーマンスを大幅に向上させます。リライトとコストに基づくオプティマイザーは、さまざまな複雑なクエリシナリオに対してより柔軟なクエリリライト機能と、計画生成時に並列度を自動調整する機能を提供します。
低コスト：より低コストのストレージ媒体を使用し、全量データを1セットのみ保存する必要があります。ローカルキャッシュ容量は必要に応じて柔軟に指定できます。
拡張性：外部テーブルと外部データソースの統合機能が柔軟で、外部ファイル（CSV/Parquet/ORC）、外部データソース（OSS/HDFS/S3…）、Catalog（ODPS/Hive）をサポートします。
Key-Value型インスタンス
Key-Value型インスタンスの共有ストレージアーキテクチャは、IoT、車両ネットワーク、時系列の構造化・半構造化・非構造化データなどのシナリオに適しています。同一の技術スタックは、多様なモデルデータと複数のオープンソース標準インターフェースの管理を同時にサポートし、SQLクエリ、時系列処理、検索分析などの機能を提供し、大量の構造化データ・半構造化データのストレージと分析ニーズを満たす必要があります。大量データストレージの拡張性とコストには一定の要求があります。また、Key-Value型インスタンスの共有ストレージアーキテクチャを選択する際には、そのアーキテクチャの複雑さにも注意が必要です。日々多様化するビジネスニーズによる多種多様なデータと、データストレージ技術アーキテクチャの複雑化およびコストの急速な上昇との間には矛盾があります。データの種類ごとに異なるストレージ分析技術を採用すると、関連する技術コンポーネントが多岐・複雑になります。さらにビジネスの発展に伴い、データ型の多様化によりデータごとに異なる処理が求められ、データストレージのさらなる断片化が予想されます。
アーキテクチャの説明
デプロイ方法：1レプリカと2レプリカをサポートします。
マルチモーダル統合：同一のプラットフォームで、多様なモデルデータを管理できます。HBase互換のワイドテーブルサービスを提供するとともに、テーブルに基づく大量アクセス能力も備えています。JSON、GIS、Vector、Arrayなどの半構造化データをサポートし、さらにオブジェクトストレージなどの標準タイプのネイティブ操作インターフェースも提供します。
高可用性：OBKVのすべてのノードは機能が同等で、非常に高い可用性を備えており、従来のHBaseアーキテクチャにおけるZKなどの一部の重要なコンポーネントに起因する単一障害点のリスクを排除します。
マルチテナント：OceanBaseデータベースのネイティブマルチテナントアーキテクチャにより、完全なリソース共有とリソース分離能力を有しています。
低コスト：高い圧縮率により、ストレージ層は理論上無限に拡張可能で、より低コストで大量の構造化・半構造化・非構造化データの拡張を実現できます。
フラグシップ版クラスタインスタンス
フラグシップ版インスタンスは、シェアード・エブリシング型（Shared-Everything）の「コンピュート・ストレージ統合アーキテクチャ」を採用し、複数のデプロイ構成に対応しています。可用性、パフォーマンス、およびコストに関するビジネス要件に応じて、最適な構成を柔軟に選択できます。
単一データセンター（2レプリカ）構成
OceanBase Cloudにおける「単一データセンターデプロイメント」では、同一アベイラビリティゾーン（AZ）内に2つのフル機能レプリカを配置します。これにより、AZ間やデータセンター間通信に起因するネットワーク遅延を排除できるため、極めて低いレイテンシーやコストパフォーマンスを重視するシナリオに最適です。
物理ホストレベルの障害に対する耐障害性を備えているだけでなく、単一データセンターデプロイメントには以下のようなメリットがあります。
複数のフル機能レプリカが同時に読み書きサービスを提供できるため、より効率的でパフォーマンスの高いロードバランシング（負荷分散）を実現できます。
書き込みリクエスト処理時のAZ間データ同期が不要になり、同一AZ内で同期処理とアクセスが完結するため、レスポンスのレイテンシーを最小限に抑えられます。
単一データセンター（3レプリカ）デプロイメント
OB Cloudにおける「単一データセンター（3レプリカ）デプロイメント」では、3つのフル機能レプリカをすべて同一AZ内に配置します。これにより、AZ間やデータセンター間通信に起因するレイテンシーを排除できるため、低レイテンシーかつ単一クラスター全体の処理能力（スループット）を最大限に引き出したいシナリオに適しています。
物理ホストレベルの障害に対する耐障害性を備えているだけでなく、単一データセンターデプロイメントには以下のようなメリットがあります。
複数のフル機能レプリカが同時に読み書きサービスを提供できるため、より効率的でパフォーマンスの高いロードバランシング（負荷分散）を実現できます。
書き込みリクエスト処理時のAZ間データ同期が不要になり、同一AZ内で同期処理とアクセスが完結するため、レスポンスのレイテンシーを最小限に抑えられます。
デュアルデータセンターデプロイメント
「デュアルデータセンターデプロイメント」では、2つのフル機能レプリカをそれぞれ異なる2つのAZに分散配置し、3つ目のAZに「アルビトレーションサービス」を配置します。このアルビトレーションサービスは、トランザクションログの同期や再生を行わず、Redoログやベースラインデータも保持しません。また、外部クライアントからの読み書きリクエストの受付も行いません。なお、デュアルデータセンターデプロイメントはバージョン4.1.0.0以降からサポートしています。
マルチデータセンターデプロイメント
「マルチデータセンターデプロイメント」では、3つのレプリカを3つの異なるAZに分散配置し、万が一のゾーン障害（AZレベルの障害）に対する強力な耐障害性を実現します。各レプリカはすべてフル機能レプリカとして動作し、通常はプライマリレプリカ（1台）が読み書きサービスを提供、他の2台のスタンバイレプリカは読み取り専用サービスを担当します。プライマリレプリカで障害が発生した場合には、自動的にスタンバイレプリカがプライマリに昇格し、サービスを中断することなく読み書き処理を引き継ぎます。
ビジネス継続性を重視し、アベイラビリティゾーンをまたぐ高度な災害復旧（可用性）とパフォーマンスを両立させたい場合は、マルチデータセンターデプロイメントが推奨されます。
デプロイメント構成の比較
デプロイメント方式 |
単一データセンター（2レプリカ） |
単一データセンター（3レプリカ） |
デュアルデータセンター |
マルチデータセンター |
|---|---|---|---|---|
| ノード／サービス数 | 3 | 3 | 3 | 3 |
| フル機能レプリカ数 | 2 | 3 | 2 | 3 |
| アービトレーションサービス数 | 1 | 0 | 1 | 0 |
トランザクション型インスタンス
シングルデータセンター（2ノード）デプロイメント
OceanBase Cloudのシングルデータセンター構成では、2つのフル機能ノードを同一のゾーンに配置し、ゾーン間やデータセンター間で生じるレイテンシを解消します。低レイテンシが求められ、コスト削減が重要なシナリオに適しています。 ホストレベルの障害復旧機能を備えており、シングルデータセンター構成には以下の利点もあります：
複数のフル機能レプリカが同時に読み書きを提供し、より高性能なロードバランシングサービスを実現します。
シングルデータセンター構成では、書き込みリクエストはデータセンター間で同期する必要がなく、同一データセンター内でのデータ同期とアクセスを行うため、レイテンシが小さくなります。
シングルデータセンター（3ノード）構成
OceanBase Cloudのシングルデータセンター構成では、3つのフル機能ノードを同一のゾーンに配置し、ゾーン間やデータセンター間で生じるレイテンシを解消します。低レイテンシが求められ、単一クラスタの総計算力規模が重要なシナリオに適しています。
ホストレベルの障害復旧機能を備えており、シングルデータセンター構成には以下の利点もあります：
複数のフル機能レプリカが同時に読み書きを提供し、より高性能なロードバランシングサービスを実現します。
シングルデータセンター構成では、書き込みリクエストはデータセンター間で同期する必要がなく、同一データセンター内でのデータ同期とアクセスを行うため、レイテンシが小さくなります。
デュアルデータセンター構成
OceanBase Cloudのダブルデータセンターデプロイプランでは、2つのフル機能ノードを2つのゾーンに配置し、3つ目のゾーンにアービトレーションノードを配置します。アービトレーションノードはログの同期や再生、Redoログやベースラインデータの格納、外部への読み書きサービスの提供は行いません。現在、4.1.0.0以降のバージョンがダブルデータセンター構成をサポートしています。
マルチデータセンター構成
OceanBase Cloudのマルチデータセンター構成では、3つのノードを3つの異なるゾーンに配置し、ゾーン間での障害復旧を実現します。 各ノードはフル機能レプリカであり、そのうち1つのプライマリレプリカが読み書きサービスを提供し、2つのスタンバイレプリカが読み取り専用サービスを提供します。プライマリレプリカに障害が発生した場合、スタンバイレプリカがプライマリレプリカに昇格し、読み書きサービスを継続します。
パフォーマンスとマルチデータセンターの可用性に対してより高い要件を持つお客様は、マルチデータセンターデプロイプランの選択を推奨します。
各デプロイプランの違い
デプロイプラン |
シングルデータセンター(2ノード) |
シングルデータセンター(3ノード) |
デュアルデータセンター |
マルチデータセンター |
|---|---|---|---|---|
| ノード数 | 3 | 3 | 3 | 3 |
| フル機能レプリカ数 | 2 | 3 | 2 | 3 |
| アービトレーションノード | 1 | 0 | 1 | 0 |
分析系インスタンス
シングルデータセンター（単一ノード）構成
OceanBase Cloudのシングルデータセンター（単一ノード）構成は、軽量なデプロイメント方式であり、フル機能レプリカが1つしか存在せず、複数ゾーンにまたがる災害復旧機能を備えています（災害復旧用ゾーンはインスタンスコンソールで指定可能）。テスト学習、事業継続性や高可用性に対する要求が低い場合、非コア業務のコスト最適化などのシナリオに適しています。
特長は以下のとおりです：
データは1つのレプリカのみ：データは1つのレプリカにのみ保存され、データの同期レプリケーションメカニズムはありません。複数レプリカ戦略（通常は高可用性を確保するために3つのデータを保存）と比較して、単一レプリカはストレージ容量とレプリケーションオーバーヘッドを節約します。
リソース消費が少ない：単一レプリカモードでは、複数のレプリカ間のデータ一貫性を維持する必要がないため、計算リソースとネットワークトラフィックの消費が削減されます。予算が限られているシナリオや、災害復旧要件が低い業務により適しています。
性能が高い：単一レプリカ構成では、データレプリケーションや一貫性検証のオーバーヘッドが存在しないため、リクエストは1つのレプリカで処理されることに集中し、結果として低遅延と高スループットを実現します。
シングルデータセンター（2ノード）デプロイメント
OceanBase Cloudのシングルデータセンター構成は、2つのフル機能ノードを同一ゾーンにデプロイし、複数ゾーン/複数データセンターによる遅延を解消します。低遅延でコスト削減のニーズが高いシナリオに適しています。 ホストレベルの障害に対する災害復旧機能を備えており、さらにシングルデータセンター構成には以下の利点もあります：
複数のフル機能レプリカが同時に読み書き機能を提供し、より高性能なロードバランシングサービスを提供します。
シングルデータセンター構成の書き込みリクエストは、データセンター間での同期を必要とせず、同一データセンター内でのデータ同期とアクセスを行うため、遅延が低く抑えられます。
デュアルデータセンター構成
OceanBase Cloudのデュアルデータセンターデプロイプランでは、2つのフル機能ノードを2つのゾーンにデプロイし、3つ目のゾーンにアービトレーションノードをデプロイします。アービトレーションノードはログの同期や再生、Redoログやベースラインデータの格納、外部への読み書きサービスの提供は行いません。現在、4.1.0.0以降のバージョンがデュアルデータセンター構成をサポートしています。
デプロイメントスキームの違い
デプロイプラン |
シングルデータセンター(単一ノード) |
シングルデータセンター(2ノード) |
デュアルデータセンター |
|---|---|---|---|
| ノード数 | 1 | 3 | 3 |
| フル機能レプリカ数 | 1 | 2 | 2 |
| アービトレーションサービス | 0 | 1 | 1 |
説明
2F1A（2つのフル機能レプリカと1つのアービトレーションサービス） レプリカデプロイメントでは、アービトレーションサービスノードはユーザーには見えないため、3つのノードを購入しても、実際にシステムで見えるのは2つのノードのみです。
Key-Value型インスタンス
シングルデータセンター（2ノード）デプロイメント
OceanBase Cloudの単一データセンター構成では、2つのフル機能ノードを同一ゾーンに配置し、ゾーンまたはデータセンターをまたがる遅延を解消します。低遅延とコスト削減のニーズが高いシナリオに適しています。 ホストレベルの障害復旧機能を備えており、単一データセンター構成には以下の利点もあります：
複数のフル機能レプリカが同時に読み書き機能を提供し、より高性能なロードバランシングサービスを実現します。
単一データセンター構成では、書き込みリクエストはデータセンター間で同期する必要がなく、同一データセンター内でのデータ同期とアクセスを行うため、遅延が低く抑えられます。
デュアルデータセンター構成
OceanBase Cloudのデュアルデータセンターデプロイプランでは、2つのフル機能ノードを2つのゾーンに配置し、3つ目のゾーンにアービトレーションノードを配置します。アービトレーションノードはログの同期や再生、Redoログやベースラインデータの格納、外部への読み書きサービスの提供は行いません。現在、V4.1.0.0以降のバージョンがデュアルデータセンター構成をサポートしています。
デプロイプランの違い
デプロイプラン |
シングルデータセンター(2ノード) |
デュアルデータセンター |
|---|---|---|
| ノード数 | 3 | 3 |
| フル機能レプリカ数 | 2 | 2 |
| アービトレーションサービス | 1 | 1 |
説明
2F1A（2つのフル機能レプリカと1つのアービトレーションサービス）レプリカデプロイメントでは、レプリカ案のアービトレーションサービスノードはユーザーには見えないため、3つのノードを購入しても、実際にシステム上で見えるのは2つのノードのみです。