すべてのプロダクト
Search
ドキュメントセンター

Lindorm:CREATE TABLE

最終更新日:Jul 04, 2026

CREATE TABLE ステートメントは、LindormTable または LindormTSDB にテーブルを作成します。VARCHAR、TIMESTAMP、BIGINT などのデータ型や、TTL、COMPRESSION などのテーブル属性をサポートしています。これらを組み合わせることで、ビジネスシナリオに合わせたテーブルを設計できます。

エンジンとバージョン

構文

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)

列定義 (column_definition)

プライマリキー (primary_key)

インデックス式 (KEY|INDEX)

✖️

パーティション (partition_definition)

✖️

テーブル属性 (table_options)

✖️

使用方法

テーブル名 (table_identifier)

テーブル名は、次の要件を満たす必要があります:

  • 名前に使用できる文字は、数字、大文字、小文字、ピリオド (.)、ハイフン (-)、アンダースコア (_) です。

  • 名前の先頭にピリオド (.) やハイフン (-) を使用することはできません。

  • 名前の長さは 1~255 文字である必要があります。

列定義 (column_definition)

構文

必須

説明

列名 (column_identifier)

はい

  • 名前に使用できる文字は、数字、大文字、小文字、ピリオド (.)、ハイフン (-)、アンダースコア (_) です。

  • システム予約語を列名として使用することはできません。

  • 名前の長さは 255 バイトを超えることはできません。

データ型 (data_type)

はい

サポートされているデータ型の詳細については、「データ型」をご参照ください。

重要

時系列テーブルを作成する際、TIMESTAMP データ型を使用する場合は、次の点にご注意ください:

  • TIMESTAMP 列は 1 つしか指定できません。

  • LindormTSDB は、中国標準時 (UTC+8) に基づいてタイムスタンプをエンコードおよび解析します。

  • 一部のレガシーシステムでは、32 ビットの UNIX タイムスタンプが処理されます。これらのタイムスタンプを LindormTSDB に書き込む前に、意味の不一致を防ぐために 1,000 を掛けてください。たとえば、タイムスタンプ 1641009600 はレガシーシステムでは 2022-01-01 12:00:00 と解釈されますが、LindormTSDB では 1970-01-20 07:50:09 (UTC+8)  と解釈されます。

NULL 制約

いいえ

列に NULL 値を許可するかどうかを示します。

重要

Lindorm SQL はこの制約を検証しません。代わりに、検証はストレージエンジンによって実行されます。

NULL 制約の検証はストレージエンジンのルールに依存し、その内容は様々です。その結果、NOT NULL で定義されていても、列に NULL 値を書き込める場合があります。

データが期待どおりに書き込まれるようにするには、次の要件に従ってください:

  • プライマリキー列は NULL にできません。テーブルを作成する際には、すべてのプライマリキー列に NOT NULL を指定する必要があります。

  • 非プライマリキー列には NOT NULL を指定しないでください。

プライマリキー (primary_key)

プライマリキーは、テーブル内のデータを一意に識別するもので、1 つ以上の列で構成されます。テーブルを作成する際には、プライマリキー (PRIMARY KEY) を指定する必要があります

重要

プライマリキーは、作成後に変更することはできません。プライマリキーは慎重に設計してください。

CREATE TABLE ステートメントを使用してテーブルを作成する際には、次の点にご注意ください:

エンジンタイプ

説明

LindormTable

  • 単一のプライマリキー列の最大長は 2 KB です。

  • すべてのプライマリキー列の合計長は 30 KB を超えることはできません。

  • 単一の非プライマリキー列の最大長は 2 MB を超えることはできません。

LindormTSDB

  • 時系列テーブルのプライマリキーでは、VARCHAR 列はTAG 列と呼ばれ、TIMESTAMP 列はタイムスタンプ列と呼ばれます。

  • プライマリキー列は、VARCHAR または TIMESTAMP データ型である必要があります。

  • プライマリキーには 1 つ以上の VARCHAR 列を含めることができますが、TIMESTAMP 列は 1 つしか含めることができません。

  • 時系列テーブルのプライマリキーには、データソースの一意の識別子を使用します。例としては、IoT シナリオのデバイス ID、Internet of Vehicles (IoV) シナリオの車両識別番号 (VIN)、監視シナリオのアプリケーション ID または ip:port 文字列などがあります。詳細については、「PRIMARY KEY の設計に関するベストプラクティス」をご参照ください。

