CREATE TABLE ステートメントは、LindormTable または LindormTSDB にテーブルを作成します。VARCHAR、TIMESTAMP、BIGINT などのデータ型や、TTL、COMPRESSION などのテーブル属性をサポートしています。これらを組み合わせることで、ビジネスシナリオに合わせたテーブルを設計できます。
エンジンとバージョン
-
CREATE TABLEは、LindormTable と LindormTSDB に適用されます。 -
LindormTSDB は、バージョン 3.4.32 以降で標準の
CREATE TABLE構文をサポートしています。バージョンの確認またはアップグレードについては、「LindormTSDB リリースノート」および「マイナーバージョンのアップグレード」をご参照ください。
構文
create_table_statement ::= CREATE TABLE [ IF NOT EXISTS ] table_identifier
'('
column_definition
( ',' column_definition )*
',' PRIMARY KEY '(' primary_key ')'
( ',' {KEY|INDEX} [index_identifier]
[ USING index_method_definition ]
[ INCLUDE column_identifier ( ',' column_identifier )* ]
[ WITH index_options ]
)*
')'
[ PARTITION BY partition_definition ]
[ ZORDER BY zorder_column_list ]
[ WITH table_options ]
column_definition ::= column_identifier data_type [ NOT NULL ]
primary_key ::= column_identifier [ ',' column_identifier (ASC|DESC)]
index_method_definition ::= { KV | SEARCH }
index_options ::= '('
option_definition (',' option_definition )*
')'
partition_definition ::= HASH '(' column_identifier (',' column_identifier )* ')'
zorder_column_list ::= column_identifier ( ',' column_identifier )*
table_options ::= '(' option_definition (',' option_definition )* ')'
option_definition ::= option_identifier '=' string_literal
構文の違い
CREATE TABLE 構文は、LindormTable と LindormTSDB で異なります。次の表で、各エンジンがサポートするパラメーターを比較します。
|
パラメーター |
LindormTable |
LindormTSDB |
|
○ |
○ |
|
|
○ |
○ |
|
|
○ |
○ |
|
|
○ |
✖️ |
|
|
✖️ |
○ |
|
|
○ |
✖️ |
使用方法
テーブル名 (table_identifier)
テーブル名は、次の要件を満たす必要があります:
-
名前に使用できる文字は、数字、大文字、小文字、ピリオド (.)、ハイフン (-)、アンダースコア (_) です。
-
名前の先頭にピリオド (.) やハイフン (-) を使用することはできません。
-
名前の長さは 1~255 文字である必要があります。
列定義 (column_definition)
|
構文 |
必須 |
説明 |
|
列名 (column_identifier) |
はい |
|
|
データ型 (data_type) |
はい |
サポートされているデータ型の詳細については、「データ型」をご参照ください。 重要
時系列テーブルを作成する際、TIMESTAMP データ型を使用する場合は、次の点にご注意ください:
|
|
NULL 制約 |
いいえ |
列に NULL 値を許可するかどうかを示します。 重要
Lindorm SQL はこの制約を検証しません。代わりに、検証はストレージエンジンによって実行されます。 NULL 制約の検証はストレージエンジンのルールに依存し、その内容は様々です。その結果、NOT NULL で定義されていても、列に NULL 値を書き込める場合があります。 データが期待どおりに書き込まれるようにするには、次の要件に従ってください:
|
プライマリキー (primary_key)
プライマリキーは、テーブル内のデータを一意に識別するもので、1 つ以上の列で構成されます。テーブルを作成する際には、プライマリキー (PRIMARY KEY) を指定する必要があります。
プライマリキーは、作成後に変更することはできません。プライマリキーは慎重に設計してください。
CREATE TABLE ステートメントを使用してテーブルを作成する際には、次の点にご注意ください:
|
エンジンタイプ |
説明 |
|
LindormTable |
|
|
LindormTSDB |
|
インデックス式 (KEY|INDEX)
CREATE TABLE ステートメントを使用してインデックスを作成する場合、KEY または INDEX キーワードを使用してインデックスを指定します。
-
インデックス式 (KEY|INDEX) は、LindormTable 2.7.7 以降および Lindorm SQL 2.8.6.0 以降でのみサポートされています。
-
LindormTable および Lindorm SQL のバージョンを確認するには、「LindormTable リリースノート」および「SQL バージョンノート」をご参照ください。コンソールで必要なバージョンにアップグレードできない場合は、Lindorm のテクニカルサポートにお問い合わせください (DingTalk ID: s0s3eg3)。
使用方法
-
インデックス名を明示的に指定しない場合、システムはデフォルトでインデックス名を生成します。生成されるインデックス名の形式は
TableName_idx_${auto-incremented ID}です。 -
現在、インデックス式を使用して作成できるのは、セカンダリインデックスと検索インデックスのみです。
-
セカンダリインデックスのデフォルトの列包含:
Lindorm SQL 2.9.3.10 以降
セカンダリインデックスを作成する際に
INCLUDE句を指定しない場合、デフォルトでは他のすべての列はインデックスに含まれません。Lindorm SQL 2.9.3.10 より前のバージョン
セカンダリインデックスを作成する際に
INCLUDE句を指定しない場合、デフォルトでは他のすべての列はインデックスに含まれます。説明これは、INDEX_COVERED_TYPE インデックス属性を
COVERED_ALL_COLUMNS_IN_SCHEMAに設定するのと同じです。テーブルが動的テーブルの場合は、属性をCOVERED_DYNAMIC_COLUMNSに設定するのと同じです。 -
テーブルを作成する際に
KEYまたはINDEX句を指定し、MUTABILITY および CONSISTENCY 属性を明示的に指定しない場合、テーブルは次のデフォルト属性で作成されます:CONSISTENCY = 'strong'およびMUTABILITY='MUTABLE_LATEST'。 -
CREATE TABLE ステートメントにインデックス式が含まれている場合、システムはまずテーブルを作成し、次にインデックスを作成します。インデックス作成中に例外が発生した場合、テーブルとインデックスが残存し、自動的にクリアされないことがあります。
SHOWやDESCRIBEなどのステートメントを使用してそれらを表示できますが、テーブルとインデックスにデータを書き込んだり、クエリを実行したりできない場合があります。残りのテーブルとインデックスを削除してから再作成することを推奨します。
パーティション (partition_definition)
パーティションは、LindormTSDB でのみサポートされています。時系列テーブルでは、PARTITION BY 句で使用される列は VARCHAR のプライマリキー列である必要があります。
テーブルを作成する際、PARTITION BY HASH(column1, column2, ..., columnN) ステートメントを使用して、ハッシュパーティショニングのために 1 つ以上の列を明示的に指定できます。例:PARTITION BY HASH(c1, p1)。
テーブル属性 (table_options)
LindormTable のみがテーブル属性をサポートしています。WITH キーワードを使用して、次のテーブル属性を追加できます:
|
オプション |
タイプ |
説明 |
|
COMPRESSION |
STRING |
テーブルの圧縮アルゴリズム。有効な値:
説明
LindormTable 2.3.4 より前のバージョンでは、デフォルトで圧縮アルゴリズムは指定されません。LindormTable 2.3.4 以降では、デフォルトで ZSTD アルゴリズムが使用されます。 |
|
TTL |
INT |
データの Time to Live (TTL)、単位は秒 (s) です。 説明
|
|
COMPACTION_MAJOR_PERIOD |
LONG |
システムが 説明
デフォルト値は、テーブルの TTL (ミリ秒に換算) と 1,728,000,000 ms (20 日) のうち、小さい方の値が適用されます。TTL が指定されていない場合、デフォルト値は 1,728,000,000 ms です。 |
|
MUTABILITY |
STRING |
ベーステーブルの書き込みモードを指定します。この属性はインデックス作成に関連しています。デフォルト値: 有効な値:
値の詳細については、「高性能なネイティブセカンダリインデックス」をご参照ください。 重要
インデックスが作成されると、MUTABILITY 属性は変更できません。この属性を変更するには、まずテーブルのすべてのインデックスを削除する必要があります。データ損失を防ぐため、この操作を実行する前にデータをバックアップしてください。 |
|
CONSISTENCY |
STRING |
テーブルの整合性レベル。クロスゾーンインスタンスの場合、この属性はプライマリレプリカとセカンダリレプリカ間のデータ整合性を指定します。有効な値:
重要
クロスゾーンインスタンスの場合、ワークロードに増加、追加、インデックス更新などの読み取り/変更/書き込み操作が含まれる場合、レプリカ間のデータ整合性を確保するために、プライマリテーブルの CONSISTENCY 属性を |
|
NUMREGIONS |
INT |
テーブルの事前分割リージョンの数。 |
|
CHS |
INT |
ホットデータとコールドデータを分離する境界、単位は秒。 説明
|
|
STARTKEY と ENDKEY |
プライマリキーの最初の列と同じデータ型。 |
テーブルのリージョンを事前分割するための開始キーと終了キー。 説明
|
|
SPLITKEYS |
プライマリキーの最初の列と同じデータ型。 |
テーブルのすべての事前分割リージョンの開始キー。 説明
|
|
SPLITALGO |
STRING |
事前パーティショニングの分割アルゴリズムを定義します。サポートされているアルゴリズムは次のとおりです:
|
|
DYNAMIC_COLUMNS |
STRING |
動的列を有効にするかどうか。有効な値:
|
|
VERSIONS |
INT |
各列値について保持するバージョン数。1 以上の整数である必要があります。デフォルト:1。データバージョニングの詳細については、「データバージョニング」をご参照ください。 重要
VERSIONS 属性の値が高いと、クエリとストレージのパフォーマンスが低下する可能性があります。この値は 1 に設定することを推奨します。 |
|
BLOB_BUCKET_NAME |
STRING |
テーブル内の BLOB 列のバケット名。 バケット名は、次のルールに従う必要があります:
説明
|
LindormTable 2.2.16 より前のバージョンでは、テーブル属性を設定するための WITH キーワードはサポートされていません。属性キーワードを単一引用符 (') で囲む必要があります。属性値はデータ型に基づいて設定されます。たとえば、STRING 値は単一引用符 (') で囲む必要があります。例:CREATE TABLE IF NOT EXISTS t1(c1 varchar, c2 bigint, c3 int, c4 int, PRIMARY KEY(c1,c2)) 'CONSISTENCY'='strong';。
例
テーブルの作成
CREATE TABLE sensor (
device_id VARCHAR NOT NULL,
region VARCHAR NOT NULL,
time TIMESTAMP NOT NULL,
temperature DOUBLE,
humidity BIGINT,
PRIMARY KEY(device_id, region, time)
);
検証
DESCRIBE table sensor; ステートメントを実行して、テーブルが作成されたことを検証します。
インデックス付きテーブルの作成
この例では、テーブルの作成時にセカンダリインデックスを作成する方法を示します。
CREATE TABLE IF NOT EXISTS sensor (
device_id VARCHAR NOT NULL,
region VARCHAR NOT NULL,
time TIMESTAMP NOT NULL,
temperature DOUBLE,
humidity BIGINT,
PRIMARY KEY(device_id, region, time),
KEY (temperature, time)
);
検証
DESCRIBE table sensor; を実行してテーブルが作成されたことを検証し、 SHOW INDEX FROM sensor; を実行してセカンダリインデックスが作成されたことを検証します。
TTL と圧縮アルゴリズムの指定
この例では、ワイドテーブルを作成し、TTL を 30 日 (2,592,000 秒) に設定し、圧縮アルゴリズムとして ZSTD を指定します。
CREATE TABLE sensor (
device_id VARCHAR NOT NULL,
region VARCHAR NOT NULL,
time TIMESTAMP NOT NULL,
temperature DOUBLE,
humidity BIGINT,
PRIMARY KEY(device_id, region, time)
) WITH (COMPRESSION='ZSTD', TTL='2592000');
検証
-
DESCRIBE table sensor;ステートメントを実行して、テーブルが作成されたことを検証します。 -
クラスター管理システムの Overview ページに移動し、目的のテーブルの名前をクリックします。[現在のテーブル詳細] エリアで、[テーブルプロパティの表示] をクリックして、COMPRESSION および TTL パラメーターを確認します。
メジャーコンパクション間隔の指定
この例では、ワイドテーブルを作成し、メジャーコンパクション間隔を 10 日 (864,000,000 ミリ秒) に設定します。
CREATE TABLE sensor (
device_id VARCHAR NOT NULL,
region VARCHAR NOT NULL,
time TIMESTAMP NOT NULL,
temperature DOUBLE,
humidity BIGINT,
PRIMARY KEY(device_id, region, time)
) WITH (COMPACTION_MAJOR_PERIOD='864000000');
検証
-
DESCRIBE table sensor;ステートメントを実行して、テーブルが作成されたことを検証します。 -
クラスター管理システムの Overview ページに移動し、対象テーブルの名前をクリックします。[現在のテーブル詳細] エリアで、[テーブルプロパティの表示] をクリックして、COMPACTION_MAJOR_PERIOD パラメーターの値を確認します。
動的カラムの有効化
ワイドテーブルの作成時に動的カラムへのデータ書き込みを有効にするには、DYNAMIC_COLUMNS を TRUE に設定します。
CREATE TABLE sensor (
device_id VARCHAR NOT NULL,
region VARCHAR NOT NULL,
time TIMESTAMP NOT NULL,
temperature DOUBLE,
humidity BIGINT,
PRIMARY KEY(device_id, region, time)
) WITH (DYNAMIC_COLUMNS='TRUE');
検証
-
DESCRIBE table sensor;ステートメントを実行して、テーブルが作成されたことを検証します。 -
クラスター管理システムの Overview ページに移動して対象のテーブル名をクリックします。[現在のテーブル詳細] エリアで [テーブルプロパティの表示] をクリックし、DYNAMIC_COLUMNS パラメーターの値を確認します。
ホット/コールドデータ境界の指定
この例では、ワイドテーブルを作成し、データアーカイブ用にホット/コールドデータ境界を設定します。
CREATE TABLE sensor (
device_id VARCHAR NOT NULL,
region VARCHAR NOT NULL,
time TIMESTAMP NOT NULL,
temperature DOUBLE,
humidity BIGINT,
PRIMARY KEY(device_id, region, time)
) WITH (CHS = '86400', CHS_L2 = 'storagetype=COLD');
検証
-
DESCRIBE table sensor;ステートメントを実行して、テーブルが作成されたことを検証します。 -
クラスター管理システムのOverview ページに移動して対象テーブルの名前をクリックし、[現在のテーブル詳細] エリアで[テーブルプロパティを表示] をクリックしてCHS および CHS_L2 パラメーターを確認します。
複数の属性を一度に設定
この例では、圧縮、TTL、およびホット/コールドデータ境界を設定したワイドテーブルを作成します。
CREATE TABLE sensor (
device_id VARCHAR NOT NULL,
region VARCHAR NOT NULL,
time TIMESTAMP NOT NULL,
temperature DOUBLE,
humidity BIGINT,
PRIMARY KEY(device_id, region, time)
) WITH (
COMPRESSION='ZSTD',
CHS = '86400',
CHS_L2 = 'storagetype=COLD',
TTL = '2592000');
検証
-
DESCRIBE table sensor;ステートメントを実行して、テーブルが作成されたことを検証します。 -
クラスター管理システムの Overview ページに移動し、目的のテーブルの名前をクリックします。[現在のテーブル詳細] エリアで、[テーブルプロパティの表示] をクリックして、COMPRESSION、CHS、CHS_L2、および TTL パラメーターを確認します。
パーティションの構成
この例では、開始キーを 1000、終了キーを 9000 として、5 つのパーティションに事前分割したワイドテーブルを作成します。
CREATE TABLE sensor (
p1 INTEGER NOT NULL,
c1 INTEGER,
c2 VARCHAR,
c3 VARCHAR,
PRIMARY KEY(p1)
) WITH (NUMREGIONS='5', STARTKEY='1000', ENDKEY='9000');
検証
-
DESCRIBE table sensor;ステートメントを実行して、テーブルが作成されたことを検証します。 -
クラスター管理システムの Overview ページに移動し、対象のテーブル名をクリックします。 [シャード情報] エリアで、各パーティションの startKey と endKey パラメーターを確認します。
複数パーティションの開始キーの設定
コード例
-
数値キーによるパーティションの指定 (データ分散に基づく)
この例では、5 つのパーティションの開始キーを事前定義したワイドテーブルを作成することで、合計 6 つのパーティションが事前分割されます。
CREATE TABLE sensor ( p1 INT NOT NULL, p2 INT NOT NULL, c1 VARCHAR, c2 BIGINT, PRIMARY KEY(p1, p2) ) WITH (SPLITKEYS = '100000,300000,500000,700000,900000'); -
文字列キーによるパーティションの指定 (データ分散に基づく)
CREATE TABLE your_table ( address VARCHAR NOT NULL, col1 VARCHAR, PRIMARY KEY (address) ) WITH ( SPLITKEYS = '0x01,0x02,0x03,0x04,0x05,0x06,0x07,0x08,0x09,0x0a,0x0b,0x0c,0x0d,0x0e,0x0f,0x10,0x11,0x12,0x13,0x14,0x15,0x16,0x17,0x18,0x19,0x1a,0x1b,0x1c,0x1d,0x1e,0x1f,0x20,0x21,0x22,0x23,0x24,0x25,0x26,0x27,0x28,0x29,0x2a,0x2b,0x2c,0x2d,0x2e,0x2f,0x30,0x31,0x32,0x33,0x34,0x35,0x36,0x37,0x38,0x39,0x3a,0x3b,0x3c,0x3d,0x3e,0x3f,0x40,0x41,0x42,0x43,0x44,0x45,0x46,0x47,0x48,0x49,0x4a,0x4b,0x4c,0x4d,0x4e,0x4f,0x50,0x51,0x52,0x53,0x54,0x55,0x56,0x57,0x58,0x59,0x5a,0x5b,0x5c,0x5d,0x5e,0x5f,0x60,0x61,0x62,0x63,0x64,0x65,0x66,0x67,0x68,0x69,0x6a,0x6b,0x6c,0x6d,0x6e,0x6f,0x70,0x71,0x72,0x73,0x74,0x75,0x76,0x77,0x78,0x79,0x7a,0x7b,0x7c,0x7d,0x7e,0x7f,0x80,0x81,0x82,0x83,0x84,0x85,0x86,0x87,0x88,0x89,0x8a,0x8b,0x8c,0x8d,0x8e,0x8f,0x90,0x91,0x92,0x93,0x94,0x95,0x96,0x97,0x98,0x99,0x9a,0x9b,0x9c,0x9d,0x9e,0x9f,0xa0,0xa1,0xa2,0xa3,0xa4,0xa5,0xa6,0xa7,0xa8,0xa9,0xaa,0xab,0xac,0xad,0xae,0xaf,0xb0,0xb1,0xb2,0xb3,0xb4,0xb5,0xb6,0xb7,0xb8,0xb9,0xba,0xbb,0xbc,0xbd,0xbe,0xbf,0xc0,0xc1,0xc2,0xc3,0xc4,0xc5,0xc6,0xc7,0xc8,0xc9,0xca,0xcb,0xcc,0xcd,0xce,0xcf,0xd0,0xd1,0xd2,0xd3,0xd4,0xd5,0xd6,0xd7,0xd8,0xd9,0xda,0xdb,0xdc,0xdd,0xde,0xdf,0xe0,0xe1,0xe2,0xe3,0xe4,0xe5,0xe6,0xe7,0xe8,0xe9,0xea,0xeb,0xec,0xed,0xee,0xef,0xf0,0xf1,0xf2,0xf3,0xf4,0xf5,0xf6,0xf7,0xf8,0xf9,0xfa,0xfb,0xfc,0xfd,0xfe,0xff' ); -
分割アルゴリズムの指定
CREATE TABLE your_table2 ( address VARCHAR NOT NULL, col1 VARCHAR, PRIMARY KEY (address) ) WITH ( NUMREGIONS = 256, SPLITALGO = 'HexStringSplit' );
検証
-
DESCRIBE table sensor;、DESCRIBE table your_table;、またはDESCRIBE table your_table2;などのステートメントを実行して、テーブルが作成されたことを検証します。 -
クラスター管理システムの Overview ページに移動し、対象テーブルの名前をクリックします。 [シャード情報] 領域で、各パーティションの startKey および endKey パラメーターを確認します。
パーティションキー列の明示的な指定
ほとんどのクエリは単一デバイスの瞬間的なデータを取得するため、device_id をパーティションキー列として指定します。
CREATE TABLE sensor (
device_id VARCHAR NOT NULL,
region VARCHAR NOT NULL,
time TIMESTAMP NOT NULL,
temperature DOUBLE,
humidity BIGINT,
PRIMARY KEY(device_id, region, time)
) PARTITION BY HASH(device_id);
検証
DESCRIBE TABLE sensor; ステートメントを実行して、テーブルが作成されたことを検証します。
地理空間テーブルの作成
-
汎用の Geometry 空間データ型をサポートするテーブルを作成し、任意のタイプの空間データを書き込めるようにします。
CREATE TABLE geoms(gid INT, g GEOMETRY, PRIMARY KEY(gid));任意の空間データ型のデータを書き込みます。
UPSERT INTO geoms(gid, g) VALUES(0,ST_GeomFromText('POINT(-10.1 3.3)')),(1,ST_GeomFromText('LINESTRING(-12.2 4.3, -10.2 4.3)')),(2,ST_GeomFromText('POLYGON((2 2, 2 8, 8 8, 8 2, 2 2))')); -
Point データ型用のテーブルを作成します。このテーブルにはポイントデータのみを書き込めます。
CREATE TABLE pts(gid INT, g GEOMETRY(POINT), PRIMARY KEY(gid));ポイントデータを書き込みます。
UPSERT INTO pts(gid, g) VALUES(0, ST_MakePoint(0,0)),(1, ST_MakePoint(1,1)); -
Polygon データ型用のテーブルを作成します。このテーブルにはポリゴンデータのみを書き込めます。
CREATE TABLE polys(gid INT, g GEOMETRY(POLYGON), PRIMARY KEY(gid));ポリゴンデータを書き込みます。
UPSERT INTO polys(gid,g) VALUES(0,ST_GeomFromText('POLYGON((2 2, 2 8, 8 8, 8 2, 2 2))')); -
ラインストリングデータ型用のテーブルを作成します。このテーブルにはラインデータのみを書き込めます。
CREATE TABLE lines(gid INT, g GEOMETRY(LINESTRING), PRIMARY KEY(gid));ラインデータを書き込みます。
UPSERT INTO lines(gid,g) VALUES(0, ST_GeomFromText('LINESTRING(-12.2 4.3, -10.2 4.3)')); -
MULTIPOINT データ型用のテーブルを作成します。このテーブルにはマルチポイントデータのみを書き込めます。
CREATE TABLE multipoints(gid INT, g GEOMETRY(MULTIPOINT), PRIMARY KEY(gid));マルチポイントデータを書き込みます。
UPSERT INTO multipoints(gid,g) VALUES(0, ST_GeomFromText('MULTIPOINT (10 40, 40 30, 20 20, 30 10)')); -
MULTILINESTRING データ型用のテーブルを作成します。このテーブルにはマルチラインストリングデータのみを書き込めます。
CREATE TABLE multilines(gid INT, g GEOMETRY(MULTILINESTRING), PRIMARY KEY(gid));マルチラインストリングデータを書き込みます。
UPSERT INTO multilines(gid,g) VALUES(0, ST_GeomFromText('MULTILINESTRING ((10 10, 20 20, 10 40),(40 40, 30 30, 40 20, 30 10))')); -
MULTIPOLYGON データ型用のテーブルを作成します。このテーブルにはマルチポリゴンデータのみを書き込めます。
CREATE TABLE multipolys(gid INT, g GEOMETRY(MULTIPOLYGON), PRIMARY KEY(gid));マルチポリゴンデータを書き込みます。
UPSERT INTO multipolys(gid,g) VALUES(0, ST_GeomFromText('MULTIPOLYGON (((30 20, 45 40, 10 40, 30 20)),((15 5, 40 10, 10 20, 5 10, 15 5)))')); -
GEOMETRYCOLLECTION データ型用のテーブルを作成します。このテーブルにはジオメトリコレクションデータのみを書き込めます。
CREATE TABLE collections(gid INT, g GEOMETRY(GEOMETRYCOLLECTION), PRIMARY KEY(gid));ジオメトリコレクションデータを書き込みます。
UPSERT INTO collections(gid,g) VALUES(0, ST_GeomFromText('GEOMETRYCOLLECTION (POINT (40 10), LINESTRING (10 10, 20 20, 10 40), POLYGON ((40 40, 20 45, 45 30, 40 40)))')); -
Geometry 型の列を複数持つテーブルを作成します。
CREATE TABLE mix(gid INT, pt GEOMETRY(POINT), ply GEOMETRY(POLYGON), PRIMARY KEY(gid));