2017년 9월 17일 일요일

[Cassandra 레퍼런스] [Data Definition] Triggers


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




트리거는 다음에 의해 정의 된 이름으로 식별됩니다.

trigger_name ::=  identifier


CREATE TRIGGER

새 트리거를 생성할 때에는 CREATE TRIGGER 문을 사용합니다.

create_trigger_statement ::=  CREATE TRIGGER [ IF NOT EXISTS ] trigger_name
                                  ON table_name
                                  USING string

예를 들어 :

CREATE TRIGGER myTrigger ON myTable USING 'org.apache.cassandra.triggers.InvertedIndex';

트리거를 구성하는 실제 logic은 모든 Java (JVM) 언어로 작성 될 수 있으며 데이터베이스 외부에 존재합니다.
트리거 코드는 Cassandra 설치 디렉토리의 lib / triggers 서브 디렉토리에 놓으면 되고, 클러스터 시작 중에 로드되며 클러스터에 참여하는 모든 노드에 존재하게 됩니다.
요청 된 DML 문이 발생하기 전에 테이블에 정의 된 트리거가 실행되어 트랜잭션의 원자성을 보장합니다.


DROP TRIGGER

트리거를 삭제할 때에는 DROP TRIGGER 문을 사용합니다.

drop_trigger_statement ::=  DROP TRIGGER [ IF EXISTS ] trigger_name ON table_name

예를 들어 :

DROP TRIGGER myTrigger ON myTable;

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

2017년 9월 16일 토요일

[Cassandra 레퍼런스] [Data Definition] JSON Support

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




Cassandra 2.2에서는 SELECT 및 INSERT 문에 대한 JSON 지원이 도입되었습니다.
이 지원은 CQL API를 근본적으로 변경하지 않습니다.(예 : 스키마가 여전히 적용됨).
또한, JSON 문서를 사용하여 편리하게 작업 할 수 있습니다.


SELECT JSON

SELECT 문을 사용하면 JSON 키워드를 사용하여 각 행을 단일 JSON 인코딩 된 맵으로 반환 할 수 있습니다.
SELECT 문 동작의 나머지 부분은 동일합니다.

결과의 맵 키는 일반적인 결과로 리턴되는 세트의 column 이름과 동일합니다.
예를 들어, SELECT JSON a, ttl (b) FROM ...과 같은 명령문은 "a"및 "ttl (b)" 키가 있는 맵을 생성합니다.
그러나 여기에는 주목할만한 예외가 존재합니다.
INSERT JSON 동작을 사용한 경우 대문자가있는 대 / 소문자를 구분하는 열 ​​이름은 큰 따옴표로 묶여서 결과로 리턴되게 됩니다.
예를 들어 SELECT JSON myColumn FROM ...은 "\"myColumn \ ""(이스케이프 된 따옴표에 유의하십시오.) 맵 키를 생성합니다.

맵 값은 결과 세트 값의 JSON 형태로 인코딩된 표현으로 나타납니다.


INSERT JSON

INSERT 문을 사용하면 새로운 JSON 키워드를 사용하여 JSON 인코딩 된 맵을 단일 행으로 삽입 할 수 있습니다.
JSON 맵의 형식은 일반적으로 동일한 테이블의 SELECT JSON 문에서 반환하는 형식과 일치해야합니다.
특별한 경우로, 대소 문자를 구분하는 열 ​​이름은 큰 따옴표로 묶어야합니다.
예를 들어 "myKey"및 "value"라는 두 개의 열이있는 테이블에 삽입하려면 다음을 수행합니다 :

INSERT INTO mytable JSON '{ "\"myKey\"": 0, "value": 0}'

기본적으로 (또는 DEFAULT NULL이 명시 적으로 사용되는 경우) JSON 맵에서 생략 된 열은 NULL로 설정됩니다. 즉, 해당 열의 기존 값이 제거되므로 삭제 표시가 작성됩니다.
또는 값 뒤에 DEFAULT UNSET 지시문을 사용하면 생략 된 열 값이 설정되지 않은 채로 남아 있습니다. 즉, 해당 열의 기존 값이 보존됩니다.


JSON Encoding of Cassandra Data Types

