반응형
블로그 이미지
개발자로서 현장에서 일하면서 새로 접하는 기술들이나 알게된 정보 등을 정리하기 위한 블로그입니다. 운 좋게 미국에서 큰 회사들의 프로젝트에서 컬설턴트로 일하고 있어서 새로운 기술들을 접할 기회가 많이 있습니다. 미국의 IT 프로젝트에서 사용되는 툴들에 대해 많은 분들과 정보를 공유하고 싶습니다.
솔웅

최근에 올라온 글

최근에 달린 댓글

최근에 받은 트랙백

글 보관함

카테고리


반응형

Minnesota Twins 에서 매년 개최하는 TwinsFest 가 1월 29~31 일, 3일동안 타겟필드에서 개최되는데 여기에 박병호 선수도 참가할 예정입니다.





행사 안내 홈페이지에 가 보니까 박병호 선수도 3일 내내 현장에 있을 예정인가 봅니다.

별일 없으면 저도 행사에 가서 박병호 선수를 응원해야 겠네요.




TwinsFest Jan. 29-31 at Target Field

Over 60 former, current and future players to attend



MINNEAPOLIS -- The Twins will host TwinsFest at Target Field for a third straight year, as the event will be held from Jan. 29-31, the club announced Thursday.

Twins 는 3년째 타겟필드에서 TwinFest를 개최한다. 이 행사는 1월 29~31일 동안 개최된다고 11월 10일 발표했다.

TwinsFest, which was created in 1989 and formerly held at the Metrodome, moved to Target Field in 2014. It's the largest fundraiser for the Twins Community Fund, and is set to feature more than 60 former, current and future Twins players.

TwinsFest는 1989년에 처음 개최됐으며 이전에는 Metrodome에서 행사가 치러졌고 2014년도에 Target Field로 장소가 옮겨졌다. 이 행사는 Twins Community Fund 의 가장 큰 fundraiser 이고 60여명의 전직, 현직 그리고 미래의 Twins 선수들이 참가한다.

"We're excited to again host TwinsFest at Target Field, the capital of Twins Territory," Twins president Dave St. Peter said. "As always, TwinsFest will serve as the unofficial start to a new baseball season while also helping raise significant proceeds for the Twins Community Fund and its many worthwhile programs across Twins Territory."

"우리는 다시 Twins 연고지의 핵심인 Target Field에서 이 행사를 개최하게 돼 아주 기쁩니다. 늘 그랬던 것처럼 TwinsFest는 새로운 야구 시즌의 비공식 시작으로서 Twins Community Fund를 위한 후원행사와 Twins 지역에 걸친 여러 가지 프로그램들이 진행됩니다." 라고 Twins 의 President 인 Dave St. Peter 가 말했다.

Tickets for the event go on sale to the general public on Dec. 8 at 10 a.m. CT and will be available online at twinsbaseball.com. Tickets are $20 for adults and $10 for children 14 and younger. Ticket sales are capped to avoid overcrowding.

이 행사에 참가할 수 있는 티켓은 12월 8일 오전 10시에 일반에 판매되며 twinsbaseball.com 에서 온라인으로 구매 가능하다. 티켓은 성인은 20불이고 14세 이하 어린이는 10불이다. 티켓 판매는 혼잡을 피하기 위해 정해진 방법으로만 판매된다.

Similar to the past two years, there will be player autographs, photo opportunities, sports memorabilia and a collector's show. But there's also plenty of other ways to interact with the players, including through boardwalk-style games and question-and-answer panels. New additions this season include Twins Jeopardy, human foosball and giant Jenga.

지난 2년간 이 행사에서 해왔듯이, 선수 싸인회와 선수와 같이 사진 찍기, 스포츠 기념품과 수집품 전시 등이 진행될 예정이다. 이 외에도 boardwalk-style games 이나 질문 답변 Panels 등 선수들과 같이 할 수 있는 다른 많은 이벤트들이 마련돼 있다. 이번 시즌에 새로 선보이는 행사는 Twins Jeopardy, human foosball and giant Jenga 등이 있다.

The Twins also offer self-guided clubhouse tours, the chance to hit in the batting cages and a guided tour of the Twins Archive Room. The annual yard sale also returns with fans able to buy Twins gear and memorabilia at discounted prices.

Twins 는 sulf-guided 클럽하우스 투어도 제공해 batting cage 안에서 공을 칠 수 있는 기회를 제공하고 Twins Archive Room 으로 tour를 guide 한다. yard sale도 개최 하는데 팬들은 Twins 유니폼과 기념품들을 할인 된 가격에 구입할 수 있다.

TwinsFest is one of the biggest team-run fan festivals in sports and has raised $4.3 million for the Twins Community Fund over the past 25 years.

TwinsFest는 구단에서 운영하는 팬들을 위한 가장 큰 행사로 지난 25년간 4천 3백만달러의 Twins Community Fund를 모금했다.




반응형


반응형

Composite Partition Key



composite partition key를 가지고 있는 테이블에 대해 카산드라는 partition key로 여러개의 컬럼을 사용한다. 이 컬럼들은 retrieval (검색)을 용이하게 하기 위해 partition 안에 logical set들을 구성한다. simple partition key와는 다르게 composite partition key는 어디에 데이터가 자리잡을지를 정하기 위해 두개 이상의 컬럼들을 사용한다. Composite partition key들은 single partition에 들어가기엔 데이터가 너무 클 경우 사용된다. partition key에 대해 한개 이상의 컬럼을 사용하는 것은 데이터를 chunks 나 bucket들로 파편화하게 된다. 이 데이터는 group 화 되어 있지만 더 작은 chunk들로 구성되게 된다. 이 방법은 Cassandra cluster 가 hotspotting 이거나 하나의 node에 집중적이고 반복적으로 데이터를 write 하는 경우에 유용하게 사용할 수 있다. 왜냐하면 이 경우 하나의 partition에 아주 집중적으로 writing이 이뤄질 것이기 때문이다. Cassandra는 종종 time series data를 사용하는 경우가 있고 hotspotting 이 문제화 될 수 있다. 입력되는 데이터를 bucket들에 파편화 할 때 년:월:일:시 이 4개의 컬럼을 기반으로 나뉘어지게 되는데 이럼으로서 partition에 hotspot을 줄일 수 있게 됩니다.

데이터는 partition key를 사용해서 검색 (retrieve) 하게 됩니다. 테이블에서 데이터를 검색하기 위해서는 모든 컬럼들의 값들이 partition key안에 정의 되어 있어야 합니다. (만약 secondary index 가 사용되지 않을 경우). 아래 race_year, race_name 테이블은 composition partition key로 된 primary key 안에 있습니다. 데이터를 검색하기 위해서는 두 파라미터 모두가 identify 되어야 합니다.




