CREATE TABLE

新しいテーブルを作成します。

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

テーブルでは、単一のカウンター・カラムがサポートされています。

構文

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 order ] ] 
  [ [ AND ] ID = 'table_hash_tag' ] ] ;
表 1. 凡例
構文規則 説明
大文字 リテラル・キーワード。
小文字 リテラル以外。
イタリック体 変数値。ユーザー定義値と置き換えます。
[] 任意。角かっこ（ [] ）で任意指定のコマンド引数を囲みます。角かっこは入力しないでください。
( ) グループ。丸かっこ（( )）は、選択肢を含むグループを示します。丸かっこは入力しないでください。
| または。縦棒（ | ）で代替要素を区切ります。要素のいずれかを入力してください。縦棒は入力しないでください。
... 繰り返し可能。省略記号（...）は、構文要素を必要な回数だけ繰り返すことができることを示します。
'Literal string' 単一引用符（ ' ）でCQL文内のリテラル文字を囲みます。大文字を維持するには、単一引用符を使用します。
{ key : value } マップ・コレクション。中かっこ（ { } ）でマップ・コレクションまたはキーと値のペアを囲みます。コロンでキーと値を区切ります。
<datatype1,datatype2> セット、リスト、マップ、またはタプル。山かっこ（< >）で、セット、リスト、マップまたはタプル内のデータ型を囲みます。データ型はコンマで区切ります。
cql_statement; CQL文の終了。セミコロン（ ; ）ですべてのCQL文を終了します。
[--] コマンドライン・オプションとコマンド引数は、2つのハイフン（--）。この構文は、引数がコマンドライン・オプションと間違われる可能性がある場合に役立ちます。
' <schema> ... </schema> ' 検索CQLのみ：単一引用符（ ' ）でXMLスキーマ宣言全体を囲みます。
@xml_entity='xml_entity_type' 検索CQLのみ：スキーマ・ファイルおよびsolrConfigファイル内のXML要素を上書きするための実体とリテラル値を示します。

column_definition

カラム名を設定し、データ型を定義し、必要に応じてカラムを静的またはプライマリ・キーに設定します。

テーブル名の後に丸かっこで囲み、コンマ区切りリストを使用して複数のカラムを定義します。すべてのテーブルは、少なくとも1つのプライマリ・キー・カラムが必要です。各カラムは次の構文を使用して定義されます。column_name cql_type_definition [STATIC | PRIMARY KEY] [, ...]
制約事項:
  • プライマリ・キーがカラム定義の末尾にある場合、そのカラムはそのテーブルの唯一のプライマリ・キーとなります。
  • テーブルには、少なくとも1つのPRIMARY KEYが必要です。
  • 静的カラムをプライマリ・キーにすることはできません。
  • プライマリ・キーにはfrozenのコレクションを含めることができます。
column_name
テーブル内のカラムごとに一意の名前を使用します。大文字と小文字の区別を維持する場合、または特殊文字を使用する場合は、名前を二重引用符で囲みます。
cql_type_definition
カラムで許可されるデータ型を定義します。「CQL data type」または「user-defined type」を参照してください。
STATIC
任意。カラムには単一値があります。
PRIMARY KEY

PRIMARY KEYが1つのカラムの場合、カラム定義の末尾にPRIMARY KEYを追加書き込みします。テーブルを作成するには、少なくともこのスキーマ情報が必要です。プライマリ・キーが1つの場合、それはパーティション・キーです。データはこのカラムの一意の値で分割され、格納されます。column_name cql_type_definition PRIMARY KEY。

あるいは、1つのカラムだけで構成されるプライマリ・キーを、複合プライマリ・キーと同じ方法で宣言することもできます。

PRIMARY KEY (column_list)

行を一意に識別し、ストレージ・パーティションを決定して、パーティション内のデータの順序（クラスター化カラム）を指定します。

行を一意に識別し、ストレージ・パーティションを決定して、パーティション内のデータの順序（クラスター化カラム）を指定します。
制約事項: プライマリ・キーのデータ型には、カウンター、frozen以外のコレクション、および静的な型を指定できません。
column_list
パーティションとクラスター化カラムを定義します。このオプションはデータの格納方法に影響を及ぼします。
  • 複合プライマリ・キー。最初のカラムがパーティション・キーで、その他のカラムはクラスター化キーです。構文：PRIMARY KEY (partition_column_name, clustering_column_name [, ...])
  • 複合パーティション・キー：パーティション・キーの複数のカラム。パーティション・キー・カラムを丸かっこで囲みます。構文：PRIMARY KEY ((partition_column_name[, ...]),clustering_column_name [, ...])