가능한 경우 Cassandra는 기본 JSON 표현으로 데이터 유형을 나타내고 수용합니다.
또한 Cassandra는 모든 단일 필드 유형에 대해 CQL 리터럴 형식과 일치하는 문자열 표현을 허용합니다.
예를 들어, float, ints, UUID 및 날짜는 CQL 리터럴 문자열로 나타낼 수 있습니다.
그러나 컬렉션, 튜플 및 사용자 정의 유형과 같은 복합 유형은 기본 JSON 모음 (maps and lists) 또는 JSON으로 인코딩 된 모음의 문자열 표현으로 나타내야합니다.


The fromJson() Function

fromJson () 함수는 INSERT JSON과 유사하지만, 단일 열 값에 사용할 수 있습니다.
INSERT.의 VALUES 절 또는 UPDATE, DELETE 또는 SELECT의 column value 중 하나로서만 사용될 수 있습니다.
예를 들어, SELECT의 선택 절에서 사용될 수 없습니다.


The toJson() Function

toJson () 함수는 SELECT JSON과 유사하게 사용될 수 있지만, 단일 열 값에 사용할 수 있습니다.
SELECT 문의 선택 절에서만 사용할 수 있습니다.


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

2017년 9월 7일 목요일

[Cassandra 레퍼런스] [Data Definition] Materialized Views

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




구체화 된 뷰 이름은 다음에 의해 정의됩니다.

view_name ::=  re('[a-zA-Z_0-9]+')


CREATE MATERIALIZED VIEW

CREATE MATERIALIZED VIEW 문을 사용하여 테이블에 구체화 된 뷰를 작성할 수 있습니다.

create_materialized_view_statement ::=  CREATE MATERIALIZED VIEW [ IF NOT EXISTS ] view_name AS
                                            select_statement
                                            PRIMARY KEY '(' primary_key ')'
                                            WITH table_options

예를 들어 :

CREATE MATERIALIZED VIEW monkeySpecies_by_population AS
    SELECT * FROM monkeySpecies
    WHERE population IS NOT NULL AND species IS NOT NULL
    PRIMARY KEY (population, species)
    WITH comment='Allow query by population instead of species';

CREATE MATERIALIZED VIEW 문은 새로운 구체화 된 뷰를 작성합니다.
이러한 각 뷰는 SELECT 문에 지정된 기본 테이블 또는 기본 테이블에있는 행에 해당하는 행 집합입니다.
구체화 된 뷰는 직접 업데이트 할 수 없지만 기본 테이블을 업데이트하면 해당 뷰가 업데이트됩니다.

구체화 된 뷰를 작성하는 과정은 다음 세 부분으로 이루어집니다.

- 뷰에 포함되는 데이터를 제한하는 select 문입니다.

- 뷰의 primary_key 정의입니다.

- 뷰를 위한 옵션

IF NOT EXISTS 옵션을 사용하지 않으면 이미 존재하는 구체화 뷰를 작성하려고 하면 오류가 리턴됩니다.
사용되는 경우, 구체화 된 뷰가 이미 존재하면 명령문은 동작하지 않습니다.


MV select statement

구체화 뷰 작성의 select 문은 어떤 기본 테이블이 뷰에 포함되는지 정의합니다.
그 명령문은 몇가지 방법으로 제한되어 있습니다:

- 그 선택은 기본 테이블의 열만 선택하는 선택으로 제한됩니다.
다시 말해, 함수 (집계 또는 결합), 형변환, 용어 등을 사용할 수 없습니다.
별칭도 지원되지 않습니다.
그러나 *를 모든 열을 선택하는 shortcut으로 사용할 수 있습니다.
또한 정적 컬럼은 구체화 된 뷰에 포함될 수 없습니다. (기본 테이블에 정적 컬럼이 있으면 SELECT *가 허용되지 않습니다.)

- WHERE 절에는 다음과 같은 제한 사항이 있습니다 :
* bind_marker를 포함 할 수 없습니다.
* 기본 테이블 기본 키의 일부가 아닌 칼럼은 IS NOT NULL 조건으로만 제한될 수 있습니다. 다른 제한은 허용되지 않습니다.
* 뷰 기본 키의 일부인 칼럼은 NULL이 될 수 없으므로 적어도 IS NOT NULL 제한 (또는 다른 제한은 없지만 값이 있어야 함)에 의해 최소한 제한되어야합니다.

- ordering 절이나 limit 을 가질 수 없으며 FILTERING을 허용 할 수도 없습니다.


MV primary key

