データ定義
CQLはデータをテーブルに格納します。テーブルのスキーマは、テーブル内のデータのレイアウトを定義します。テーブルはキースペースに配置されます。キースペースは、キースペースのすべてのテーブルに適用されるオプションを定義します。 レプリケーション戦略は、レプリケーションファクターと同様に、重要なキースペースオプションです。一般的なルールとして、アプリケーションごとに1つのキースペースを使用することをお勧めします。アクティブなアプリケーションに対してクラスタで1つのキースペースのみを定義することが一般的です。
このセクションでは、キースペースとテーブルの作成、変更、削除に使用されるステートメントについて説明します。
共通の定義
キースペースとテーブルの名前は、次の文法で定義されます。
keyspace_name::= name
table_name::= [keyspace_name '.' ] name
name::= unquoted_name | quoted_name
unquoted_name::= re('[a-zA-Z_0-9]\{1, 48}')
quoted_name::= '"' unquoted_name '"'キースペース名とテーブル名は、英数字のみで構成され、空にすることができず、サイズは48文字に制限されています（この制限は、主にファイル名（キースペース名とテーブル名を含む可能性があります）が特定のファイルシステムの制限を超えないようにするためです）。デフォルトでは、キースペース名とテーブル名は大文字と小文字が区別されません（myTableはmytableと同じです）が、二重引用符を使用することで大文字と小文字の区別を強制できます（"myTable"はmytableとは異なります）。
さらに、テーブルは常にキースペースの一部であり、テーブル名はそれが属するキースペースによって完全修飾して指定できます。完全修飾されていない場合、テーブルは現在のキースペースにあると仮定されます（USEステートメントを参照）。
さらに、列の有効な名前は次のように定義されます。
column_name::= identifierまた、次のセクションで使用するためのステートメントオプションの概念を定義します。
options::= option ( AND option )*
option::= identifier '=' ( identifier
| constant
| map_literal )CREATE KEYSPACE
キースペースは、CREATE KEYSPACEステートメントで作成されます。
create_keyspace_statement::= CREATE KEYSPACE [ IF NOT EXISTS ] keyspace_name
WITH options例:
CREATE KEYSPACE excelsior
WITH replication = {'class': 'SimpleStrategy', 'replication_factor' : 3};
CREATE KEYSPACE excalibur
WITH replication = {'class': 'NetworkTopologyStrategy', 'DC1' : 1, 'DC2' : 3}
AND durable_writes = false;既に存在するキースペースを作成しようとすると、IF NOT EXISTSオプションを使用しない限り、エラーが返されます。このオプションを使用すると、キースペースが既に存在する場合は、ステートメントはノーオプになります。
サポートされているoptionsは次のとおりです。
| 名前 | 種類 | 必須 | デフォルト | 説明 |
|---|---|---|---|---|
|
マップ |
はい |
n/a |
キースペースに使用するレプリケーション戦略とオプション（詳細については以下を参照）。 |
|
単純 |
いいえ |
true |
このキースペースの更新にコミットログを使用するかどうか（このオプションを無効にするのは自己責任で！）。 |
replicationプロパティは必須であり、目的のレプリケーション戦略クラスを定義する'class'サブオプションを含んでいる必要があります。残りのサブオプションは、どのレプリケーション戦略が使用されるかによって異なります。デフォルトでは、Cassandraは次の'class'値をサポートしています。
SimpleStrategy
クラスタ全体にデータを分散するためのレプリケーションファクターを定義する単純な戦略。データセンターのレイアウトを考慮せず、クエリレイテンシが大きく変動する可能性があるため、一般的に本番環境には適していません。本番環境では、NetworkTopologyStrategyを使用してください。SimpleStrategyは、1つの必須引数をサポートしています。
| サブオプション | 型 | バージョン | 説明 |
|---|---|---|---|
|
int |
すべて |
範囲ごとに保存するレプリカの数 |
NetworkTopologyStrategy
データセンターごとにレプリケーションファクターを個別に設定する本番環境対応のレプリケーション戦略。残りのサブオプションはキー値ペアで、キーはデータセンター名に設定され、値は関連付けられたレプリケーションファクターに設定されます。オプション
| サブオプション | 型 | 説明 | '<datacenter>' |
|---|---|---|---|
int |
指定されたデータセンターの範囲ごとに保存するレプリカの数。 |
|
int |
後でキースペースを変更し、replication_factorを変更する場合、自動拡張は安全のために新しいデータセンターを追加するのみであり、既存のデータセンターを変更したり、クラスタに存在しなくなった場合でも削除したりすることはありません。replication_factorを設定しながらデータセンターを削除する場合は、レプリカをゼロにするデータセンターを明示的にゼロに設定します。
2つのデータセンター（DC1とDC2）を持つデータセンターを自動拡張する例:
CREATE KEYSPACE excalibur
WITH replication = {'class': 'NetworkTopologyStrategy', 'replication_factor' : 3};
DESCRIBE KEYSPACE excalibur;次のようになります。
CREATE KEYSPACE excalibur WITH replication = {'class': 'NetworkTopologyStrategy', 'DC1': '3', 'DC2': '3'} AND durable_writes = true;データセンターを自動拡張して上書きする例:
CREATE KEYSPACE excalibur
WITH replication = {'class': 'NetworkTopologyStrategy', 'replication_factor' : 3, 'DC2': 2};
DESCRIBE KEYSPACE excalibur;次のようになります。
CREATE KEYSPACE excalibur WITH replication = {'class': 'NetworkTopologyStrategy', 'DC1': '3', 'DC2': '2'} AND durable_writes = true;replication_factorを使用しながらデータセンターを除外する例:
CREATE KEYSPACE excalibur
WITH replication = {'class': 'NetworkTopologyStrategy', 'replication_factor' : 3, 'DC2': 0};
DESCRIBE KEYSPACE excalibur;次のようになります。
CREATE KEYSPACE excalibur WITH replication = {'class': 'NetworkTopologyStrategy', 'DC1': '3'} AND durable_writes = true;トランジェントレプリケーションが有効になっている場合、'<total_replicas>/<transient_replicas>'形式でレプリケーションファクターを定義することで、SimpleStrategyとNetworkTopologyStrategyの両方に対してトランジェントレプリカを設定できます。
たとえば、このキースペースはDC1に3つのレプリカ（そのうち1つはトランジェント）、DC2に5つのレプリカ（そのうち2つはトランジェント）を持ちます。
CREATE KEYSPACE some_keyspace
WITH replication = {'class': 'NetworkTopologyStrategy', 'DC1' : '3/1'', 'DC2' : '5/2'};USE
USEステートメントは、現在のキースペースを指定されたキースペースに変更します。CQLの多くのオブジェクト（テーブル、ユーザー定義型、関数など）はキースペースにバインドされており、現在のキースペースは、完全修飾名（キースペース名のプレフィックスなし）のないクエリでこれらのオブジェクトが参照される場合に使用されるデフォルトのキースペースです。USEステートメントは、引数として使用するキースペースを指定します。
use_statement::= USE keyspace_nameCQLの使用
USE excelsior;ALTER KEYSPACE
ALTER KEYSPACEステートメントは、キースペースのオプションを変更します。
alter_keyspace_statement::= ALTER KEYSPACE [ IF EXISTS ] keyspace_name
WITH options例:
ALTER KEYSPACE excelsior
WITH replication = {'class': 'SimpleStrategy', 'replication_factor' : 4};キースペースが存在しない場合、ステートメントはエラーを返します。ただし、IF EXISTSを使用すると、操作はノーオプになります。サポートされているオプションは、キースペースの作成の場合と同じです。
DROP KEYSPACE
キースペースの削除は、DROP KEYSPACEステートメントで行います。
drop_keyspace_statement::= DROP KEYSPACE [ IF EXISTS ] keyspace_name例:
DROP KEYSPACE excelsior;キースペースを削除すると、すべてのテーブル、ユーザー定義型、ユーザー定義関数、およびこれらのテーブルに含まれるすべてのデータを含む、そのキースペースが即座に、そして元に戻せない方法で削除されます。
キースペースが存在しない場合、ステートメントはエラーを返します。ただし、IF EXISTSを使用すると、操作はノーオプになります。
CREATE TABLE
新しいテーブルの作成には、CREATE TABLEステートメントを使用します。
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) )*例として、テーブルを作成するいくつかのCQLステートメントを以下に示します。
CREATE TABLE monkey_species (
species text PRIMARY KEY,
common_name text,
population varint,
average_size int
) WITH comment='Important biological records';
CREATE TABLE timeline (
userid uuid,
posted_month int,
posted_time uuid,
body text,
posted_by text,
PRIMARY KEY (userid, posted_month, posted_time)
) WITH compaction = { 'class' : 'LeveledCompactionStrategy' };
CREATE TABLE loads (
machine inet,
cpu int,
mtime timeuuid,
load float,
PRIMARY KEY ((machine, cpu), mtime)
) WITH CLUSTERING ORDER BY (mtime DESC);CQLテーブルには名前があり、一連の行で構成されています。テーブルを作成するということは、各行が持つ列、これらの列のうち主キーを構成する列、およびテーブルの定義済みのオプションを定義することを意味します。
既に存在するテーブルを作成しようとすると、IF NOT EXISTSディレクティブを使用しない限り、エラーが返されます。このディレクティブを使用すると、テーブルが既に存在する場合は、ステートメントはノーオプになります。
列の定義
CQLテーブルの各行には、テーブル作成時に定義された事前定義された列があります。列は後でALTERステートメントを使用して追加できます。
column_definitionは、列の名前とその型で構成され、その列で受け入れられる値を制限します。さらに、列定義には次の修飾子を含めることができます。
静的列
テーブル定義では、一部の列をSTATICとして宣言できます。静的列は、同じパーティション（同じパーティションキーを持つ）に属するすべての行で「共有」されます。
例:
CREATE TABLE t (
pk int,
t int,
v text,
s text static,
PRIMARY KEY (pk, t)
);
INSERT INTO t (pk, t, v, s) VALUES (0, 0, 'val0', 'static0');
INSERT INTO t (pk, t, v, s) VALUES (0, 1, 'val1', 'static1');
SELECT * FROM t; pk | t | v | s
----+---+--------+-----------
0 | 0 | 'val0' | 'static1'
0 | 1 | 'val1' | 'static1'ご覧のとおり、パーティション内の2つの行（パーティションキーはpkであり、両方の行は同じパーティションにあります）では、sの値は（static1）同じです。2回目の挿入によってsの値が上書きされます。
静的列の使用には、次の制限があります。
-
クラスタリング列のないテーブルには、静的列を含めることができません。（クラスタリング列のないテーブルでは、各パーティションには1行しかなく、したがってすべての列は本質的に静的です）。
-
静的列にすることができるのは、主キー以外の列のみです。
主キー
テーブル内では、行はPRIMARY KEYによって一意に識別されるため、すべてのテーブルは必ず単一のPRIMARY KEYを定義する必要があります。PRIMARY KEYは、テーブルで定義された1つ以上の列で構成されます。構文的には、主キーはPRIMARY KEYという句の後に、括弧内に列名をコンマで区切ったリストを付けることで定義されます。主キーが1列のみの場合は、テーブル定義のその列にPRIMARY KEY句を追加することもできます。主キー定義内の列の順序は、パーティションキーとクラスタリング列を定義します。
CQL主キーは2つの部分で構成されます。
主キー定義の例をいくつか示します。
-
PRIMARY KEY (a)：aは単一のパーティションキーであり、クラスタリング列はありません。 -
PRIMARY KEY (a, b, c)：aは単一のパーティションキーであり、bとcはクラスタリング列です。 -
PRIMARY KEY ((a, b), c)：aとbは複合パーティションキーを構成し、cはクラスタリング列です。
|
上記のように、主キーはテーブル内の行を一意に識別します。この一意性の結果として、同じ主キーを使用して別の行を挿入すると、 |
パーティションキー
テーブル内では、CQLはCassandraクラスタ内のデータの場所を定義するパーティションの概念を定義します。パーティションとは、パーティションキーの値が同じである行の集合です。
パーティションキーが複数の列で構成されている場合、すべてのパーティションキー列の値が同じである場合、行は同じパーティションに属することに注意してください。パーティションキー列からハッシュが計算され、そのハッシュ値によってパーティションの場所が定義されます。たとえば、次のテーブル定義と内容があるとします。
CREATE TABLE t (
a int,
b int,
c int,
d int,
PRIMARY KEY ((a, b), c, d)
);
INSERT INTO t (a, b, c, d) VALUES (0,0,0,0);
INSERT INTO t (a, b, c, d) VALUES (0,0,1,1);
INSERT INTO t (a, b, c, d) VALUES (0,1,2,2);
INSERT INTO t (a, b, c, d) VALUES (0,1,3,3);
INSERT INTO t (a, b, c, d) VALUES (1,1,4,4);
SELECT * FROM t;次のようになります。
a | b | c | d
---+---+---+---
0 | 0 | 0 | 0 (1)
0 | 0 | 1 | 1
0 | 1 | 2 | 2 (2)
0 | 1 | 3 | 3
1 | 1 | 4 | 4 (3)
(5 rows)| 1 | 行1と行2は、列aとbの両方がゼロであるため、同じパーティションにあります。 |
| 2 | 行3と行4は、列aがゼロで列bが1であるため、同じパーティション（ただし別のパーティション）にあります。 |
| 3 | 行5は、列aとbの両方が1であるため、単独で3番目のパーティションにあります。 |
テーブルには常にパーティションキーがあり、テーブルにクラスタリング列がない場合、そのテーブルの各パーティションには1行しかありません。なぜなら、パーティションキー（複合キーでもそうでなくても）は単一の場所を識別するためです。
パーティションの最も重要な特性は、同じパーティションに属するすべての行が、同じレプリカノードのセットに格納されることが保証されていることです。つまり、テーブルのパーティションキーは、クラスタ内の同じノードに配置される行を定義します。データのローカリゼーションは、データの効率的な取得にとって重要であり、Cassandraコーディネーターが可能な限り少ないノードに接続する必要があります。ただし、この保証の裏返しがあり、パーティションキーを共有するすべての行は同じノードに格納され、読み書きの両方でホットスポットが作成されます。テーブル行をグループ化する主キーを選択すると、バッチ更新が支援され、更新がアトミックに分離して実行されることが保証されますが、パーティションのサイズは「大きすぎず、小さすぎない」ように適切に調整する必要があります。
クエリパターンを考慮し、クエリに基づいて主キーを割り当てるデータモデリングは、データの取得における待ち時間が最も短くなります。
クラスタリング列
テーブルのクラスタリング列は、そのテーブルのパーティションのクラスタリング順序を定義します。特定のパーティションでは、すべての行はそのクラスタリング順序によって順序付けられます。クラスタリング列は、テーブル内の行にも一意性を追加します。
たとえば、次のような場合。
CREATE TABLE t2 (
a int,
b int,
c int,
d int,
PRIMARY KEY (a, b, c)
);
INSERT INTO t2 (a, b, c, d) VALUES (0,0,0,0);
INSERT INTO t2 (a, b, c, d) VALUES (0,0,1,1);
INSERT INTO t2 (a, b, c, d) VALUES (0,1,2,2);
INSERT INTO t2 (a, b, c, d) VALUES (0,1,3,3);
INSERT INTO t2 (a, b, c, d) VALUES (1,1,4,4);
SELECT * FROM t2;次のようになります。
a | b | c | d
---+---+---+---
1 | 1 | 4 | 4 (1)
0 | 0 | 0 | 0
0 | 0 | 1 | 1
0 | 1 | 2 | 2
0 | 1 | 3 | 3
(5 rows)| 1 | 行1は1つのパーティションにあり、行2～5は別のパーティションにあります。表示順序も異なります。 |
同じパーティション内の4つの行をよく見ると、bクラスタリング列は、これらの行が表示される順序を定義しています。テーブルのパーティションキーは同じノード上の行をグループ化しますが、クラスタリング列は、これらの行がノード上にどのように格納されるかを制御します。
そのソートにより、パーティション内の行の範囲を非常に効率的に取得できます。
SELECT * FROM t2 WHERE a = 0 AND b > 0 and b <= 3;次のようになります。
a | b | c | d
---+---+---+---
0 | 1 | 2 | 2
0 | 1 | 3 | 3
(2 rows)テーブルオプション
CQLテーブルには、作成時に設定できる（そして、ほとんどの場合、後で変更できる）多くのオプションがあります。これらのオプションは、WITHキーワードの後に指定されます。
作成後に変更できない重要なオプションの1つであるCLUSTERING ORDER BYは、テーブルに対してクエリを実行する方法に影響を与えます。ここで詳しく説明する価値があります。
クラスタリング順序
テーブルのクラスタリング順序は、クラスタリング列によって定義されます。デフォルトでは、クラスタリング列のデータ型は昇順になります。たとえば、整数は1、2、…nの順序になり、テキストはAからZの順序になります。
CLUSTERING ORDER BYテーブルオプションは、コンマで区切られたクラスタリング列のリストを使用し、各列はASC（昇順）またはDESC（降順）のいずれかに設定されます。CLUSTERING ORDER BYオプションが設定されていない場合、デフォルトはすべてのクラスタリング列の昇順になります。
このオプションは基本的に、行を格納する順序を変更するストレージエンジンのヒントです。このオプションの設定結果に注意してください。
-
ORDER BY句がないSELECT文でクエリを実行した場合、デフォルトの昇順の結果が変わります。 -
そのテーブルの
SELECT文でORDER BY句を使用する方法が制限されます。結果は、元のクラスタリング順序または逆のクラスタリング順序のいずれかでしか順序付けることができません。2つのクラスタリング列aとbで、WITH CLUSTERING ORDER BY (a DESC, b ASC)と定義されたテーブルを作成するとします。テーブルのクエリでは、ORDER BY (a DESC, b ASC)またはORDER BY (a ASC, b DESC)を使用できます。ORDER BY (a ASC, b ASC)またはORDER BY (a DESC, b DESC)などの混合順序では、予期される順序が返されません。 -
クエリのパフォーマンスに影響を与えます。逆のクラスタリング順序でのクエリは、デフォルトの昇順よりも遅くなります。主に降順でクエリを実行する予定がある場合は、
WITH CLUSTERING ORDER BY ()を使用してテーブルスキーマにクラスタリング順序を宣言します。この最適化は、データを最新のものから古いものの順序で取得するために、時系列でよく使用されます。
その他のテーブルオプション
テーブルは次のオプションをサポートします。
| オプション | 種類 | デフォルト | 説明 |
|---|---|---|---|
|
単純 |
なし |
自由形式の人間が読めるコメント |
単純 |
99PERCENTILE |
スペキュレーティブリトライオプション |
|
|
ブール値 |
false |
テーブルに変更データキャプチャ（CDC）ログを作成します。 |
|
単純 |
99PERCENTILE |
|
|
単純 |
864000 |
墓石（削除マーカー）をガーベッジコレクトする前に待機する時間 |
|
単純 |
0.00075 |
SSTableブルームフィルターの偽陽性のターゲット確率。このブルームフィルターは、指定された確率を提供するようにサイズ変更されるため、この値を下げると、メモリ内およびディスク上のブルームフィルターのサイズに影響します。 |
|
単純 |
0 |
テーブルのデフォルトの有効期限（「TTL」）を秒単位で指定します。 |
|
マップ |
下記参照 |
|
|
マップ |
下記参照 |
|
|
マップ |
下記参照 |
キャッシングオプション |
|
単純 |
0 |
Cassandraがメモリテーブルをディスクにフラッシュするまでの時間（ミリ秒） |
|
単純 |
BLOCKING |
読み取り修復動作を設定します（下記参照）。 |
スペキュレーティブリトライオプション
デフォルトでは、Cassandraの読み取りコーディネーターは、整合性レベルを満たすために必要な数のレプリカのみを照会します。整合性レベルONEの場合は1つ、QUORUMの場合はクォーラムなどです。speculative_retryは、レプリカが遅延している場合や応答していない場合に、コーディネーターが追加のレプリカを照会するタイミングを決定します。スペキュレーティブリトライは遅延を削減します。speculative_retryオプションは、コーディネーターが必要以上に多くの要求を送信する高速読み取り保護を設定します。
|
追加のレプリカから頻繁に読み取ると、クラスタのパフォーマンスが低下する可能性があります。不明な場合は、デフォルトの |
Cassandra 4.0より前のスペキュレーティブリトライポリシーは、パラメーターとして単一の文字列を取ります。
-
NONE -
ALWAYS -
99PERCENTILE（PERCENTILE） -
50MS（CUSTOM）
スペキュレーティブリトライの設定例では、カスタム値を設定します。
ALTER TABLE users WITH speculative_retry = '10ms';この例では、設定にパーセンタイルを使用しています。
ALTER TABLE users WITH speculative_retry = '99PERCENTILE';パーセンタイル設定は裏目に出る可能性があります。単一のホストが利用できなくなると、パーセンタイルが上昇する可能性があります。指定されたパーセンタイルの値が大幅に増加するため、p99の値は意図したとおりに推測されません。整合性レベルがALLに設定されている場合、スペキュレーティブリトライ設定に関係なく、すべてのレプリカが照会されます。
Cassandra 4.0では、スペキュレーティブリトライ値の大文字と小文字が区別されなくなりました（CASSANDRA-14293）。たとえば、値をnone、None、またはNONEとして割り当てると、同じ効果があります。
さらに、次の値が追加されます。
| 形式 | 例 | 説明 |
|---|---|---|
|
90.5PERCENTILE |
コーディネーターは、すべてのレプリカのテーブルごとの平均応答時間を記録します。レプリカが、このテーブルの平均応答時間の |
|
90.5P |
|
|
25ms |
レプリカの応答に |
|
MIN(99PERCENTILE,35MS) |
計算時に低い値を使用する、指定されたパーセンタイルまたは固定ミリ秒のいずれかを使用するハイブリッドポリシーです。パラメーターは |
|
MAX(90.5P,25ms) |
計算時に高い値を使用する、指定されたパーセンタイルまたは固定ミリ秒のいずれかを使用するハイブリッドポリシーです。 |
Cassandra 4.0では、MIN()とMAX()のspeculative retryポリシーを混在させたハイブリッドモードがサポートされました。MIN(), MAX()、MIN(), MIN()、MAX(), MAX()の組み合わせが可能です(CASSANDRA-14293)。 ハイブリッドモードでは、テーブルの通常のp99が最小値である50ms未満の場合も、依然としてspeculative retryを実行します。しかし、p99レベルが最大値を超えた場合は、その値が使用されます。ハイブリッド値では、一方の値は固定時間（ms）値で、もう一方はパーセンタイル値である必要があります。
様々なバリエーションを示すために、以下の例はすべて有効です。
min(99percentile,50ms)
max(99p,50MS)
MAX(99P,50ms)
MIN(99.9PERCENTILE,50ms)
max(90percentile,100MS)
MAX(100.0PERCENTILE,60ms)additional_write_policy設定は、安価なクォーラム書き込みを一時レプリカを含む書き込みにアップグレードするしきい値を指定します。
圧縮オプション
compactionオプションは、最低限、使用する圧縮戦略クラスを指定する'class'サブオプションを定義する必要があります。サポートされているクラスは以下のとおりです。
カスタム戦略が必要な場合は、完全なクラス名を文字列定数として指定します。
圧縮オプション
compressionオプションは、テーブルのSSTableを圧縮するかどうか、およびその方法を定義します。圧縮は、CREATE TABLEまたはALTER TABLEへのオプション引数として、テーブルごとに構成されます。以下のサブオプションを使用できます。
| オプション | デフォルト | 説明 |
|---|---|---|
|
LZ4Compressor |
使用する圧縮アルゴリズムです。デフォルトの圧縮アルゴリズムは、LZ4Compressor、SnappyCompressor、DeflateCompressor、ZstdCompressorです。圧縮を無効にするには、 |
|
true |
SSTable圧縮の有効/無効を切り替えます。 |
|
64 |
ディスク上のSSTableはブロック単位で圧縮されます（ランダム読み込みを許可するため）。このオプションは、そのブロックのサイズ（KB単位）を定義します。詳細については注記を参照してください。 |
|
3 |
圧縮レベル。 |
|
値が大きいほど圧縮率は向上しますが、読み取り時にディスクから読み取る必要のあるデータの最小サイズが増加します。デフォルト値は、テーブルを圧縮するための最適な値です。圧縮されていないファイルオフセットからチャンク番号を計算する場合、チャンクの長さは2の累乗である必要があります。ブロックサイズは、以下のような読み取り/書き込みアクセスパターンに基づいて調整できます。
|
たとえば、LZ4Compressorと4KBのchunk_length_in_kbを使用してテーブルを作成するには、以下のようにします。
CREATE TABLE simple (
id int,
key text,
value text,
PRIMARY KEY (key, value)
) WITH compression = {'class': 'LZ4Compressor', 'chunk_length_in_kb': 4};キャッシュオプション
キャッシングは、テーブルのキャッシュメモリの使用を最適化します。キャッシュされたデータは、サイズとアクセス頻度によって重み付けされます。cachingオプションを使用すると、テーブルのキーキャッシュと行キャッシュの両方を構成できます。以下のサブオプションを使用できます。
| オプション | デフォルト | 説明 |
|---|---|---|
|
ALL |
このテーブルのキー（キーキャッシュ）をキャッシュするかどうかを指定します。有効な値は |
|
NONE |
パーティションごとにキャッシュする行数（行キャッシュ）です。整数 |
たとえば、キーキャッシュとパーティションごとに10行をキャッシュするテーブルを作成するには、以下のようにします。
CREATE TABLE simple (
id int,
key text,
value text,
PRIMARY KEY (key, value)
) WITH caching = {'keys': 'ALL', 'rows_per_partition': 10};読み込み修復オプション
read_repairオプションは、読み込み修復の動作を構成し、様々なパフォーマンスと整合性の動作に合わせて調整します。
値は以下のとおりです。
| オプション | デフォルト | 説明 |
|---|---|---|
|
はい |
読み込み修復がトリガーされると、書き込みが整合性レベルに達するまで、他のレプリカに送信される書き込みがブロックされます。 |
|
いいえ |
設定されている場合、コーディネーターはレプリカ間の違いを調整しますが、修復しようとしません。 |
2つの整合性プロパティは、読み込み修復の動作によって影響を受けます。
-
単調クォーラム読み込み：単調クォーラム読み込みは、状況によっては読み込みが過去にさかのぼって見えることを防ぎます。単調クォーラム読み込みが提供されておらず、書き込みがレプリカのクォーラムに到達しない場合、読み込み値は1つの読み込みでは表示され、その後の読み込みでは消える可能性があります。
BLOCKINGはこの動作を提供します。 -
書き込みアトミック性：書き込みアトミック性は、部分的に適用された書き込みが読み込みで返されることを防ぎます。Cassandraはパーティションレベルの書き込みアトミック性を提供しようとしますが、SELECT文でカバーされているデータのみが読み込み修復によって修復されるため、読み込み修復は、データが書き込まれたよりも粒度の細かいレベルでデータが読み取られると、書き込みアトミック性を破る可能性があります。たとえば、バッチで複数の行をクラスタ化されたパーティションに書き込み、その後SELECT文でクラスタリングカラムを指定して単一行を選択した場合、読み込み修復は書き込みアトミック性を破る可能性があります。
NONEはこの動作を提供します。
ALTER TABLE
既存のテーブルを変更するには、ALTER TABLEステートメントを使用します。
alter_table_statement::= ALTER TABLE [ IF EXISTS ] table_name alter_table_instruction
alter_table_instruction::= ADD [ IF NOT EXISTS ] column_definition ( ',' column_definition)*
| DROP [ IF EXISTS ] column_name ( ',' column_name )*
| RENAME [ IF EXISTS ] column_name to column_name (AND column_name to column_name)*
| ALTER [ IF EXISTS ] column_name ( column_mask | DROP MASKED )
| WITH options
column_definition::= column_name cql_type [ column_mask]
column_mask::= MASKED WITH ( DEFAULT | function_name '(' term ( ',' term )* ')' )テーブルが存在しない場合、IF EXISTSを使用しない限り、ステートメントはエラーを返します。その場合は、操作はno-opとなります。
例:
ALTER TABLE addamsFamily ADD gravesite varchar;
ALTER TABLE addamsFamily
WITH comment = 'A most excellent and useful table';ALTER TABLEステートメントは、以下の操作を実行できます。
-
テーブルに新しい列を追加します。テーブルの主キーを変更することはできません。したがって、新しい列は主キーの一部にすることはできません。列の追加は、テーブル内のデータ量に基づいて定数時間操作です。新しい列が既に存在する場合、
IF NOT EXISTSを使用しない限り、ステートメントはエラーを返します。その場合は、操作はno-opとなります。 -
テーブルから列を削除します。このコマンドは、列とそのすべてのコンテンツを削除します。列はすぐに使用できなくなりますが、コンテンツは圧縮時に遅延削除されることに注意してください。この遅延削除のため、コマンドはテーブル内のデータ量に基づいて定数時間操作です。また、削除された列がコレクションなどの非フリーズ列でない限り、削除された列と同じ名前の列を再追加できることに注意することが重要です。削除する列が存在しない場合、
IF EXISTSを使用しない限り、ステートメントはエラーを返します。その場合は、操作はno-opとなります。
|
警告
列を削除する際には、この列の値に使用されるタイムスタンプがマイクロ秒単位の「リアル」タイムスタンプであることを前提としています。マイクロ秒単位の「リアル」タイムスタンプの使用はデフォルトであり、強く推奨されますが、Cassandraはクライアントが任意のテーブルに任意のタイムスタンプを提供することを許可しているため、理論的には別の規約を使用することも可能です。そうした場合、列の削除が正しく実行されない可能性があることに注意してください。 |
-
テーブルの主キー列の名前を変更します。主キー以外の列の名前を変更することはできません。また、既に存在する別の名前に列の名前を変更することもできません。名前変更された列には、依存するセカンダリインデックスがないようにする必要があります。名前変更する列が存在しない場合、
IF EXISTSを使用しない限り、ステートメントはエラーを返します。その場合は、操作はno-opとなります。 -
テーブルオプションを変更するには、
WITHを使用します。サポートされているオプションは、テーブル作成時に使用されるオプションと同じですが、CLUSTERING ORDERを除きます。ただし、compactionサブオプションを設定すると、以前のcompactionオプションがすべて消去されるため、保持するすべてのサブオプションを再指定する必要があります。compressionサブオプションについても同様です。
