CREATE TABLE

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

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

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

構文

CREATE TABLE [IF NOT EXISTS] [keyspace_name.]table_name ( 
   column_definition [, ...]
   PRIMARY KEY (column_list))
[WITH table_options
   | CLUSTERING ORDER BY (clustering_column_name order])
   | ID = 'table_hash_tag'
   | COMPACT STORAGE]

表 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データ型」または「ユーザー定義型」を参照してください。

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テーブル・プロパティとその構文の説明。

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

単一値の場合：option_name = 'value'
値が複数の場合：option_name = { 'subproperty' : 'value' [, ...] } [AND ...]
単純なJSON形式のキー/値ペアのコンマ区切りリストを中かっこで囲みます。

注: 値を指定しない場合、デフォルトが使用されます。

以下の例に示すように、CQL文ではWITH句を使用してテーブル・プロパティのオプションを定義し、複数の値をANDで区切ります。

ALTER 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 = TRUE | FALSE

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

有効な値：

TRUE：CDCログを作成します。
FALSE：CDCログを作成しません。

comments = 'some text that describes the table etc'

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

ヒント: テーブルが条件を満たしているクエリーの種類の説明を入力します。

dclocal_read_repair_chance

読み取り操作が成功して読み取りリペアがトリガーされる確率を0～1で示します。デフォルト値：0.01。read_repair_chanceで制御されているリペアと異なり、このリペアはコーディネーターと同じデータ・センターにあるレプリカに制限されます。

default_time_to_live

TTL（Time To Live）を秒単位で指定します。0を指定すると無効になります。この値を指定すると、テーブルの各カラムにTime To Live（TTL）マーカーの値が設定されます。デフォルト値：0。テーブルのTTLを超過すると、テーブルにトゥームストーンのマークが付きます。

gc_grace_seconds

データにトゥームストーン（削除マーカー）のマークが付いてから、ガーベージ・コレクションの対象になるまでの時間（秒数）。デフォルト値：864000。デフォルト値を使用すると、削除する前にデータベースの整合性を最大限に高めるための時間を確保できます。

注: トゥームストーンのマークが付いたレコードは、猶予期間の間、ヒントまたはバッチ・ミューテーションから除外されます。

単一ノード・クラスターでは、このプロパティを安全に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はメモリーの負荷に対して最も疎なサンプリングになります。

read_repair_chance

読み取り操作が成功して読み取りリペアがトリガーされる確率。dclocal_read_repair_chanceで制御されているリペアと異なり、このリペアはコーディネーターと同じデータ・センターにあるレプリカに制限されません。値は0～1とする必要があります。デフォルト値：0.0。

speculative_retry

read_repair_chanceが1.0ではない場合に通常の読み取りタイムアウトをオーバーライドして、別の読み取り要求を送信します。値には、数字の次に型（ms（ミリ秒数）またはpercentile）を指定します。たとえば、speculative_retry = '3ms'のようになります。

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

ALWAYS：コーディネーター・ノードは、そのテーブルの読み取りがすべて終わった後に、その他すべてのレプリカに追加の読み取り要求を送信します。
Xpercentile：各テーブルの一般的な読み取りレイテンシーを追跡します（ミリ秒単位）。コーディネーター・ノードはテーブル読み取りの一般的なレイテンシー時間を取得し、その値のXパーセントを計算します。応答がないままコーディネーターが待機しているミリ秒数がその計算値を超えると、コーディネーターは冗長読み取り要求を送信します。
たとえば、Table_Aのspeculative_retryプロパティが80percentileに設定されており、そのテーブルの一般的なレイテンシーが60ミリ秒である場合、Table_Aの読み取りを処理するコーディネーター・ノードは最初に通常の読み取り要求を送信し、48　ms以内（60 msの80%）に応答がない場合に冗長読み取り要求を送信します。
Nms：コーディネーター・ノードは、Nミリ秒以内に応答がなかった場合、他のすべてのレプリカに追加の読み取り要求を送信します。
NONE：コーディネーター・ノードはそのテーブルの読み取りが行われた後、追加の読み取り要求を送信しません。


コンパクション・ストラテジ
LCS	STCS	TWCS	DTCS（廃止予定）

cassandra.yamlファイルの場所は、インストールのタイプによって異なります。

パッケージ・インストール Installer-Servicesインストール	/etc/dse/cassandra/cassandra.yaml
tarボール・インストール Installer-No Servicesインストール	`install_location`/resources/cassandra/conf/cassandra.yaml

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

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

デフォルト：LZ4Compressor。

chunk_length_kb

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

デフォルト：。

crc_check_chance

