CQL data modeling

Data modeling concepts

데이터 모델링은 아이템들이 저장될 entity들에 대해 구별/정의 하고 그 entity 들간의 관계를 짓는 프로세스이다. 여러분의 데이터 모델링을 생성하기 위해서는 접근되는 데이터들의 타입을 알아내고 perform 될 쿼리들의 타입들을 알아내야 한다. 이 두개의 요소가 데이터의 organization과 structure 구성에 주요한 역할을 한다. 또한 데이터베이스의 테이블들을 디자인하고 생성할 때에도 이 두가지 요소는 중요하게 작용한다. 때에 따라 데이터를 indexing 하는 것은 퍼포먼스 향상에 도움을 준다. 그래서 어떤 컬럼이 secondary index가 될지에 대해 정하게 된다.

카산드라에서의 데이터 모델링은 query-driven (쿼리 기반)의 방식을 사용한다. 데이터를 organizing 하기 위해 특정 쿼리를 이용해서 하게 된다는 것이죠. 쿼리는 테이블에서 데이터를 selecting 하는 도구 입니다. 스키마는 테이블에서 어떻게 데이터가 arrange 되어야 하는가에 대한 정의이구요. 카산드라의 데이터베이스 디자인은 fast read and write라는 요구조건을 기반으로 만들어 졌습니다. 그러므로 좋은 스키마 디자인은 데이터를 읽고 retrieve 하는 과정을 더 빨리 할 수 있는 디자인입니다.

반면에 관계형 데이터베이스는 테이블과 관계 디자인에 근거해서 만들어 집니다. 그 이후에 쿼리를 만들어서 사용하는 것이지요. 관계형 데이터베이스의 데이터 모델링은 table-driven (테이블 기반) 이라고 할 수 있습니다. 그리고 테이블간의 관계는 쿼리에서 table join으로 표현 됩니다.

Cassandra의 데이터모델은 조정 가능한 consistency의 특성을 가진 분할된 row store라고 얘기할 수 있습니다. 저정 가능한 consistency라는 의미는 어떤 read 혹은 right 작업에서 client application이 요청된 데이터가 어떤 consistent를 가져야 하는지를 결정한다는 겁니다. Row들은 Table 안에 있습니다. 테이블의 primary key의 첫번째 component은 partition key 입니다. 이것은 partition 안에 존재하죠. row들은 그 key의 나머지 columns에 남아있으면서 cluster 됩니다. 다른 컬럼들은 primary key 와 별도로 인덱스 될 수 있습니다. 왜냐하면 Cassandra는 distributed database로서 파티션에 의해 노드들에서 데이터들이 그룹화 되어 있을 때 read와 write 작업에 대해 효율성을 담보할 수 있기 때문입니다. 빠른 response를 기대한 다면 그 쿼리가 되도록 적은 파티션에 작용하도록 해야 합니다. consistancy 레벨을 조정하는 것은 숨어있는 또 다른 부분 이지만 이것이 데이터 모델링 프로세스에 속하지는 않습니다.

카산드라 데이터 모델링은 쿼리에 focusing 돼 있습니다. 아래 Pro Cycling statistics demonstrate의 예제에서는 특정 쿼리에 대한 카산드라 테이블 스키마가 어떻게 modeling 하는 가를 보여 줍니다. 이 데이터 모델은 entity들과 관계들을 보여 줍니다.

이 엔티티들과 그 관계들은 테이블 디자인을 할 때 참고됩니다. 한개의 테이블에 access 할 때 쿼리는 가장 잘 디자인 된 것입니다. 그래서 쿼리에 포함되어 relationship안에 구성돼 있는 모든 엔티티들은 반드시 한개의 테이블이어야만 합니다. 어떤 테이블들은 한개의 엔티티와 그것의 attribute들만으로 구성됩니다. (아래 첫번째 예제가 이 경우입니다) 다른 경우는 1개 이상의 entity와 그 속성(attributes)들을 가지는 경우입니다. 아래의 두번째 예제에 해당되는 것이죠. 하나의 카산드라 테이블에 모든 데이터가 들어가 있는 것은 관계형 데이터베이스와 구별 되는데요. 관계형 데이터베이스 같은 경우는  두개 이상의 테이블에 데이터가 들어가 있고 foreign key로 테이블들간의 데이터의 관계를 설정하게 되죠. 카산드라는 이렇게 single table - single query 방식을 사용하기 때문에 쿼리 속도가 빠르게 되는 겁니다.

