カラムストアレプリカの使用

TP強化型のハイブリッドワークロード（準リアルタイムの意思決定分析）シナリオに対応するため、OceanBaseデータベースはカラムストアレプリカ（COLUMNSTORE、以下Cレプリカと略称）をサポートしています。ユーザーはCレプリカを独立したゾーンにデプロイできます。Cレプリカでは、すべてのユーザーテーブル（複製テーブルを含み、インデックステーブル、内部テーブル、システムテーブルは除く）がカラムストア形式で保存されます。OLAP業務は独立したプロキシエントリを通じてCレプリカにアクセスし、弱い整合性読み取り方式で意思決定分析系の業務を実行します。

注意事項

Cコピーを使用する際には、以下の点に注意してください：

• V4.3.5 BP1バージョン以降では、複数のCコピーのデプロイがサポートされており、最大で3つのCコピーをデプロイすることを推奨します。

• CコピーとFコピーまたはRコピー間での相互変換はサポートされていません。

• Cコピーへのアクセスには独立したODPのデプロイが必要なため、Cコピーが存在するゾーンにはCコピーのみをデプロイすることを推奨します。同時に、ODPをデプロイする際には、そのバージョンがODP V4.3.2以上である必要があります。

• F/Rコピー上のクエリはCコピーへ転送することができません。逆に、Cコピー上のユーザーテーブルクエリもF/Rコピーへ転送することはできず、そうしないとエラーが発生します。

• Cコピーがデプロイされているクラスタでは、DDL操作を実行する際にCPU、メモリ、ディスク、I/Oなどのリソース使用に影響が出ます。

• Cコピーのメジャーコンパクションは、F/Rコピーのメジャーコンパクションよりも遅いです。Cコピーのメジャーコンパクションが完了していない場合、新たなテナントレベルのメジャーコンパクションを開始することはできません。手動でメジャーコンパクションをトリガーする前に、CDB_OB_ZONE_MAJOR_COMPACTIONまたはDBA_OB_ZONE_MAJOR_COMPACTIONビューを確認し、前回のすべてのコピーでメジャーコンパクションが完了しているかどうかを確認することを推奨します。

  メジャーコンパクション状況の詳細な操作については、メジャーコンパクション情報の表示を参照してください。

• 物理復旧ではCコピーの復旧はサポートされておらず、指定されたテナントのローカリティにCコピーが指定されている場合、復旧操作は失敗します。

• プライマリデータベースにCコピーがデプロイされていない場合、スタンバイデータベースにもCコピーをデプロイすることは推奨されません。

CコピーのデプロイとODPの設定

以下の内容は、OceanBaseクラスタ内でODPをデプロイし、CコピーにアクセスするためのODPの設定方法について説明します。

ステップ１：Cコピーのデプロイ

クラスタ内にCコピーをデプロイするには、テナントのローカリティにCコピーを指定するだけです。主に以下の2つのシナリオがあります：

• テナント作成時にCコピーを指定する

• テナントのローカリティを変更してCコピーを追加する

テナント作成時にCコピーを指定する

既にデプロイ済みのクラスタがあり、そのクラスタのデプロイモードが2F1A（2コピー＋1アービトレーションサービス）であると仮定します。クラスタ内の3つのゾーンはそれぞれzone1、zone2、zone3であり、アービトレーションサービスはzone3にデプロイされています。このクラスタ上にCコピーを含むテナントを作成する手順は以下の通りです：

1. 現在のクラスタとネットワークで相互接続可能なマシンを見つけ、そのマシンにODPをデプロイします。

   リソース競合を防ぐため、ODPは単独のマシンにデプロイすることを推奨します。ODPのデプロイ時には、バージョンがODP V4.3.2以降である必要があります。ODPの詳細なデプロイ手順については、ODPのデプロイを参照してください。

2. テナント用のリソースユニットunit1を作成します。

   obclient [oceanbase]> CREATE RESOURCE UNIT unit1, MAX_CPU=5, MIN_CPU=5, MEMORY_SIZE= '32G', MAX_IOPS=10000, MIN_IOPS=5000, LOG_DISK_SIZE=5301023539200;
   

3. テナント用のリソースプールpool1を作成し、リソースユニットとしてunit1を指定します。

   obclient [oceanbase]> CREATE RESOURCE POOL pool1 UNIT='unit1', UNIT_NUM = 1, ZONE_LIST = ('zone1','zone2','zone3');
   

4. テナントtenant_cを作成し、そのローカリティをF@zone1,F@zone2,C@zone3と指定します。

   obclient [oceanbase]> CREATE TENANT tenant_c LOCALITY = 'F@zone1,F@zone2,C@zone3', primary_zone='zone1;zone2,zone3', RESOURCE_POOL_LIST=('pool1') SET ob_tcp_invited_nodes = '%';
   

   この例では、作成されるテナントはデフォルトでMySQL互換モードのテナントです。Oracle互換モードのテナントを作成する場合は、システム変数ob_compatibility_modeを使用して明示的にob_compatibility_mode='oracle'と指定する必要があります。

テナントのローカリティを変更してCコピーを追加する

現在のクラスタにtenant_cという名前のテナントがあり、そのローカリティはF@zone1,F@zone2,F@zone3で、テナントのリソースプールはpool1であり、そのZONE_LIST範囲は'zone1','zone2','zone3'です。今回、テナントにCコピーを追加する必要があるため、Zone4を追加し、テナントのローカリティをF@zone1,F@zone2,F@zone3,C@zone4に変更します。手順は以下のとおりです：

1. クラスタに新しいゾーンzone4を追加します。ゾーンの追加手順の詳細については、ゾーンの追加を参照してください。