Composit partition key를 가지고 있는 테이블을 생성하려면 아래와 같이 하면 된다.

    CREATE TABLE 구문의 마지막에 쉼표를 넣고 PRIMARY KEY 라는 키워드를 입력한다. 그리고 그 다음에 partition key 의 컬럼 이름을 넣는다. Composite partition key인 컬럼 이름은 double parentheses(이중 괄호) 안에 넣습니다.

카산드라는 데이터의 전체 row를 partition key 에 따라서 node 에 저장합니다. 만약 하나의 partition에 너무 많은 데이터가 있다면 그리고 그 데이터들을 여러개의 노드들에 분산시키기를 원한다면 composite partition key를 사용합니다.



Using a composite partition key

쿼리를 실행시킬 때 결과를 정렬 시켜야 되는 컬럼이 있다면 이 컬럼을 만들 때 primary key 안에 이 composite partition key를 사용하세요. 아래 예제는  rank_by_year_and_name 이라는 테이블을 만듭니다. 여기에는 레이스에서 이긴 사이클 선수의 순위와 이름이 저장될 겁니다. 이 테이블은 primary key의 composition partition key 로 정의된 컬럼으로 race_year 와 race_name을 사용하고 있습니다. 쿼리는 year와 race name 값을 사용해서 레이스에서 우승한 사이클 선수의 순위를 알아내는데 사용됩니다.

composite partition key 테이블은 아래와 같이 두가지 방법으로 생성할 수 있습니다.



Procedure

    * cycling 키스페이스에 rank_by_year_and_name 이라는 테이블을 생성합니다. composite partition key 로 race_year 와 race_name을 사용합니다. 이 테이블에는 primary key로 사용하는 컬럼인 rank 가 있습니다. 테이블을 만들기 전에, USE 구문을 사용해서 해당 키스페이스로 들어가세요. 이 예제에는 맨 마지막에 primary key 를 정의 합니다. PRIMARY KEY 에서 이중괄호를 사용한 것을 기억하시기 바랍니다.

    cqlsh> USE cycling;
    CREATE TABLE rank_by_year_and_name (
    race_year int,
    race_name text,
    cyclist_name text,
    rank int,
    PRIMARY KEY ((race_year, race_name), rank)
    );




  

USE 구문을 생성해서 해당 키스페이스 안에 들어가는것 대신에 CREATE TABLE 구문에서 키스페이스 이름을 사용함으로서 해당 키스페이스에 테이블을 만들 수 있습니다.

    cqlsh> CREATE TABLE cycling.rank_by_year_and_name (
    race_year int,
    race_name text,
    cyclist_name text,
    rank int,
    PRIMARY KEY ((race_year, race_name), rank)
    );



Compound Primary Key



compound primary key를 가지고 있는 테이블을 만들려면 simple 이나 composite partition key를 사용합니다. 거기에 추가로 clustering 컬럼들을 정의하게 됩니다. Clustering 은 clustering 컬럼들을 정의한 것에 근거해 각 partition 안에 데이터들을 정렬하는 storage engine process 입니다. 대개 컬럼들은 알파벳 오름차순으로 정렬 됩니다. 일반적으로 데이터들의 different grouping은 simplistic choice 보다 더 좋은 read 와 write 결과를 가져오게 됩니다.

데이터는 Cassandra cluster 전체에 걸쳐 distributed 된다는 것을 기억해 두세요. 만약 적은 데이터를 얻기 위해 전체 partition을 read 해야만 한다면 어플리케이션은 large partition으로부터 데이터를 검색해야 하는 부담을 갖게 될 것입니다. physical node 에서 partition key 에 대한 row들이 clustering column들에 근거해 정렬돼 저장됐다면 row들을 검색하는게 아주 효율적일 겁니다. clustering column을 사용하는 테이블내에서 데이터를 그룹핑하는 것은 관계형 데이터베이스의 JOIN 과 비슷하면서 오직 한개의 테이블만 사용하게 됨으로서 훨씬 좋은 performance를 보여줍니다. 이 테이블은 partition key로서 category를 사용하고 clustering column으로서 points를 사용합니다. 각각의 category에 대해 point들은 내림차순으로 정렬된다는 것을 기억해 두세요.



partition으로부터 데이터를 검색하는 것은 clustering column들과 함께 다용도로 사용됩니다. 위 예제를 예로 들면 one-day-races 에 대해 200보다 큰 point 값들을 검색할수 있습니다.

compound primary key를 가지고 있는 테이블을 생성하려면 아래와 같이 합니다.

    * CREATE TABLE 구문의 마지막 컬럼 다음에 PRIMARY KEY 키워드를 넣고 그 키의 column 이름을 넣습니다. 그 컬럼 이름은 괄호로 감싸게 됩니다.



Using a compound primary key

정렬된 결과를 받는 쿼리를 사용할 컬럼을 생성할 때 compound primary key를 사용합니다. 만약 pro cycling 예제가 관계형 데이터베이스용으로 디자인 된다면 races 테이블에 대해 cyclists 테이블에 foreign key를 만들에 서로 관계를 맺게 할 겁니다. 카산드라에서는 이 데이터를 denormalize 하게 됩니다. 왜냐하면 distributed system 에서는 JOIN 은 그렇게 좋은 퍼포먼스를 보여주지 못하기 때문입니다. 이후에 카산드라에서 퍼포먼스를 향상시키기 위해 사용하는 다른 schema를 보게 될 겁니다. Collections와 indexes 는 두개의 데이터 모델링 방법입니다. 아래 예제는 각 race category 에 대해 사이클 선수의 성과 ID, points 가 저장되는 cyclist_category 테이블을 생성합니다. 이 테이블은 partition key로 category를 사용하고 single clustering column으로는 points를 사용합니다. 이 테이블은 points로 정렬된 결과를 검색할 수 있습니다. 검색 내용은 하나의 카테고리 안에 사이클 선수와 그들의 points 리스트가 될 겁니다.

compound primary key 테이블은 아래와 같이 두가지 방법으로 생성할 수 있습니다.