table_options

CQLテーブル・プロパティとその構文の説明。

cassandra.yaml

cassandra.yamlファイルの場所は、インストールのタイプによって異なります。
パッケージ・インストール /etc/dse/cassandra/cassandra.yaml
tarボール・インストール installation_location/resources/cassandra/conf/cassandra.yaml

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

テーブルにChange Data Capture（CDC）ログを作成します。

有効な値：
  • TRUE：CDCログを作成します。
  • FALSE：CDCログを作成しません。
comments = 'some text that describes the table'
テーブルに関するドキュメントを指定します。
ヒント: テーブルが条件を満たしているクエリーの種類の説明を入力します。
dclocal_read_repair_chance
コーディネーター・ノードと同じデータ・センターに制限して、読み取り操作が成功して読み取りリペアがトリガーされる確率。
警告: このオプションは廃止予定で、0.0に設定する必要があります。
default_time_to_live
TTL（Time To Live）を秒単位で指定します。0を指定すると無効になります。設定可能な最大値は630720000（20年）です。2018年以降、有効期限タイムスタンプは、ストレージ・エンジンでサポートされている最大値を超える可能性があります。以下の警告を参照してください。値が0より大きい場合は、テーブル全体に対してTTLが有効になり、各カラムに有効期限タイムスタンプが追加されます。新しいTTLタイムスタンプは、データが更新されるたびに計算され、すべてのデータの有効期限が切れると行が削除されます。

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

警告: 2038年問題のため、データベース・ストレージ・エンジンでは、January 19 2038 03:14:07 UTCのみをエンコードできます。TTL日付オーバーフローポリシーによって、有効期限が最長の日付よりも後のタイムスタンプの要求を拒否するか、受け入れるかどうかが決定します。-Dcassandra.expiration_date_overflow_policyを参照してください。
gc_grace_seconds
データにトゥームストーン（削除マーカー）のマークが付いてから、ガーベージ・コレクションの対象になるまでの時間（秒数）。デフォルト値：864000（10日）デフォルト値を使用すると、削除する前にデータベースの整合性を最大限に高めるための時間を確保できます。
注: トゥームストーンのマークが付いたレコードは、猶予期間の間、ヒントまたはバッチ・ミューテーションから除外されます。
単一ノード・クラスターでは、このプロパティを安全に0に設定できます。また、テーブルのデータが明示的に削除されていない場合、たとえばデータとTTLセットのみを含むテーブルや、default_time_to_liveセットを含むテーブルでは、この値を小さくすることもできます。ただし、gc_grace_seconds値を小さくする場合は、以下の操作とのインタラクションを考慮してください。
  • ヒントのリプレイ：ノードが停止した後で稼働を再開すると、他のノードは、応答がない間にそのノードのキューに登録されていた書き込み操作（「ヒント」と呼ばれる）をリプレイします。データベースでは、作成後にgc_grace_secondsよりも時間が経過しているヒントはリプレイしません。cassandra.yamlファイルのmax_hint_window_in_ms設定により、応答しないノードのヒントを回収する際の時間制限が設定されます（デフォルトでは3時間）。
  • バッチ・リプレイ：ヒント・キューと同様に、バッチ操作でもリプレイされるデータベース・ミューテーションが順番に格納されます。ヒントと同様に、データベースでもバッチ・ミューテーションは作成後にgc_grace_secondsが経過するまでリプレイされません。アプリケーションでバッチ操作を使用している場合は、gc_grace_secondsを小さくすると、バッチ書き込み操作によって削除されたデータが復元される可能性が高まることを考慮してください。Batchlog_replay_throttle_in_kbプロパティ（cassandra.yaml ファイル）で、バッチ・リプレイ・プロセスを一部制御できます。ただし、最も重要な要因は、使用するバッチのサイズと範囲です。
memtable_flush_period_in_ms
テーブルに関連したmemtablesがフラッシュされるまでのミリ秒数。
memtable_flush_period_in_ms=0の場合、memtableは以下の場合にフラッシュされます。
  • フラッシュのしきい値に達した場合
  • 停止時
  • nodetool flushの実行時
  • commitlogsが一杯になったとき

デフォルト：0

