OceanBaseデータベースは、シェアードナッシング（Shared-Nothing、SN）モードと共有ストレージ（Shared-Storage、SS）モードの2種類のデプロイメントモードをサポートしています。
シェアード・ノウルーム・モードなし
シェアード・ノウルーム（SN）モードの分散クラスターアーキテクチャは、OceanBaseデータベースでよく使用されるデプロイ方法です。SNモードでは、各ノードは完全に対等であり、各ノードは独自のSQLエンジン、ストレージエンジン、トランザクションエンジンを持ち、一般的なPCサーバーで構成されたクラスター上で動作します。高い拡張性、高可用性、高性能、低コスト、主要なデータベースとの高い互換性などのコア機能を備えています。
OceanBaseデータベースのクラスターは、複数のノードで構成されます。これらのノードは複数のゾーン（Zone）に属しており、各ノードは1つのゾーンに属します。ゾーンは論理的な概念であり、クラスター内でハードウェアの可用性が類似するノードのグループを表します。異なるデプロイモードでは、その意味合いも異なります。例えば、クラスター全体が単一のデータセンター（IDC）内にデプロイされている場合、1つのゾーンのノードは同じラックや同じスイッチに属することがあります。クラスターが複数のデータセンターに分散している場合、各ゾーンは1つのデータセンターに対応することがあります。各ゾーンにはIDCとリージョン（Region）という2つの属性があり、そのゾーンが存在するIDCおよびIDCが属する地域を記述します。一般的に、リージョンはIDCが所在する都市を指します。ゾーンのIDCとRegion属性は、デプロイ時の実際の状況を反映させる必要があり、これによりクラスター内の自動ディザスタリカバリ処理や最適化戦略がより効果的に機能します。業務によってデータベースシステムに求められる高可用性要件が異なるため、OceanBaseクラスターは複数のデプロイモードを提供しています。デプロイモードの詳細については、OceanBaseクラスター高可用性デプロイソリューションの概要を参照してください。
OceanBaseデータベースでは、テーブルのデータは特定の分割ルールに従って水平方向に複数のシャードに分割でき、各シャードをテーブルパーティション、略してパーティション（Partition）と呼びます。各行データは1つのパーティションにのみ属します。パーティションのルールはユーザーがテーブル作成時に指定し、Hash、Range、Listなどのタイプのパーティションをサポートしており、さらにサブパーティションもサポートしています。例えば、取引データベースの注文テーブルでは、まずユーザーIDに基づいて複数のパーティションに分割し、さらに月単位で各パーティションを複数のサブパーティションに分割できます。サブパーティションテーブルでは、サブパーティションの各パーティションが物理パーティションであり、パーティションは論理的な概念にすぎません。テーブルの複数のパーティションは、1つのゾーン内の複数のノードに分散配置できます。各物理パーティションには、順序付けられたデータレコードを格納するためのストレージ層オブジェクトであるTabletがあります。
ユーザーがTablet内のレコードを変更する際、データの永続性を保証するために、RedoログをTabletに対応するログストリーム（Log Stream、LS）に記録する必要があります。各ログストリームは、それが存在するノード上の複数のTabletにサービスを提供します。データを保護し、ノード障害発生時にサービスを中断しないために、各ログストリームとそれに属するTabletには複数のレプリカがあります。一般的に、複数のレプリカは複数の異なるゾーンに分散されています。複数のレプリカのうち、変更操作を受け付けるのは1つだけであり、これをリーダーレプリカ（Leader）と呼び、他のレプリカをフォロワーレプリカ（Follower）と呼びます。リーダーレプリカとフォロワーレプリカの間では、Multi-Paxosに基づく分散型コンセンサスプロトコルにより、レプリカ間のデータ一貫性が実現されています。リーダーレプリカが存在するノードで障害が発生した場合、フォロワーレプリカの1つが新しいリーダーレプリカとして選出され、サービスを継続します。
クラスターの各ノードでは、observerと呼ばれるサービスプロセスが実行され、その内部には複数のオペレーティングシステムスレッドが含まれます。ノードの機能はすべて対等です。各サービスは、自身が存在するノード上のパーティションデータの格納・取得を担当するとともに、ローカルホストにルーティングされたSQL文の解析と実行も担当します。各ノード上のobserverサービスプロセス間では、TCP/IPプロトコルを介して通信が行われます。同時に、各サービスは外部アプリケーションからの接続要求をリッスンし、接続とデータベースセッションを確立して、データベースサービスを提供します。observerサービスプロセスの詳細については、スレッドの概要を参照してください。
大規模な複数の業務データベースのデプロイ管理を簡素化し、リソースコストを削減するために、OceanBaseデータベースは独自のマルチテナント機能を提供しています。1つのOceanBaseクラスター内では、互いに隔離されたデータベース「インスタンス」を複数作成でき、これをテナントと呼びます。アプリケーションの観点から見ると、各テナントは独立したデータベースインスタンスと同等です。さらに、各テナントはMySQL互換モードまたはOracle互換モードを選択できます。アプリケーションがMySQLテナントに接続すると、テナント内でユーザーやデータベースを作成でき、独立したMySQLデータベースを使用する体験と一致します。同様に、アプリケーションがOracleテナントに接続すると、テナント内でスキーマを作成したりロールを管理したりでき、独立したOracleデータベースを使用する体験と一致します。新しいクラスターが初期化されると、最初にsysという名前の特殊なテナント、すなわちシステムテナントが存在します。システムテナントにはクラスターのメタデータが保存されており、MySQL互換モードのテナントです。
機能の適用範囲
OceanBaseデータベースCommunity EditionはMySQLモードのみを提供します。
テナントのリソースを隔離するために、各observerプロセス内には、異なるテナントに属する複数の仮想コンテナが存在でき、これをリソースユニット（Unit）と呼びます。リソースユニットにはCPUとメモリリソースが含まれます。各テナントの複数ノード上のリソースユニットが1つのリソースプールを形成します。
OceanBaseデータベースがアプリケーションから内部のパーティションやレプリカの分散などの詳細を隠蔽し、アプリケーションが分散データベースに単一マシンのデータベースにアクセスするかのように簡単にアクセスできるようにするために、OceanBaseデータベースプロキシODP（OceanBase Database Proxy、OBProxyとも呼ばれる）サービスを提供しています。アプリケーションはOceanBaseデータベースノードに直接接続するのではなく、まずODPに接続し、その後ODPがSQLリクエストを適切なOceanBaseデータベースノードに転送します。ODPはステートレスなサービスであり、複数のODPノードがネットワーク負荷分散（例えば、SLB）を通じてアプリケーションに統一されたネットワークアドレスを提供します。
共有ストレージモード
マルチクラウド環境においてユーザーによりコスト効率の高いデータベースサービスを提供するため、OceanBaseデータベースは汎用オブジェクトストレージを基盤として共有ストレージ（SS）モードを実装し、クラウド上でクラウドネイティブなデータベースサービスを提供します。これにより、データベースの使用コストを削減し、パフォーマンスと使いやすさを向上させます。
SSモードは、SNモードの基盤の上でストレージとコンピューティングを分離したアーキテクチャを採用しています。読み書きノード（RW）が読み書きサービスを提供し、0個以上の読み取り専用ノード（RO）が読み取りサービスを提供するため、コンピューティングノードの単独でのスケーリングが可能となり、高い柔軟性を実現します。
SSモードでは、アップロードノード（SSWriter）が増分データとベースラインデータを生成し、オブジェクトストレージにアップロードする役割も担っています。コンピューティングノード間ではオブジェクトストレージ上のすべてのデータを共有し、データのヒートを自動的に識別します。すべてのコンピューティングノードはホットデータをローカルキャッシュするのみであるため、低遅延と高スループットを最適化します。
さらに、SSモードではログとコンピューティングを分離しています。データベースのログサービスは、独立した高性能で高可用性、強整合性を備え、ログアクセスの特性に極めて最適化された分散型ストレージシステムによって提供されます。図中のログサービス（LogService）がそれに該当します。
このアーキテクチャでは、ログはログサービスのレプリカ間で一貫性プロトコルを通じて同期されるだけであり、データの永続性が保証されます。そのため、コンピューティングノードにはログ状態が存在せず、複数レプリカのコンピューティングノードをデプロイする必要がなくなり、コストを大幅に削減できます。さらに、コンピューティングノードはログに依存せずに迅速に読み取り専用ノード（RO）を追加できるため、柔軟性を一段と高めることができます。
同時に、読み書きノード（RW）はPaxosプロトコルを介してログサービスの複数レプリカに直接書き込むことで高可用性を実現し、読み取り専用ノード（RO）は最新のログサービスレプリカからログを読み取り、ローカルでホットデータを再生することで、低遅延と高スループットをさらに最適化します。