圧縮が有効にされている場合、圧縮されている各ブロックには、ディスクのデータ劣化を検知し、破損が他のレプリカに伝播するのを防止するために、そのブロックのチェックサムが含まれます。このオプションは、読み取り時にそれらのチェックサムをチェックする確率を定義します。デフォルトでは、常にチェックされます。チェックサムのチェックを無効にするには、0に設定します。たとえば、2回に1回チェックするには、0.5に設定します。

デフォルト：1.0。

sstable_compression

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

compaction = {compaction_map}

コンパクション・オプションとそのサブプロパティのマップの作成。

書き込み後のデータのクリーンアップのためのストラテジを定義します。コンパクション・クラスとプロパティを単純なJSON形式で定義します。compaction = { 'class' : 'compaction_strategy_name' [, 'subproperty_name' : 'value',...] }

注: 詳細なガイダンスについては、「レベル化コンパクションを使用する場合」、レベル化コンパクションのブログ、および「データはどのように維持されるか？」を参照してください。

DataStax Enterpriseには以下のコンパクション・クラスが用意されており、クラスごとにサブプロパティは異なります。

compaction_strategy_name

SizeTieredCompactionStrategy（STCS）

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

デフォルトのコンパクション・ストラテジ。

表 2. サブプロパティ
サブプロパティ	デフォルト	説明
bucket_high	`1.5`	サイズ階層化コンパクションは、ほぼ同じサイズのSSTableのセットをマージします。データベースは、ノードのすべてのSSTableサイズの平均と各SSTableサイズを比較します。サイズ（KB単位）が[平均サイズ × bucket_low]～[平均サイズ × bucket_high]の範囲のSSTableをマージします。
bucket_low	`0.5`	「bucket_high」を参照してください。
enabled	`true`	バックグラウンド・コンパクションを有効にします。
log_all	`false`	クラスター全体に対して高度なロギングをアクティブ化します。
max_threshold	`32`	マイナー・コンパクションで許可するSSTableの最大数。
min_threshold	`4`	マイナー・コンパクションをトリガーするSSTableの最小数。
min_sstable_size	`50 MB`	STCSは、SSTableをバケットにグループ分けします。バケット・プロセスは、サイズの違いが50%未満のSSTableをグループ分けします。SSTableのサイズが小さい場合、このバケット・プロセスでは分類が細かすぎます。SSTableのサイズが小さい場合は、一定値未満のSSTableはすべて同一のバケットに分類されるように、min_sstable_sizeを使用して、サイズのしきい値（単位はバイト）を定義してください。
only_purge_repaired_tombstones	`false`	`true`に設定すると、トゥームストーンのみをリペア済みのSSTableからパージできます。これにより、リペアが`gc_grace_seconds`内で実行されない場合に、データが復活されることがなくなります。長期間リペアを実行しないと、データベースにすべてのトゥームストーンが保持され、問題が発生する場合があります。
tombstone_compaction_interval	`86400`	SSTableの作成後、SSTableがトゥームストーン・コンパクションの対象と見なされるまでの最小秒数。テーブルがtombstone_thresholdの比率を超えると、SSTableがトゥームストーン・コンパクションの対象になります。
tombstone_threshold	`0.2`	ガーベージ・コレクションの対象にできるトゥームストーンと、含まれているすべてのカラムの比率。比率がこの制限を超えると、トゥームストーンをパージするためにそのテーブルでのみコンパクションが開始されます。
unchecked_tombstone_compaction	`false`	`true`に設定すると、この操作の対象であるテーブルを事前にチェックせずにトゥームストーン・コンパクションを実行できます。この事前チェックがなくても、DataStax Enterpriseでは、トゥームストーンを安全に削除できることを確認するためにSSTableをチェックします。

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

DateTieredCompactionStrategy（廃止予定）

代わりに、TimeWindowCompactionStrategy（TWCS）を使用してください。

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

表 3. サブプロパティ
サブプロパティ	デフォルト	説明
base_time_seconds	`3600`	最初の時間枠のサイズ。
enabled	`true`	バックグラウンド・コンパクションを有効にします。
log_all	`false`	`true`に設定すると、クラスター全体に対して高度なロギングがアクティブ化されます。
max_sstable_age_days（廃止予定）	`1000`	DataStax Enterpriseでは、最新のデータがこのプロパティよりも古い場合、SSTableのコンパクションが行われません。小数の日数を設定できます。
max_window_size_seconds	`86400`	時間枠の最大サイズ（秒単位）。
max_threshold	`32`	マイナー・コンパクションで許可するSSTableの最大数。
min_threshold	`4`	マイナー・コンパクションをトリガーするSSTableの最小数。
timestamp_resolution	`MICROSECONDS`	挿入されたデータのタイムスタンプを照合する単位。`MICROSECONDS`または`MILLISECONDS`。
tombstone_compaction_interval	`86400`	SSTableの作成後、SSTableがトゥームストーン・コンパクションの対象と見なされるまでの最小秒数。テーブルがtombstone_thresholdの比率を超えると、SSTableがトゥームストーン・コンパクションの対象になります。
tombstone_threshold	`0.2`	ガーベージ・コレクションの対象にできるトゥームストーンと、含まれているすべてのカラムの比率。比率がこの制限を超えると、トゥームストーンをパージするためにそのテーブルでのみコンパクションが開始されます。
unchecked_tombstone_compaction	`false`	`true`に設定すると、この操作の対象であるテーブルを事前にチェックせずにトゥームストーン・コンパクションを実行できます。この事前チェックがなくても、DataStax Enterpriseでは、トゥームストーンを安全に削除できることを確認するためにSSTableをチェックします。