min_index_interval
インデックス・サマリーのインデックス・エントリー間のギャップの最小値。min_index_intervalを小さくすると、インデックス・サマリーに含まれるインデックス・エントリーが多くなるため、データベースが読み取りを実行する際に検索するインデックス・エントリーが少なくなります。インデックス・サマリーを大きくすると、使用メモリーも増えます。min_index_intervalの値は、密度が最大限に高い、インデックスのサンプリングです。
max_index_interval
すべてのインデックス・サマリーの合計メモリー使用量がこの値に達すると、DataStax Enterpriseは最も読み取り頻度の低いSSTableのインデックス・サマリーをmax_index_intervalで設定された最大値まで減らします。max_index_intervalはメモリーの負荷に対して最も疎なサンプリングになります。
nodesync
以下の構文を使用してテーブル・リペア設定を管理します。
{ 'enabled' : value, 'deadline_target_sec' : seconds }
  • enabled：テーブルでNodeSyncを有効/無効にするには、trueまたはfalseに設定します。

    デフォルト：true。

  • deadline_target_sec：テーブルのすべてのセグメントを検証する際の最大秒数を指定します。削除されたデータの復活を回避するため、gc_grace_seconds未満に設定します。nodetool nodesyncservice ratesimulatorを使用して適切な設定を計算することを推奨します。

    デフォルト：gc_grace_secondsの最大値または4日。

read_repair_chance
読み取り操作が成功して読み取りリペアがトリガーされる確率。
警告: このオプションは廃止予定で、0.0に設定する必要があります。
speculative_retry
高速読み取り保護を構成します。通常の読み取り要求は、consistency levelを十分に満たすレプリカ・ノードにのみ送信されます。高速読み取り保護の場合、整合性レベルを満たした後も、追加の読み取り要求が他のレプリカに送信されます。推測的リトライ・プロパティは、これらの追加の読み取り要求のトリガーを指定します。
  • ALWAYS：コーディネーター・ノードは、そのテーブルの読み取りがすべて終わった後に、その他すべてのレプリカに追加の読み取り要求を送信します。
  • Xpercentile：各テーブルの一般的な読み取りレイテンシーを追跡します（ミリ秒単位）。コーディネーター・ノードはテーブル読み取りの一般的なレイテンシー時間を取得し、その値のXパーセントを計算します。応答がないままコーディネーターが待機しているミリ秒数がその計算値を超えると、コーディネーターは冗長読み取り要求を送信します。

    たとえば、Table_Aのspeculative_retryプロパティが80percentileに設定されており、そのテーブルの一般的なレイテンシーが60ミリ秒である場合、Table_Aの読み取りを処理するコーディネーター・ノードは最初に通常の読み取り要求を送信し、48　ms以内（60 msの80%）に応答がない場合に冗長読み取り要求を送信します。

  • Nms：コーディネーター・ノードは、Nミリ秒以内に応答がなかった場合、他のすべてのレプリカに追加の読み取り要求を送信します。
  • NONE：コーディネーター・ノードはそのテーブルの読み取りが行われた後、追加の読み取り要求を送信しません。
コンパクション・ストラテジ
LCS STCS TWCS DTCS（廃止予定）

compression = { compression_map }

テーブル圧縮を設定します。

圧縮アルゴリズムclassの後に単純なJSON形式でサブプロパティを指定して、compression_mapを構成します。
ヒント: org.apache.cassandra.io.compress.ICompressorインターフェイスを使用してカスタム圧縮クラスを実装します。
compression = { 
   ['class' : 'compression_algorithm_name', 
     'chunk_length_kb' : 'value',  
     'crc_check_chance' : 'value',] 
   | 'sstable_compression' : ''] 
}
class
圧縮名を設定します。DataStax Enterpriseには、以下の組み込みクラスがあります。
  • LZ4Compressor
  • SnappyCompressor
  • DeflateCompressor
重要: DSEにバンドルされている圧縮実装のみを使用します。

適切な圧縮は、読み取りパフォーマンスよりも領域の節約を重視するかどうかにより異なります。解凍速度が最も速いのはLZ4で、次にSnappy、Deflateの順になります。圧縮効果は解凍速度に反比例します。一般用途のワークロードでDeflateまたはSnappyを使用した場合、圧縮率の向上よりパフォーマンス低下の影響が大きいですが、アーカイブ用データではこれらの使用を検討してみる価値があります。

デフォルト：LZ4Compressor。

chunk_length_kb

ブロックのサイズ（KB単位）。ディスク上では、SSTableは、ランダム読み取りを可能にするためにブロック単位で圧縮されます。値をデフォルト値より大きくすると、圧縮率が上がりますが、実際に読み取るときに読み取るデータの最小サイズが大きくなります。テーブルの圧縮には、デフォルト値が適切です。読み取り/書き込みアクセス・パターン（一度に要求される標準的なデータ量）とテーブル行の標準的なサイズに合わせて圧縮サイズを調整します。