Procedure

    * Compound primary key 를 가지고 있는 table을 만들려면 두개 이상의 primary key를 사용합니다. 이 예제에서는 points에 대해 내림차순으로 보기 위해 WITH CLUSTERING ORDER BY라는 추가적인 절을 사용하고 있습니다. 오름차순이 저장하기에는 좀 더 효율적입니다. 하지만 storage engine의 특성상 내림차순이 더 빠릅니다.

    cqlsh> USE cycling;
    CREATE TABLE cyclist_category (
    category text,
    points int,
    id UUID,
    lastname text,    
    PRIMARY KEY (category, points)
    ) WITH CLUSTERING ORDER BY (points DESC);





    USE 구문을 사용해서 해당 키스페이스 안에 들어가지 않고 테이블을 만들려면 keyspace 이름을 아래와 같이 명시해 주면 됩니다.

    cqlsh> CREATE TABLE cycling.cyclist_category (
    category text,
    points int,
    id UUID,
    lastname text,    
    PRIMARY KEY (category, points)
    ) WITH CLUSTERING ORDER BY (points DESC);

    Note: category와 points의 조합은 cyclist_category 테이블내에서 row를 구별해 주는 unique 한 구분 방법입니다. 같은 category에 대해 한개 이상의 row들이 존재할 수 있는데 이 경우 row들은 다른 points 값을 가지고 있는 경우 일 겁니다. 위 예제를 다시 보세요. 이 데이터를 저장하기 위한 최적화 된 데이터 모델링 인가요? 어떤 condition들이 에러를 유발할 수 있을 까요?



Creating a counter table



Counter는 여러 데이터 모델들에 유용합니다. 예를 들어, 어느 회사에서 회사 홈페이지의 웹페이지 뷰 숫자를 하는 경우 혹은 Scorekeeping 어플리케이션은 온라인으로 현재 게임하는 유저의 숫자를 저장하거나 게임에 접속한 유저의 숫자를 저장하기 위해 counter를 사용할 수 있을 겁니다. 아래 테이블은 id를 primary key로 하고 counter 테이블의 popularity필드에 thumbs up/down 에 근거한 cyclist의 popularity 를 관리하는데 counter 가 사용됨을 보여 줍니다.



distributed database의 Tracking count를 살펴보는 건 흥미로운 일입니다. 카산드라에서는 counter value는 Memtable 안에 위치할 것입니다. 그리고 특정 시기에 한개 이상의 SSTable에 commit 하게 됩니다. 노드들 사이에서 replication (응답) 하는 것은 특정 상황에서 consistency 문제를 야기시킬 수 있습니다. 카산드라의 counter는 counter의 기능을 개선하기 위해 Cassandra 2.1 에서 redesign 됐습니다.다. 그 내용을 자세히 보려면 "What’s New in Cassandra 2.1: Better Implementation of Counters" 를 보세요.

counter는 증가되는 숫자를 저장하기 위한 특별한 column 입니다. counter는 integer 값을 가지면 오름차순/내림차순으로 사용할 수 있습니다. counter는 다른 컬럼들에서 서로 다르게 구현될 수 있기 때문에 counter 컬럼들은 dedicated table에서만 정의 될 수 있습니다.

카산드라 2.1 이상에서는 cassandra.yaml 파일에 여러 counter-related setting을 configure 할 수 있습니다.


Note : 카산드라 2.0.x 에서 사용한 replicate_on_write 테이블 프로퍼티는 카산드라 2.1 에서는 사용하지 않습니다.

counter 컬럼은 index 되거나 delete 될 수 없습니다. counter 컬럼에 데이터를 로드하기 위해서는 혹은 counter의 값을 증가/감소 시키기 위해서는 UPDATE command를 사용합니다. Cassandra는 counter 컬럼을 업데이트 할 때 USING TIMESTAMP 나 USING TTL 은 reject 합니다.

counter 컬럼을 가지고 있는 테이블을 생성하기 위해서는 이렇게 하면 됩니다.

    * counter 와 non-counter 컬럼들을 정의하기 위한 CREATE TABLE을 사용하는데 PRIMARY KEY 정의 하는 일 부분으로 non-counter column들을 사용합니다.




Using a counter

counter 컬럼에 데이터를 로드하기 위해서 혹은 counter 값을 증가/감소시키기 위해서는 UPDATE 명령어를 사용합니다. Cassandra는 counter 컬럼을 업데이트 할 때 USING TIMESTAMP 나 USING TTL 은 reject 합니다.



Procedure

    * counter column을 갖는 테이블 생성.

    cqlsh> USE cycling;
    CREATE TABLE popular_count (
      id UUID PRIMARY KEY,
      popularity counter
      );





    * counter column에 데이터를 로딩하는 방법은 다른 테이블과 좀 다릅니다. 해당 데이터는 insert 되는 것이 아니라 update 된다.

    UPDATE cycling.popular_count
     SET popularity = popularity + 1
     WHERE id = 6ab09bec-e68e-48d9-a5f8-97e6fb4c9b47;

    * counter value를 잘 살펴보세요. popularity 가 1의 값을 가지고 있는 부분을 잘 보세요.


    SELECT * FROM cycling.popular_count;





    * 추가적인 증가/감소는 counter column의 value를 바꿀 겁니다.




Create table with COMPACT STORAGE

테이블을 생성하면서 compound primary key를 할 때 저장된 모든 데이터에 대해 그것과 함께 column 이름이 저장될 필요가 있습니다. 디스크에 하나의 컬럼으로서 각 컬럼에 대응하는 저장된 각각의 non-primary key 컬럼 대신에 디스크에 전체 row를 한개의 컬럼에 저장합니다. 디스크 공간을 절약해야 할 경우 WITH COMPACT STORAGE를 사용합니다. 그러면 legacy (Thrift) storage engine format 으로 데이터를 저장합니다.

CREATE TABLE sblocks (
  block_id uuid,
  subblock_id uuid,
  data blob,
  PRIMARY KEY (block_id, subblock_id)
)
WITH COMPACT STORAGE;





Compact storage 를 사용하면 compount primary key가 아닌 한개 이상의 컬럼을 정의해야 되는것을 막아 줍니다. compact 되지 않은 primary key를 사용하는 compact table은 primary key 가 아닌 여러개의 컬럼들을 가질 수 있습니다.

compound primary key를 사용하는 compact table은 적어도 한개 이상의 clustering 컬럼을 정의 해야만 합니다. compact table이 생성되고 나면 컬럼들은 추가되거나 제거될 수 없습니다. WITH COMPACT STORAGE 를 사용하지 않으면 CQL은 non-compact storage로 테이블을 생성합니다.

Collection과 static 컬럼들은 COMPACT STORAGE tables 에 사용될 수 없습니다.



Table schema collision fix

Dynamic schema 생성이나 update는 에러를 유발하는 schema collision 을 발생 시킬 수 있습니다.