이 Pro Cycleing statistics에 대한 기본 쿼리 (Q1)는 cyclist들의 리스트 입니다. 여기에는 사이클리스트의 id, firstname 그리고 lastname 이 들어가 있습니다. 이 테이블에서 사이클 선수들을 구별해 주기 위해 UUID를 사용한 id 가 있습니다. 이 테이블에서 사이클 선수들 리스트를 뽑는 간단한 쿼리를 위해 이 id 에 partition K가 있습니다. 아래 다이어그램을 보면 Pro Cycling data model에 대한 lgical model 의 portion을 보실 수 있습니다.

Query 1 : 특정 id에 해당하는 사시클 선수 이름 찾기

연관된 쿼리 (Q2) 는 특정 race 카테고리에 대한 모든 사이클 선수들을 찾는 겁니다. 카산드라에서는 테이블에 카테고리 별로 모든 사이클 선수들의 그룹이 있는 것이 훨씬 효과적으로 작동할 수 있습니다.
그러기 위해 몇개의 공통된 컬럼들이 필요합니다. (id, lastname). 여기서는 테이블의 primary key에 카테고리가 patition key (K)로 포함돼 있습니다. 그리고 이 안에 있는 id 는 partition C로 돼 있습니다. 이럼으로서 각각의 사이클 선수에 해당하는 unique 한 record들을 관리할 수 있게 됩니다.

Query 2 : 특정 카테고리 별 사이클 선수들 찾기

이상이 두개의 아주 간단한 쿼리를 보여주는 예제입니다. 좀 더 많은 예제들은 CQL을 사용한 데이터모델링 그림을 보면 아실 수 있습니다.

테이블을 디자인하는데 가장 중요한 부분은 테이블과 테이블간의 관계가 아니라는 것을 명심하시기 바랍니다. 그것은 관계형 데이터베이스의 모델링 입니다. 카산드라에 있는 데이터는 대개 한 테이블 당 한개의 쿼리 형식으로 구성됩니다. 그리고 데이터는 여러 테이블들에 반복적으로 사용됩니다. 이러한 프로세스를 denormalization이라고 합니다.
관계형 데이터베이스에서는 데이터의 중복을 피하기 위해 normalize 데이터를 사용합니다.  entity 들간의 관계는 중요합니다. 카산드라에 저장돼 있는 데이터의 순서는 데이터를 가져올 때 간편성과 속도성에 큰 영향을 미칠 수 있기 때문입니다. 스키마 디자인은 같은 테이블의 관계된 속성들을 포함함으로서 entity들간의 관계를 capture 할 수 있게 해 줍니다. 어플리케이션에서 사용하는 client-side join은 테이블 스키마가 그 관계의 복잡성을 제대로 capture 하지 못했을 때 사용하게 됩니다.

Data modeling analysis

entity와 그 관계들에 대한 모델 개념이 만들어 졌다면 이 conceptual model로부터 테이블 스키마를 생성하기 위한 예상되는 쿼리들을 사용하실 수 있습니다. 데이터 모델의 마지막 단계는 logical design의 분석을 완료하는 것입니다. 그 과정을 통해 필요한 수정사항들을 발견하고 또 수정을 할 수 있게 되는 것이죠.
이 수정작업은 partition size limitation, cost of data consistency 그리고 performance costs 등에 대한 이해를 바탕으로 진행하실 수 있습니다. 왜냐하면 여러 다른 선택 가능한 디자인들이 있을 수 있기 때문입니다.

