テーブルの作成

CQLテーブルの作成方法。

CQLでは、データはSQL定義と同様にカラムの行を含むテーブルに格納されます。
注: Cassandraの内部実装における行とカラムの概念は、同じではありません。詳細については、「A thrift to CQL3 upgrade guide」または「CQL3 for Cassandra experts」を参照してください。
テーブルは実行時に作成、削除、変更を行うことができます。更新やクエリーを妨げることはありません。テーブルを作成する際、テーブルのプロパティとともにプライマリ・キーとカラムを定義します。キャッシュ、コンパクション、その他の操作など、テーブルのプロパティを構成するには、オプションのWITH句とキーワード引数を使用します。テーブルのプロパティは、「table settings(テーブルの設定)」に示したようにテーブルごとに指定されます。

cqlshを使用したスキーマの作成

cqlshを使用してテーブル・スキーマを作成します。動的スキーマ生成はサポートされていません。複数のクライアントがテーブルを同時に生成しようとすると、衝突が発生する可能性があります。間違って衝突を発生させてしまった場合、問題を修正するには、「schema collision fix」の手順を参照してください。

プライマリ・キー

プライマリ・キーは、データ・ストレージの場所と順序を特定します。プライマリ・キーはテーブルの作成時に定義され、変更することはできません。プライマリ・キーを変更する必要がある場合は、新しいテーブル・スキーマを作成し、新しいテーブルにデータを書き込みます。Cassandraは、パーティション行ストアであり、プライマリ・キーのコンポーネントであるパーティション・キーは特定のテーブル行を格納するノードを特定します。作成後のテーブルの変更の詳細については、「ALTER TABLE」を参照してください。

プライマリ・キーは、最低でも1つのパーティション・キーで構成される必要があります。複合パーティション・キーは、関連データがそれぞれ別々のパーティションに保存されるように、データ・セットを分割できます。複合プライマリ・キーには、パーティション上のデータを順序付けるクラスター化カラムが含まれます。

Cassandraではテーブルのプライマリ・キーの定義は非常に重要です。どのカラムでプライマリ・キーを定義するかを選択する前に、テーブル内でのデータの挿入と取得の方法を慎重にモデリングしてください。パーティションのサイズ、パーティション内のデータの順序、クラスターのノード間のパーティションの配分などをすべてを考慮することにより、テーブルに最も効果的なプライマリ?キーの選択が決まります。

テーブルの特性

有効なテーブル名は、英数字とアンダースコアで構成され、英字で始まる文字列です。テーブル名を指定するには、以下のようにします。
  • ドット表記を使用してテーブル名を指定します。ピリオドで区切ったテーブル名から分離したキースペース名を使用してテーブルを作成します。キースペースは現在のキースペースに維持されますが、指定されたキースペースにテーブルが作成されます。
  • 現在のキースペースを使用します。テーブル名のみを使用してテーブルを作成します。

カラムの特性

カラムはCQLテーブルには欠かせないコンポーネントです。テーブル・スキーマを柔軟に設計できるように、複数のカラム型があります。テーブル内の各カラムには、テーブル作成中にデータ型が割り当てられます。コレクション型カラムを除くカラム型は、カラム名と型のペアを、丸かっこで囲んだコンマ区切りリストとして指定します。次の例は、3つのデータ型UUIDtext、およびtimestampを示しています。
CREATE TABLE cycling.cyclist_alt_stats ( id UUID PRIMARY KEY, lastname text, birthday timestamp, nationality text, weight text, height text );
サポートされるコレクション・カラム型は、mapset、およびlistです。コレクション・カラムはコレクション型を使用して宣言します。コレクション型の後ろに、intやtextなどの型を<>で囲みます。その他のカラムと同様に、コレクション・カラムは、カラム名と型のペアを、丸かっこで囲んだコンマ区切りリストとして指定します。次の例は、各コレクション型を示していますが、実際のクエリー用には設計されていません。
CREATE TABLE cycling.whimsey ( id UUID PRIMARY KEY, lastname text, cyclist_teams set<text>, events list<text>, teams map<int,text> );
現在、コレクション型をネストすることはできません。コレクションにはfrozenデータ型を含めることができます。例と使用方法については、「コレクション型」を参照してください。
カラム型タプル・データ型は、位置指定された型付きのフィールドを要素とする固定要素数の集合を保持します。ユーザー定義型の代わりにタプルを使用できます。タプルには多くのフィールド(32768)を含めることができますが、使用できる数より控えめにしてください。通常、タプルは、少数のフィールドを含めて作成します。タプルは、通常2~5個のフィールドに使用します。テーブルにタプルを作成するには、山かっことカンマ・デリミターを使用してタプル・コンポーネント型を宣言します。タプルsはネストできます。次の例は、textフィールド、および2つのfloatフィールドのあるネストされたtupleフィールドで構成されたタプル型を示しています。
CREATE TABLE cycling.route (race_id int, race_name text, point_id int, lat_long tuple<text, tuple<float,float>>, PRIMARY KEY (race_id, point_id));
注: Cassandra 2.1.0~2.1.2ではtuplesに対してfrozenを使用する必要がありますが、Cassandra 2.1.3以降では次のキーワードは必要ありません:
frozen <tuple <int, tuple<text, double>>>
詳細については、「タプル型」を参照してください。

ユーザー定義型(UDT)は、CREATE TYPEを使用して複数のフィールドのデータ型が作成されている場合にカラム型に使用できます。UDTは、複数のテーブル定義に使用される場合に作成されます。カラム型ユーザー定義型(UDT)にはfrozenキーワードが必要です。 frozen値は、複数のコンポーネントを1つの値にシリアライズします。frozen以外の型では、個々のフィールドを更新できます。Cassandraでは、frozen型の値はBLOBとして扱われます。値全体を上書きしなければなりません。 ユーザー定義型は、それを定義したキースペース内で有効です。その範囲外のキースペースから型にアクセスするには、ドット表記を使用します。キースペース名の後にピリオドを付け、その後に型の名前を記述します。Cassandraは、指定されたキースペース内でその型にアクセスしますが、現在のキースペースは変更しません。キースペースを指定しないと、Cassandraは現在のキースペース内のその型にアクセスします。例と使用方法については、「ユーザー定義型の使用」を参照してください。

カウンターは、インクリメントで変化する数値の格納に使用される特別なカラムです。カウンターは、counter data typeカラムを含む専用のテーブルでのみ使用できます。例と使用方法については、「カウンターの使用」を参照してください。