CREATE TABLE

新しいテーブルの列を定義します。

Apache Cassandraは、選択したキースペースに新しいテーブルを作成することをサポートしています。テーブルが既に存在する場合にエラーメッセージを抑制するには、IF NOT EXISTSを使用してください。テーブルは作成されません。静的列は、パーティションの複数のクラスタ化された行に同じデータを格納し、単一のSELECTステートメントでそのデータを取得できます。

テーブルは単一のカウンター列をサポートします。

参照: ALTER TABLE、DROP TABLE、ストレージアタッチインデックス (SAI) のCREATE CUSTOM INDEX、セカンダリインデックス (2i) のCREATE INDEX

構文

BNF定義

create_table_statement::= CREATE TABLE [ IF NOT EXISTS ] table_name '('
	column_definition  ( ',' column_definition )*
	[ ',' PRIMARY KEY '(' primary_key ')' ]
	 ')' [ WITH table_options ]
column_definition::= column_name cql_type [ STATIC ] [ column_mask ] [ PRIMARY KEY]
column_mask::= MASKED WITH ( DEFAULT | function_name '(' term ( ',' term )* ')' )
primary_key::= partition_key [ ',' clustering_columns ]
partition_key::= column_name  | '(' column_name ( ',' column_name )* ')'
clustering_columns::= column_name ( ',' column_name )*
table_options::= COMPACT STORAGE [ AND table_options ]
	| CLUSTERING ORDER BY '(' clustering_order ')'
	[ AND table_options ]  | options
clustering_order::= column_name (ASC | DESC) ( ',' column_name (ASC | DESC) )*

CREATE TABLE [ IF NOT EXISTS ] [<keyspace_name>.]<table_name>
  ( <column_definition> [ , ... ] | PRIMARY KEY (column_list) )
  [ WITH [ <table_options> ]
  [ [ AND ] CLUSTERING ORDER BY [ <clustering_column_name> (ASC | DESC) ] ]
  [ [ AND ] ID = '<table_hash_tag>' ] ] ;

構文の凡例

凡例
構文規則	説明
大文字	リテラルキーワード。
小文字	リテラルではありません。
`< >`	変数。ユーザー定義の値に置き換えます。
`[]`	オプション。角かっこ (`[]`) は、オプションのコマンド引数を囲みます。角かっこを入力しないでください。
`( )`	グループ。括弧 (`( )`) は、選択するグループを識別します。括弧を入力しないでください。
`\|`	または。縦棒 (`\|`) は、代替要素を区切ります。要素のいずれかを入力します。縦棒を入力しないでください。
`...`	反復可能。省略記号 (`...`) は、構文要素を必要に応じて繰り返しできることを示します。
`'<リテラル文字列>'`	単一引用符 (`'`) は、CQLステートメントのリテラル文字列を囲む必要があります。大文字を保持するには、単一引用符を使用します。
`{ <キー> : <値> }`	マップコレクション。中かっこ (`{ }`) は、マップコレクションまたはキーと値のペアを囲みます。コロンは、キーと値を区切ります。
`<データ型2`	セット、リスト、マップ、またはタプル。山かっこ (`< >`) は、セット、リスト、マップ、またはタプルのデータ型を囲みます。データ型をコンマで区切ります。
`<cql_ステートメント>;`	CQLステートメントの終了。セミコロン (`;`) は、すべてのCQLステートメントを終了します。
`[--]`	コマンドラインオプションをコマンド引数から区切るには、2つのハイフン (`--`) を使用します。この構文は、引数がコマンドラインオプションと間違えられる可能性がある場合に役立ちます。
`' <<スキーマ\> ... </スキーマ\>> '`	CQL検索のみ：単一引用符 (`'`) は、XMLスキーマ宣言全体を囲みます。
`@<xml_エンティティ>='<xml_エンティティ_タイプ>'`	CQL検索のみ：スキーマおよびsolrConfigファイル内のXML要素を上書きするエンティティとリテラル値を識別します。

必須パラメータ

table_name: インデックスを作成するテーブルの名前。
column_name: 列の名前。