뷰에는 primary_key가 있어야하며 primary_key는 다음 제한 사항을 준수해야합니다 :

- 기본 테이블의 모든 primary_key 컬럼 세트를 포함해야합니다.
이렇게하면 뷰의 모든 행이 기본 테이블의 정확히 한 행에 해당합니다.

- 기본 테이블의 기본 키 컬럼이 아닌 경우, 단일 컬럼만 포함 할 수 있습니다.


예를 들어, 다음 기본 테이블 정의를 보면 :

CREATE TABLE t (
    k int,
    c1 int,
    c2 int,
    v1 int,
    v2 int,
    PRIMARY KEY (k, c1, c2)
)

다음 뷰 정의가 허용됩니다 :

CREATE MATERIALIZED VIEW mv1 AS
    SELECT * FROM t WHERE k IS NOT NULL AND c1 IS NOT NULL AND c2 IS NOT NULL
    PRIMARY KEY (c1, k, c2)

CREATE MATERIALIZED VIEW mv1 AS
    SELECT * FROM t WHERE k IS NOT NULL AND c1 IS NOT NULL AND c2 IS NOT NULL
    PRIMARY KEY (v1, k, c1, c2)

하지만 다음은 허용되지 않습니다 :

// Error: cannot include both v1 and v2 in the primary key as both are not in the base table primary key
CREATE MATERIALIZED VIEW mv1 AS
    SELECT * FROM t WHERE k IS NOT NULL AND c1 IS NOT NULL AND c2 IS NOT NULL AND v1 IS NOT NULL
    PRIMARY KEY (v1, v2, k, c1, c2)

// Error: must include k in the primary as it's a base table primary key column
CREATE MATERIALIZED VIEW mv1 AS
    SELECT * FROM t WHERE c1 IS NOT NULL AND c2 IS NOT NULL
    PRIMARY KEY (c1, c2)


MV options

구체화 된 뷰는 내부적으로 테이블에 의해 구현되므로 MV를 작성하면 테이블을 작성하는 것과 동일한 옵션을 사용할 수 있습니다.


ALTER MATERIALIZED VIEW

작성한 후에는 ALTER MATERIALIZED VIEW 문을 사용하여 구체화 된 뷰의 옵션을 변경할 수 있습니다.

alter_materialized_view_statement ::=  ALTER MATERIALIZED VIEW view_name WITH table_options

업데이트 할 수있는 옵션은 작성시와 동일하므로, 따라서 테이블과 동일합니다.


DROP MATERIALIZED VIEW

구체화 된 뷰를 삭제할 때에는 DROP MATERIALIZED VIEW 문이 사용됩니다.

drop_materialized_view_statement ::=  DROP MATERIALIZED VIEW [ IF EXISTS ] view_name;

구체화 된 뷰가 존재하지 않으면, IF EXISTS가 사용되는 경우가 아니라면 명령문은 오류를 리턴합니다.
사용되는 경우 아무런 동작을 하지않습니다.

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

2017년 9월 2일 토요일

[Cassandra 레퍼런스] [Data Definition] Secondary Indexes

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




CQL은 테이블에 대한 보조 인덱스 생성을 지원하므로 테이블에 대한 쿼리를 통해 해당 인덱스를 사용할 수 있습니다.
보조 인덱스는 다음에 의해 정의 된 이름으로 식별됩니다.

index_name ::=  re('[a-zA-Z_0-9]+')


CREATE INDEX

테이블에 보조 인덱스를 생성할 때는 CREATE INDEX 문을 사용합니다.

create_index_statement ::=  CREATE [ CUSTOM ] INDEX [ IF NOT EXISTS ] [ index_name ]
                                ON table_name '(' index_identifier ')'
                                [ USING string [ WITH OPTIONS = map_literal ] ]
index_identifier       ::=  column_name
                           | ( KEYS | VALUES | ENTRIES | FULL ) '(' column_name ')'

예를 들어 :

CREATE INDEX userIndex ON NerdMovies (user);
CREATE INDEX ON Mutants (abilityId);
CREATE INDEX ON users (keys(favs));
CREATE CUSTOM INDEX ON users (email) USING 'path.to.the.IndexClass';
CREATE CUSTOM INDEX ON users (email) USING 'path.to.the.IndexClass' WITH OPTIONS = {'storage': '/mnt/ssd/indexes/'};