Procedure

    1. schema match를 위해 모든 노드에서 전체적으로 재 시작을 합니다. 모든 노드가 있는 클러스터에서 nodetool을 실행합니다. 그리고 한개의 schema 버전이 있는지 확인합니다.

    2.각 노드에서 - data directory 를 체크 한다. - 질문에 해당하는 테이블에 대한 두개의 디렉토리를 찾는다. 만약 한개의 디렉토리만 있다면 다음 노드로 이동한다. 만약에 그 노드에 두개 이상의 디렉토리가 있다면 오래된 테이블 디렉토리는 업데이트 이전것이고 새것은 update 이후를 위한 것이다. 다음으로 간다.

    $ cqlsh -e "SELECT * FROM system.schema_column_families" |grep <tablename>

    3. 어떤 cf_id (column family ID) 가 system.schema_columnfamilies 의 최신 테이블 ID 인지 찾는다. 이 column family ID는 결과의 5번째 컬럼이다.
   
    Move the data from the older table to the newer table's directory and remove the old directory. Repeat this step as necessary.
    4. 이전 테이블의 데이터를 최근 테이블의 디렉토리로 옮기고 이전 디렉토리는 지운다. 이 작업을 다른 노드들에서도 계속 반복한다.

    5. nodetool refresh 를 실행한다.

반응형


반응형

Creating a table


CQL 에서는 SQL 과 마찬가지로 컬럼의 row들을 가지고 있는 테이블들에 데이터가 저장된다.

Note: 카산드라 내부에서 구현되는 row와 column (행과 열) 들은 SQL 과 똑같지 않다. 좀 더 자세한 내용은 A thrift to CQL3 upgrade guide or CQL3 for Cassandra experts 를 보세요.

테이블은 runtime 시 업데이트나 쿼리를 block 하지 않으면서 create, drop, alter 될 수 있다. 테이블을 생성할 때 primary key와 컬럼들을 테이블 property들과 함께 정의한다. 테이블 프로퍼티를 configure 하기 위해서는 optional로 WITH clause와 keyword argument들을 사용한다. "caching, compaction, and other operations" 테이블 프로퍼티들은 테이블 세팅처럼 테이블별로 특정된다.


Create schema using cqlsh

cqlsh 를 사용해서 테이블 스키마를 생성한다. Dynamic 하게 schema를 생성 하는것은 지원되지 않는다. 만약 여러 client들이 동시에 테이블을 generate 하기 위한 시도가 있을 경우 collision 이 생길 수도 있다. 만약 이렇게 collision이 일어날 경우 해결하는 방법은 schema collision fix instructions를 보면 나와있다.

Primary Key

primary key는 data storagy은 순서와 위치를 지정한다. 이 primary key는 테이블이 생성될 때 정의되고 alter 되지 않는다. 만약 primary key 의 변경이 필요하면 새로운 table schema를 생성하고 그 새로운 테이블에 데이터를 입력해야 한다. 카산드라는 어떤 node가 특정 테이블 row를 hold 할 것인가를 식별하는 partition row store, partition key, primary key 의 component 이다. 테이블 생성 이후에 그 테이블을 alter 하는 자세한 방법은 ALTER TABLE 을 보라.

프라이머리 키는 반드시 partition key를 가져야 한다. Composite partition key는 data set을 split 할 수 있다. 그래서 관련된 데이터가 각각의 partition들에 분산되서 저장된다. Compound primary key는 partition에 data를 order 한 clustering column을 포함한다.

테이블의 primary key를 정의하는 것은 카산드라에서는 아주 중요한 부분이다. 어떤 컬럼이 primary key 가 될 것인지 정의하기 이전에 데이터가 테이블에 어떻게 insert되고 retrive 될 것인지를 충분히 고려한 후 모델링을 해야 한다. 클러스터의 노드들 사이에서의 partition들의 size, partition안의 데이터의 순서, partition들의 distribution 이런 것들은 테이블에 대한 베스트 primary key를 결정하기 위해 고려되어야 할 사항들이다.


Table characteristics


테이블 이름으로는 알파벳 문자로 이뤄진 string과 밑줄 (맨처음은 안 됨)을 사용할 수 있다. 테이블 이름을 정할 때

    다른 keyspace에 테이블을 생성할 경우.  keyspace 이름과 table 이름을 구분하기 위해 . (점)을 사용한다. 이렇게 하면 다른 키스페이스에 있더라도 원하는 키스페이스에 해당 테이블을 생성할 수 있다.
    현재 위치한 키스페이스를 사용할 경우. 테이블 이름만 명시하면 된다.

Column characteristics

컬럼은 CQL table의 중요한 component 이다. 테이블 스키마를 디자인하는데 유연성을 주기위해 여러개의 컬럼 타입들이 존재한다. 테이블 내의 각각의 컬럼은 테이블을 생성할 때 데이터 타입을 할당하게 된다. 컬럼 타입들은 collection-type 컬럼을 제외하고는 괄호를 사용해서 표시하고 컬럼이름과 type 의 쌍은 쉼표로 구분된다. 다음 예제는 UUID, text 그리고 timestamp 등 세개의 데이터 타입을 사용한다.

CREATE TABLE cycling.cyclist_alt_stats ( id UUID PRIMARY KEY, lastname text, birthday timestamp, nationality text, weight text, height text );





Collection column 타입은 map, set, list를 지원한다. 이 컬렉션 컬럼은 collection type을 사용해서 정의되고 그 다음에 꺽쇠 괄호 안에 int나 text 등의 다른 타입이 온다. 다음 예제는 각 collection type을 지정한다. 하지만 실제 쿼리를 위해 디자인 하는 것은 아니다.

CREATE TABLE cycling.whimsey ( id UUID PRIMARY KEY, lastname text, cyclist_teams set<text>, events list<text>, teams map<int,text> );





현재로서는 Collection type은 nest 될 수 없다. (collection 안의 또 다른 collection은 불가능하다.) Collection은 frozen data type을 포함할 수 있습니다. 그 사용예와 사용법을 보시려면  Collection type 을 보세요.
컬럼 타입인 tuple 데이터 타입은 입력된 positional field의 고정된 length 값을 가진다. tuple을 사용저 정의 타입의 대안으로 사용한다. tuple은 많은 field (32768)들을 가질 수 있다. 대개 tuple은 적은 수의 field로 생성한다. tuple은 대개 2~5 개 필드들에 사용된다. 테이블에 tuple을 생성하려면 꺽쇠 괄호를 사용한다. 그리고 tuple component type을 정의하기 위해 쉼표로 구분한다. Tuple은 nest 될 수 있다. (Tuple 안에 또 다른 Tuple을 만들 수 있다.) 다음 예제는 text 필드로 구성되고 또 그 안에 두개의 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));





Note : 카산드라 2.1.0 에서 2.1.2 까지는 tuple을 위해 frozen을 사용해야 한다. 2.1.3 이상의 버전에서는 이 keyword가 꼭 필요하지는 않다.

frozen <tuple <int, tuple<text, double>>>

좀 더 자세한 정보는 "Tuple type" 을 보세요.

