ShaShaKa Dev Note

CREATE TABLE

20 August 2017

새 테이블을 만들 때는 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 ] [ PRIMARY KEY]
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) )*

예를 들어 :

CREATE TABLE monkeySpecies (
    species text PRIMARY KEY,
    common_name text,
    population varint,
    average_size int
) WITH comment='Important biological records'
   AND read_repair_chance = 1.0;

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 EXISTS가 사용되지 않는 한 명령문은 오류를 반환합니다.
IF EXISTS가 사용되는 경우에는 아무 작업도하지 않습니다.

Column definitions

CQL 테이블의 모든 행에는 테이블을 만들 때 정의 된 칼럼 집합이 있습니다 (또는 나중에 alter 문을 사용하여 추가된).

column_definition은 주로 정의 된 칼럼의 이름과 이 칼럼에 대해 허용되는 값을 제한하는 type으로 구성됩니다.
또한 칼럼에 대한 정의는 다음 modifier를 가질 수 있습니다 :

- STATIC
컬럼을 정적 컬럼으로 선언합니다.

- PRIMARY KEY
컬럼을 테이블 기본 키의 유일한 구성 요소로 선언합니다.

Static columns

일부 칼럼은 테이블 정의에서 STATIC으로 선언 될 수 있습니다.
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'

위에서 볼 수 있듯이, s 값은 같은 파티션의 두 행에 대해 동일한 값을 가집니다.(이 예에서 파티션 키는 pk이고 두 행은 같은 파티션에 있음).
두 번째 insert는 s 값을 덮어씌우게 됩니다.

STATIC 칼럼에 대해서는 아래와 같은 제한 사항이 존재합니다 :

- COMPACT STORAGE 옵션이있는 테이블은 사용할 수 없습니다.

- 클러스터링 칼럼이없는 테이블은 static 칼럼을 가질 수 없습니다 (클러스터링 칼럼이 없는 테이블에서, 모든 파티션에는 하나의 열만 있으므로 모든 열은 본질적으로 정적입니다).

- PRIMARY KEY가 아닌 열만 static으로 선언이 가능합니다.

The Primary key

테이블 내에서 행은 PRIMARY KEY에 의해 고유하게 식별되므로 모든 테이블은 PRIMARY KEY(오직 하나의)를 정의해야합니다.
PRIMARY KEY는 테이블에 정의 된 하나 이상의 열로 구성됩니다.
구문적으로 PRIMARY KEY는 키워드 "PRIMARY KEY" 다음 괄호 안에 쉼표로 구분 된 괄호로 묶인 열 이름 목록이 정의되지만 PRIMARY KEY에 하나의 열만있는 경우 "PRIMARY KEY" 키워드로 해당 열 정의를 대신 수행 할 수 있습니다.
또한, PRIMARY KEY 정의의 열 순서는 중요합니다.

CQL PRIMARY KEY는 다음 두 부분으로 구성됩니다 :

- partition_key 부분 :
PRIMARY KEY 정의의 첫 번째 구성 요소입니다.
하나의 열이거나 괄호를 사용하여 여러 개의 열로 구성될 수 있습니다.
테이블에는 항상 최소한 하나의 파티션 키가 있습니다. 가능한 가장 작은 테이블 정의는 다음과 같습니다.

CREATE TABLE t (k text PRIMARY KEY);

- clustering_columns 부분 :
PRIMARY KEY 정의의 첫 번째 구성 요소 다음에 오는 열이며, 이 열의 순서는 클러스터링 순서를 정의합니다.

PRIMARY KEY 정의의 몇 가지 예는 다음과 같습니다.

* PRIMARY KEY (a): a는 파티션 키이고 클러스터링 컬럼은 없습니다.
* PRIMARY KEY (a, b, c) : a는 파티션 키이고, b와 c는 클러스터링 컬럼입니다.
* PRIMARY KEY ((a, b), c) : a와 b는 파티션 키를 구성하며 (복합 파티션 키라고도 함) c는 클러스터링 칼럼입니다.

The partition key

테이블 내에서 CQL은 파티션의 개념을 정의합니다.
파티션은 간단히 파티션 키에 대해 동일한 값을 공유하는 행 세트입니다.
만약 파티션 키가 여러 열로 구성된 경우, 모든 파티션 키 칼럼의 값이 동일한 값인 경우에만 행은 동일한 파티션에 속합니다.
예를 들어, 다음 표의 정의와 내용을 보면 :

CREATE TABLE t (
    a int,
    b int,
    c int,
    d int,
    PRIMARY KEY ((a, b), c, d)
);

SELECT * FROM t;
   a | b | c | d
  ---+---+---+---
   0 | 0 | 0 | 0    // row 1
   0 | 0 | 1 | 1    // row 2
   0 | 1 | 2 | 2    // row 3
   0 | 1 | 3 | 3    // row 4
   1 | 1 | 4 | 4    // row 5

행 1과 행 2는 같은 파티션에 있고, 행 3과 행 4도 같은 파티션 (그러나 다른 파티션)에 있으며 행 5는 또 다른 파티션에 있습니다.

테이블에는 항상 파티션 키가 있으며 테이블에 클러스터링 컬럼이없는 경우 해당 테이블의 모든 파티션은 단일 열으로 만 구성됩니다.
(PRIMARY KEY는 행을 고유하게 식별하고 클러스터링 칼럼이 없으면 PRIMARY KEY가 파티션 키와 같기 때문입니다.)

파티션의 가장 중요한 특성은 동일한 파티션에 속한 모든 행이 동일한 replica노드의 세트에 저장된다는 것입니다.
즉, 테이블의 파티션 키는 클러스터에서 어떤 행이 함께 배치되는지 정의하므로 함께 가져와야하는 행이 동일한 파티션에 있도록 파티션 키를 현명하게 선택하는 것이 중요합니다.
(해당 행을 쿼리하면 최소 갯수의 노드에 연결할 수 있도록).