CREATE INDEX 문은 주어진 테이블에서 주어진 칼럼에 대한 새로운 2차 인덱스를 작성하는 데 사용됩니다.
원할 경우, ON 키워드 앞에 인덱스 자체의 이름을 지정할 수 있습니다.
데이터가 이미 해당 열에 존재하면 비동기적으로 해당 데이터에 대해 인덱스가 적용됩니다.
인덱스가 생성된 후 열에 대한 새 데이터는 삽입시 자동으로 인덱싱됩니다.

IF NOT EXISTS 옵션을 사용하지 않으면 이미 존재하는 인덱스를 만들려고 하는 경우 오류가 반환됩니다.
사용하는 경우, 인덱스가 이미 존재하면 명령문은 실행되지 않습니다.


Indexes on Map Keys

맵에 인덱스를 만들 때는 키 또는 값을 인덱싱 할 수 있습니다.
열 식별자가 keys () 함수 내에 칼럼의 구분자가 있으면 인덱스가 맵 키에 있으므로 WHERE 절에 CONTAINS KEY를 사용할 수 있습니다.
그렇지 않은 경우는 인덱스가 맵 값에 있게 됩니다.


DROP INDEX

보조 인덱스를 삭제할 때에는 DROP INDEX 문이 사용됩니다.

drop_index_statement ::=  DROP INDEX [ IF EXISTS ] index_name

DROP INDEX 문은 기존 보조 인덱스를 삭제할 때 사용됩니다.
명령문의 인수는 인덱스 이름이며, 선택적으로 색인의 키 스페이스를 지정할 수 있습니다.

인덱스가 존재하지 않으면 IF EXISTS가 사용되지 않는 한 명령문은 오류를 리턴합니다.
사용되는 경우, 명령문은 실행되지 않습니다.

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

2017년 8월 31일 목요일

[Cassandra 레퍼런스] [Data Definition] Custom Types

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




사용자 정의 유형은 다음에 의해 정의됩니다 :

custom_type ::=  string

사용자 정의 유형은 서버 측 AbstractType 클래스를 확장하고 Cassandra가 로드할 수있는 Java 클래스의 이름을 포함하는 문자열입니다.
(따라서 Cassandra를 실행하는 모든 노드의 CLASSPATH에 있어야합니다).
이 클래스는 유형에 유효한 값과 클러스터링 컬럼에 사용될 때 시간 정렬 방법을 정의합니다.
다른 목적을 위해, 커스텀 타입의 값은 blob의 값과 동일하며 특히 BLOB 리터럴 구문을 사용하여 입력 할 수 있습니다.


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

[Cassandra 레퍼런스] [Data Definition] Tuples

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





또한 CQL은 튜플 및 튜플 유형 (요소가 다른 유형이 될 수 있음)을 지원합니다.
기능상 튜플은 익명 필드가 있는 익명 UDT 일 수 있습니다.
튜플 유형과 튜플 리터럴은 다음과 같이 정의됩니다 :

tuple_type    ::=  TUPLE '<' cql_type ( ',' cql_type )* '>'
tuple_literal ::=  '(' term ( ',' term )* ')'

다음과 같이 사용할 수 있습니다.

CREATE TABLE durations (
    event text,
    duration tuple,
)

INSERT INTO durations (event, duration) VALUES ('ev1', (3, 'hours'));


다른 "작성된"유형(콜렉션 및 UDT)과 달리, 튜플은 고정 된 키워드가 필요없이 항상 고정되어 있으며, 전체 튜플을 업데이트하지 않고서 튜플의 일부 요소만 업데이트 할 수는 없습니다.
또한 튜플 리터럴은 튜플인 유형에서 선언 된 값과 동일한 수의 값을 항상 가져야합니다.
(일부 값은 null 일 수 있지만 명시 적으로 그렇게 선언해야 함).


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

[Cassandra 레퍼런스] [Data Definition] User-Defined Types

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






CQL은 사용자 정의 유형 (UDT)의 정의를 지원합니다.
이러한 유형은 아래에 설명 된 create_type_statement, alter_type_statement 및 drop_type_statement를 사용하여 작성, 수정 및 제거 할 수 있습니다.
그러나 일단 만들어지면, UDT는 단순히 그 이름으로 참조됩니다 :

user_defined_type ::=  udt_name
udt_name          ::=  [ keyspace_name '.' ] identifier