사용자 정의 타입 (UDTs)은 여러 필드들의 데이터 타입이 CREATE TYPE 을 사용해 생성할 때 컬럼 타입으로 사용될 수 있다. UDT는 여러 테이블 정의에서 사용되어질 컬럼 타입일 경우 사용된다. 사용자 정의 컬럼 타입은 frozen 키워드를 사용한다. frozen 은 여러 컴포넌트들을 하나의 value로 serializes 한다. Non-frozen type은 개별적인 필드에 대해 update할 수 있도록 한다. 카산드라는 frozen type의 value를 blob로 처리한다. keyspace의 scope : 키스페이스 이름 다음에 점을 찍고 타입의 이름을 사용한다. 이렇게 하면 (점을 사용하면) 카산드라는 해당 키스페이스의 타입에 접근하면서도 현재의 키스페이스를 바꾸지는 않는다. 다른 방법으로 키스페이스를 특정 하지 않으면 카산드라는 현재의 키스페이스 내에서 작업할 것이다. 자세한 사항은 "Using a user-defined type" 를 보라.

counter는 점차 증가하는 숫자를 저장하는데 사용되는 특별한 컬럼이다. countercounter data type 컬럼을 포함하고 있는 dedicated table에만 사용될 수 있다.



Using the keyspace qualifier

가끔 키스페이스를 선택하기 위해 USE 구문을 사용하는 것이 불편할 때가 있다. Connection pooling 은 여러개의 키스페이스를 관리해야 한다. 여러 키스페이스를 tracking 하는 것을 간편화하기 위해 USE 구문 대신에 keyspace  qualifier 를 사용한다. 이 statement들에 keyspace qualifier를 사용해서 키스페이스를 특정할 수 있다.

    ALTER TABLE
    CREATE TABLE
    DELETE
    INSERT
    SELECT
    TRUNCATE
    UPDATE

Procedure


사용할 키스페이스에 있지 않으면서 그 키스페이스 내의 테이블을 특정하려면 그 키스페이스 이름을 적고 그 다음에 점을 찍고 그리고 테이블 이름을 명시한다.
예를 들어 cycling.race_winners 이렇게 하면 cycling 키스페이스 안의 race_winners 테이블을 명시하는 것이다.

cqlsh> INSERT INTO cycling.race_winners ( race_name, race_position, cyclist_name ) VALUES (
  'National Championships South Africa WJ-ITT (CN)',
  1,
  {firstname:'Frances',lastname:'DU TOUT'}
);


Simple Primary Key

간단한 프라이머리 키를 가지고 있는 테이블에 대해 카산드라는 partition key로서 한개의 column name을 사용한다. 이 primary key는 이 경우 오직 한개의 partition key만을 갖게 되는 것이다. 만약 많은 양의 데이터가 사용되고 -프라이머리 키가 정의된 컬럼에 대해 적은 value만이 insert 되는 경우- 그 partition은 더 커지게 된다. Large partition은 read request에 대해 반응 속도가 느리거나 노드의 할당된 디스크공간에 대해 너무 크게 증가할 것이다. 다른 한편으로는 간단한 프라이머리 키에 저장된 데이터는 insert 와 retrieve시 속도가 빠를 것이다. 만약 해당 컬럼에 대해 많은 value들이 여러 노드에 걸쳐 partition들이 distribute 될 경우 더 효과적일 것이다.

가끔 카산드라를 사용할 때 부딪히는 첫번째 어려움에는 simple primary key를 가지고 있는 테이블과 관련된 일도 포함된다. 오직 해당 primary key만이 테이블에서 데이터를 retrieve 할 때 명시되어야 한다는 것을 명심하라. (secondary index가 사용되지 않을 경우.) 많은 production table들이 simple primary key 같은 unique identifier 들을 사용한다. 이런 identifier를 살펴보고 테이블의 나머지 데이터를 retrive 하라. 만약 어플리케이션이 simple lookup table이 필요하면 simple primary key를 사용하라. 그 테이블은 primary key로 id를 사용할 것이다.



To create a table having a single primary key, two methods can be used:
single primary key를 가지고 있는 테이블을 생성할 때 두가지 방법을 사용할 수 있다.

   
    CREATE TABLE definition 안의 컬럼 이름 다음에 PRIMARY KEY 라는 키워드를 넣는다.
    CREAET TABLE definition 안의 마지막 컬럼 정의 이후에 PRIMARY KEY 라는 키워드를 넣는다. 그 다음에 그 키의 컬럼 이름을 명시하면 된다. 그 컬럼 이름은 괄호 안에 넣는다.



Using a simple primary key


정렬된 결과를 return 하도록 하는 쿼리에 사용될 컬럼을 생성하기 위해 simple primary key를 사용한다. 이 예제는 ID number 가 저장된 cyclist_name 테이블을 생성한다. 그리고 컬럼들에는 사이클 선수의 이름과 성이 들어간다. 이 테이블은 primary key로 UUID 를 사용한다. 이 테이블은 해당 ID number에 해당하는 사이클 선수의 이름을 찾을 때 사용될 수 있다.


simple primary key 테이블 생성 방법은 다음과 같이 3가지가 있다.

Procedure

    cycling 키스페이스안에 cyclist_name이라는 테이블을 생성한다. primary key로 ID를 사용한다. 이 테이블을 생성하기 이전에 USE 구문으로 해당 키스페이스로 들어간다.

    cqlsh> USE cycling;
    CREATE TABLE cyclist_name ( id UUID PRIMARY KEY, lastname text, firstname text );





    테이블 definition 끝에 primary key 를 지정함으로서 똑같은 결과를 얻을 수 있다.

    cqlsh> USE cycling;
    CREATE TABLE cyclist_name ( id UUID, lastname text, firstname text, PRIMARY KEY (id) );

    USE 구문을 사용하지 않고 키스페이스 이름을 명시함으로서 해당 키스페이스에 테이블을 사용할 수 있다.

    cqlsh> CREATE TABLE cycling.cyclist_name ( id UUID, lastname text, firstname text, PRIMARY KEY (id) );

    Cassandra 2.2 이상 버전에서는 date 나 time data type을 사용할 수 있다.

    CREATE TABLE cycling.birthdays (id UUID PRIMARY KEY, bday date, btime time);



제가 설치한 카산드라에서 이 구문을 실행했더니 위와 같은 에러가 나오네요.


그래서 카산드라 버전을 확인해 봤습니다.


select peer, release_version from system.peers;
select release_version from system.local;




역시나 제가 설치한 카산드라 버전은 2.1.11.969 이네요.


여기까지 테이블 생성 관련해서 Simple Primary Key 까지 공부했습니다.


다음은 테이블 생성이 나머지 부분을 공부해 보겠습니다.

반응형

아파치 카산드라 - CQL 실습 1 keyspace

2015. 12. 21. 08:27 | Posted by 솔웅


반응형


오늘은 keyspace와 관련해서 리스트업 해보고 생성하고 업데이트 하는 것에 대해 공부해 보겠습니다.


Creating and updating a keyspace


