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データ型の詳細については、データ型を参照してください。
説明
パフォーマンスと今後のメンテナンスの観点から、テーブル作成時に主キーまたは一意キーを設計することを推奨します。適切なフィールドが主キーとして利用できない場合は、テーブルに数値列を追加して主キーとし、Oracleテナントのシーケンスを使用してその列に値を挿入することができます。シーケンスの詳細については、シーケンスの管理を参照してください。
レプリケーションテーブルの作成
レプリケーションテーブルは、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);
説明
WITH COLUMN GROUP(all columns)オプションを設定して行ストアテーブルを作成した場合、ユーザーが後からDROP 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 はテーブル作成時に指定すると、その設定値は変更できなくなります。
ここで、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);