テーブルの作成

CQLテーブルの作成方法。

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

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

cqlshを使用してテーブル・スキーマを作成します。DataStax Enterpriseは、動的スキーマの生成をサポートしていません。複数のクライアントがテーブルを同時に生成しようとした場合は、衝突が発生する場合があります。衝突から復旧するには、「スキーマ衝突の修正」の手順に従ってください。

プライマリ・キー

プライマリ・キーは、格納されているデータの場所と順序を特定します。プライマリ・キーはテーブルの作成時に定義され、変更することはできません。プライマリ・キーを変更する必要がある場合は、新しいテーブル・スキーマを作成し、既存のデータを新しいテーブルに書き込みます。作成後のテーブルの変更の詳細については、「ALTER TABLE」を参照してください。

DataStax Enterpriseのデータベースはパーティション行ストアです。プライマリ・キーの最初の要素であるパーティション・キーは、特定のテーブル行を保持するノードを指定します。プライマリ・キーは、最低でも1つのパーティション・キーで構成される必要があります。複合パーティション・キーを定義してデータ・セットを分割し、関連データをそれぞれ別々のパーティションに格納することができます。複合プライマリ・キーには、パーティション上のデータを順序付けるクラスター化カラムが含まれます。
注: DataStax Enterprise 5.0以前では、クラスター化カラムの最大サイズは64 KBです。

テーブルのプライマリ・キーの定義は非常に重要です。プライマリ・キーで定義するカラムを選択する前に、テーブル内のデータの挿入と取得の方法を慎重にモデル化してください。パーティションのサイズ、パーティション内のデータの順序、クラスターのノード間でのパーティションの分散など、テーブルのプライマリ・キーを選択するときは、これらすべてを考慮する必要があります。

テーブルの特性

テーブル名には英数字とアンダースコアの文字列を使用できますが、英字で始まる必要があります。テーブル名に関するヒントを次に示します。
  • テーブルを含むキースペースを指定するには、keyspace_name.table_nameのようにキースペース名の後にピリオド、次にテーブル名を入力します。これで、現在のセッション(たとえばUSEコマンドのセッション)のキースペースとは異なるキースペースに新しいテーブルを作成できます。
  • 現在のキースペースにテーブルを作成する場合は、単に新しいテーブル名を使用します。

カラムの特性

CQLでは、複数のカラム型をサポートしています。テーブルを作成するときに、データ型を各カラムに割り当てます。テーブル定義は、名前と型のペアのコンマ区切りリストで(非コレクション)カラムを定義します。次の例は、3つのデータ型UUIDtextおよびtimestampを示しています。
CREATE TABLE cycling.cyclist_alt_stats ( id UUID PRIMARY KEY, lastname text, birthday timestamp, nationality text, weight text, height text );
CQLでは、コレクション・カラム型として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データ型を含めることができます。例と使用法については、次を参照してください。 コレクション型のフリーズ
タプル・カラム型は、型付きの位置指定フィールドを要素とする固定要素数の集合を保持します。ユーザー定義型の代わりにタプルを使用できます。タプルには多くのフィールド(32,768個)を収容できますが、あまり多くのフィールドを収容しないようにしてください。通常、タプルには2~5個のフィールドを含めます。タプルはテーブル定義内で山かっこを使用して指定します。山かっこ中では、コンマ区切りリストを使用して各コンポーネントの型を定義します。タプルはネストできます。次の例は、1つのtextフィールドと、2つのfloatフィールドのあるネストされたタプルで構成されたタプル型を示しています。
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));
タプル型」を参照してください。

CREATE TYPEを使用して、ユーザー定義型(UDT)を複数のフィールドのデータ型として作成します。複数のテーブル定義に使用できるUDTを作成するようにしてください。ユーザー定義カラム型(UDT)にはfrozenキーワードが必要です。 ユーザー定義の型は、それを定義したキースペース内で有効です。その範囲外のキースペースから型にアクセスするには、ドット表記を使用します。キースペース名の後にピリオドを付け、その後に型の名前を記述します。たとえば、test.myType testはキースペースの名前で、myTypeは型名です。データベースは、指定されたキースペース内の型にアクセスしますが、現在のキースペースは変更しません。キースペースを指定しない場合、データベースは現在のキースペース内の型にアクセスします。 例と使用法については、「ユーザー定義型の使用」を参照してください。

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