CQL에서 keyspace를 생성하는 것은 SQL database를 생성하는 것과 비슷하지만 약간 다르다. Cassandra keyspace는 namespace로서 어떻게 node들에 데이터가 replicate (복제)될 것인가를 정의하는 것이다. 일반적으로 어플리케이션 당 한개의 cluster는 한개의 keyspace 를 가지고 있다. Replication은 keyspace별로 컨트롤 된다. 다른 replication을 가진 데이터는 다른 keyspace에 있어야 한다. 키스페이스는 데이터모델안에서 significant map layer로서 사용되도록 디자인되지 않았다.

키스페이스를 생성할 때, replicating keyspace를 위해 특정 strategy class를 명시해야 한다. SimpleStrategy 클래스는 카산드라를 evaluating할 때 좋다. 실제 프로덕션용이나 mixed workloads들을 위해서는 NetworkTopologyStrategy 클래스를 사용하는 것이 좋다.

NetworkTopologyStrategy를 예를 들어 single node cluster 같은 evaluating 목적으로 사용하기 위해서는 default data center name 이 사용된다. NetworkTopologyStrategy 를 프로덕션용으로 사용할 때에는, default snitch 인 SimpleSnitch를 network-aware snitch (네트워크에서 사용되는 snitch) 로 바꿔야 한다. 한개 이상의 데이터 센트 이름을 snitch property 파일에 정의하고 그 데이터 센터 이름을 keyspace를 정의할 때 사용해야 한다. Snitch 부분을 보세요. 만약 cluster 가 PropertyFileSnitch를 사용한다면 keyspace를 생성할 때 user-defined data center와 rack name을 cassandra-topologies.properties 파일에서 사용한다. 만약 cluster 가 Ec2Snitch를 사용한다면 키스페이스를 EC2 data center 와 rack 이름을 사용해서 생성한다. 만약 cluster가 GoogleCloudSnitch를 사용한다면 키스페이스를 GoogleCloud data center와 rack name을 사용해서 생성한다.

만약 default snitch를 바꾸고 NetworkTopologyStrategy를 사용하는데 실패하면 카산드라는 write request를 수행하지 못할 것이다. (예를 들어 데이터를 테이블에 insert 하는 것 같은...) 그리고 이런 에러 메세지를 log 할 것이다.

Unable to complete request: one or more nodes were unavailable.

데이터 센터 이름을 snitch property 파일에 정의하거나 datacenter1이라는 single data center 를 사용하지 않는 한 NetworkTopologyStrategy 를 사용하는 keyspace 에서는 table 에 데이터를 insert 할 수 없다.




CQL 을 한번 실습해 보겠습니다.

우선 다운 받은 Datastax Enterprise 에서 start_cassandra 를 더블 클릭해서 카산들를 실행합니다.

그리고 커맨드 창을 열어서 cqlsh 를 실행합니다.

그러면 위 화면과 같이 cqlsh 가 실행됩니다.



이제 전체 keyspace가 어떤게 있는지 보겠습니다.

select * from system.schema_keyspaces;


보니까 기본적으로 4개의 키스페이스가 있네요.

첫번째 키스페이스의 구조를 한번 보겠습니다.


desc dse_system;

이러면 해당 키스페이스의 구조를 볼 수 있습니다.



특정 키스페이스를 사용하시려면 이렇게 합니다.

use des_system;


그리고 이 keyspace 에 있는 column family들을 보려면 이렇게 합니다.


select * from system.schema_columnfamilies;


너무 복잡하니까 컬럼패밀리 이름들만 출력해 볼까요?





select columnfamily_name from system.schema_columnfamilies;


그리고 특정 컬럼패밀리의 구조를 보시려면 desc encryped_keys 를 하시면 됩니다.


참고로 use 'keyspace' 를 하지 않은 상태에서 특정 키스페이스 안의 컬럼패밀리들을 보려면 where절을 넣으시면 됩니다.

select columnfamily_name from syste.schema_columnfamilies where keyspace_name = '키스페이스';


desc tables; 라고 하면 현재 키스페이스 내의 테이블들을 보실 수 있습니다.



이제 keyspace를 생성해 보겠습니다.

CREATE KEYSPACE demodb WITH REPLICATION =
 { 'class' : 'NetworkTopologyStrategy', 'datacenter1' : 3 };



생성된 키스페이스를 확인하기 위해 아래 두개의 쿼리를 이용했습니다.


select * from system.schema_keyspaces; , describe keyspaces;


Datastax 의 최신 버전 CQL Tutorial 페이지에서는 cycling 이라는 키스페이스를 생성했네요.

그래서 그 키스페이스도 생성해 보았습니다.


CREATE KEYSPACE IF NOT EXISTS cycling WITH REPLICATION 
= {
'class' : 'NetworkTopologyStrategy', 'datacenter1' : 3 };


use cycling; , desc cycling; 을 해 보았습니다.


이제 이 키스페이스를 업데이트 해 보겠습니다.


Updating the replication factor


replication factor를 증가시키면 카산드라 클러스터에 저장된 keyspace data 의 copy 의

tatal number 가 증가된다. security feature를 사용한다면 default(1) 에서부터

system_auth 키스페이스의 replication factor 를 증가시키는 것이 중요하다.

왜냐하면 node 의 그 유일한 replication이 다운되면 더이상 클러스터에 log를 할 수 없기 때문이다.

system_auth 키스페이스에는 각 데이터 센터별 node 의 갯수 만큼 replication factor를

세팅하는 것이 권장된다.




ALTER KEYSPACE "cycling" WITH REPLICATION

= { 'class' : 'SimpleStrategy', 'replication_factor' : 3 };





반응형


반응형

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 하는 것도 필요하다.





반응형

CQL (Cassandra Query Language)

2015. 12. 18. 23:51 | Posted by 솔웅


반응형

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 기능들


New CQL features include:

Improved CQL features include:

Removed CQL features include:

  • Removal of CQL2
  • Removal of cassandra-cli

Native protocol

The Native Protocol has been updated to version 4, with implications for CQL use in the DataStax drivers.




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 EXISTSIF 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




반응형

내가 안철수에 기대하는 것은.....

2015. 12. 15. 23:19 | Posted by 솔웅


반응형

기사 보기



첫째로 부패에 대해서, 막말이나 갑질에 대해 단호한 분,
두번째로는 이분법적 사고를 가지지 않으신 분, 낡은 진보 청산에서 순혈주의, 폐쇄주의, 온정주의, 우리 편만 봐주는 이중잣대를 가지지 않으신 분이 필요하다
세번째로 합리적이고 개혁적인 보수가 아니라 수구적인 보수 편에 서신 분들이면 곤란하다. 수구 보수적인 편에 서지 않는 분이면 어떤 분과도 함께 손을 잡고 나갈 생각