TimeWindowCompactionStrategy（TWCS）

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

表 4. サブプロパティ
コンパクション・サブプロパティ	デフォルト	説明
compaction_window_unit	`milliseconds`	バケット・サイズ、ミリ秒、秒、時間などを定義するために使用される時間単位。
compaction_window_size		バケットあたりの単位。
log_all	`false`	`True`に設定すると、クラスター全体に対して高度なロギングがアクティブ化されます。

LeveledCompactionStrategy（LCS）

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

表 5. サブプロパティ
サブプロパティ	デフォルト	説明
enabled	`true`	バックグラウンド・コンパクションを有効にします。
log_all	`false`	`true`に設定すると、クラスター全体に対して高度なロギングがアクティブ化されます。
sstable_size_in_mb	`160 MB`	レベル化コンパクション・ストラテジを使用するSSTableのターゲット・サイズ。SSTableのサイズは、sstable_size_in_mb以下である必要がありますが、コンパクションを行うとこの値を超える場合があります。これは、指定されたパーティション・キーのデータが非常に大きい場合に発生します。DSEデータベースは、データを2つのSSTableに分割しません。
tombstone_compaction_interval	`864000`（1日）	SSTableの作成後、SSTableトゥームストーン・コンパクションが行われるまでの最小秒数。トゥームストーン・コンパクションは、SSTableのtombstone_thresholdが設定値を超えると開始されます。
tombstone_threshold	`0.2`	ガーベージ・コレクションの対象にできるトゥームストーンと、含まれているすべてのカラムの比率。比率がこの制限を超えると、トゥームストーンをパージするためにそのテーブルでのみコンパクションが開始されます。
unchecked_tombstone_compaction	`false`	`true`に設定すると、この操作の対象であるテーブルを事前にチェックせずにトゥームストーン・コンパクションを実行できます。この事前チェックがなくても、DataStax Enterpriseでは、トゥームストーンを安全に削除できることを確認するためにSSTableをチェックします。

Tableキーワード

CLUSTERING ORDER BY ( column_name ASC | DESC)

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

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

DESC：降順、逆の順序

COMPACT STORAGE

従来の（Thrift）ストレージ・エンジン形式でデータを格納し、ディスク領域を節約するには、COMPACT STORAGEを使用します。

重要: DataStax Enterprise 5.0以降では、ストレージ・エンジンはデータの格納効率が非常に高いため、コンパクト・ストレージは不要です。

ID

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

例

frozenユーザー定義型を持つテーブルを作成します。

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

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

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

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

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

サイクリスト・カテゴリー・テーブルを作成して、データを逆順に格納します。

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) );

キャッシングの設定

データベースによってキャッシュされるのは、パーティション内の最初のN行だけで、これはクラスター化の順序によって決まります。

たとえば、各ageパーティション内のすべてのサイクリストをキャッシュするには、次のように指定します。

ALTER MATERIALIZED VIEW cycling.cyclist_by_age 
WITH caching = { 
 'keys' : 'ALL', 
 'rows_per_partition' : 'ALL' } ;

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

サイクリスト名テーブル用の変更ログを作成します。

CREATE TABLE cycling.cyclist_name 
WITH cdc = TRUE;

コメントの追加

たとえば、マテリアライズド・ビューのベース・テーブルについて次のようにコメントを追加できます。

ALTER MATERIALIZED VIEW cycling.cyclist_by_age 
WITH comment = "Basetable: cyclist_mv";

推測的リトライの変更

10ミリ秒を使用するようユーザー・テーブルを変更します。

ALTER TABLE users WITH speculative_retry = '10ms';

99パーセントを使用するようユーザー・テーブルを変更します。

ALTER TABLE users WITH speculative_retry = '99percentile';

バックグラウンド・コンパクションの有効化と無効化

enableプロパティを使用してバックグラウンド・コンパクションを無効にするには、次のように指定します。

