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]
構文規則 | 説明 |
---|---|
大文字 | リテラル・キーワード。 |
小文字 | リテラル以外。 |
イタリック体 |
変数値。ユーザー定義値と置き換えます。 |
[] |
任意。角かっこ( [] )で任意指定のコマンド引数を囲みます。角かっこは入力しないでください。 |
( ) |
グループ。丸かっこ(( ) )は、選択肢を含むグループを示します。丸かっこは入力しないでください。 |
| |
または。縦棒( | )で代替要素を区切ります。要素のいずれかを入力してください。縦棒は入力しないでください。 |
... |
繰り返し可能。省略記号(... )は、構文要素を必要な回数だけ繰り返すことができることを示します。 |
'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
カラム名を設定し、データ型を定義し、必要に応じてカラムを静的またはプライマリ・キーに設定します。
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)
行を一意に特定し、ストレージ・パーティションとパーティション内のデータの順序(クラスター化)を特定します。
- 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形式のキー/値ペアのコンマ区切りリストを中かっこで囲みます。
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:コーディネーター・ノードはそのテーブルの読み取りが行われた後、追加の読み取り要求を送信しません。
パッケージ・インストール |
/etc/dse/cassandra/cassandra.yaml |
tarボール・インストール |
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',...] }
- 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をチェックします。 - 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を使用して作成される場合は、フィールド値を個別に更新および削除できます。
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行だけで、これはクラスター化の順序によって決まります。
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";
推測的リトライの変更
ALTER TABLE users WITH speculative_retry = '10ms';
ALTER TABLE users WITH speculative_retry = '99percentile';
バックグラウンド・コンパクションの有効化と無効化
ALTER TABLE mytable WITH COMPACTION = { 'class': 'SizeTieredCompactionStrategy', 'enabled': 'false' }
バックグラウンド・コンパクションを無効にすると、ディスク領域が回復せず、ゾンビが伝搬する可能性があるため、悪影響が及ぶことがあります。コンパクションはI/Oを消費しますが、ほとんどの場合、コンパクションを有効にしておくことを推奨します。
拡張コンパクション・ログの取得
特定のノードでのコンパクション・アクティビティーに関する詳細な情報を専用のログ・ファイルで収集するには、log_all
サブプロパティをtrue
に設定します。
拡張コンパクションを有効にすると、データベースによってcompaction-%d.log(%d
は連続番号)という名前のファイルがhome/logsに作成されます。
-
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
に設定してください。