インデックス式 (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 ステートメントにインデックス式が含まれている場合、システムはまずテーブルを作成し、次にインデックスを作成します。インデックス作成中に例外が発生した場合、テーブルとインデックスが残存し、自動的にクリアされないことがあります。SHOWDESCRIBE などのステートメントを使用してそれらを表示できますが、テーブルとインデックスにデータを書き込んだり、クエリを実行したりできない場合があります。残りのテーブルとインデックスを削除してから再作成することを推奨します。

パーティション (partition_definition)

パーティションは、LindormTSDB でのみサポートされています。時系列テーブルでは、PARTITION BY 句で使用される列は VARCHAR のプライマリキー列である必要があります。

テーブルを作成する際、PARTITION BY HASH(column1, column2, ..., columnN) ステートメントを使用して、ハッシュパーティショニングのために 1 つ以上の列を明示的に指定できます。例:PARTITION BY HASH(c1, p1)

テーブル属性 (table_options)

LindormTable のみがテーブル属性をサポートしています。WITH キーワードを使用して、次のテーブル属性を追加できます:

オプション

タイプ

説明

COMPRESSION

STRING

テーブルの圧縮アルゴリズム。有効な値:

  • SNAPPY

  • ZSTD

  • LZ4

説明

LindormTable 2.3.4 より前のバージョンでは、デフォルトで圧縮アルゴリズムは指定されません。LindormTable 2.3.4 以降では、デフォルトで ZSTD アルゴリズムが使用されます。

TTL

INT

データの Time to Live (TTL)、単位は秒 (s) です。

説明
  • デフォルトでは、この属性は設定されていません。つまり、データは期限切れになりません。

  • ステートメントに TTL=<time> を追加してテーブルの TTL を設定するか、TTL を空の文字列に設定して TTL を削除できます。使用例については、「」をご参照ください。

COMPACTION_MAJOR_PERIOD

LONG

システムが メジャーコンパクションを実行する間隔、単位はミリ秒 (ms) です。使用例については、「メジャーコンパクションの間隔の指定」をご参照ください。

説明

デフォルト値は、テーブルの TTL (ミリ秒に換算) と 1,728,000,000 ms (20 日) のうち、小さい方の値が適用されます。TTL が指定されていない場合、デフォルト値は 1,728,000,000 ms です。

MUTABILITY

STRING

ベーステーブルの書き込みモードを指定します。この属性はインデックス作成に関連しています。デフォルト値:MUTABLE_LATEST

有効な値:

  • IMMUTABLE

  • IMMUTABLE_ROWS

  • MUTABLE_LATEST

  • MUTABLE_ALL

  • MUTABLE_UDT

値の詳細については、「高性能なネイティブセカンダリインデックス」をご参照ください。

重要

インデックスが作成されると、MUTABILITY 属性は変更できません。この属性を変更するには、まずテーブルのすべてのインデックスを削除する必要があります。データ損失を防ぐため、この操作を実行する前にデータをバックアップしてください。

CONSISTENCY

STRING

テーブルの整合性レベル。クロスゾーンインスタンスの場合、この属性はプライマリレプリカとセカンダリレプリカ間のデータ整合性を指定します。有効な値:

  • eventual:結果整合性レベル。これは、インデックス式なしで作成されたテーブルのデフォルト値です。

  • strong:強力な整合性レベル。

重要

クロスゾーンインスタンスの場合、ワークロードに増加、追加、インデックス更新などの読み取り/変更/書き込み操作が含まれる場合、レプリカ間のデータ整合性を確保するために、プライマリテーブルの CONSISTENCY 属性を strong に設定する必要があります。

NUMREGIONS

INT

テーブルの事前分割リージョンの数。

CHS

INT

ホットデータとコールドデータを分離する境界、単位は秒。

説明
  • この境界を設定するには、コールドストレージ機能を有効にする必要があります。概要と有効化の手順については、「ホット/コールドデータ分離」をご参照ください。

  • この属性を設定する際には、CHS_L2='storagetype=COLD' も設定する必要があります。

STARTKEY と ENDKEY

プライマリキーの最初の列と同じデータ型。

テーブルのリージョンを事前分割するための開始キーと終了キー。

説明
  • STARTKEY と ENDKEY を指定する場合は、NUMREGIONS も指定する必要があります。NUMREGIONS を指定せずに STARTKEY と ENDKEY を指定した場合、それらは無視されます。

  • STARTKEY と ENDKEY に指定された文字列リテラル値は、プライマリキーの最初の列のデータ型に暗黙的に変換され、パーティションの開始キーと終了キーとして使用されます。この機能は、次のデータ型のみをサポートしています:

    • SMALLINT

    • INTEGER

    • BIGINT

    • CHAR

    • VARCHAR

    • FLOAT

    • DOUBLE

SPLITKEYS

プライマリキーの最初の列と同じデータ型。

テーブルのすべての事前分割リージョンの開始キー。

説明
  • SPLITKEYS 属性は LindormTable 2.5.4 以降でサポートされています。

  • 文字列ベースの SPLITKEYS 値では、コンマ (,) を使用して事前分割リージョンの開始キーを区切ります。二重引用符 ("") で囲まれたコンマは、通常の文字として扱われます。

  • SPLITKEYS 属性は、NUMREGIONS、STARTKEY、または ENDKEY 属性と一緒には使用できません。

  • STARTKEY および ENDKEY と同様に、指定された文字列リテラル値は、プライマリキーの最初の列のデータ型に暗黙的に変換され、パーティションの開始キーとして使用されます。この機能は、次のデータ型のみをサポートしています:

    • SMALLINT

    • INTEGER

    • BIGINT

    • CHAR

    • VARCHAR

    • FLOAT

    • DOUBLE

SPLITALGO

STRING

事前パーティショニングの分割アルゴリズムを定義します。サポートされているアルゴリズムは次のとおりです:

  • HexStringSplit:16 進バイトに基づいてプライマリキーを分割します。

  • UniformSplit:元のバイト値に基づいてプライマリキーを均等に分割します。

DYNAMIC_COLUMNS

STRING

動的列を有効にするかどうか。有効な値:

  • True:動的列を有効にします。

  • False:動的列を無効にします。これはデフォルト値です。

説明

動的列は Varbinary データ型のみをサポートしています。動的列の詳細については、「動的列」をご参照ください。

VERSIONS

INT

各列値について保持するバージョン数。1 以上の整数である必要があります。デフォルト:1。データバージョニングの詳細については、「データバージョニング」をご参照ください。

重要

VERSIONS 属性の値が高いと、クエリとストレージのパフォーマンスが低下する可能性があります。この値は 1 に設定することを推奨します。

BLOB_BUCKET_NAME

STRING

テーブル内の BLOB 列のバケット名。

バケット名は、次のルールに従う必要があります:

  • 使用できるのは、小文字、数字、ピリオド (.)、ハイフン (-) のみです。

  • 長さは 3~63 文字である必要があります。

  • 先頭または末尾にハイフン (-) を使用することはできません。

  • 連続したピリオド (.) を含めることはできません。

説明
  • BLOB_BUCKET_NAME 属性は LindormTable 2.6.4 以降でサポートされています。

  • テーブル作成時に BLOB 列を指定しないが、BLOB_BUCKET_NAME 属性を設定した場合、システムはバケット名の有効性をチェックしません。

説明

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_COLUMNSTRUE に設定します。

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 ページに移動し、目的のテーブルの名前をクリックします。[現在のテーブル詳細] エリアで、[テーブルプロパティの表示] をクリックして、COMPRESSIONCHSCHS_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 ページに移動し、対象のテーブル名をクリックします。 [シャード情報] エリアで、各パーティションの startKeyendKey パラメーターを確認します。

複数パーティションの開始キーの設定

コード例

  • 数値キーによるパーティションの指定 (データ分散に基づく)

    この例では、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));