カラムストアレプリカ(Cレプリカ)は、OceanBaseの読み取り専用レプリカタイプの一つであり、主に分析型(AP)読み取り専用クエリを処理するために使用されます。データはCレプリカ上でカラムストア形式で保存され、フル機能レプリカ(F)、読み取り専用レプリカ(R)などと組み合わせて使用されます。TP書き込みおよび通常の強力な読み取りは依然として主にF/Rに依存しますが、APスキャンではCレプリカ上でより適したストレージ形態を得ることができます。Cレプリカ上では、すべてのユーザーテーブル(レプリケーションテーブルを含む、インデックステーブル、内部テーブル、システムテーブルを除く)がカラムストア形式で保存されます。OLAP業務は独立したproxyエントリポイントを介してCレプリカにアクセスし、弱い読み取り方式で意思決定分析業務を実行します。
カラムストアレプリカには、主に以下の特徴があります:
完全なログ、MemTable、SSTableなどを含みます。
ベースライン(メジャースタブロ):同一ログストリーム上のユーザーテーブルはCレプリカ上にあり、ベースラインデータはカラムストア形式で整理されており、広範囲のスキャンとAP計算を容易にします。
増分と統合:MemTable、ダンプ(マイナー)などの増分データは依然として行ストア形式で整理されます。Cレプリカはログ(clog)を介してソースレプリカと非同期で同期し、ローカルで再生します。
Paxosメンバーグループを構成することはできません。Paxosメンバーとしてログの投票には参加せず、観察者としてリアルタイムでPaxosメンバーのログを追従し、ローカルで再生するため、投票メンバーの増加によるトランザクションコミット遅延の増加は発生しません。
カラムストアレプリカはPaxos投票には参加せず、非同期でログを追従しローカルで再生することでデータビューを形成するため、一貫性要件が比較的緩やかな読み取り専用分析負荷を担うのに適しています。
同一ログストリーム上で、ユーザーテーブルはMajor SSTableレベルでカラムストアモードで保存されます。
他のレプリカタイプに変換することはできません。
その他の特徴と説明は以下の表のとおりです。
特徴項 |
説明 |
|---|---|
| レプリカ名及び略称 | COLUMNSTORE(C) |
| LOGの有無 | あり、非同期ログですが、Paxosグループには属さず、単なるリスナー(ASYNC_CLOG)です |
| MemTableの有無 | あり(WITH_MEMSTORE) |
| SSTableの有無 | あり(WITH_SSSTORE) |
| データセキュリティ | 中 |
| Leaderへの復元時間 | サポートされていません |
| リソースコスト | 高 |
| サービス | 非一貫性読み取り可能 |
| レプリカタイプ変換制限 | 他のレプリカタイプに変換することはできません |
Cレプリカ上で一時的に行ストアとなるシナリオ
OceanBaseデータベースでは、テーブル作成時に行ストアテーブルであった場合、システムはCレプリカ上に対応する純粋なカラムストアテーブルを作成します。テーブル作成時にカラムストアテーブルであった場合、Cレプリカ上の保存方式はFレプリカと一致します。したがって、Cレプリカは、Fレプリカ上の行ストアユーザーテーブルのユーザーパーティションをカラムストア形式に変換する役割のみを担い、この記述は「最終的」な状態がカラムストアであることを示しています。Cレプリカ上では、必ずしも常にパーティションがカラムストア形式で表現されるわけではありません。以下のシナリオでは、Cレプリカ上のユーザーテーブルパーティションは一時的に行ストアとなり、システムが自発的に行から列への変換タスクをスケジュールし、最新のベースラインデータをカラムストアに変換する必要があります。
シナリオ |
説明 |
|---|---|
| レプリカの補完(レプリカの追加) | Localityを変更してF@z1, F@z2をF@z1, F@z2, C@z3に変更する例を挙げます:
|
| ログストリームのRebuild | Cコピー上のログストリームのRebuildがトリガーされると、システムはソースから対応するベースラインをCコピーにプルします。ベースラインデータが行ストアの場合は一時的に行ストアとなり、バックグラウンドで行から列への変換タスクがスケジュールされた後に列ストアに変換されます。 |
| コピー補完とOffline DDLの同時実行シナリオ | Cコピーがログストリームメンバーリストに含まれている場合、Offline DDLを実行すると、システムはCコピー上に直接列ストアのベースラインを構築します。しかし、コピー補完とOffline DDLが同時に発生すると、CコピーはDDLタスクを実行しているログストリームのリーダーに対して不可視となります。この場合、システムはCコピー上にまず行ストアのベースラインを構築し、バックグラウンドで行から列への変換タスクがスケジュールされた後に列ストアに変換します。 |
| フルダイレクトロード | フルダイレクトロードは現在、まずCコピーに行ストアをインポートし、バックグラウンドで行から列への変換タスクがスケジュールされた後に列ストアに変換することのみをサポートしています。 |
| テーブルレベルの復元 | 現在の列ストアテーブルはテーブルレベルの復元をサポートしていないため、Cコピー上のテーブルレベルの復元も、まず行ストアに復元し、バックグラウンドで行から列への変換タスクがスケジュールされた後に列ストアに変換することのみをサポートしています。 |
上記のシナリオでは、行ストアから列ストアへの変換プロセスにおいて、オプティマイザーが生成するのは列ストアのクエリプランであっても、実際に実行されるのは依然として行ストアのベースラインに対するクエリです。ユーザーはビューCDB_OB_CS_REPLICA_STATS(システムテナント)およびDBA_OB_CS_REPLICA_STATS(ユーザーテナント)を使用して、Cコピーの利用可能情報および行から列への変換の進捗状況を確認できます。行から列への変換タスクが完全に終了した後、Cコピー上でクエリを実行してください。
sysテナント内で、すべてのテナントのCコピーのログストリームにおけるTabletの行から列への変換進捗状況を確認する例を以下に示します:
obclient[oceanbase]> SELECT * FROM oceanbase.CDB_OB_CS_REPLICA_STATS;
クエリ結果は次のとおりです:
+-----------+----------------+----------+-------+------------------+----------------------+-----------------------+---------------------------+-----------+
| TENANT_ID | SVR_IP | SVR_PORT | LS_ID | TOTAL_TABLET_CNT | AVAILABLE_TABLET_CNT | TOTAL_MACRO_BLOCK_CNT | AVAILABLE_MACRO_BLOCK_CNT | AVAILABLE |
+-----------+----------------+----------+-------+------------------+----------------------+-----------------------+---------------------------+-----------+
| 1004 | xx.xxx.xxx.212 | 63000 | 1001 | 1019 | 1019 | 10706 | 10706 | TRUE |
| 1006 | xx.xxx.xxx.212 | 63000 | 1001 | 133 | 133 | 875 | 875 | TRUE |
+-----------+----------------+----------+-------+------------------+----------------------+-----------------------+---------------------------+-----------+
2 rows in set
最初の行のクエリ結果から、テナントIDが1004のテナントのCコピーが配置されているサーバーはxx.xxx.xxx.212、ポート番号は63000であることがわかります。CコピーのログストリームIDは1001、現在列ストアに変換する必要があるパーティションの総数は1019、利用可能なパーティションの総数も1019です。現在のベースラインマクロブロックの総数は10706、利用可能なベースラインマクロブロックの総数も10706です。ユーザーはAVAILABLE_TABLET_CNT / TOTAL_TABLET_CNTまたはAVAILABLE_MACRO_BLOCK_CNT / TOTAL_MACRO_BLOCK_CNTを用いて、行から列への変換の進捗状況を大まかに推定できます。ログストリーム上のすべてのTabletが利用可能になった場合にのみ、そのログストリームは完全に利用可能となります。