column_definition

テーブル名の後の括弧で囲み、カンマ区切りのリストを使用して複数の列を定義します。すべてのテーブルには、少なくとも1つのプライマリキー列が必要です。各列は、次の構文を使用して定義されます。column_name cql_type_definition [STATIC | PRIMARY KEY] [, ...]

制限

テーブルには、少なくとも1つのPRIMARY KEYが必要です。
PRIMARY KEYが列定義の最後にある場合、その列はテーブルの唯一のプライマリキーであり、パーティションキー[パーティションキー]として定義されます。
静的列はプライマリキーにはできません。
プライマリキーには、凍結されたコレクションを含めることができます。

column_name

テーブル内の各列に一意の名前を使用します。大文字小文字を保持したり、特殊文字を使用したりするには、名前を二重引用符で囲みます。

cql_type_definition

列で許可されるデータの型を定義します。CQLデータ型またはユーザー定義型を参照してください。

STATIC

オプション、列には単一の値があります。

PRIMARY KEY

PRIMARY KEYが1つの列である場合は、列定義の最後にPRIMARY KEYを追加します。これは、テーブルを作成するために必要なスキーマ情報のみです。プライマリキーが1つある場合、それはパーティションキーです。データは、この列の一意の値によって分割および格納されます。column_name cql_type_definition PRIMARY KEY。

または、複合プライマリキーを宣言するのと同じ方法で、1つの列のみで構成されるプライマリキーを宣言することもできます。

column_definition

制限

テーブルには、少なくとも1つのPRIMARY KEYが必要です。
PRIMARY KEYが列定義の最後にある場合、その列はテーブルの唯一のプライマリキーであり、パーティションキー[パーティションキー]として定義されます。
静的列はプライマリキーにはできません。
プライマリキーには、凍結されたコレクションを含めることができます。

column_name

テーブル内の各列に一意の名前を使用します。大文字小文字を保持したり、特殊文字を使用したりするには、名前を二重引用符で囲みます。

cql_type_definition

列で許可されるデータの型を定義します。CQLデータ型またはユーザー定義型を参照してください。

STATIC

オプション、列には単一の値があります。

PRIMARY KEY

PRIMARY KEYが1つの列である場合は、列定義の最後にPRIMARY KEYを追加します。これは、テーブルを作成するために必要なスキーマ情報のみです。プライマリキーが1つある場合、それはパーティションキーです。データは、この列の一意の値によって分割および格納されます。column_name cql_type_definition PRIMARY KEY。

または、複合プライマリキーを宣言するのと同じ方法で、1つの列のみで構成されるプライマリキーを宣言することもできます。

table_options

I/O操作、圧縮、コンパクションなど、データ処理を調整します。テーブルプロパティオプションは、次の構文を使用します。

単一の値: <option_name> = '<value>'
複数の値: <option_name> = { '<subproperty>' : '<value>' [, ...] } [AND ...]

単純なJSON形式、中かっこで囲まれたカンマ区切りのリストのキーと値のペア。

値が指定されていない場合は、デフォルトが使用されます。

CREATE TABLE (または ALTER TABLE) CQLステートメントでは、WITH句を使用してテーブルプロパティオプションを定義します。複数の値をANDで区切ります。

CREATE TABLE [<keyspace_name>.]<table_name>
WITH option_name = '<value>'
AND option_name = {<option_map>};

bloom_filter_fp_chance = <N>: SSTable ブルームフィルタの偽陽性確率。クライアントがデータを要求すると、ブルームフィルタは、ディスクI/Oを実行する前に行が存在するかどうかを確認します。値の範囲は0〜1.0で、0は可能な限り最大のブルームフィルタを有効にするために使用される最小値（最も多くのメモリを使用）であり、1.0はブルームフィルタを無効にする最大値です。

推奨設定: 0.1。値を大きくすると、収穫逓減になります。

デフォルト: bloom_filter_fp_chance = '0.01'

caching = { 'keys' : 'value', 'rows_per_partition' : 'value'}

