ログストリームとレプリカの概要

OceanBaseデータベースは、従来のデータベースのパーティションテーブルの概念を参考にしており、1つのテーブルのデータを複数のパーティション(Partition)に分割します。V4.x系では、パーティションはユーザーが作成する論理オブジェクトであり、テーブルデータを分割・管理するための仕組みです。

各パーティションには対応するデータストレージオブジェクトがあり、これをTabletと呼びます。Tabletはデータを格納する機能を持ち、マシン間での移行(transfer)をサポートしており、データ分散の最小単位となります。Tabletはパーティションと一対一で対応しており、単一パーティションテーブルでは1つのTabletが作成され、複数パーティションテーブルでは各パーティションごとに1つのTabletが作成されます。

ログストリームは、OceanBaseデータベースが自動的に作成・管理するエンティティであり、複数のTabletと順序付きRedoログストリームからなるデータ集合を表します。Paxosプロトコルを用いて複数レプリカ間のログ同期を実現し、レプリカ間のデータ整合性を保証することで、データの高可用性を実現しています。

分散環境下では、データの読み書きサービスの高可用性を確保するため、OceanBaseデータベースは同一ログストリームのデータを複数のマシンにコピーします。異なるマシン上にある同一ログストリームのデータコピーをレプリカ(Replica)と呼びます。同一ログストリームの複数レプリカは、Paxos整合性プロトコルを用いてレプリカ間の強い整合性を保証し、各ログストリームとそのレプリカは独立したPaxosグループを構成します。このうち1つのログストリームがリーダーレプリカ(Leader)となり、他のログストリームはフォロワーレプリカ(Follower)となります。リーダーレプリカは強い整合性を持つ読み書き機能を備え、フォロワーレプリカは弱い整合性を持つ読み取り機能を備えます。

ロケーションキャッシュ

OceanBaseデータベースは、ログストリームおよびシャードに基づいてユーザーデータを組織し、各ログストリームには災害復旧用の複数のレプリカが存在します。そのため、SQLリクエストの実行時にはパーティションデータの位置情報を把握し、特定のマシンにルーティングして対応するレプリカのデータを読み書きする必要があります。このパーティションデータの位置情報を「ロケーション(Location)」と呼び、各observerプロセスには、自身のマシンで必要なパーティションのロケーション情報を更新およびキャッシュするためのサービスが存在します。このサービスを「ロケーションキャッシュ(Location Cache)」サービスと呼びます。

V4.0.0バージョンからログストリームおよびシャードの概念が導入されました。パーティションデータのロケーション情報を取得するには、パーティションに対応するシャード、シャードとログストリームのマッピング関係、およびログストリームレプリカの位置情報を知る必要があります。これらの情報は、以下のシステムテナントのデータディクショナリから取得できます：

• oceanbase.CDB_OBJECTS：OBJECT_TYPE を TABLE、TABLE PARTITION、または TABLE SUBPARTITION に指定することで、対応するパーティションの DATA_OBJECT_ID、すなわち TABLET_ID（テナント内のシャードの一意識別子）を取得できます。

• oceanbase.CDB_OB_TABLET_TO_LS：シャードが属するログストリームを取得します。ログストリームはテナント内で LS_ID によって一意に識別されます。

• oceanbase.CDB_OB_LS_LOCATIONS：ログストリームのレプリカタイプおよび位置を取得します。

レプリカタイプ

ログストリームレプリカが保存するデータの種類によって、レプリカは異なるタイプに分類され、データの安全性、パフォーマンスのスケーラビリティ、可用性、コストなどの観点から、さまざまなビジネスニーズに対応します。

OceanBaseデータベースは、以下のタイプのレプリカをサポートしています：

• フル機能型レプリカ(FULL/F)

  フル機能型レプリカはPaxosレプリカと呼ばれ、対応するレプリカはPaxosメンバーグループを構成し、選挙投票に参加できます。

• 読み取り専用型レプリカ(READONLY/R)

  V4.x系では、OceanBaseデータベースはV4.2.0バージョンから読み取り専用型レプリカをサポートしています。読み取り専用型レプリカは非Paxosレプリカであり、対応するレプリカはPaxosメンバーグループを構成できず、選挙投票にも参加しません。

• カラムストア型レプリカ(COLUMNSTORE/C)

  V4.x系では、OceanBaseデータベースはV4.3.3バージョンからカラムストア型レプリカをサポートしています。カラムストア型レプリカは読み取り専用型レプリカと同様に非Paxosレプリカであり、対応するレプリカはPaxosメンバーグループを構成できず、選挙投票にも参加しません。

分散一貫性プロトコル

OceanBaseデータベースは、同一ログストリーム内の各レプリカ間でトランザクションログを同期するためにPaxosプロトコルを使用します。多数派が同期に成功した場合にのみ、トランザクションがコミットされます。デフォルトでは、読み書き操作はリーダーレプリカ上で強い一貫性が保証されます。フォロワーレプリカは弱い一貫性の読み取りをサポートしており、若干古いバージョンのデータを読み取ることが許可されています。

さらに、V4.3.x系では、OceanBaseデータベースはV4.3.1バージョンからRレプリカをRegion単位でカスケード化する機能をサポートしています。RegionをまたいでデプロイされたRレプリカは、自動的にツリー状のカスケード構造を形成してログを同期し、Region間のネットワークトラフィック消費を削減できます。

データバランシング

OceanBaseデータベースは、Root Serviceを通じてテナント内の各リソースユニット間のロードバランシングを管理します。異なるタイプのレプリカはそれぞれ異なるリソース要件を持つため、Root Serviceがバランシング操作を実行する際には、各リソースユニットのCPU使用率、ディスク使用量、メモリ使用量、およびIOPS使用状況などの要素を考慮する必要があります。ロードバランシングを経て、最終的にすべてのマシンの各種リソースの占有状況が比較的均等な状態になり、各マシンの全リソースが最大限に活用されます。

Root Serviceは主に以下の2つの方法でデータバランシングを実現します：

• レプリカバランシング

  Root Serviceは、Unitの移行やログストリームレプリカの複製・移行といった手法を通じて、テナント内の各マシン上のリソース占有状況を調整します。

• リーダーバランシング

  レプリカバランシングを基盤として、Root ServiceはテナントのPrimary Zoneなどの要因に基づき、各マシンのログストリームのリーダー数を自動的に作成およびバランシングします。ログストリームリーダーのバランシングに関する詳細は、テナント内バランシングを参照してください。