보다 효율적으로 운영하기 위해 파티션들은 특정 limit 내에서 제한되어야 합니다. 이 파티션 size를 측량하는 두 가지 요소는 파티션 안의 값들의 갯수와 디스크에서의 파티션 size 입니다. 한 row 당 최대 컬럼수는 20억 입니다. 디스크 공간을 sizing 하는 것은 좀 더 복잡합니다. 각 테이블의 row의 갯수, 컬럼의 갯수, primary key column 들 그리고 static 컬럼등을 고려해야 합니다. 각 어플리케이션은 각각 다른 efficiency parameter들을 가질 겁니다. 가장 좋은 방법은 value의 최대 갯수를 10만 아이템 이하로  디스크 사이즈는 100MB 이하로 유지하는 겁니다.

Data redundancy 도 반드시 고려해야 할 부분 입니다. 카산드라의 distributed design 의 결과인 이 두개의 redundancy는 테이블들과 여러 partition replicate들에 중복된 데이터 들이다.

데이터는 일반적으로 여러개의 테이블에 중복된다. 이것은 write를 하는 동안 퍼포먼스에 영향을 준다. 그리고 좀 더 많은 디스크 스페이스도 필요로 한다. 사이클 선수의 이름과 아이디를 레이스 카테고리, 종료된 레이스, 사이클 선수 통계와 같은 여러개의 데이터와 함께 저장하는 것을 생각해 보자. 여러개의 테이블에 이름과 id를 저장하면 linear duplication 이 발생한다. 두개의 값들이 각각의 테이블에 저장되는 것이다. 테이블 디자인은 좀 더 높은 order duplication의 가능성을 고려해야 할 것이다. 예를 들어 unlimited keyword 들이 광범한 수의 row에 저장되는 것 등. n keyword들이 m row들에 저장되는 경우는 좋은 테이블 디자인이 아니다. 이럴 경우 좀 더 나은 디자인을 위해 테이블 스키마를 다시 생각해 보아야 한다. 해당 쿼리는 계속 생각하고 있어야 하는 것은 물론이다.

Cassandra는 replication factor에 기반해서 파티션 데이터을 복제한다. (당연히 디스크 공간을 차지하게 될 것이다.) Replication (복제) 할 때 distributed database(데이터 베이스 분산)과 디스크 저장공간의 sizing을 감안해서 해야 하는 것은 중요하다.

어플리케이션 쪽에서의 join은 퍼포먼스에 악영향을 줄 수 있다. 일반적으로 여러분은 join을 필요로 하는 쿼리에 대해 본석해야 하고 별도의 테이블에 그 join 결과를 pre-computing 하고 저장하는 것에 대해 생각해야 한다. 카산드라에서는 목표가 퍼포먼스를 위해 1 개의 테이블에 1개의 쿼리를 사용하는 것이다. LWT (LightWeight Transactions)도 퍼포먼스에 영향을 미친다. 쿼리가 LWT를 사용하는 지 여부를 고려하는 것이 필요하고 정말 필요한것이 아닐 경우 그 requirement를 remove 하는 것도 필요하다.

Cassandra Query Language (CQL)은 카산드라 데이터베이스를 사용할 수 있는 primary lanuage 이다. 카산드라와 상호작용할 수 있는 가장 기본적인 방법은 CQL shel (cqlsh)을 이용하는 것이다. 이것을 이용해서 keyspace와 table 들을 만들 수 있고 insert와 다른 query tables 등등을 할 수 있다. graphocal tool을 원하시면 DataStax DevCenter 를 사용할 수 있다. Production을 위해서는 Datastax가 여러 driver들을 제공하기 때문에 CQL 구만은 client 에서 cluster 로 전달 되고 또 그 반대로 전달 받게 된다. 다른 관리 차원의 일들은 OpsCenter를 이용하면 된다.

Cassanddra 2.2 와 3.0을 위한 CQL 기능들

