テーブルの作成

CREATE TABLE ステートメントを使用してテーブルを作成できます。

このセクションでは、非パーティションテーブルの作成について説明します。パーティションテーブルの作成と使用方法については、パーティションテーブルの作成を参照してください。

非パーティションテーブルの作成

非パーティションテーブルとは、パーティションが1つしかないテーブルを指します。

非パーティションテーブルを作成する例文は以下のとおりです：

obclient> CREATE TABLE table_name1(w_id int,
w_ytd decimal(12,2),
w_tax decimal(4,4),
w_name varchar(10),
w_street_1 varchar(20),
w_street_2 varchar(20),
w_city varchar(20),
w_state char(2),
w_zip char(9),
unique(w_name, w_city),
primary key(w_id)
);

obclient> CREATE TABLE table_name2 (c_w_id int NOT NULL,
c_d_id int NOT null,
c_id int NOT null,
c_discount decimal(4, 4),
c_credit char(2),
c_last varchar(16),
c_first varchar(16),
c_middle char(2),
c_balance decimal(12, 2),
c_ytd_payment decimal(12, 2),
c_payment_cnt int,
c_credit_lim decimal(12, 2),
c_street_1 varchar(20),
c_street_2 varchar(20),
c_city varchar(20),
c_state char(2),
c_zip char(9),
c_phone char(16),
c_since date,
c_delivery_cnt int,
c_data varchar(500),
FOREIGN KEY (c_w_id) REFERENCES table_name1(w_id),
primary key (c_w_id, c_d_id, c_id)
);

この例では、2つのテーブルを作成し、それぞれのテーブルの列に対して主キーや外部キーなどの制約を定義しています。主キーや外部キーの詳細については、列の制約タイプの定義を参照してください。

テーブルの列を作成する際は、適切なデータ型を選択してください。SQLデータ型の詳細については、データ型を参照してください。

レプリケーションテーブルの作成

レプリケーションテーブルは、OceanBaseデータベースの特殊なテーブルです。このテーブルは、任意の「正常」なレプリカでデータの最新の変更を読み取ることができます。書き込み頻度の要求が低く、読み取り操作の遅延とロードバランシングの要求が高いユーザーにとって、レプリケーションテーブルは優れた選択肢です。

ユーザーがレプリケーションテーブルを作成すると、そのテナント内のすべてのOBServerノードにレプリケーションテーブルのレプリカが作成されます。これらのレプリカのうち1つがリーダーとして選出され、書き込みリクエストを受け付けます。残りのレプリカは読み取りリクエストのみを受け付けることができます。

すべてのレプリカはリーダーに状態を報告する必要があり、主にレプリカの再生進捗、つまりデータ同期の進捗を報告します。一般的に、フォロワーの再生進捗はリーダーより若干遅れますが、その遅れが一定のしきい値を超えない限り、リーダーはレプリカが「正常」な状態にあり、リーダー上の変更を迅速に再生できると判断します。リーダーがあるレプリカを一定期間「正常」と認定すると、そのフォロワーに一定期間のリースを付与します。一般的に言えば、リーダーはその後の一定期間、フォロワーが「正常」な状態を維持し、強整合性読み取りサービスを提供できると「信頼」しています。この「信頼」期間中、リーダーはレプリケーションテーブルのトランザクションをコミットする前に、常にフォロワーの再生進捗を確認します。フォロワーがそのトランザクションの変更を再生した後、リーダーはユーザーにトランザクションのコミット成功を通知します。この時点で、ユーザーはフォロワー上で、ちょうどコミットされたトランザクションの変更を読み取ることができます。

レプリケーションテーブル機能は、OceanBaseデータベースV3.xバージョンから存在していました。しかし、V4.xバージョンでは、OceanBaseデータベースのアーキテクチャが大きく変更されたため、V4.xのレプリケーションテーブルは、単一マシンログストリームの新しいアーキテクチャに適応するために、パーティションに基づく読み取り可能バージョン番号の検証およびログストリームに基づくリース付与メカニズムを構築し、強整合性読み取りの正確性を保証しています。