ALTER TABLE mytable 
WITH COMPACTION = {
   'class': 'SizeTieredCompactionStrategy', 
   'enabled': 'false' }

バックグラウンド・コンパクションを無効にすると、ディスク領域が回復せず、ゾンビが伝搬する可能性があるため、悪影響が及ぶことがあります。コンパクションはI/Oを消費しますが、ほとんどの場合、コンパクションを有効にしておくことを推奨します。

拡張コンパクション・ログの取得

特定のノードでのコンパクション・アクティビティーに関する詳細な情報を専用のログ・ファイルで収集するには、log_allサブプロパティをtrueに設定します。

重要: 拡張ロギングは、どのノードのどのテーブルに対して有効にした場合も、クラスター内の全ノードの全テーブルで有効になります。

拡張コンパクションを有効にすると、データベースによってcompaction-%d.log（%dは連続番号）という名前のファイルがhome/logsに作成されます。

コンパクション・ロギング・サービスでは、次の4種類のコンパクション・イベントに関する詳細な情報がログに記録されます。

type:enable

以前にフラッシュされたSSTableをリストします。

{"type":"enable","keyspace":"test","table":"t","time":1470071098866,"strategies":
  [    {"strategyId":"0","type":"LeveledCompactionStrategy","tables":[],"repaired":true,"folders":
      ["/home/carl/oss/cassandra/bin/../data/data"]},
    {"strategyId":"1","type":"LeveledCompactionStrategy","tables":[],"repaired":false,"folders":
      ["/home/carl/oss/cassandra/bin/../data/data"]
    }
 ]
}

type: flush

各テーブルのCompactionStrategyも含め、memtableのフラッシュ・イベントをディスク上のSSTableのログに記録します。

{"type":"flush","keyspace":"test","table":"t","time":1470083335639,"tables":
  [    {"strategyId":"1","table":
      {"generation":1,"version":"mb","size":106846362,"details":
        {"level":0,"min_token":"-9221834874718566760","max_token":"9221396997139245178"}
      }
    }
 ]
}

type: compaction

コンパクション・イベントをログに記録します。

{"type":"compaction","keyspace":"test","table":"t","time":1470083660267,"start":"1470083660188","end":"1470083660267","input":
  [    {"strategyId":"1","table":
      {"generation":1372,"version":"mb","size":1064979,"details":
        {"level":1,"min_token":"7199305267944662291","max_token":"7323434447996777057"}
      }
    }
 ],"output":
  [    {"strategyId":"1","table":
      {"generation":1404,"version":"mb","size":1064306,"details":
        {"level":2,"min_token":"7199305267944662291","max_token":"7323434447996777057"}
      }
    }
 ]
}

type: pending
コンパクション・ストラテジの保留中タスクの数をリストします。
```
{"type":"pending","keyspace":"test","table":"t","time":1470083447967,"strategyId":"1","pending":200}
```

降順でのデータの格納

次の例に示すテーブル定義では、ポイントの高い順にカテゴリーが格納されます。

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.cyclist_category ( 
   category text, 
   points int, 
   id UUID, 
   lastname text, 
   PRIMARY KEY (category, points)) 
WITH CLUSTERING ORDER BY (points DESC)
   AND COMPACT STORAGE;

コミット・ログ・リプレイヤーからの復元

ユーザー・テーブルをコミット・ログから復元します。

CREATE TABLE users (
  userid text PRIMARY KEY,
  emails set<text>
) WITH ID='5a1c395e-b41f-11e5-9f22-ba0be0483c18';

読み取りリペアの構成

読み取りによってレプリカ間の不整合が検出されるたびに、データベースで読み取りリペアが実行されます。完全に整合した読み取りの後で読み取りリペアを実行するようデータベースを構成することもできます。DataStax Enterpriseでは、成功した読み取りでアクセスしなかったレプリカを含め、すべてのレプリカの比較およびコーディネートが行われます。dclocal_read_repair_chanceとread_repair_chanceは、読み取りリペアがテーブルの読み取りの整合性によってトリガーされる確率を設定します。最初のプロパティは、コーディネーター・ノードと同じデータ・センターに限定された読み取りリペアの確率を設定します。2番目のプロパティは、条件に一致するレプリカを含んでいるすべてのデータ・センターを対象とした読み取りリペアの確率を設定します。複数のデータ・センターにまたがるこの操作は、リソース使用量がローカル操作よりはるかに多くなります。

推奨事項：時系列データに関するテーブルの場合は、両方のプロパティを0（ゼロ）に設定できます。それ以外のテーブルの場合は、dc_local_read_repair_chanceを0.1に設定し、read_repair_chanceを0に設定すると、ストラテジのパフォーマンスを高めることができます。read_repair_chanceを使用する場合は、このプロパティを0.1に設定してください。