CQL for Cassandra 2.0 & 2.1

Cassandra 2.1 features

Cassandra 2.1 은 다음과 같은 새로운 CQL 기능을 포함한다.
* Nested user-defined types
* Improved counter columns : 카산드라가 commit log를 replay 할 때 정확한 count를 유지하기 위한 기능
* 수정 가능한 counter cache
* collenction에 대한 index 지원 기능, query result를 filter 하기 위햔 map key를 사용하기도 함
* millisecond 까지 가능한 Timestamps
* typed positional fields의 fixed-length set을 hold 하는 tuple typed

cqlsh utility도 개선된 기능들이 있다.
* operating system command line에서 CQL 구문을 받아서 처리할 수 있는 기능
* DESCRIBE 명령어를 사용해 type들을 표시해 주는 기능

DataStax Java Driver 2.0.0 은 제한적으로 Cassandra 2.1을 지원한다. 이 드라이버의 버전은 새로운 기능과 호환되지 않습니다.

다른 변화들은 이런 것들이 있습니다.
* counter column을 업데이트하기 위해 명령어에 USING TIMESTAMP나 USING TTL을 사용하는 것을 reject 합니다. 이럴 경우 카산드라는 에러 메세지를 보내게 됩니다.
* Cassandra 2.1 에서 CQL table property index_interval은 min_index_interval 과 max_index_interval로 대체됐습니다. max_index_interval 은 디폴트로 2048 입니다. 이 디폴트는 SSTable들이 불규칙적으로 읽히고 index summary memory pool이 full일 때에만 도달하게 됩니다. 이전 release에서 upgrade할 때 Cassandra는 min_index_interval에 대해 이전버전에서 사용하던 index_interval 값을 사용할겁니다.

Cassandra 2.0.x 기능들이

* INSERT와 UPDATE 구문에서 IF 키워드를 사용해 Lightweight transaction을 가능하게 한다.
* 현재 있는 테이블, 키스페이스, 인덱스등에 대해 conditional test를 실행함으로서 application error를 방지한다.
  간단히 DROP 이나 CREATE 구문에 IF EXISTS 나 IF NOT EXISTS 를 포함하면 된다.
* 데이터베이스 클러스터 안팎에서 실행되는 이벤트들을 fire 하는 트리거를 위한 initial support 기능
* ALTER TABLE DROP command : 이전 버전에서는 제외 됐었었음
* Coulmn aliases : Select 구문에서 사용할 수 있으며 다른 RDBMS SQL의 aliase와 비슷하다.
* part, partition key 또는 Clustering columns, portion of a compound primary key 의 indexing 기능
DataStax 드라이버들은 Cassandra 2.0 을 자원한다.

Cassandra 2.0에 대한 CQL은 super column을 추천하지 않습니다. 카산드라는 CQL constructs 및 results에 즉석에서 슈퍼 컬럼을 번역하거나 쿼리하는 방법으로 계속적으로 지원하고 있습니다.

CQL Cassandra 2.0 에는 아래와 같은 cqlsh command에 변화가 있었습니다.
* ASSUME 명령어는 사라졌음. 이것 대신 blobAsType 과 typeAsBlob conversion 기능을 사용하면 됨.
* COPY 명령어가 collection도 지원하게 됨

Cassandra 2.0 에서 CQL에 다음과 같은 CQL table attribute들이 추가 됐습니다.

* default_time_to_live
* memtable_flush_period_in_ms
* populate_io_cache_on_flush
* speculative_retry

카산드라에서 사용되는 주요 개념들 정리해 보겠습니다.

Key concepts and data model

Key concepts

The following concepts are important for understanding Cassandra:

Cluster
    A group of nodes where you store your data. In this guide, you create a single-node cluster.
   
    데이터를 저장하는 노드들의 그룹이다.

   