さらに、V4.xバージョンのレプリケーションテーブル機能は、リーダー切り替え時にトランザクションをキルしない機能を向上させています。ユーザーまたはロードバランシングがリーダー切り替えを開始すると、未コミットのレプリケーションテーブルトランザクションは、V3.xバージョンのように継続できなくなることはなく、リーダー切り替え後に実行を続けることができます。V3.xバージョンと比較して、V4.xのレプリケーションテーブル機能は、書き込みトランザクションのパフォーマンスが向上し、災害復旧能力も強化されており、レプリカのダウンが読み取り操作に与える影響が低くなっています。

レプリケーションテーブルの制限事項

• レプリケーションテーブル：

  • レプリケーションテーブルの作成制限：sysテナントおよびmetaテナントにはブロードキャストログストリームがないため、レプリケーションテーブルの作成はサポートされません。

  • 書き込み性能はノード数の影響を受ける：レプリケーションテーブルへの書き込みはすべてのレプリカに同期する必要があるため、ノード数が多いほど書き込み性能に大きな影響を与えます。

    • 回避策：レプリケーションテーブルの書き込みと読み取りを同一トランザクション内で行うことは避けてください。レプリケーションテーブルに対する純粋な書き込みまたは純粋な読み取りのトランザクションは問題ありません。

  • プロパティ変換：

    • レプリケーションテーブルとTableGroupは互斥関係にあり、レプリケーションテーブルのTableGroupプロパティを変更しようとするとエラーが発生します。通常のテーブルをレプリケーションテーブルに変換する際、その通常のテーブルが特定のTableGroupに属している場合、プロパティ変更コマンドはエラーになります。
    • レプリケーションテーブルの変換はロードバランシングとtransferに依存しているため、関連するパラメータが有効な状態であることを確認する必要があります。

  • ルーティング：

    • トランザクション内でレプリケーションテーブルに対する書き込み操作があり、その後レプリケーションテーブルをクエリする際、ランダムにフォロワーにルーティングされた場合、レプリカが読み取り不可である問題に直面する可能性があります。これは、observer内部で再ルーティングされてレプリケーションテーブルのリーダーに到達する際に、クエリ性能に影響を与えます。

      • ODP V4.3.3ではルーティング戦略が調整されており、レプリケーションテーブルに対する書き込み操作があった場合、その後のクエリはレプリケーションテーブルのリーダーにルーティングされます。

    • レプリケーションテーブルと通常のテーブルをJOINするクエリ操作では、レプリケーションテーブルに基づいてランダムにルーティングされます（JOINクエリについては、ODPは最初のテーブルに基づいてルーティングします）。この際、通常のテーブルの非リーダーノードにルーティングされる可能性があり、リモートプランが発生する原因となります。

    • 通常のテーブルのプロパティをレプリケーションテーブルに変更しても、ODPはそれを検出できず、レプリケーションテーブルに基づいてルーティングして負荷を分散することができません。

  • トランザクション内でレプリケーションテーブルに変更を加えた後のクエリ操作：レプリケーションテーブルをクエリする際、生成された実行計画はローカルレプリカを選択しますが、変更が加えられているためレプリカが読み取り不可であるエラーが発生します。SQLはリトライしてリーダーレプリカを選択しますが、この時点でプランキャッシュがヒットせず、クエリ性能が低下します。

    説明

    OceanBaseデータベースでは、トランザクション内でレプリケーションテーブルに変更を加えた場合、システムはクエリ時に常にレプリケーションテーブルのリーダーレプリカを優先的に選択し、直接ローカルレプリカを選択することはありません。これにより、OceanBaseデータベースはクエリ効率を向上させ、誤ったレプリカの選択を回避します。

• ブロードキャストログストリーム：

  • 各ユーザーテナントは最大1つのブロードキャストログストリームしか持てません。
  • ブロードキャストログストリームと通常のログストリーム間のプロパティ変換はサポートされていません。
  • ブロードキャストログストリームの手動削除はサポートされていません。現在はテナントの削除と同時に削除されます。

レプリケーションテーブルの作成構文

レプリケーションテーブルを作成する構文は、CREATE TABLE ステートメントの後に DUPLICATE_SCOPE オプションを追加することです。レプリケーションテーブルはユーザーテナントのみが作成でき、sys テナントでは作成できません。レプリケーションテーブルを作成するSQLステートメントは以下のとおりです：

CREATE TABLE table_name column_definition DUPLICATE_SCOPE='none | cluster';