手動調整なしでキャッシュメモリの使用を最適化します。キャッシュされたデータをサイズとアクセス頻度によって重み付けします。この設定は、cassandra.yamlファイルのグローバルキャッシュプロパティと連携させます。有効な値

ALL-- すべてのプライマリキーまたは行
NONE-- プライマリキーまたは行なし
<N>: (パーティションごとの行数のみ) — 整数を指定しますデフォルト: { 'keys': 'ALL', 'rows_per_partition': 'NONE' }

cdc

テーブルにチェンジデータキャプチャ (CDC) ログを作成します。

有効な値

TRUE- CDCログを作成する
FALSE- CDCログを作成しない

comment = 'テーブルを説明するテキスト'

テーブルに関するドキュメントを提供します。

テーブルが満たすように設計されたクエリのタイプに関する説明を入力します。

default_time_to_live

TTL（Time To Live）は秒単位で、ゼロの場合は無効です。設定可能な最大値は630720000（20年）です。2018年以降、有効期限のタイムスタンプはストレージエンジンでサポートされる最大値を超える可能性があります。以下の警告を参照してください。値がゼロより大きい場合、テーブル全体でTTLが有効になり、各列に有効期限のタイムスタンプが追加されます。データが更新されるたびに新しいTTLタイムスタンプが計算され、すべてのデータが期限切れになると行が削除されます。

デフォルト値：0（無効）。

データベースのストレージエンジンは、2038年問題により、2038年1月19日03:14:07 UTCまでのTTLタイムスタンプしかエンコードできません。TTL日付オーバーフローポリシーは、最大日付より後の有効期限タイムスタンプを持つリクエストを拒否するか、挿入するかを決定します。

gc_grace_seconds

データに墓石（削除マーカー）が付けられてから、ガベージコレクションの対象になるまでの秒数。デフォルト値：864000（10日）。デフォルト値は、削除前にデータベースが最大限の整合性を確保するのに十分な時間を確保します。

猶予期間内の墓石化されたレコードは、ヒントまたはバッチ処理された変更から除外されます。

シングルノードクラスタでは、このプロパティを安全にゼロに設定できます。また、明示的に削除されないデータを含むテーブル（例えば、TTLが設定されたデータのみを含むテーブル、またはdefault_time_to_liveが設定されたテーブル）の場合は、この値を小さくすることができます。ただし、gc_grace_secondsの値を小さくする場合は、これらの操作との相互作用を考慮してください。

ヒントのリプレイ：ノードがダウンして復旧すると、他のノードは、そのノードが応答しなかった間にキューに入っていた書き込み操作（ヒントと呼ばれる）をリプレイします。データベースは、作成後gc_grace_secondsより古いヒントをリプレイしません。 max_hint_window設定は、cassandra.yamlファイルにあり、応答しないノードに対するヒントの収集時間制限（デフォルトでは3時間）を設定します。
バッチリプレイ：ヒントキューと同様に、バッチ操作は、順番にリプレイされるデータベースの変更を保存します。ヒントと同様に、データベースは作成後gc_grace_secondsより古いバッチ処理された変更をリプレイしません。アプリケーションがバッチ操作を使用する場合、gc_grace_secondsを小さくすると、バッチ処理された書き込み操作が削除されたデータを復元する可能性が高まることを考慮してください。cassandra.yamlファイルのconfiguration/cass_yaml_file.html#batchlog_replay_throttle[batchlog_replay_throttle]プロパティは、バッチリプレイプロセスの制御を可能にします。ただし、最も重要な要因は、使用するバッチのサイズと範囲です。

memtable_flush_period_in_ms

テーブルに関連付けられたmemtableがフラッシュされるまでのミリ秒数。memtable_flush_period_in_ms=0の場合、memtableは次のときにフラッシュされます。

フラッシュのしきい値に達した場合
シャットダウン時
nodetool flush時
コミットログがいっぱいになったときデフォルト：0

min_index_interval

インデックスサマリー内のインデックスエントリ間の最小ギャップ。min_index_intervalが小さいほど、インデックスサマリーにはインデックスからのエントリが多く含まれるため、データベースは読み取りを実行するために検索するインデックスエントリを減らすことができます。インデックスサマリーが大きいと、より多くのメモリを使用する可能性があります。min_index_intervalの値は、インデックスの可能な限り最も密なサンプリングです。

