システムアーキテクチャ

OceanBaseデータベースは、シェアードナッシング(Shared-Nothing、SN)と共有ストレージ(Shared-Storage、SS)という、2種類の分散デプロイモードに対応しています。

シェアードナッシング(SN)モード

SNモードは、OceanBaseデータベースにおける主要な分散アーキテクチャです。このモードでは、各ノードがSQLエンジン、ストレージエンジン、トランザクションエンジンを個別に持ち、完全に対等な構成で動作します。これらのノードは、汎用的なサーバー上で一つのクラスタとして動作し、高い拡張性、可用性、パフォーマンス、コスト効率を実現します。さらに、主要なデータベースとの高い互換性も備えています。

OceanBaseのクラスタは複数の「ノード」で構成され、これらのノードは「ゾーン(Zone)」という論理グループに分けられます。各ノードは、必ずいずれかのゾーンに所属します。ゾーンは、可用性の観点が近接したノード群をまとめたもので、例えば単一データセンター(IDC)内では「同じラック」・「同じvSwitch」を、複数データセンターにまたがる構成では「データセンター自体」を一つのゾーンとして定義できます。各ゾーンは、物理的な位置情報を示す「IDC」と「リージョン(Region)」という2つの属性を持ちます。通常、リージョンはIDCの所在都市を指します。これらの属性を実際の構成に合わせて正しく設定することで、クラスタの自動障害復旧や最適化が効果的に機能するようになります。ビジネスの可用性要件に応じて、OceanBaseクラスタは複数の高可用性デプロイモードをサポートしています。詳細については、OceanBaseクラスタ高可用性デプロイプランの概要を参照してください。

OceanBaseデータベースでは、テーブルのデータを特定のルールに基づいて水平に分割し、複数の「パーティション」に格納できます。テーブルの各行は、いずれか一つのパーティションにのみ属します。パーティションの分割ルールは、テーブル作成時にユーザーが指定します。これには、Hash、Range、Listといったパーティショニングタイプがあり、さらにサブパーティションもサポートされています。例えば、取引データベースの注文テーブルでは、まずユーザーIDごとに複数の一次パーティションに分割し、次に各一次パーティションを月ごとにサブパーティションに分けることが可能です。サブパーティションを使用するコンポジット・パーティションテーブルの場合、一次パーティションは論理的なグループ分けとして機能し、実際のデータはサブパーティション単位で格納されます。複数のパーティションは、一つのゾーン内の複数のノードに分散配置されます。各物理パーティションは、データを格納するためのストレージ層オブジェクトを持ち、これは「Tablet」と呼ばれ、順序付けられたデータレコードを保持します。

ユーザーがTablet内のレコードを更新する際、データの永続性を保証するため、RedoログがTabletに対応するログストリーム(Log Stream、LS)へ書き込まれます。各ログストリームは、同一ノード上にある複数のTabletで共有されます。データを保護し、ノード障害時にもサービスを継続できるよう、各ログストリームとそれに紐づくTabletは複数のレプリカを持ちます。通常、これらのレプリカは異なるゾーンに分散配置されます。書き込み操作を担うレプリカはリーダー(Leader)のみで、他はフォロワー(Follower)です。リーダーとフォロワー間のデータ一貫性は、Multi-Paxosに基づく分散合意プロトコルによって保証されます。万が一、リーダーレプリカのノードに障害が発生した場合は、いずれかのフォロワーレプリカが新しいリーダーに昇格し、処理を継続します。

クラスタの各ノードでは、「observer」と呼ばれるサービスプロセスが実行されます。このプロセスは複数のOSスレッドで構成されています。ノードの機能はすべて対等です。各observerプロセスは、担当ノード上のパーティションデータの保存と取得、およびそのノードにルーティングされたSQLステートメントの解析・実行を担います。ノード間の通信は、それぞれのobserverプロセスがTCP/IPプロトコルを用いて行います。また、observerプロセスは外部アプリケーションからの接続要求を監視し、データベースセッションを確立してサービスを提供する役割も担っています。observerサービスプロセスの詳細については、スレッドの概要を参照してください。

複数の業務データベースを大規模に運用する際の管理を簡素化し、リソースコストを削減するために、OceanBaseデータベースは独自のマルチテナント機能を提供します。この機能により、一つのOceanBaseクラスタ内に、互いに完全に隔離されたデータベース環境を複数作成できます。この独立した環境を「テナント」と呼びます。アプリケーションの観点から見ると、各テナントはそれぞれが独立したデータベースインスタンスのように振る舞います。さらに、テナントごとにMySQLまたはOracleの互換モードを選択することが可能です。MySQL互換テナントに接続すると、ユーザーやデータベースを作成でき、独立したMySQLデータベースと同じように使用できます。Oracle互換テナントに接続すると、スキーマの作成やロールの管理ができ、独立したOracleデータベースと同じように使用できます。クラスタを新規に初期化すると、「sys」という名前を持つシステムテナントが自動で作成されます。このシステムテナントはクラスタ全体のメタデータを格納し、MySQL互換モードで動作します。

テナントのリソース隔離は、各observerプロセス内に配置される仮想コンテナ「リソースユニット(Unit)」によって実現されます。各リソースユニットは特定のテナントに割り当てられ、CPUとメモリのリソースを保持します。複数ノードにまたがるユニット群が、各テナントのリソースプールを構成します。

また、OceanBaseデータベースは、内部のパーティションやレプリカの分散といった複雑な構成をアプリケーションから隠蔽し、あたかも単一のデータベースを扱うかのようにアクセスできるようにするため、ODP(OceanBase Database Proxy、OBProxyとも呼ばれる)というプロキシサービスを提供しています。アプリケーションは、データベースノードに直接接続するのではなく、まずODPに接続します。ODPは受け取ったSQLリクエストを解析し、適切なデータベースノードに転送する役割を担います。ODP自体はステートレスなサービスであり、複数台で構成することで、SLB(Server Load Balancer)のようなロードバランサー(負荷分散装置)と連携し、アプリケーションに単一のアクセスポイントを提供します。

共有ストレージ(SS)モード

OceanBaseデータベースは、よりコストパフォーマンスの高いデータベースサービスを提供するため、汎用的なオブジェクトストレージを基盤とした共有ストレージ(SS)モードも提供しています。このクラウドネイティブなアーキテクチャは、データベースの利用コストを削減し、パフォーマンスと利便性の向上を実現します。

SSモードは、ストレージと計算リソースを分離している点です。各テナントのデータとログは共有オブジェクトストレージに保存される一方、頻繁にアクセスされるホットデータやログは各ノードのローカルストレージにキャッシュされます。これにより、ストレージコストを抑えつつ、高速なデータアクセスを可能にしています。

ログの複製にはPaxosプロトコルが用いられ、テナントのログストリームのレプリカ間で一貫性を保ちます。各レプリカのログは、まずノードのローカルストレージに書き込まれます。その後、リーダーレプリカが全てのログをオブジェクトストレージにアップロードする仕組みです。各フォロワーレプリカは、必要なホットログのみを自動的に判断してローカルにキャッシュします。

データに関しても同様に、リーダーレプリカが全てのベースラインデータをオブジェクトストレージにアップロードし、複数のレプリカ間で共有します。各レプリカは、アクセス頻度の高いホットデータのみをローカルにキャッシュすることで、効率的なデータ管理を実現します。なお、各レプリカは独立してデータのダンプ（バックアップ）を行いますが、このダンプされたデータはレプリカ間では共有されません。