ここで、DUPLICATE_SCOPE パラメータはレプリケーションテーブルの属性を指定するために使用され、取り得る値は以下のとおりです：

• none：このテーブルが通常のテーブルであることを示します。
• cluster：このテーブルがレプリケーションテーブルであることを示し、リーダーはトランザクションを現在のテナント内のすべてのFレプリカおよびRレプリカに複製する必要があります。

テーブル作成時に DUPLICATE_SCOPE を指定しない場合、デフォルト値は none です。

CREATE TABLE dup_t1 (c1 NUMBER,c2 NUMBER) DUPLICATE_SCOPE= 'cluster';

あるテナントで最初のレプリケーションテーブルが作成されると、システムは同時に特殊なログストリーム、つまりブロードキャストログストリームを作成します。その後に新規作成されるレプリケーションテーブルはすべて、このブロードキャストログストリーム上に作成されます。ブロードキャストログストリームは通常のログストリームと異なり、テナント内の各OBServerノードに自動的にレプリカをデプロイするため、理想的な状況下では、レプリケーションテーブルは任意のOBServerノードで強整合性読み取りを提供できます。テナントのレプリケーションテーブルが配置されているブロードキャストログストリームを確認するには、以下のSQLを実行します：

SELECT * FROM SYS.DBA_OB_LS WHERE flag LIKE "%DUPLICATE%";

クエリ結果の例は以下のとおりです。

+-------+--------+--------------+---------------+-------------+---------------------+----------+---------------------+---------------------+-----------+-----------+
| LS_ID | STATUS | PRIMARY_ZONE | UNIT_GROUP_ID | LS_GROUP_ID | CREATE_SCN          | DROP_SCN | SYNC_SCN            | READABLE_SCN        | FLAG      | UNIT_LIST |
+-------+--------+--------------+---------------+-------------+---------------------+----------+---------------------+---------------------+-----------+-----------+
|  1003 | NORMAL | z1;z2        |             0 |           0 | 1684982852976428261 |     NULL | 1684983282912048623 | 1684983282912048623 | DUPLICATE |           |
+-------+--------+--------------+---------------+-------------+---------------------+----------+---------------------+---------------------+-----------+-----------+
1 rows in set

例では、LS_ID が 1003 のログストリームがブロードキャストログストリームであり、現在のテナントのすべてのレプリケーションテーブルはこのログストリーム上に作成されています。ブロードキャストログストリームの詳細については、レプリカの紹介を参照してください。

レプリケーションテーブルの作成が成功すると、通常のテーブルと同様に挿入や読み書き操作を実行できます。ただし、読み取りリクエストの場合、Proxy経由でデータベースに接続すると、リクエストは任意のOBServerノードにルーティングされて実行される可能性があります。一方、直接接続でデータベースに接続する場合、ローカルのレプリカが読み取り可能であれば、システムは直接接続されたOBServerノード上で読み取りリクエストを実行します。データベース接続方法の詳細については、接続方法の概要を参照してください。

既存テーブルのデータをコピーして新しいテーブルを作成する

CREATE TABLE AS SELECT ステートメントを使用すると、テーブルの基本データ型とデータをコピーできますが、制約、インデックス、NOT NULLなどの属性は含まれません。

例：

CREATE TABLE t2_copy AS SELECT * FROM t2;

CREATE TABLE LIKE ステートメントを使用してテーブル構造をコピーすることはサポートされていません。

行ストアテーブルの作成

OceanBaseデータベースは、行ストアテーブルの作成および行ストアとカラムストアの変換機能をサポートしています。

パラメータdefault_table_store_format=‘row’（デフォルト値）が設定されている場合、デフォルトで作成されるテーブルは行ストアテーブルです。default_table_store_formatがrow以外の場合は、WITH COLUMN GROUP(all columns)オプションを設定することで行ストアテーブルを作成できます。

行ストアとカラムストアの変換に関する情報については、テーブルの変更を参照してください。カラムストアインデックスの作成に関する情報については、インデックスの作成を参照してください。

WITH COLUMN GROUP(all columns)を指定して行ストアテーブルを作成します。

例：

CREATE TABLE tbl1_cg (col1 INT PRIMARY KEY, col2 VARCHAR(50)) WITH COLUMN GROUP(all columns);