max_index_interval

すべてのインデックスサマリーの合計メモリ使用量がこの値に達した場合、Apache Cassandraは、最もコールドなSSTablesのインデックスサマリーをmax_index_intervalで設定された最大値まで縮小します。max_index_intervalは、メモリ負荷に関連して可能な限り最も疎なサンプリングです。

speculative_retry

高速読み取り保護を構成します。通常の読み取り要求は、整合性レベルを満たすのに十分な数のレプリカノードにのみ送信されます。高速読み取り保護では、整合性レベルが満たされた後でも、追加の読み取り要求が他のレプリカに送信されます。投機的再試行プロパティは、これらの追加の読み取り要求のトリガーを指定します。

ALWAYS：コーディネーターノードは、そのテーブルの読み取りごとに、他のすべてのレプリカに追加の読み取り要求を送信します。
<X>パーセンタイル：各テーブルの一般的な読み取りレイテンシ（ミリ秒単位）を追跡します。コーディネーターノードは、読み取り対象のテーブルの一般的なレイテンシ時間を取得し、その数値のXパーセントを計算します。コーディネーターは、応答なしに待機するミリ秒数が計算された数値を超える場合、冗長な読み取り要求を送信します。

たとえば、Table_Aのspeculative_retryプロパティが80パーセンタイルに設定されていて、そのテーブルの一般的なレイテンシが60ミリ秒の場合、Table_Aの読み取りを処理するコーディネーターノードは、最初に通常の読み取り要求を送信し、48ミリ秒（60ミリ秒の80％）以内に応答がない場合、冗長な読み取り要求を送信します。
<N>ms：コーディネーターノードは、Nミリ秒以内に応答を受信しなかった場合、他のすべてのレプリカに追加の読み取り要求を送信します。
NONE：コーディネーターノードは、そのテーブルの読み取り後に追加の読み取り要求を送信しません。

コンパクション戦略
UCS	LCS	STCS	TWCS

コンパクション戦略

compression = { compression_map }

圧縮アルゴリズムclassと、それに続くサブプロパティをシンプルなJSON形式で指定して、compression_mapを構成します。

org.apache.cassandra.io.compress.ICompressorインターフェースを使用して、カスタム圧縮クラスを実装します。

compression = {
   ['class' : '<compression_algorithm_name>',
     'chunk_length_in_kb' : '<value>',
     'crc_check_chance' : '<value>',]
   | 'sstable_compression' : '']
}

class

コンプレッサー名を設定します。Apache Cassandraは、次の組み込みクラスを提供します。

圧縮アルゴリズム Cassandraクラス圧縮解凍比率 C*バージョン

圧縮アルゴリズム	Cassandraクラス	圧縮	解凍	比率	C*バージョン
LZ4	`LZ4Compressor`	A+	A+	C+	`>=1.2.2`
LZ4HC	`LZ4Compressor`	C+	A+	B+	`>= 3.6`
Zstd	`ZstdCompressor`	A-	A-	A+	`>= 4.0`
Snappy	`SnappyCompressor`	A-	A	C	`>= 1.0`
Deflate（zlib）	`DeflateCompressor`	C	C	A	`>= 1.0`

LZ4

LZ4Compressor

A+

C+

>=1.2.2

LZ4HC

LZ4Compressor

C+

A+

B+

>= 3.6

Zstd

ZstdCompressor

A-

A+

>= 4.0

Snappy

SnappyCompressor

A-

>= 1.0

Deflate（zlib）

DeflateCompressor

>= 1.0

Apache Cassandraにバンドルされている圧縮実装のみを使用してください。

適切なコンプレッサーの選択は、読み取りパフォーマンスに対するスペース節約の要件によって異なります。LZ4は解凍が最も速く、Snappy、Deflateの順になります。圧縮効果は、解凍速度と反比例します。DeflateまたはSnappyによる追加の圧縮は、一般的なワークロードでのパフォーマンス低下を補うには十分ではありませんが、アーカイブデータでは検討する価値があるかもしれません。