Replication

    The process of storing copies of data on multiple nodes to ensure reliability and fault tolerance. The number of copies is set by the replication factor.

    여러 노드들에 데이터의 복사본을 저장하는 프로세스. 이렇게 함으로서 안정성과 fault tolerance (내고장성 耐故障性)을 보장할 수 있다. 복사본의 수는 replication factor에 의해 세팅된다.

   
Partitioner

    A partitioner distributes data evenly across the nodes in the cluster for load balancing.

    partitioner는 로드발란스를 위해 클러스트에 있는 노드들에 데이터가 고르게 분산되도록 조절한다.

   
Data Center
   
    A group of related nodes configured together within a cluster for replication purposes. It is not necessarily a physical data center. In DataStax Enterprise, the term related nodes refers to the type of node: transactional, analytics, search. Each type of node must be contained in its own data center.
   
    replication을 위해 클러스트 안에 설정된 연결된 노드들의 그룹이다. 꼭 물리적인 데이터 센터로 구분될 필요는 없다. DataStax Enterprise에서는 transactional, analytics, search 등의 노드 타입과 관련된 노드들을 가리킨다. 각 노드의 타입은 속해있는 데이터 센터에 포함돼 있어야 한다.

   
Links to related information in Cassandra

• Cassandra key features
• Cassandra Architecture

   
The data model distilled


Cassandra is a partitioned row store. It is an open-source, distributed-database system that is designed for storing and managing large amounts of data across commodity servers.

카산드라는 분할된 행의 저장공간이다. 오픈소스이며 범용서버에서 대량의 데이터를 저장하고 관리하기 위해 디자인된 분산 데이터베이스 시스템이다.


You design the data model

    The design of the data model is based on the queries you want to perform, not on modelling entities and relationships like you do for relational databases.

    데이터 모델의 디자인은 실행하고자 하는 쿼리에 기반한다. modelling entity 와 relationship에 기반한 관계형데이터베이스와는 다르다.

   
Column family
   
    In general, the term Table has replaced Column family. A Cassandra database consists of column families. A column family is a set of key-value pairs. Every column family has a key and consists of columns and rows. You can think of column family as a table and a key-value pair as a record in a table.
   
    일반적으로 얘기하는 Table은 카산드라에서는 Column family 가 그 역할을 한다. 카산드라 데이터베이스는 이러한 column family들로 구성된다. column family는 key-value pair들로 구성 돼 있다. 각 column family는 key와 column/row 들로 구성돼 있다. 이 column family는 관계형데이터베이스에서의 table 이라고 생각하면 된다. 그리고 key-value pair는 테이블의 record라고 생각하면 된다.
   
    Note: In CQL 3 (the latest implementation of the Cassandra Query Language), column families are called tables. The Cassandra CLI client utility (deprecated) , API classes, and OpsCenter continue to use column family.
   
    Note : CQL3에서는 column family를 table 이라고 부른다. Cassandra CLI client utility (deprecated) , API classes, 그리고  OpsCenter 에서는 계속 column family라고 부른다.

   
Table
   
    The definition of a table depends on the version of CQL:
   
    table에 대한 정의는 CQL 버전에 의존한다.

   
        In CQL 3, a table is a collection of ordered (by name) columns.
        In previous versions of CQL, a column family was synonymous, in many respects, to a table. In CQL 3 a table is sparse, which means it only includes columns for rows that have been assigned a value.

        CQL 3에서는 name에 의해 정렬된 column들의 집합이다.
        그 이전 버전의 CQL 에서는 column family는 table 과 거의 동의어로 사용됐다. CQL 3 에서 table은 값이 할당된 row들에 대한 column들을 포함하고 있다는 의미가 들어있다.

     
Keyspaces
   
    The outermost grouping of data, similar to a schema in a relational database. All tables go inside a keyspace. Typically, a cluster has one keyspace per application.
   
    outermost grouping of data 로 관계형 데이터베이스의 Schema 와 비슷하다. 모든 테이블들은 keyspace 안에 있게 된다. 일반적으로 어플리케이션 당 하나의 클러스터는 하나의 keyspace를 갖는다.
   