カラムストアテーブルの作成

OceanBaseデータベースは、カラムストアテーブルの作成、行ストアとカラムストアの変換、およびカラムストアインデックスの作成をサポートしています。WITH COLUMN GROUPオプションを設定することで、明示的にカラムストアまたは行ストア/カラムストアの冗長状態を指定できます。また、パラメータdefault_table_store_formatを設定することで、カラムストアまたは行ストア/カラムストアの冗長をデフォルトのストレージ形式に設定できます。

行ストアとカラムストアの変換に関する情報については、テーブルの変更を参照してください。カラムストアインデックスの作成に関する情報については、インデックスの作成を参照してください。

WITH COLUMN GROUP(all columns, each column)を指定して、行ストア/カラムストアの冗長テーブルを作成します。

例：

CREATE TABLE tbl1_cg (col1 NUMBER PRIMARY KEY, col2 VARCHAR2(50)) WITH COLUMN GROUP(all columns, each column);

WITH COLUMN GROUP(each column)を指定して、カラムストアテーブルを作成します。

例：

CREATE TABLE tbl2_cg (col1 NUMBER PRIMARY KEY, col2 VARCHAR2(50)) WITH COLUMN GROUP(each column);

カラムストアテーブルを作成して使用する際、大量のデータをインポートした場合は、読み取り性能を向上させるために一度のメジャーコンパクション操作を実行し、統計情報収集を行って実行戦略を調整する必要があります。

• メジャーコンパクション操作：データを一括インポートした後、メジャーコンパクション操作を一度実行することを推奨します。これは、断片化されたデータを整理し、物理的に連続した状態にすることで、読み取り時のディスクI/Oを削減し、読み取り性能を向上させるのに役立ちます。データインポート後、テナント内で一度メジャーコンパクション操作をトリガーし、すべてのデータがベースライン層にマージされていることを確認してください。操作についてはMAJOR AND MINORを参照してください。

• 統計情報収集：メジャーコンパクション操作完了後、統計情報の収集を行うことを推奨します。これは、オプティマイザーが有効なクエリ計画と実行戦略を生成するために非常に重要です。GATHER_SCHEMA_STATSを実行して、すべてのテーブルの統計情報を収集し、ビューGV$OB_OPT_STAT_GATHER_MONITORで収集進捗を監視できます。

注意点として、カラムストアテーブルのデータ量が増加するにつれて、メジャーコンパクション操作の速度が低下する可能性があります。

テーブルの更新モデルの指定

テーブル作成時に更新モデルを指定する構文は、CREATE TABLE ステートメントの後にテーブルオプション MERGE_ENGINE を追加することです。SQLステートメントは以下のとおりです：

CREATE TABLE table_name column_definition
    MERGE_ENGINE = {delete_insert | partial_update}
    WITH COLUMN GROUP([all columns,] each column);

ここで、MERGE_ENGINE パラメータはテーブルの更新モデルを指定するために使用され、取り得る値は以下のとおりです：

• partial_update：デフォルト値で、既存の更新モードを変更しないことを意味します。
• delete_insert: merge on write 方式を採用し、update を delete と insert に変換し、全列を書き込むことを意味します。

MERGE_ENGINE オプションを指定しない場合、このオプションの値は構成パラメータ default_table_merge_engine の値と同じになります。

適用シナリオ

OLAPシナリオでは delete_insert の使用が推奨されますが、それ以外のシナリオでは partial_update の使用が推奨されます。より詳細な構成シナリオの紹介については、構成のベストプラクティスを参照してください。

例：

• 純粋なカラムストアテーブル mer_tbl1 を作成し、更新モデルを merge on write に設定します。

  CREATE TABLE mer_tbl1 (col1 NUMBER, col2 NUMBER) MERGE_ENGINE = delete_insert WITH COLUMN GROUP(each column);
  

• 行ストアとカラムストアの冗長テーブル mer_tbl2 を作成し、更新モデルを merge on write に設定します。

  CREATE TABLE mer_tbl2 (col1 NUMBER, col2 NUMBER) merge_engine = delete_insert WITH COLUMN GROUP(all columns, each column);
  

関連ドキュメント

• CREATE TABLE

• ALTER TABLE