デフォルト：LZ4Compressor。

chunk_length_in_kb

ブロックのサイズ（KB単位）。ディスク上では、SSTablesはランダムな読み取りを可能にするためにブロック単位で圧縮されます。デフォルト値よりも大きい値は、圧縮率を向上させる可能性がありますが、読み取りが発生したときにディスクから読み取るデータの最小サイズが増加します。デフォルト値は、テーブルを圧縮するための適切な中間点です。読み取り/書き込みアクセスパターン（一度に要求されるデータの量）とテーブル内の行の平均サイズを考慮して、圧縮サイズを調整します。

デフォルト：64。

crc_check_chance

圧縮が有効になっている場合、各圧縮ブロックには、ディスクのビット腐敗を検出し、破損が他のレプリカに伝播するのを防ぐために、そのブロックのチェックサムが含まれています。このオプションは、読み取り中にそれらのチェックサムがチェックされる確率を定義します。デフォルトでは、常にチェックされます。チェックサムのチェックを無効にする場合は0に設定し、たとえば、読み取りごとにチェックする場合は0.5に設定します。

デフォルト：1.0。

sstable_compression

圧縮を無効にします。null値を指定します。

compaction = {compaction_map}

書き込み後のデータをクリーンアップするための戦略を定義します。

構文はシンプルなJSON形式を使用します

compaction = {
     'class' : '<compaction_strategy_name>',
     '<property_name>' : <value> [, ...] }

ここで、<compaction_strategy_name>は、SizeTieredCompactionStrategy、TimeWindowCompactionStrategy、またはLeveledCompactionStrategyです。

Apache Cassandraにバンドルされているコンパクション実装のみを使用してください。詳細については、コンパクションを参照してください。

共通プロパティ

次のプロパティは、すべてのコンパクション戦略に適用されます。

compaction = {
     'class' : 'compaction_strategy_name',
     'enabled' : (true | false),
     'log_all' : (true | false),
     'only_purge_repaired_tombstone' : (true | false),
     'tombstone_threshold' : <ratio>,
     'tombstone_compaction_interval' : <sec>,
     'unchecked_tombstone_compaction' : (true | false),
     'min_threshold' : <num_sstables>,
     'max_threshold' : <num_sstables> }

enabled

バックグラウンドコンパクションを有効にします。

trueはマイナーコンパクションを実行します。
falseはマイナーコンパクションを無効にします。

コンパクションの実行を開始するには、nodetool enableautocompactionを使用します。

デフォルト：true

log_all

クラスター全体の高度なロギングを有効にします。

デフォルト：false

only_purge_repaired_tombstone

このプロパティを有効にすると、gc_grace_seconds内で修復が実行されない場合にデータが復活するのを防ぎます。修復の間隔が長い場合、データベースはすべての墓石を保持します。

true - 修復されたSSTablesでの墓石のパージのみを許可します。
false - テーブルが修復されていない場合でも、コンパクション中にSSTablesの墓石をパージします。

デフォルト：false

tombstone_threshold

ガベージコレクション可能な墓石の、含まれるすべての列に対する比率。比率がこの制限を超えると、墓石をパージするために、そのテーブルでのみコンパクションが開始されます。

デフォルト：0.2

tombstone_compaction_interval

SSTableが作成されてからコンパクションが実行可能になるまでの秒数。SSTableがtombstone_thresholdを超えると、コンパクションの対象になります。単一のSSTableコンパクションを実行するときに墓石を削除できない可能性があり、コンパクションが推定された墓石の比率に基づいてトリガーされるため、この設定は、SSTableが絶えず再コンパクションされるのを防ぐために、2つの単一SSTableコンパクション間の最小間隔を調整可能にします。

デフォルト：86400（1日）

unchecked_tombstone_compaction

trueに設定すると、どのテーブルが操作の対象であるかを事前に確認せずに、墓石コンパクションを実行できます。この事前チェックがなくても、Apache CassandraはSSTableをチェックして、墓石を安全に削除できることを確認します。