안철수가 말한 같이 정치를 하고 싶은 사람들이다. (인재 영입 3원칙)

내가 안철수에 대해 가졌던 기대는 보수로 부터도 거리가 멀고 민주로 부터는 더더욱 거리가 먼 새누리당의 수구 세력들로부터 합리적인 보수를 구해내 주는 것이었다.

기본적으로 현재 한국의 양당은 지역주의를 기반으로 나뉘어졌고 새누리는 겉으로만 보수를 내걸었지 실질적으로는 반헌법 수구 세력이 기득권을 잡고 있다.
그리고 보수라고 할 수 있는 사람들은 비겁하게 그 수구 세력들에 꼬랑지 흔들며 밉보이지 않음으로서 자신의 정치생명을 구걸하는 것이 보편화 돼 있다.

반면 민주당은 개혁적인 이미지를 가지고 싶어 하지만 실질적으로는 이 수구 세력에 반대하는 보수들 + 경상도 정권에 반대하는 사람들 + 진보를 추구하는 세력들의 짬뽕이다.
또한 자신이 진보적 입장이라고 생각하는 자들 중에서도 내편 네편 갈라서 내쪽은 옳고 상대편은 그르다는 단순 논리를 전개하는 반 공화적인 행태를 보이는 사람들도 많다. (나는 이것이 반 공화 세력에 대항하다가 그 괴물을 닮아버린 낡은 진보의 구린내로 느껴진다)

내가 안철수에 가졌던 기대는 새누리당 안에 있는 자괴감에 빠진 합리적인 보수들이 수구세력과 결연히 갈러서고 나와서 갈 수 있는 정치적 토대를 만드는 것이었다.
그러면 더불어서 경상도 정권에 반대하기 때문에 들어온 민주당의 보수 세력들도 같이 참여할 수 있을 것이다.

그럼으로서 수구로부터 결별한 보수 세력이 제대로 서야 그에 대응하는 진보세력이 지역주의라는 굴레속에서 더렵혀진 본연의 모습을 제대로 찾을 거라고 믿는다.

그렇기 때문에 나는 정치적인 위치는 진보쪽에 서겠지만 안철수에게 제대로 된 보수 정치 세력을 기대하고 있는 것이다.
이것은 진보세력이 독자적인 힘으로는 지역주의와 수구 이념주의를 헤쳐나올 능력을 못 보여줬기 때문이다.

그래서 나는 안철수가 민주당에 있는 것이 몸에 맞지 않는 옷을 입고 있는 사람을 보는 것 처럼 껄끄러웠다.

내가 보기엔 안철수는 보수에 가장 큰 방점을 찍고 있다.
그렇기 때문에 그는 현장에 없었다. 집회에 참가한 국민들 옆에 그는 없었고 세월호 가족들이 도움을 호소할 때도 그는 없었고 거기에 대해 한마디도 언급한게 없다.

그래서 안철수 주위에 뭔가 진보적인 위치에 있는 사람들이 꼬이는 걸 보고 머뜩치 않아 했다.
기본적으로 그는 보수주의자인데 왜 진보를 내세우는 자들이 꼬이는가..
새정치를 바라는 국민의 여망에 자기 숟가락 얹을려는 꼼수에 지나지 않는다.
오히려 MB 진영 출신이 그 옆에 있는게 훨씬 더 자연스러운 모습니다.

안철수가 두번째로 방점을 찍고 있는 부분은 합리적인 경제 구조에 대한 것으로 보인다.
이 부분은 안철수가 말한 인재 영입 3원칙에는 나오지 않는다.
그 만큼 현재의 한국 정치판이 국민들의 먹고 사는 문제 (경제) 보다는 자기들의 정치적 기득권 싸움에 혈안이 돼 있기 때문이 아닐까 싶다.

하여간 그는 재벌들이 독식함으로서 중소기업들의 다양한 도전과 성공을 가로막는 현재의 재벌 편향적인 경제구조에 반대를 해 왔다.

이 것은 보수 대 진보의 정계개편이 이뤄지면 그 둘이 함께 개혁해 나갈 수 있는 공집합이 될 수 있다고 본다.

내가 판단하는 안철수는 이런 정치/경제 적인 마인드를 가지고 있는 사람이다.
그에게 남북문제 즉 우리 민족이 나아갈 방향 이라던가 세계를 바라보는 정치철학 같은 것은 보이지 않는다.
정치 능력을 봤을 때 그는 그렇게 썩 훌륭한 정치인이 될 기본 토대는 못되는 인물인것 같다.

우선 순위는 진짜 보수대 진보의 정치 프레임을 만듬으로서 반헌법 수구 세력과 전혀 공화적이지 않은 야권 세력에 매달려 있는 정치발전 저해세력들을 아웃사이더로 만드는 일일 것이다.

거기에 있어서 안철수는 아직 중요한 역할을 해 낼 가능성이 있다.
나는 거기에 기대를 건다.

이번에 안철수가 말한 인재 영입 3원칙이 나의 그 기대를 앗아갈 만한 내용이 아니라서 오히려 반갑다.

그런데 동시에 내년 총선과 다음 대선을 보면 답답하기도 하다.

아침부터 너무 정치에 시간을 많이 빼앗겼다.
이제 남은 시간은 그런거 잊고 오늘 할 일이나 열심히 해야겠다.

반응형

QA 엔지니어가 하는 일

2015. 12. 12. 11:43 | Posted by 솔웅


반응형

What a QA engineer does
QA 엔지니어가 하는 일



    Write test plans from the requirements, specifications and test strategies
    Use versioning systems to code test scripts
    Create and perform test campaign whenever it is necessary to fit in the overall planning
    Use bug tracking database to report bugs
    Analyses test results
    Reports results to the QA manager
    Raise an alert when an important issue is likely to put in jeopardy the whole project
   


    요구조건, 명세서 그리고 strategy 에 근거해 Test Plan을 만든다.
    test script를 코딩할 때 versioning (형상관리) system (CVS) 을 사용한다.
    전체 계획에 맞게 각 개발 단계마다 테스트 업무를 생성하고 진행한다.
    버그를 보고 하기 위해 버그 tracking database를 사용한다.
    테스트 결과를 분석한다.
    QA manager에게 결과를 보고한다.
    전체 프로젝트에 악영향을 끼칠만한 주요한 문제가 발견 되면 신속하게 보고하고 대처한다.



    What makes a good QA Engineer
무엇이 좋은 QA 엔지니어를 만드는가


Broad understanding of the product
제품에 대한 넓은 이해


To test efficiently a product, the QA engineer must know it well enough. This sounds obvious must unfortunately, this is often under-estimated. Knowing well the product includes also knowing how end-users expect it to work. Again this may sound obvious but remember that the biggest part in testing is black-box testing. The QA engineer must have a "customer-focus" vision.