2. zone4にノードを追加します。ノードの追加手順の詳細については、ノードの追加を参照してください。

3. 現在のクラスタとネットワークで相互接続可能なマシンを見つけ、そのマシンにODPをデプロイします。

   リソース競合を防ぐため、ODPは単独のマシンにデプロイすることを推奨します。ODPをデプロイする際には、バージョンがODP V4.3.2以降である必要があります。ODPのデプロイ手順の詳細については、ODPのデプロイを参照してください。

4. リソースユニットunit2を作成します。

   obclient [oceanbase]> CREATE RESOURCE UNIT unit2, MAX_CPU=5, MIN_CPU=5, MEMORY_SIZE= '32G', MAX_IOPS=10000, MIN_IOPS=5000, LOG_DISK_SIZE=5301023539200;
   

5. リソースプールpool2を作成し、リソースユニットをunit2と指定します。

   obclient [oceanbase]> CREATE RESOURCE POOL pool2 UNIT = 'unit2', UNIT_NUM = 1, ZONE_LIST = ('zone4');
   

6. テナントにリソースプールpool2を追加します。

   obclient [oceanbase]> ALTER TENANT tenant_c RESOURCE_POOL_LIST = ('pool1','pool2');
   

7. テナントのローカリティをF@zone1,F@zone2,F@zone3,C@zone4に変更します。

   obclient [oceanbase]> ALTER TENANT tenant_c LOCALITY = 'F@zone1,F@zone2,F@zone3,C@zone4';
   

ステップ2：ルーティング転送ポリシーと弱い整合性読み取りリクエストの設定

Cコピーをデプロイした後、OLAPリクエストが自動的に弱い整合性読み取りリクエストに変換され、対応するCコピーに転送されるように、ルーティング転送ポリシーと弱い整合性読み取りリクエストを設定する必要があります。

1. root@proxysysユーザーで、CコピーにアクセスするためのODPにログインします。

   接続例は以下のとおりです：

   [admin@obtest ~]$ obclient -uroot@proxysys -h10.10.10.1 -P2883 -p
   

2. 以下のステートメントを実行して、ルーティング転送ポリシーと弱い整合性読み取りリクエストを設定します。

   次の2種類の構成パラメータの組み合わせがサポートされており、いずれか一方を選択して設定することができます。

   • パターン1

     • SQLリクエストを読み取り専用タイプに設定します。

       obclient> ALTER PROXYCONFIG SET obproxy_read_only = 0;
       

     • SQLリクエストを弱い整合性読み取りに設定します。

       obclient> ALTER PROXYCONFIG SET obproxy_read_consistency = 1;
       

     • 弱い整合性読み取りの場合、ODPのすべてのリクエストをCコピーが存在するゾーンにのみルーティングし、同時にCコピーのクエリ計画を生成します。

       例えば、Cコピーが存在するゾーンがzone4の場合。

       obclient> ALTER PROXYCONFIG SET proxy_primary_zone_name='zone4';
       

       obclient> ALTER PROXYCONFIG SET init_sql='set @@ob_route_policy = COLUMN_STORE_ONLY';
       

   • パターン2

     • SQLリクエストを読み取り専用タイプに設定します。

       obclient> ALTER PROXYCONFIG SET obproxy_read_only = 0;
       

     • SQLリクエストを弱い整合性読み取りに設定します。

       obclient> ALTER PROXYCONFIG SET obproxy_read_consistency = 1;
       

     • 弱い整合性読み取りの場合、すべてのリクエストをCコピーにのみルーティングし、同時にCコピーのクエリ計画を生成します。

       obclient> ALTER PROXYCONFIG SET route_target_replica_type = 'ColumnStore';
       

       obclient> ALTER PROXYCONFIG SET init_sql='set @@ob_route_policy = COLUMN_STORE_ONLY';
       

     • 弱い整合性読み取りの場合、すべてのリクエストがスレーブコピーからのみ選択され、スレーブコピーがすべて利用不可能な場合は、クライアントとの接続を切断します。

       obclient> ALTER PROXYCONFIG SET proxy_route_policy='TARGET_REPLICA_TYPE_FOLLOWER_ONLY';
       

3. 変更が成功したら、以下のステートメントを使用して、変更結果を確認します。

   obclient> SHOW PROXYCONFIG ALL LIKE 'obproxy_read_only';
   

   obclient> SHOW PROXYCONFIG ALL LIKE 'obproxy_read_consistency';
   

   obclient> SHOW PROXYCONFIG ALL LIKE 'proxy_primary_zone_name';
   

   obclient> SHOW PROXYCONFIG ALL LIKE 'init_sql';
   

   obclient> SHOW PROXYCONFIG ALL LIKE 'route_target_replica_type';
   

   obclient> SHOW PROXYCONFIG ALL LIKE 'proxy_route_policy';
   

設定が成功すると、OLAP業務において、ユーザーはこの独立したODPを通じてクエリリクエストをCコピーに向けることができ、カラムストアのバッチ処理の利点を活用してクエリを高速化できます。また、既存のOLTP業務に影響を与えません。

Cコピー上で一時的に行ストアとなるいくつかのシナリオ

OceanBaseデータベースでは、テーブルが作成時に行ストアテーブルである場合、システムはCコピー上に対応する純粋なカラムストアテーブルを作成します。一方、テーブルが作成時にカラムストアテーブルである場合、Cコピー上のストレージ方式はFコピーと同一になります。したがって、CコピーはFコピー上に行ストアされているユーザーテーブルのユーザーパーティションをカラムストアに変換する役割のみを担い、この記述は「最終的」にカラムストア状態になることを示しています。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が利用可能である場合にのみ、そのログストリームは完全に利用可能となります。