システムアーキテクチャ

OceanBaseデータベースは、シェアードナッシング（Shared-Nothing）分散クラスターアーキテクチャを採用しており、各ノードは完全に対等であり、各ノードには独自の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互換モードのテナントです。

テナントのリソースを隔離するために、各observerプロセス内には、異なるテナントに属する複数の仮想コンテナが存在でき、これをリソースユニット（Unit）と呼びます。リソースユニットにはCPUとメモリリソースが含まれます。各テナントの複数ノード上のリソースユニットが1つのリソースプールを形成します。

OceanBaseデータベースがアプリケーションから内部のパーティションやレプリカの分散などの詳細を隠蔽し、アプリケーションが分散データベースに単一マシンのデータベースにアクセスするかのように簡単にアクセスできるようにするために、OceanBaseデータベースプロキシODP（OceanBase Database Proxy、OBProxyとも呼ばれる）サービスを提供しています。アプリケーションはOceanBaseデータベースノードに直接接続するのではなく、まずODPに接続し、その後ODPがSQLリクエストを適切なOceanBaseデータベースノードに転送します。ODPはステートレスなサービスであり、複数のODPノードがネットワーク負荷分散（例えば、SLB）を通じてアプリケーションに統一されたネットワークアドレスを提供します。