명심해야 할 점은 이것을 개런티하는 데에는 filp-side가 있다는 것입니다 :
파티션 키를 공유하는 모든 행이 동일한 복제본 세트에 저장되도록 보장되므로 너무 많은 데이터를 그룹화하는 파티션 키의 경우 핫스팟을 만들 수 있습니다.

파티션의 또 다른 유용한 특성은 데이터를 쓸 때 단일 파티션에 속한 모든 업데이트가 개별적으로 분리되어 수행된다는 것입니다. 이는 파티션 전체에 해당하지 않습니다.

테이블에 대한 파티션 키와 클러스터링 컬럼의 올바른 선택은 아마도 Cassandra의 데이터 모델링에서 가장 중요한 부분 중 하나이며, 수행 할 수 있는 쿼리의 효율성에 크게 영향을 미칩니다.

The clustering columns

테이블의 클러스터링 컬럼은 해당 테이블의 파티션에 대한 클러스터링 순서를 정의합니다.
주어진 파티션의 경우 클러스터링 순서에 따라 모든 행이 카산드라 내부에서 물리적으로 정렬됩니다.
예를 들어 :

CREATE TABLE t (
    a int,
    b int,
    c int,
    PRIMARY KEY (a, b, c)
);

SELECT * FROM t;
   a | b | c
  ---+---+---
   0 | 0 | 4     // row 1
   0 | 1 | 9     // row 2
   0 | 2 | 2     // row 3
   0 | 3 | 3     // row 4

(모든 파티션이 동일한 파티션에 속하는) 행은 모두 b 열의 값의 순서 (위에서 표시된 순서)에 따라 내부적으로 저장됩니다.
따라서 테이블의 파티션 키는 동일한 복제본 집합의 행을 그룹화하고 클러스터링 칼럼은 해당 행이 복제본에 저장되는 방법을 제어합니다.
이러한 정렬을 사용하면 파티션 내의 행 범위를 효과적으로 검색 할 수 있습니다.
(예를 들어, 위의 예에서 SELECT * FROM t WHERE a = 0 AND b > 1 및 b <= 3).

Table options

CQL 테이블에는 생성시 설정할 수있는 옵션이 많이 있습니다 (대부분 나중에 변경됨).
이 옵션은 WITH 키워드 다음에 지정됩니다.

이러한 옵션들 중 COMPACT STORAGE와 CLUSTERING ORDER 옵션은 생성 후 변경 될 수 없으며, 해당 테이블에 수행 할 수있는 쿼리에 대해 영향을 끼칩니다.

Reversing the clustering order

테이블의 클러스터링 순서는 해당 테이블의 클러스터링 컬럼에 의해 정의됩니다.
기본적으로 이러한 순서는 해당 클러스터링 순서의 자연 순서에 따라 결정되지만 CLUSTERING ORDER는 클러스터링 순서를 변경하여 일부 (잠재적으로 모든 것) 열에 대해 역 자연 순서를 사용하도록 허용합니다.

CLUSTERING ORDER 옵션은 클러스터링 열의 쉼표로 구분 된 목록을 가집니다. ASC는 각각 ASC (자연 순서) 또는 DESC (자연 순서가 역순)와 같습니다.
CLUSTERING ORDER 옵션을 사용하지 않는 경우, 기본값은 모든 클러스터링 열과 함께 ASC 수정자를 사용하는 옵션과 동일합니다.

이러한 옵션으로 저장소 엔진에 대해 열을 저장하는 순서를 변경하는 경우에 아래와 같이 3가지 결과를 알 수 있습니다.

# 해당 테이블에서 SELECT에 허용되는 ORDER BY 절을 제한합니다.
당신은 오직 클러스터링 순서 또는 역방향 클러스터링 순서로만 결과를 정렬 할 수 있습니다.
테이블에 2 개의 클러스터링 컬럼 a와 b가 있고 WITH CLUSTERING ORDER (DESC, b ASC)를 정의한 경우, 조회를 할 때 ORDER BY (DESC, b ASC)와 (역 클러스터링 순서인) ORDER BY (a ASC, b DESC)를 사용할 수 있습니다.
ORDER BY (a ASC, b ASC) (또는 ORDER BY (a DESC, b DESC))는 가능하지 않습니다.

# 또한 query 될 때 결과의 기본 순서를 변경합니다 (ORDER BY가 제공되지 않은 경우).
결과는 항상 (파티션 내에서) 클러스터링 순서로 리턴됩니다.

# 역방향 클러스터링 순서의 쿼리가 순방향 클러스터링 순서 쿼리보다 느리기 때문에 일부 쿼리에 작은 성능 영향을줍니다.

Other table options

테이블은 다음 옵션을 지원합니다 :

---

* Compaction options

압축 옵션은 테이블을 압축하는 방법을 정의합니다.
다음과 같은 하위 옵션을 사용할 수 있습니다 :

---

*Caching options

캐싱 옵션을 사용하면 테이블의 키 캐시와 행 캐시를 모두 구성 할 수 있습니다.
다음과 같은 하위 옵션을 사용할 수 있습니다 :

---

다른 고려 사항들 :

- 새로운 컬럼 추가 상수 시간 오퍼레이션입니다.
따라서 테이블을 만들 때 미래의 사용법을 예상 할 필요가 없습니다.

출처 : http://cassandra.apache.org/doc/latest/cql/ddl.html

이 문서는 개인적인 목적이나 배포하기 위해서 복사할 수 있다. 출력물이든 디지털 문서든 각 복사본에 어떤 비용도 청구할 수 없고 모든 복사본에는 이 카피라이트 문구가 있어야 한다.