デフォルト：64。

crc_check_chance

圧縮が有効にされている場合、圧縮されている各ブロックには、ディスクのデータ劣化を検知し、破損が他のレプリカに伝播するのを防止するために、そのブロックのチェックサムが含まれます。このオプションは、読み取り時にそれらのチェックサムをチェックする確率を定義します。デフォルトでは、常にチェックされます。チェックサムのチェックを無効にするには、0に設定します。たとえば、2回に1回チェックするには、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です。
重要: DSEにバンドルされているコンパクション実装のみを使用します。詳細については、「データはどのように維持されるか」を参照してください。

一般的なプロパティ

以下のプロパティは、すべてのコンパクション・ストラテジに適用されます。
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 - リペア済みSSTableでのみトゥームストーンのパージが可能です。
  • false - テーブルが未リペアでも、コンパクション時にSSTableでトゥームストーンをパージします。

デフォルト：false

tombstone_threshold
ガーベージ・コレクションの対象にできるトゥームストーンと、含まれているすべてのカラムの比率。比率がこの制限を超えると、トゥームストーンをパージするためにそのテーブルでのみコンパクションが開始されます。

デフォルト：0.2

tombstone_compaction_interval
SSTableの作成後にそこでコンパクションが実行可能になるまでの秒数。SSTableは、tombstone_thresholdを超えると、コンパクションの対象になります。1回のSSTableコンパクションの実行ではトゥームストーンを廃棄できない可能性があり、コンパクションがトゥームストーンの推定比率に基づいてトリガーされるため、この設定によって、2つのSSTableコンパクション間の最小間隔を調整可能にして、SSTableが常に再コンパクションされるのを防止します。

デフォルト：86400（1日）

unchecked_tombstone_compaction
trueに設定すると、この操作の対象であるテーブルを事前にチェックせずにトゥームストーン・コンパクションを実行できます。この事前チェックがなくても、DSEでは、トゥームストーンを安全に削除できることを確認するためにSSTableをチェックします。

デフォルト：false

min_threshold
マイナー・コンパクションをトリガーするSSTableの最小数。
制約事項: LeveledCompactionStrategyでは使用されません。

デフォルト：4

max_threshold
マイナー・コンパクションがトリガーされる前のSSTableの最小数。
制約事項: 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はすべて同一のバケットに分類されるように、このオプションを使用して、サイズのしきい値（MB単位）を定義してください。

デフォルト：50（MB）

注: SizeTieredCompactionStrategy（STCS）のcold_reads_to_omitプロパティは現在、サポートされていません。

TimeWindowCompactionStrategy

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

以下のプロパティは、TimeWindowCompactionStrategyのみに適用されます。
compaction = { 
     'class' : 'TimeWindowCompactionStrategy, 
     'compaction_window_unit' : milliseconds,
     'compaction_window_size' : int, 
     'split_during_flush' : (true | false)}
compaction_window_unit
バケット・サイズ、ミリ秒、秒、時間などを定義するために使用される時間単位。

デフォルト：milliseconds

compaction_window_size
バケットあたりの単位。
split_during_flush
リペアおよびヒントの古いデータが現在の時間枠の新しいデータと混在するのを防止します。フラッシュ操作中に、構成済みの時間枠に基づいてデータ・パーティションを分割するかどうかを決定します。
  • false - 構成済みの時間枠に基づいてデータ・パーティションが分割されません。
  • true - NodeSyncによってリペアされたデータが適切なTWCS枠に配置されます。TWCSによってNodeSyncを使用する場合、またはノードのリペアを実行する場合、split_during_flushを有効にします。

デフォルト：false

フラッシュ操作中、データは最大12の時間枠に分割されます。各時間枠では、別々のSSTableでデータが保持されます。現在の時刻がt0で、各時間枠の時間がwの場合、データは以下のようにSSTableに分割されます。
  • SSTable 0には、期間< t0 - 10 * wのデータが含まれます。
  • SSTable 1～10には、（t0 - 10 * w）～（t0 - 1 * w）の10に等しい期間のデータが含まれます。
  • 12番目のテーブルであるSSTable 11には、期間> t0のデータが含まれます。

LeveledCompactionStrategy