제품을 효율적으로 테스트하기 위해서 QA엔지니어는 그 제품을 잘 알아야 한다. 당연하게 들릴 지 모르겠지만 불행히도 이 사실이 종종 과소평가된다. 제품을 잘 안다는 뜻은 최종 소비자(일반 사용자)의 기대치를 잘 이해하는 것도 포함된다. 너무나 당연한 얘기이지만 꼭 기억해야 할 것은 테스트 중에 제일 큰 부분이 블랙 박스 시험이라는 것을 기억하라. QA 엔지니어는 "고객에게 맞춘" 시선을 가져야 한다.

  But a good QA engineer must also know how the product is designed because the more you know the product, the better you're able to test it. However, the QA engineer will have to analyse the design only after his black-box testplan is completed. Indeed, knowing the design can widely influence the test strategy. It is better to first write the test plan with a high-level vision, then getting more and more information to refine the testing.


좋은 QA 엔지니어는 제품이 어떻게 디자인 되었는지 알아야 한다 왜냐하면 제품에 대해 더 잘 알수록 그것을 더 잘 테스트 할 수 있기 때문이다. QA 엔지니어는 그의 블랙박스 시험 계획이 완성된 후에 디자인을 분석해야 한다. 실제로, 디자인을 아는 것이 시험 전략에전반적인 영향을 미친다. 높은 레벨의 관점에서 test plan을 먼저 쓴 다음에, testing을 refine 하기 위한 좀 더 많은 정보들을 얻는 것이 좋은 방향이다.



Effective communication
효과적인 커뮤니케이션



Communication is an extremely important skill for a QA engineer. Of course, meetings (stand-up etc.) and status reports are part of the communication but more importantly, a QA engineer must be particularly efficient in the following tasks:

커뮤니케이션은 QA엔지니어에게 너무나도 중요한 기술이다. 당연히, 회의(stand-up 등)나 상황 보고는 커뮤니케이션의 일부인데, 더 중요한 것은 QA 엔제니어는 밑에 적힌 것들에 특히 더 능률적이어야 한다.    

    Direct communication with both Development and Product definition teams
    Capability to communicate with technical and non-technical people
    Having the diplomacy to say "no" when a bug is considered as not fixed
    Having the diplomacy to communicate about a bug without "offensing" the developer. Developers may often feel offensed when a bug is submited. This is 100% natural. This is why the QA engineer must have the ability to "criticize without offensing"
    Do not rely on "bug tracking" database for communication! there is nothing better that a bug tracking system to create "misunderstanding" between Development and QA teams


    개발, 제품 정의 팀과 직접적인 소통
    기술자들과 기술자가 아닌 사람들과 소통하는 능력
    버그(오류)가 고쳐지지 않은 것으로 간주될 때 "안된다(고쳐지지않았다)"라고 말할 수 있는 외교능력
    버그에 대해 이야기 할 때 개발자를 공격하지 않고 소통하는 외교능력.
    오류가 발견되었을 때 개발자들은 기분이 좋지 않을 수 있다. 이건 100% 자연스러운 일이다. 이것이 바로 QA 엔지니어가 (남을) 깎아내리지 않으면서 비평할 수 있는 능력을 가져야 하는 이유다.
    소통할 때 버그 추적 데이터베이스에 의지하지 마라! 버그 추적 시스템은 개발자와 QA 팀 사이에 오해를 만들기에 더 없이 좋은 시스템이다.



Creativity
창의성



Testing requires a lot of creativity. Bugs are often hidden and just performing the obvious positive tests will have only a few chances to actually find bugs. Hence, the QA engineer must use its creativity to figure out all the scenarios that are likely to detect a bug. In other words, the QA engineer must be able to "see beyond the obvious".


시험은 많은 창의성을 요구한다. 버그는 종종 숨어있을 때가 많고 positive test만을 실행하면 실제로 버그를 찾을 확률은 적어진다. 그러므로, QA 엔지니어는 그들의 창의성을 이용해 버그를 발견할만한 모든 시나리오를 알아내야 한다. 다른 말로 하면, QA 엔지니어는 "see beyond the obvious" 할 줄 알아야 한다.



Development knowledge
개발 지식



Quality Assurance requires knowledge about software development for two basic reasons:

품질 보증은 두가지 이유로 소프트웨어 개발에 대한 지식을 요구한다.    

    Development capabilities are required to eventually code automated tests
    If you know how to develop, you have better ideas on what is "dangerous" to code, so what to test more thoroughly


    automated tests를 코딩할 때 개발 능력이 필요하다.
    개발할 줄 알면, 코드화할 때 무엇이 위험한지를 좀 더 잘 이해할 수 있다. 그래서 무엇을 더 철저하게 테스트 해야하는지 알 수 있다.




Driving for results
결과를 위해 노력하기



A good QA engineer never forgets that the ultimate goal is not only to find bugs but also have them fixed. Once a bug has been found and has been "acknowledged" by the development team, the QA engineer may be required to "convince" people to fix it.


좋은 QA 엔지니어는 최후 목적이 버그를 찾는 것만이 아니라 그것을 고칠 때 까지 관리해야 하는 것이다. 버그가 발견되어 개발팀이 알려주면, QA 엔지니어는 사람들에게 그것은 고쳐야 되는 것이라는 것을 계속 고지시켜야 한다.

     Additionally, getting a nice automation framework with smart tools does not bring anything if it does not find any bug at the end.


또한, 아무리 좋은 툴이 겸비된 자동화 프레임워크이라도 그것이 버그를 찾을 수 없다면 아무 의미가 없다.

    Ask yourself if the automation is going to help to find more bugs and when
    Prioritize your testing tasks on the only important criteria
        How many bugs is this likely going to find?
        How major will be the found bugs (detecting thousands of cosmetic bugs is irrelevant/useless - and often easy - until all major/show-stopper bugs have been found)?


    자신에게 이 자동화(自動化)가 더 많은 버그를 찾는데 도움이 될것인지 물어보라. (언제발견될지도)
    당신의 testing 세부 task 들을 중요한 분야별로 나누어 우선순위를 정하라
        이것이 얼마나 많은 버그를 찾을 것인가?
        발견된 버그가 얼마나 중대한(큰) 것인지(자잘한 버그를 수천개 찾는 것보다 크고(중요하고) 시급한 버그를 찾는 것이 더 의미 있다)

반응형

Key concepts and data model

2015. 12. 11. 11:29 | Posted by 솔웅


반응형

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


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


   
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 할 수 있도록 해 준다.
   

   

반응형

Install Cassandra 2 - Maven 설치하기

2015. 12. 10. 10:51 | Posted by 솔웅


반응형

어제 설치하지 못한 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 들을 다운 받을 겁니다.




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

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

반응형
이전 1 2 다음