http://www.slideshare.net/planetcassandra/apache-cassandra-and-datastax-enterprise-explained-with-peter-halliday-at-wildhacks-nu

   
Snitches
   
    Snitch는 어떤 데이터센터와 rack 에 write 하고 read 할 것인지 결정한다.

   
Gossip = Internode Communications
   
    매 순간 어떤 노드와 정보를 exchange 할 것인지에 대한 peer to peer communication protocol
    카산드라는 이 gossip을 카산드라 클러스터에 있는 다른 노드들에 대한 위치와 상태정보를 알아내는데 사용한다.


Vnodes (Vertual Nodes)   

    각 노드가 single token range를 가지는 대신 Vnode는 각 노드를 많은 range (256) 로 나눈다.

그리고 회의 하다가 나온 얘긴데 Spark 을 사용하면 테이블 간 join 사용 효과를 낼 수 있다고 합니다.
   
Apache Spark

        테이블간 join 할 수 있도록 해 준다.
   

   

어제 설치하지 못한 Maven 을 설치 하려고 합니다.

http://maven.apache.org/download.cgi 로 가서 메이븐을 다운로드 합니다.

Home 이나 적당한 곳에 에 압축을 풀고 나면 이제 Path 를 지정해 줍니다.

open -e .bash_profile 로 파일을 열고 메이븐 Path 를 지정합니다.

export M2_HOME=//Users/changsoopark/Maven/apache-maven-3.3.9
export PATH=${M2_HOME}/bin:${PATH}

.bash_profile 이 없으면touch .bash_profile로생성하면됩니다.

그러면 설치가 다 끝난거구요.

어제 다운 받았던 playlist 폴더로 가서

$ mvn verify

이렇게 입력하세요.

그러면 아래와 같이 dependencies 들을 다운 받을 겁니다.

이러면 어제 못했던 마무리를 다 한거네요.

이제 다음 단계를 공부할 차례네요.

카산드라를 설치하고 환경설정을 할 겁니다.

http://docs.datastax.com/en/playlist/doc/java/playlistSettingUp.html

그 전에 필요한 소프트웨어들이 미리 설치돼 있어야 합니다.

Required software 

The following software is required to build and run the Playlist tutorial example application:

• A Linux or OS X machine
• JDK 7 or later
• Apache Maven 3 or later
• Git 2.3 or later
• DataStax Enterprise 4.7 or later, or Cassandra 2.1 or later
• The playlist example code
• A code editor of your choice

저는 제 맥북에 설치해 보려고 합니다.

카산드라 설치하기

1. Download here

2. 다운로드 받은 dmg 파일을 더블 클릭한 후 아래 가이드 대로 진행한다.

설치가 끝나면 바탕화면에 DataStax Enterprise shortcut 이 생깁니다.

이 shortcut 안으로 들어가면 start_cassandra , start_datastax_agent 를 포함해 여러가지 실행 파일들이 있습니다.

이렇게 하면 간단하게 카산드라 설치가 끝납니다.

터미널을 실행해서 카산드라가 설치된 폴더로 이동합니다.

숏컷을 실행하면 해당 폴더를 알 수 있습니다.

그 폴더에서 bin 폴더 안으로 들어갑니다.

그곳에서 아래와 같이 명령어를 칩니다.

(그 전에 숏컷에서 start_datastax_agent 를 실행해야 합니다.)

./nodetool status

그러면 아래와 같은 화면을 보실 수 있습니다.

이렇게 되면 DataStax Enterprise 이 실행중 이라는 얘기입니다.

이제 Playlist example code 를 받으려면 아래와 같이 받습니다.

$ git clone https://github.com/DataStaxDocs/playlist.git

그 다음 example application's dependencies 를 다운받으려면 메이븐을 사용해야 하는데 제 컴에 아직 메이븐을 설치하지 않아서 안 되네요.

$ cd playlist
$ mvn verify

이 부분은 메이븐을 설치한 다음에 시도해 봐야겠습니다.