コンパクション・クラスLeveledCompactionStrategy（LCS）では、いくつかのレベルにグループ分けされる、固定の、比較的小さなサイズ（デフォルトでは160 MB）のSSTableが作成されます。各レベル内で、SSTableはオーバーラップしないことが保証されます。各レベル（L0、L1、L2など）は、1つ下のレベルの10倍のサイズです。SSTableは、継続的に、次第により大きなレベルへとコンパクションされていくため、レベルが低い場合よりもレベルが高い方が、ディスクI/Oが均等化され予測しやすくなります。レベルごとに、行キーはオーバーラップしない次のレベルのSSTableにマージされます。「LeveledCompactionStrategy（LCS）」を参照してください。

注: 詳細なガイダンスについては、「レベル化コンパクションを使用する場合」と「Apache Cassandraのレベル化コンパクション」のブログを参照してください。
以下のプロパティは、LeveledCompactionStrategyのみに適用されます。
compaction = { 
     'class' : 'LeveledCompactionStrategy, 
     'sstable_size_in_mb' : int}
sstable_size_in_mb
LeveledCompactionStrategyを使用するSSTableのターゲット・サイズ。SSTableのサイズは、sstable_size_in_mb以下である必要がありますが、コンパクションを行うとこの値を超える場合があります。これは、指定されたパーティション・キーのデータが非常に大きい場合に発生します。DSEデータベースは、データを2つのSSTableに分割しません。

デフォルト： 160

DateTieredCompactionStrategy（廃止予定）

重要: 代わりに、TimeWindowCompactionStrategyを使用してください。

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

base_time_seconds
最初の時間枠のサイズ。

デフォルト：3600

max_sstable_age_days（廃止予定）
DSEでは、最新のデータがこのプロパティよりも古い場合、SSTableのコンパクションが行われません。小数の日数を設定できます。

デフォルト：1000

max_window_size_seconds
時間枠の最大サイズ（秒単位）。

デフォルト：86400

timestamp_resolution
挿入されたデータのタイムスタンプを照合する単位。MICROSECONDSまたはMILLISECONDS。

デフォルト：MICROSECONDS

Tableキーワード

CLUSTERING ORDER BY ( column_name ASC | DESC)

行ストレージの順序を指定することで、ディスク上でのカラムのソート順を利用できます。順序を指定すると、クエリー結果がさらに効率化されます。オプションは以下のとおりです。

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

DESC：降順、逆の順序

ID

DROP TABLEでテーブルを誤って削除した場合は、このオプションを使用してテーブルを作成し直し、コミット・ログのリプレイを実行してデータを取得します。

例

CREATE TABLE CQLの例。

cassandra.yaml

cassandra.yamlファイルの場所は、インストールのタイプによって異なります。
パッケージ・インストール /etc/dse/cassandra/cassandra.yaml
tarボール・インストール installation_location/resources/cassandra/conf/cassandra.yaml

frozen UDTを使用したテーブルの作成

frozenユーザー定義型（UDT）を持つrace_winnersテーブルを作成します。
CREATE TABLE cycling.race_winners (
  cyclist_name FROZEN<fullname>, 
  race_name text,
  race_position int,
  PRIMARY KEY (race_name, race_position)
);

UDTの作成方法については、「ユーザー定義型の作成」を参照してください。ユーザー定義型の作成時に非コレクション・フィールドのみが使用される場合に、UDTをunfrozenとして作成できます。テーブルがunfrozen UDTを使用して作成される場合は、フィールド値を個別に更新および削除できます。

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

UUIDをプライマリ・キーとして持つcyclist_name テーブルを作成します。
CREATE TABLE cycling.cyclist_name (
  id UUID PRIMARY KEY,
  lastname text,
  firstname text
);

複合プライマリ・キーの作成

cyclist_categoryテーブルを作成して、データを逆順に格納します。
CREATE TABLE cycling.cyclist_category (
  category text,
  points int,
  id UUID,
  lastname text,
  PRIMARY KEY (category, points)
)
WITH CLUSTERING ORDER BY (points DESC);

複合パーティション・キーの作成

サイクリストの年度別ランクのクエリー用に最適化されたテーブルを作成します。
CREATE TABLE cycling.rank_by_year_and_name (
  race_year int,
  race_name text,
  cyclist_name text,
  rank int,
  PRIMARY KEY ((race_year, race_name), rank)
);

CDCログを使用したテーブルの作成

cyclist_idテーブルのChange Data Capture（CDC）ログを作成します。
CREATE TABLE 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 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 cycling.cyclist_emails (
  userid text PRIMARY KEY,
  id UUID,
  emails set<text>
) WITH ID='1bb7516e-b140-11e8-96f8-529269fb1459';