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

오늘은 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 };