本記事では、SQLステートメントを使用してテーブルを作成する方法について説明します。テーブル作成の前提条件、テーブルの概要、従うべき要件などを解説し、いくつかの例を紹介します。
テーブルの概要
テーブルは、データオブジェクト間の関係を表し、保存するために使用される二次元配列の集合です。データベーステーブルを適切に設計および使用することで、データの信頼性、整合性、およびクエリのパフォーマンスを向上させることができ、データベース内のデータを効率的に管理および活用できます。
OceanBaseデータベーステーブルの詳細については、テーブルの概要を参照してください。
前提条件
テーブルを作成する前に、以下の点を確認する必要があります:
OceanBaseクラスタをデプロイし、MySQLモードのテナントを作成していること。OceanBaseクラスタのデプロイに関する情報については、デプロイの概要を参照してください。
OceanBaseデータベースのMySQLテナントに接続していること。データベースへの接続に関する詳細については、接続方法の概要を参照してください。
データベースを作成していること。データベースの作成に関する詳細については、データベースの作成を参照してください。
既に
CREATE権限を保有していること。現在のユーザー権限を確認する操作の詳細については、ユーザー権限の確認を参照してください。該当する権限を持っていない場合は、管理者に連絡し権限の付与を依頼してください。ユーザー権限に関する操作については、直接権限付与を参照してください。
コマンドラインでテーブルを作成する
CREATE TABLE ステートメントを使用してテーブルを作成してください。
説明
データベース内のテーブルの情報を表示するには、SHOW TABLES; ステートメントを使用できます。
テーブル名の定義
テーブルを作成する際には、まずテーブル名を付ける必要があります。以下は、テーブル名を定義する際に従うべき要件です:
OceanBaseデータベースのMySQLモードでは、各テーブル名はデータベース内で一意である必要があります。
テーブル名は64文字を超えることはできません。
テーブルには意味のある名前を付けることを推奨します。
t1、table1のような名前は使用しないでください。テーブルの命名ルールの詳細については、テーブルの命名ルールを参照してください。
例1:注文情報に関するテーブルを作成します。
注意
列情報が追加されていないため、現在以下のSQLを実行することはできません。
CREATE TABLE orders (...);
列の定義
データベースにおいて、列(Column)とは、テーブル内の特定の属性の値を格納するためのフィールドです。ユーザーが各属性に付ける名前が列名となります。列には、列名のほかに、データ型やその最大長(精度)といった情報も含まれています。
以下は、テーブルの列を定義する際に従うべき要件です:
データ型の特性に基づいて、列に格納するデータに適したデータ型を選択します。
OceanBaseデータベースのMySQLモードでサポートされているデータ型とその詳細については、データ型の概要を参照してください。
文字列データに対しては、可変長の文字列データ型を使用し、最大長を指定することを推奨します。指定する最大長は、格納する必要がある最大文字数より大きく設定してください。これにより、最大長を超えた場合に文字が切り捨てられるのを防ぎます。
主キー列 の要件に基づき、テーブルに主キー列を定義する必要があるかどうかを確認します。
その他の制約 の要件に基づき、列に他の制約を追加する必要があるかどうかを確認します。
列に
NOT NULL制約がある場合、通常はその列にデフォルト値を設定することを推奨します。列のタイプが日付または時刻の場合、データベースの現在時刻をデフォルト値として設定できます。
主キー列の定義
主キー制約(Primary Key Constraint)とは、特定のキー(1つまたは複数の列の組み合わせ)に対して定義されるルールであり、テーブル内の各行をそのキーの値によって一意に識別できるようにするためのものです。各データベーステーブルには、PRIMARY KEY 制約を1つだけ定義できます。この制約を構成する列(単一列または複数列)の値は、各行データの一意な識別子として機能します。つまり、各データ行はこの主キー値によって識別されます。
特定の列を主キー列として指定するには、その列の定義の後に PRIMARY KEY キーワードを追加します。複数の列に主キー制約を定義する場合は、CREATE TABLE ステートメントのすべての列のリストの後に、主キー制約の定義を追加します。
以下は、主キー列を定義する際に従うべき要件です:
テーブルに主キーを定義することを推奨します。各データベーステーブルで設定できる主キー(単一列または複数列)は、最大で1つです。
OceanBaseデータベースでは、ユーザーがテーブルに主キーを定義することは必須ではありませんが、主キーを使用すると、テーブル内の各行データを一意に識別することができ、重複するデータ行の存在を防ぐことができます。主キーとする適切なフィールドがない場合、主キーを指定せずにテーブルを作成することができます。テーブルが正常に作成されると、システムは主キーのないテーブルに自動インクリメント列を非表示の主キーとして指定します。自動インクリメント列の詳細については、自動インクリメント列の定義を参照してください。
また、作成時に主キー列を定義していない場合でも、OceanBaseデータベースでは既存のテーブルに主キー列を追加することをサポートしています。
主キー列の集合の値は、テーブル全体で一意です。
主キー列の数は64列までで、主キーのデータ総長は16 KBを超えることはできません。
主キー列の値はNULLまたは空文字列にすることはできません。主キー列には値を入力する必要があります。
主キー制約の名前を明確に指定することを推奨します。例えば、主キー制約を「PK_xxx」と命名します。
主キー制約の詳細については、主キー制約を参照してください。
例2:複数の列に主キー制約を定義します。
obclient> CREATE TABLE test(c1 INT, c2 INT, CONSTRAINT PK_c1_c2 PRIMARY KEY(c1, c2));
Query OK, 0 rows affected
obclient> desc test;
+-------+---------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-------+---------+------+-----+---------+-------+
| c1 | int(11) | NO | PRI | NULL | |
| c2 | int(11) | NO | PRI | NULL | |
+-------+---------+------+-----+---------+-------+
2 rows in set
例2では、c1 および c2 列を主キー列として定義し、制約名を PK_c1_c2 とします。 c1、c2 列の値は NULL を許容せず、かつ重複してはなりません。
主キー列を定義した後でも、主キーの削除がサポートされます。主キー制約に関するその他の操作については、列の制約タイプの定義を参照してください。
その他の列制約の定義
PRIMARY KEY 制約に加えて、OceanBaseデータベースは NOT NULL 制約、一意性(UNIQUE)制約、外部キー(FOREIGN KEY)制約、および CHECK 制約をサポートしています。制約を使用することで、テーブルのクエリが簡素化され、クエリパフォーマンスが向上し、データのセマンティックな整合性が保証されます。
各制約タイプとその説明は以下のとおりです:
NOT NULL制約(
NOT NULL):この制約は、対象の列にNULL値を許可しないことを示します。NOT NULL制約のある列の場合、
INSERTステートメントでその列の値を指定する必要があります。ただし、その列にNOT NULLデフォルト値が定義されている場合は除きます。一意性制約(
UNIQUE):制約が適用された列の値は重複を許容されませんが、複数のNULL値は許容されます。外部キー制約(
FOREIGN KEY):制約される列の値は、別のテーブルの主キー列から取得される必要があります。外部キー制約を作成する際に、外部キー名を指定しない場合、システムは自動的に制約名を割り当てます。自動的に割り当てられる制約名は、
テーブル名_OBFK_作成日時となります。例えば、t1_OBFK_1627747200000000。OceanBaseデータベースは、デフォルトで外部キー制約チェックが有効になっています。外部キー制約チェックのオンとオフは、テナント変数
foreign_key_checksで制御されます。foreign_key_checks変数の詳細については、foreign_key_checksを参照してください。CHECK制約:データベースの特定の列の値が指定された条件を満たすことを要求します。単一の列に対して1つ以上の
CHECK制約を定義することで、その列に特定の値のみを許可することができます。また、テーブルレベルのCHECK制約を定義することで、複数の列にCHECK制約を適用することもできます。テーブル名を変更しても、CHECK制約名は変更されません。テーブルを削除すると、そのテーブルに適用されたCHECK制約も同時に削除されます。CHECK制約を作成する際に制約名を指定しない場合、システムは自動的に制約名を割り当てます。自動的に割り当てられる制約名はテーブル名_OBCHECK_作成日時の形式になります。例えば、t1_OBCHECK_1629350823880271のようになります。
単一の列を制約するには、その列の定義に制約キーワードを追加してください。複数の列を制約するには、CREATE TABLE ステートメントのすべての列のリストの後に、制約全体の定義を追加します。
以下は、その他の列制約を定義する際に従うべき要件です:
NULL値が入らないことが明確なフィールドには、
NOT NULL制約を追加することを推奨します。別のテーブルの値を参照する場合は、外部キー制約を使用してください。
複合主キーは外部キーとして使用することはできません。
列に重複値を許容しない場合は、一意制約を使用してください。
NOT NULL制約以外、その他の制約には明確な制約名を付けることを推奨します。例えば、一意性制約は “UNI_xxx”、外部キー制約は “FK_xxx” と名付けられます。
例3:テーブル tbl1 を作成し、列 col1 にNOT NULL制約を設定します。
obclient> CREATE TABLE tbl1(col1 INT NOT NULL,col2 INT);
Query OK, 0 rows affected
obclient> DESC tbl1;
+-------+---------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-------+---------+------+-----+---------+-------+
| col1 | int(11) | NO | | NULL | |
| col2 | int(11) | YES | | NULL | |
+-------+---------+------+-----+---------+-------+
2 rows in set
例3では、以降のデータ挿入時に、列 col1 には NULL 値を挿入できません。
例4:テーブル tbl2 を作成し、列 col1 に一意性制約を設定します。
obclient> CREATE TABLE tbl2(col1 INT UNIQUE,col2 INT);
Query OK, 0 rows affected
obclient> desc tbl2;
+-------+---------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-------+---------+------+-----+---------+-------+
| col1 | int(11) | YES | UNI | NULL | |
| col2 | int(11) | YES | | NULL | |
+-------+---------+------+-----+---------+-------+
2 rows in set
例4では、列 col1 の値は重複してはいけません。
例5:外部キー制約を作成します。
obclient> CREATE TABLE test(c1 INT, c2 INT, CONSTRAINT PK_c1 PRIMARY KEY(c1));
Query OK, 0 rows affected
obclient> CREATE TABLE tbl3(col1 INT PRIMARY KEY,col2 INT,CONSTRAINT FK_col2 FOREIGN KEY(col2) REFERENCES test(c1));
Query OK, 0 rows affected
obclient> SELECT * FROM information_schema.TABLE_CONSTRAINTS;
+--------------------+-------------------+-------------------------------+--------------+------------+-----------------+----------+
| CONSTRAINT_CATALOG | CONSTRAINT_SCHEMA | CONSTRAINT_NAME | TABLE_SCHEMA | TABLE_NAME | CONSTRAINT_TYPE | ENFORCED |
+--------------------+-------------------+-------------------------------+--------------+------------+-----------------+----------+
| def | xxx | PRIMARY | xxx | test | PRIMARY KEY | YES |
| def | xxx | PRIMARY | xxx | tbl3 | PRIMARY KEY | YES |
| def | xxx | FK_col2 | xxx | tbl3 | FOREIGN KEY | YES |
+--------------------+-------------------+-------------------------------+--------------+------------+-----------------+----------+
3 rows in set
例5では、テーブル tbl3 の列 col2 は、別のテーブル test の主キー列 c1 と関連付けられています。作成が完了したら、information_schema.TABLE_CONSTRAINTS ビューで確認できます。
例6:テーブル tbl4 を作成し、列 col1 の値が 10 より大きくなるように設定します。
obclient> CREATE TABLE tbl4(col1 INT CHECK(col1>10),col2 INT);
Query OK, 0 rows affected
obclient> INSERT INTO tbl4 VALUES(2,2);
ERROR 3819 (HY000): check constraint violated
obclient> INSERT INTO tbl4 VALUES(11,2);
Query OK, 1 row affected
例6では、col1 列に CHECK 制約が追加されたため、col1 列に挿入される値が 10 以下の場合、エラーが発生します。
その他の列制約の定義の操作の詳細については、列の制約タイプの定義を参照してください。
テーブルの自動インクリメント列の定義
OceanBaseデータベースでは、テーブル作成時に特定の数値列を重複しない値とし、かつインクリメントを続けるようにする必要がある場合、テーブル内の列のタイプを AUTO_INCREMENT、つまり自動インクリメント列として定義することができます。
自動インクリメント列には、自動インクリメント開始値、自動インクリメントステップサイズ、自動インクリメントキャッシュサイズという3つの重要な属性があり、auto_increment_cache_size、auto_increment_increment、auto_increment_offset の3つのテナント変数で制御されます。
| 変数名 | 説明 |
|---|---|
| auto_increment_cache_size | グローバル変数で、自動インクリメントのキャッシュ数を設定します。値の範囲は [1, 100000000]、デフォルト値は 1000000 です。 |
| auto_increment_increment | セッション変数で、自動インクリメントステップサイズを設定します。値の範囲は [1, 65535]、デフォルト値は 1 です。 |
| auto_increment_offset | セッション変数で、AUTO_INCREMENT 列の値の開始点を決定します。値の範囲は [1, 65535]、デフォルト値は 1 です。 |
ビジネスのニーズに応じて、これらの3つのシステム変数の値を変更することができます。システム変数の変更操作については、構成パラメータとシステム変数の概要を参照してください。
以下は、自動インクリメント列を定義する際に従うべき要件です:
AUTO_INCREMENTはデータ列の属性であり、整数型データ列のみに適用されます。AUTO_INCREMENTが設定されているデータ列にはNOT NULL属性を備える必要があります。パーティションテーブルを作成する際に、自動インクリメント列をパーティションキーとして使用する場合、OceanBaseデータベースでは、自動インクリメント列の値はグローバルに一意ですが、パーティション内で連続して増えていくとは限りません。
自動インクリメント列の作成後、INSERTステートメントを使用してデータを挿入する際に自動インクリメント列の値を指定した場合、システム変数 SQL_MODE に NO_AUTO_VALUE_ON_ZERO が設定されていなければ、次のように動作します:指定した値が 0 の場合、システムは自動インクリメント列の次の値を割り当てます。指定した値が現在の最大値より小さい場合、自動インクリメント列の次の値の計算には影響しません。指定した値が現在の最大値より大きい場合、自動インクリメント列は今回の挿入値と自動インクリメント列キャッシュ値の合計を次の自動インクリメントの開始値として使用します。
説明
システム変数 SQL_MODE の値が NO_AUTO_VALUE_ON_ZERO の場合、挿入値が0の列では AUTO_INCREMENT を生成しないことを表します。
例7:自動インクリメント列を含むテーブルを作成します。
obclient> CREATE TABLE personal_info(id bigint NOT NULL AUTO_INCREMENT PRIMARY KEY, name varchar(50), gmt_create timestamp NOT NULL default current_timestamp);
Query OK, 0 rows affected
例7では、id 列が自動インクリメント列として設定されているため、INSERT ステートメントでデータを挿入する際にid列の値を指定する必要はありません。以下のように、システムが自動的にこの列の値を割り当てます。
obclient> INSERT INTO personal_info(name) VALUES('A'),('B'),('C');
Query OK, 3 rows affected
Records: 3 Duplicates: 0 Warnings: 0
obclient> SELECT * FROM personal_info;
+----+------+---------------------+
| id | name | gmt_create |
+----+------+---------------------+
| 1 | A | 2020-04-03 17:09:55 |
| 2 | B | 2020-04-03 17:09:55 |
| 3 | C | 2020-04-03 17:09:55 |
+----+------+---------------------+
3 rows in set
自動インクリメント列の紹介と操作の詳細については、自動インクリメント列の定義を参照してください。
パーティションスキームの選択
テーブル内のデータ量が多い場合は、テーブルをパーティション化することを推奨します。テーブルを作成する際には、テーブルのパーティション方式を明確にする必要があります。パーティションテーブルを作成する際には、テーブルに格納するデータに基づいて適切なパーティション方式を選択する必要があります。
OceanBaseデータベースのMySQLモードでは、単一テーブルで作成できるパーティションの最大数は、テナントレベルの構成パラメータ max_partition_num で制御します。デフォルトは8192個です。
OceanBaseデータベースのMySQLモードでは、パーティション戦略に基づいて、パーティションテーブルは以下のように分類されます。
Rangeパーティション / Range Columnsパーティション
Listパーティション / List Columnsパーティション
Hashパーティション / keyパーティション
コンポジット・パーティション
パーティションの分割レベルに基づいて、パーティションはパーティションとサブパーティションに分けられます。サブパーティションはパーティションの二次分割です。そのため、パーティションテーブルには1つのパーティションキーがあり、コンポジット・パーティションテーブルには2つのパーティションキーがあります。また、1回目と2回目の分割で異なるパーティション戦略を採用することも可能です。OceanBaseデータベースでは、コンポジット・パーティションテーブルには、テンプレートを使用したテーブルとテンプレートを使用しないテーブルの2種類に分類されます。
パーティションの紹介の詳細については、パーティションの概要を参照してください。
Rangeパーティション / Range Columnsパーティション
RangeパーティションとRange Columnsパーティションはどちらも、各パーティションに作成されるパーティションキー値の範囲に基づいてパーティションを分割します。通常、パーティションキーに対し範囲に基づく検索を行うクエリに使用されます。例えば、時間フィールドや価格範囲などに基づく範囲(RANGE) のパーティション化を実行します。
RangeパーティションとRange Columnsパーティションの違いは以下のとおりです:
Rangeパーティションのパーティションキーは整数型である必要があります。日付フィールドをパーティション化する場合は、関数を使用して変換する必要があります。例えば、dateフィールドをパーティション化する場合は、
YEAR()関数を使用して変換する必要があります。一方、Range Columnsパーティションのパーティションキーは整数である必要はなく、任意のタイプにすることができます。Rangeパーティションのパーティションキーには式を記述できますが、複数列(列ベクトル)を記述することはできません。例えば、
partition by range(c1, c2)を記述することはできません。Range Columnsパーティションのパーティションキーには式を記述することはできませんが、複数列(列ベクトル)にすることができます。
RangeパーティションとRange Columnsパーティションは、VALUES LESS THAN(value) キーワードを使用して各パーティションを定義します。ここで、value の値は小さい値から大きい値に並ぶ連続した重複しない値である必要があります。
例8:Range Columnsパーティションテーブルを作成します。
obclient> CREATE TABLE tb1_rc(col1 INT,col2 INT)
PARTITION BY RANGE COLUMNS(col1)
(PARTITION p0 VALUES LESS THAN(100),
PARTITION p1 VALUES LESS THAN(200),
PARTITION p2 VALUES LESS THAN(300)
);
Query OK, 0 rows affected
例8では、Range Columnsパーティションのパーティションキーは任意のタイプにすることができるため、col1 列名をパーティションキーとして使用することができます。パーティションテーブル tb1_rc は 100、200、300 の数値範囲に基づいてパーティションされます。p0、p1、p2 は指定されたパーティション名であり、任意に定義できますが、同じテーブル内の各パーティション名は重複しないようにする必要があります。
Listパーティション / List Columnsパーティション
Listパーティションは、具体的な数値に基づいてパーティションを作成します。各パーティションの数値は重複しません。Listパーティションの利点は、順序付けされていない、または関連付けされていないデータセットを簡単にパーティション化できることです。
複数列のListパーティションを使用する必要がある場合、または他のデータ型のListパーティションを使用する必要がある場合は、List Columnsパーティションを使用できます。List Columnsパーティションは、Listパーティションの拡張機能であり、複数のパーティションキーをサポートし、INTタイプ、DATEタイプ、およびDATETIMEタイプをサポートします。
ListパーティションとList Columnsパーティションの違いは以下のとおりです:
Listパーティションのパーティションキーは整数型である必要があります。List Columnsパーティションのパーティションキーは任意のタイプにすることができます。
Listパーティションは、単一パーティションキーのみをサポートし、そのパーティションキーは、列または式にすることができます。List Columnsパーティションのパーティションキーを式にすることはできませんが、複数列(列ベクトル)にすることができます。
ListパーティションとList Columnsパーティションは、VALUES IN(value_list) キーワードを使用して各パーティションを定義します。
例9:Listパーティションテーブルを作成します。
obclient> CREATE TABLE tbl2_l (col1 INT,col2 DATE)
PARTITION BY LIST(col1)
(PARTITION p0 VALUES IN (100),
PARTITION p1 VALUES IN (200)
);
Query OK, 0 rows affected
例9では、Listパーティションのパーティションキーは整数型でなければならないため、col1 列をパーティションキーとして使用し、パーティションテーブル tbl2_l は 100、200 の範囲で数値をパーティション化します。
Hashパーティション / Keyパーティション
Hashパーティションでは、パーティションキーとパーティション数を指定する必要があります。システムはHashパーティション式を通して整数を算出し、この結果をパーティション数でモジュロ演算することで、特定の行データがどのパーティションに属するかを決定します。
Keyパーティションは、Hashパーティションと同様に、パーティション数のモジュロ演算を通してデータがどのパーティションに属するかを決定します。異なる点は、システムがKeyのパーティションキーに内部的にデフォルトのHash関数を適用してからモジュロ演算を行うことです。そのため、ユーザーは通常、単純な計算では特定の行がどのパーティションに属しているかを判断することができません。
KeyパーティションとHashパーティションの違いは以下のとおりです:
Hashパーティションのパーティションキーは整数でなければなりません。Keyパーティションにはこの要件がなく、文字列をサポートします。
Hashパーティションのパーティションキーは式をサポートしますが、Keyパーティションのパーティションキーを式にすることはできません。
例10:HASHパーティションテーブル tbl3_h を作成します。
obclient> CREATE TABLE tbl3_h(col1 INT,col2 VARCHAR(50))
PARTITION BY HASH(col1) PARTITIONS 2;
Query OK, 0 rows affected
例10では、Hashパーティションのパーティションキーが整数でなければならないため、col1 をパーティションキーとして使用することで、テーブル tbl3_h を2つのパーティションに分割できます。テーブル作成時にパーティション名を指定しないため、パーティションの命名はシステムが命名ルールに従って自動的に行い、それぞれのパーティションはp0、p1、...、pnと命名されます。
コンポジット・パーティション(サブパーティション)
コンポジット・パーティションは通常、最初に1つのパーティション戦略を適用し、次にサブパーティションに別のパーティション戦略を適用します。これは、ビジネステーブルのデータ量が非常に大きい場合に適しています。コンポジット・パーティションを使用すると、複数のパーティション戦略の長所を活かすことができます。
Rangeパーティション、Range Columnsパーティション、Listパーティション、List Columnsパーティション、Hashパーティション、およびkeyパーティションはすべて、コンポジット・パーティションテーブルのサブパーティション戦略として使用できます。OceanBaseデータベースでは、コンポジット・パーティションテーブルには、テンプレート化されたコンポジット・パーティションテーブルと非型テンプレートのコンポジット・パーティションテーブルが含まれます。
以下に、いくつかの簡単な例を用いて、コンポジット・パーティションテーブルの作成方法を簡単に紹介します。
例11:テンプレート化されたRange Columns + Rangeパーティションテーブルを作成します。
obclient> CREATE TABLE tb1_m_rcr(col1 INT,col2 INT)
PARTITION BY RANGE COLUMNS(col1)
SUBPARTITION BY RANGE(col2)
SUBPARTITION TEMPLATE
(SUBPARTITION mp0 VALUES LESS THAN(3),
SUBPARTITION mp1 VALUES LESS THAN(6),
SUBPARTITION mp2 VALUES LESS THAN(9)
)
(PARTITION p0 VALUES LESS THAN(100),
PARTITION p1 VALUES LESS THAN(200),
PARTITION p2 VALUES LESS THAN(300)
);
Query OK, 0 rows affected
obclient> SELECT table_name,partition_name,subpartition_name FROM information_schema.partitions;
+------------+----------------+-------------------+
| table_name | partition_name | subpartition_name |
+------------+----------------+-------------------+
| tb1_m_rcr | p0 | p0smp0 |
| tb1_m_rcr | p0 | p0smp1 |
| tb1_m_rcr | p0 | p0smp2 |
| tb1_m_rcr | p1 | p1smp0 |
| tb1_m_rcr | p1 | p1smp1 |
| tb1_m_rcr | p1 | p1smp2 |
| tb1_m_rcr | p2 | p2smp0 |
| tb1_m_rcr | p2 | p2smp1 |
| tb1_m_rcr | p2 | p2smp2 |
+------------+----------------+-------------------+
9 rows in set
例11では、Rangeパーティションのパーティションキーは整数型である必要があるため、サブパーティションは col2 列名をパーティションキーとして直接使用することができ、SUBPARTITION TEMPLATE キーワードを使用してテンプレート化されたコンポジット・パーティションテーブルを作成します。テンプレート化されたコンポジット・パーティションテーブルにおいて、各パーティションの下にあるサブパーティションは、テンプレート内のサブパーティション定義に従うため、各パーティションの下にあるサブパーティション定義はすべて同じです。本例では、まずRange Columnsパーティション方式でパーティションを作成し、次にRangeパーティション方式でサブパーティションを作成します。
さらに、テンプレート化されたサブパーティションを作成する際には、サブパーティションの定義が完了した後、各パーティションのパーティション名を個別に指定する必要はなく、システムが命名ルールに従って一括で命名を行います。各サブパーティションの命名ルールは ($part_name)s($subpart_name) です。この例では、パーティション p0 に対応するサブパーティションのパーティション名はそれぞれ p0smp0、p0smp1、p0smp2 です。
注意
Hash / Keyパーティションの場合、パーティション数を指定する方法(例:SUBPARTITIONS 5)でサブパーティション化を行う場合、テンプレート化されたコンポジット・パーティションテーブルの作成時に SUBPARTITION TEMPLATE キーワードを指定する必要はありません。
例12:非型テンプレートList + List Columnsパーティションテーブルを作成します。
obclient> CREATE TABLE tbl2_f_llc(col1 INT,col2 DATE)
PARTITION BY LIST(col1)
SUBPARTITION BY LIST COLUMNS(col2)
(PARTITION p0 VALUES IN(100)
(SUBPARTITION sp0 VALUES IN('2021/04/01'),
SUBPARTITION sp1 VALUES IN('2021/07/01'),
SUBPARTITION sp2 VALUES IN('2021/10/01'),
SUBPARTITION sp3 VALUES IN('2022/01/01')
),
PARTITION p1 VALUES IN(200)
(SUBPARTITION sp4 VALUES IN('2021/04/01'),
SUBPARTITION sp5 VALUES IN('2021/07/01'),
SUBPARTITION sp6 VALUES IN('2021/10/01'),
SUBPARTITION sp7 VALUES IN('2022/01/01')
)
);
Query OK, 0 rows affected
例12では、非型テンプレートのコンポジット・パーティションテーブルが作成され、各パーティションに対してサブパーティションを定義する必要があります。各パーティションの下にあるサブパーティションの定義は同一でも異なっていても構いません。
例13:非型テンプレートHash + Keyパーティションテーブルを作成します。
obclient> CREATE TABLE tbl3_f_hk (col1 INT,col2 VARCHAR(50))
PARTITION BY HASH(col1)
SUBPARTITION BY KEY(col2)
(PARTITION p1
(SUBPARTITION sp0
,SUBPARTITION sp1
,SUBPARTITION sp2
,SUBPARTITION sp3
),
PARTITION p2
(SUBPARTITION sp4
,SUBPARTITION sp5
,SUBPARTITION sp6
,SUBPARTITION sp7
)
);
Query OK, 0 rows affected
例13でKeyパーティションでは文字列をパーテーションキーとしてサポートするため、col2 列をパーティションキーとして使用しサブパーティション化を実行することができます。ここで、sp0、……、sp7 は指定されたサブパーティション名です。
レプリケーションテーブルの作成
レプリケーションテーブルはOceanBaseデータベースの特殊なテーブルです。このテーブルは、任意の「正常」なレプリカ上でデータの最新の更新を読み取ることができます。書き込み頻度が低く、読み込み頻度が高いシナリオでは、レプリケーションテーブルは非常によい選択肢です。
レプリケーションテーブルの詳細については、テーブルの作成 の レプリケーションテーブルの作成 セクションを参照してください。
注意
ユーザーテナントのみがレプリケーションテーブルを作成できます。sys テナントはレプリケーションテーブルを作成できません。
レプリケーションテーブルを作成するSQL構文は次のとおりです:
CREATE TABLE table_name column_definition DUPLICATE_SCOPE='none | cluster';
パラメータの説明:
table_name:テーブル名。column_definition:テーブルの列情報。例えば、列定義、主キー定義など。DUPLICATE_SCOPE:レプリケーションテーブルのプロパティを指定するために使用します。値は以下のとおりです:none:このテーブルが通常のテーブルであることを示しています。cluster:このテーブルはレプリケーションテーブルであり、Leaderはトランザクションを現在のテナントのすべてのFレプリカとRレプリカにレプリケートする必要があります。
例14:以下のSQLステートメントを使用して、レプリケーションテーブル test_tbl14 を作成します。
CREATE TABLE test_tbl14 (col1 INT,col2 INT) DUPLICATE_SCOPE= 'cluster';
次の操作
テーブルの作成が完了したら、テーブルの使用と管理を最適化するために、次の操作を実行する必要があるかもしれません:
テーブルを作成したら、
INSERTステートメントを使用してテーブルにデータを挿入できます。データの挿入に関する詳細については、データの挿入を参照してください。クエリのパフォーマンスを向上させる必要がある場合は、テーブルの列にインデックスを作成できます。インデックスの作成に関する詳細については、インデックスの作成を参照してください。
関連ドキュメント
- テーブルのプロパティの詳細については、テーブルの定義の確認を参照してください。
- テーブルの削除の詳細については、テーブルの削除を参照してください。
- テーブル構造の変更に関する詳細については、テーブルの変更を参照してください。
- パーティションテーブルの作成の詳細については、パーティションテーブルの作成を参照してください。