デフォルト：false

min_threshold

マイナーコンパクションをトリガーするSSTablesの最小数。

制限： LeveledCompactionStrategyでは使用されません。

デフォルト：4

max_threshold

マイナーコンパクションがトリガーされるまでのSSTablesの最大数。

制限： LeveledCompactionStrategyでは使用されません。

デフォルト：32

SizeTieredCompactionStrategy

コンパクションクラスSizeTieredCompactionStrategy（STCS）は、テーブルがmin_thresholdを満たすと、マイナーコンパクションをトリガーします。マイナーコンパクションは、キースペース内のすべてのテーブルを対象とするわけではありません。「SizeTieredCompactionStrategy (STCS)」を参照してください。

デフォルトのコンパクション戦略。

以下のプロパティは、SizeTieredCompactionStrategyにのみ適用されます。

compaction = {
     'class' : 'SizeTieredCompactionStrategy',
     'bucket_high' : <factor>,
     'bucket_low' : <factor>,
     'min_sstable_size' : <int> }

bucket_high: サイズ階層型コンパクションは、ほぼ同じサイズのSSTableのセットをマージします。データベースは、各SSTableのサイズを、ノード上のこのテーブルのすべてのSSTableサイズの平均と比較します。KB単位のサイズが[平均サイズ * bucket_low]と[平均サイズ * bucket_high]の間にあるSSTableをマージします。

デフォルト: 1.5
bucket_low: サイズ階層型コンパクションは、ほぼ同じサイズのSSTableのセットをマージします。データベースは、各SSTableのサイズを、ノード上のこのテーブルのすべてのSSTableサイズの平均と比較します。KB単位のサイズが[平均サイズ * bucket_low]と[平均サイズ * bucket_high]の間にあるSSTableをマージします。

デフォルト: 0.5
min_sstable_size: STCSはSSTableをバケットにグループ化します。バケット処理では、サイズが50％未満異なるSSTableをグループ化します。このバケット処理は、小さなSSTableには細かすぎます。SSTableが小さい場合は、このオプションを使用して、すべてのSSTableが1つの固有のバケットに属するMB単位のサイズしきい値を定義します。

デフォルト: 50 (MB)

SizeTieredCompactionStrategy (STCS)のcold_reads_to_omitプロパティは、サポートされなくなりました。

TimeWindowCompactionStrategy

コンパクションクラスTimeWindowCompactionStrategy（TWCS）は、一連の時間ウィンドウまたはバケットを使用してSSTableをコンパクションします。TWCSは、連続する各時間間隔内で新しい時間ウィンドウを作成します。アクティブな時間ウィンドウの間、TWCSは、メモリからフラッシュされたすべてのSSTableをSTCSを使用してより大きなSSTableにコンパクションします。時間間隔の終わりに、これらのすべてのSSTableは1つのSSTableにコンパクションされます。次に、次の時間ウィンドウが開始され、プロセスが繰り返されます。「TimeWindowCompactionStrategy (TWCS)」を参照してください。

STCSのすべてのプロパティは、TWCSでも有効です。

以下のプロパティは、TimeWindowCompactionStrategyにのみ適用されます。

compaction = {
     'class' : 'TimeWindowCompactionStrategy,
     'compaction_window_unit' : <days>,
     'compaction_window_size' : <int>,
     'split_during_flush' : (true | false) }

compaction_window_unit: バケットサイズを定義するために使用される時間単位。値はJavaのTimeUnitに基づいています。有効な値のリストについては、docs.oracle.com/javase/8/docs/api/java/util/concurrent/TimeUnit.htmlにあるJava API TimeUnitページを参照してください。

デフォルト: days
compaction_window_size: バケットあたりの単位数。

デフォルト: 1

LeveledCompactionStrategy