Creating a UDT

새 사용자 정의 유형 작성은 다음에 의해 정의 된 CREATE TYPE 문을 사용하여 수행됩니다.

create_type_statement ::=  CREATE TYPE [ IF NOT EXISTS ] udt_name
                               '(' field_definition ( ',' field_definition )* ')'
field_definition      ::=  identifier cql_type

UDT는 이름(해당 타입으로 선언되는 칼럼에 사용되는)을 가지며 이름을 지정하는 필드와 유형을 지정하는 필드로 구성됩니다.
필드 이름은 콜렉션 또는 다른 UDT를 포함하여 모든 유형이 될 수 있습니다.
예를 들어 :

CREATE TYPE phone (
    country_code int,
    number text,
)

CREATE TYPE address (
    street text,
    city text,
    zip text,
    phones map
)

CREATE TABLE user (
    name text PRIMARY KEY,
    addresses map
>
)

참고 사항 :

- IF NOT EXISTS 옵션을 사용하지 않으면 이미 존재하는 유형을 생성하려고하면 오류가 발생합니다.
사용되는 경우 유형이 이미 존재하면 아무런 동작을 하지 않습니다.

- 유형은 본질적으로 생성 된 키 스페이스에 바인드되며 해당 키 스페이스에서만 사용할 수 있습니다.
생성시, 유형 이름 앞에 키 스페이스 이름이 있으면 해당 키 스페이스에 유형 이름이 작성됩니다.
그렇지 않으면, 현재 키 스페이스에 작성됩니다.

- Cassandra 4.0에서 UDT는 대부분의 경우 동결되어야하므로 위의 테이블 정의에서
frozen
를 사용해야합니다.
자세한 내용은 고정 섹션을 참조하십시오.


UDT literals

일단 사용자 정의 된 타입이 생성되면, 값은 UDT 리터럴을 사용하여 입력 될 수 있습니다 :

udt_literal ::=  '{' identifier ':' term ( ',' identifier ':' term )* '}'

즉, UDT 리터럴은 맵 리터럴과 비슷하지만 해당 키는 해당 유형의 필드 이름입니다.
예를 들어, 다음을 사용하여 이전 섹션에서 정의한 테이블에 삽입 할 수 있습니다.

INSERT INTO user (name, addresses)
          VALUES ('z3 Pr3z1den7', {
              'home' : {
                  street: '1600 Pennsylvania Ave NW',
                  city: 'Washington',
                  zip: '20500',
                  phones: { 'cell' : { country_code: 1, number: '202 456-1111' },
                            'landline' : { country_code: 1, number: '...' } }
              },
              'work' : {
                  street: '1600 Pennsylvania Ave NW',
                  city: 'Washington',
                  zip: '20500',
                  phones: { 'fax' : { country_code: 1, number: '...' } }
              }
          })

유효한 입력을 위해서는 UDT 리터럴은 리터럴인 유형으로 정의된 필드만을 포함해야 하지만 일부 필드는 생략 할 수 있습니다 (이 경우 해당 값은 null입니다).


Altering a UDT

기존 사용자 정의 유형은 ALTER TYPE 문을 사용하여 수정할 수 있습니다 :

alter_type_statement    ::=  ALTER TYPE udt_name alter_type_modification
alter_type_modification ::=  ADD field_definition
                             | RENAME identifier TO identifier ( identifier TO identifier )*

할 수있는 일 :

- 유형에 새 필드를 추가합니다 (ALTER TYPE address ADD country text).
그 새로운 필드는 추가 전에 작성된 모든 값에 대해 null이됩니다.

- 유형의 필드 이름을 바꿉니다 (ALTER TYPE address RENAME zip TO zipcode).


Dropping a UDT

DROP TYPE 문을 사용하여 기존 사용자 정의 유형을 삭제할 수 있습니다.

drop_type_statement ::=  DROP TYPE [ IF EXISTS ] udt_name

유형을 삭제하면 해당 유형이 즉시 되돌릴 수 없게됩니다.
그러나 다른 유형, 테이블 또는 함수에서 계속 사용중인 유형을 삭제하려고 시도하면 오류가 발생합니다.

삭제 된 유형이 없는 경우 IF EXISTS가 사용되지 않으면 오류가 반환됩니다.
사용되는 경우 작업은 아무 작업도 수행하지 않습니다.


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