コンパクションクラスLeveledCompactionStrategy（LCS）は、レベルにグループ化された固定の比較的小さなサイズ（デフォルトでは160MB）のSSTableを作成します。各レベル内では、SSTableが重複しないことが保証されています。各レベル（L0、L1、L2など）は、前のレベルの10倍の大きさです。SSTableが徐々に大きなレベルに継続的にコンパクションされるため、ディスクI/Oは低いレベルよりも高いレベルでより均一で予測可能です。各レベルで、行キーは次のレベルの重複しないSSTableにマージされます。「LeveledCompactionStrategy (LCS)」を参照してください。

詳細については、「Leveled Compactionを使用する場合」と「Leveled Compaction」のブログを参照してください。

以下のプロパティは、LeveledCompactionStrategyにのみ適用されます。

compaction = {
     'class' : 'LeveledCompactionStrategy,
     'sstable_size_in_mb' : <int> }

sstable_size_in_mb

LeveledCompactionStrategyを使用するSSTableのターゲットサイズ。SSTableのサイズはsstable_size_in_mb以下にする必要がありますが、コンパクション中にコンパクションによってより大きなSSTableが生成される可能性があります。これは、特定のパーティションキーのデータが非常に大きい場合に発生します。Apache Cassandraデータベースは、データを2つのSSTableに分割しません。

デフォルト: 160

デフォルト値の160MBは非効率的であり、データベースのインデックス作成やインデックスに依存するクエリに悪影響を与える可能性があります。たとえば、(SAI) インデックスを使用するテーブルでsstable_size_in_mbに大きな値を使用することのメリットを検討してください。関連情報については、「コンパクション戦略」を参照してください。

DateTieredCompactionStrategy（非推奨）

代わりに「TimeWindowCompactionStrategy」を使用してください。

特定の期間内に書き込まれたデータを同じSSTableに保存します。

base_time_seconds: 最初の時間ウィンドウのサイズ。

デフォルト: 3600
max_sstable_age_days（非推奨）: Apache Cassandraは、最新のデータがこのプロパティよりも古い場合、SSTableをコンパクションしません。小数点付きの日数を設定できます。

デフォルト: 1000
max_window_size_seconds: 秒単位の最大ウィンドウサイズ。

デフォルト: 86400
timestamp_resolution: 挿入されたデータのタイムスタンプに一致する単位（<MICROSECONDS>または<MILLISECONDS>）。

デフォルト: MICROSECONDS

オプションパラメーター

テーブルキーワード

CLUSTERING ORDER BY（column_name ASC | DESC）: 列のディスク上のソートを利用するために行のストレージを並べ替えます。順序を指定すると、クエリ結果がより効率的になる可能性があります。オプションは次のとおりです。

ASC: 昇順（デフォルトの順序）

DESC: 降順、逆順
ID: テーブルがDROP TABLEで誤って削除された場合は、このオプションを使用してテーブルを再作成し、コミットログを再生してデータを取得します。
index_name: インデックスの名前。特殊文字を使用したり、大文字と小文字を保持したりする場合は、引用符で囲みます。名前が指定されていない場合、Apache Cassandraはインデックスに<table_name>_<column_name>_idxという名前を付けます。
keyspace_name: インデックスを付けるテーブルを含むキースペースの名前。名前が指定されていない場合は、現在のキースペースが使用されます。

使用上の注意

列にすでにデータが含まれている場合は、このステートメントの実行中にインデックスが作成されます。インデックスが作成されると、列のデータが変更されると自動的に更新されます。

CREATE INDEXコマンドを使用したインデックス作成は、パフォーマンスに影響を与える可能性があります。インデックスを作成する前に、インデックスを作成するタイミングとインデックスを作成しないタイミングを把握しておいてください。

制限事項：カウンター列のインデックス作成はサポートされていません。

例

UUIDをプライマリキーとして持つテーブルを作成する

UUIDをプライマリキーとして持つcyclist_nameテーブルを作成します。

CREATE TABLE IF NOT EXISTS cycling.cyclist_name (
  id UUID PRIMARY KEY,
  lastname text,
  firstname text
);

複合プライマリキーを作成する

cyclist_categoryテーブルを作成し、データを逆順に保存します。

CREATE TABLE IF NOT EXISTS cycling.cyclist_category (
  category text,
  points int,
  id UUID,
  lastname text,
  PRIMARY KEY (category, points)
)
WITH CLUSTERING ORDER BY (points DESC);

複合パーティションキーを作成する

年ごとのサイクリストのランクによるクエリ用に最適化されたテーブルを作成します。

CREATE TABLE IF NOT EXISTS cycling.rank_by_year_and_name (
  race_year int,
  race_name text,
  cyclist_name text,
  rank int,
  PRIMARY KEY ((race_year, race_name), rank)
);

ベクトル列を持つテーブルを作成する

ベクトル列を持つテーブルを作成します。

CREATE TABLE IF NOT EXISTS cycling.comments_vs (
  record_id timeuuid,
  id uuid,
  commenter text,
  comment text,
  comment_vector VECTOR <FLOAT, 5>,
  created_at timestamp,
  PRIMARY KEY (id, created_at)
)
WITH CLUSTERING ORDER BY (created_at DESC);

フリーズされたUDTを持つテーブルを作成する

フリーズされたユーザー定義型（UDT）を持つrace_winnersテーブルを作成します。

CREATE TABLE IF NOT EXISTS cycling.race_winners (
  cyclist_name FROZEN<fullname>,
  race_name text,
  race_position int,
  PRIMARY KEY (race_name, race_position)
);

UDTの作成については、「ユーザー定義型の作成」を参照してください。ユーザー定義型の作成でコレクション以外のフィールドのみが使用される場合、UDTをフリーズ解除して作成できます。テーブルがフリーズ解除されたUDTで作成された場合、「個々のフィールド値を更新および削除できます。

CDCログを持つテーブルを作成する

cyclist_idテーブルの変更データキャプチャログを作成します。

CREATE TABLE IF NOT EXISTS cycling.cyclist_id (
  lastname text,
  firstname text,
  age int,
  id UUID,
  PRIMARY KEY ((lastname, firstname), age)
);

CDCロギングはcassandra.yamlで有効にする必要があります。

CDCロギングを有効にする前に、ログ情報を移動および消費するための計画を立ててください。ディスク容量の制限に達すると、CDC対応のテーブルへの書き込みは、より多くのスペースが解放されるまで拒否されます。利用可能なCDC設定については、「Change-data-capture（CDC）スペース設定」を参照してください。

降順でデータを保存する

次の例は、最高のポイントを持つカテゴリを最初に保存するテーブル定義を示しています。

CREATE TABLE IF NOT EXISTS cycling.cyclist_category (
  category text,
  points int,
  id UUID,
  lastname text,
  PRIMARY KEY (category, points)
)
WITH CLUSTERING ORDER BY (points DESC);

コミットログ再生用のテーブルIDからの復元

コミットログの再生によるテーブルデータの復元を容易にするために、元のIDを使用してテーブルを再作成します。

CREATE TABLE IF NOT EXISTS cycling.cyclist_emails (
  userid text PRIMARY KEY,
  id UUID,
  emails set<text>
)
WITH ID = '1bb7516e-b140-11e8-96f8-529269fb1459';

テーブルのIDを取得するには、system_schema.tablesのid列をクエリします。例:

SELECT id
FROM system_schema.tables
WHERE keyspace_name = 'cycling'
  AND table_name = 'cyclist_emails';

テーブルの復元を実行するには、詳細について「バックアップ」を参照してください。

Cassandra ドキュメント

バージョン

CREATE TABLE

構文

必須パラメータ

column_definition

column_definition

table_options

compression = { compression_map }

compaction = {compaction_map}

共通プロパティ

SizeTieredCompactionStrategy

TimeWindowCompactionStrategy

LeveledCompactionStrategy

DateTieredCompactionStrategy（非推奨）

オプションパラメーター

テーブルキーワード

使用上の注意

例

UUIDをプライマリキーとして持つテーブルを作成する

複合プライマリキーを作成する

複合パーティションキーを作成する

ベクトル列を持つテーブルを作成する

フリーズされたUDTを持つテーブルを作成する

CDCログを持つテーブルを作成する

降順でデータを保存する

コミットログ再生用のテーブルIDからの復元