Tag Archives: Cassandra

[NoSQL] Cassandra + CodeIgniter + PHPCassa 간단하게 연동해 보기

사용자 삽입 이미지사용자 삽입 이미지
PHP에서 간단한 프로젝트를 생성하는데 도움이 되는 프레임워크로 CodeIgniter(코드이그나이터)가 괜찮은것 같습니다. PHP와 카산드라가 통신하기 위해서는 thrift를 시용해야 하는데요 [이글]에 관련된 설치에 대해 적어두었습니다. 이제 간단하게 연동하는 방법에 대해 적어보도록 하겠습니다.

1. Cassandra 설치하기

[이글]에 관련된 글을 적어두었습니다. 리눅스 기반이긴 하지만 윈도우라고 해서 크게 다르진 않을것이라 생각합니다.

2. CodeIgniter 설치하기

http://codeigniter.com/ 에 방문하여 CodeIgniter의 최신 소스를 다운받아 서버에 업로드하여 적당한 위치에 압축을 풀어주도록 합니다. 이후에 application/config/config.php파일을 수정하여 줍니다.
[code php]// 원하는 프로젝트의 루트 디렉토리 URL을 적어줍니다. 끝에 꼭 /를 붙입니다.
$config[‘base_url’] = ‘http://theeye.pe.kr/codeigniter/’;

// mode_rewrite를 사용하기 위해 기본값을 제거합니다
$config[‘index_page’] = ”;[/code]
프로젝트의 루트디렉토리에 .htaccess파일을 생성합니다.
[code]RewriteEngine on
RewriteCond $1 !^(index\.php|images|robots\.txt)
RewriteRule ^(.*)$ /index.php/$1 [L][/code]

3. PHPCassa 설치하기

[이글]을 참고하셔서 PHPCassa의 소스를 다운받도록 합니다. PHPCassa의 위치는 application/libraries/phpcassa로 올리면 됩니다.

4. CodeIgniter 추가 설정하기

application/config/cassandra.php 파일을 생성합니다. 다음과 같은 정보를 기입하도록 합니다.
[code]<? if ( ! defined(‘BASEPATH’)) exit(‘No direct script access allowed’);

$config[‘cassandra’] = array();
// 노드의 갯수만큼 배열로 정의한다.
$config[‘cassandra’][‘nodes’] = array(‘localhost:9160’);
// 기본적으로 사용할 키스페이스 이름을 정의한다.
$config[‘cassandra’][‘keyspace’] = ‘Keyspace1’;

?>[/code]
application/libraries/cassandra.php 파일을 생성합니다. 다음과 같은 코드를 작성합시다.
[code php]<?
require_once(‘phpcassa/connection.php’);
require_once(‘phpcassa/columnfamily.php’);
require_once(‘phpcassa/uuid.php’);

class Cassandra
{
  private $_CI;
  private $_config;
  private $_connection;
  private $_columnfamily;

  public function __construct()
  {  
    $this->_CI = & get_instance();

    $this->_CI->config->load(‘cassandra’);
    $this->_config = $this->_CI->config->item(‘cassandra’);
    $this->_connection = new ConnectionPool($this->_config[‘keyspace’],
                                                $this->_config[‘nodes’]);
    $this->_columnfamily = array();
  }  

  public function cf($columnfamily)
  {  
    if(!isset($this->_columnfamily[$columnfamily]))
    {  
      $this->_columnfamily[$columnfamily] = new ColumnFamily($this->_connection, $columnfamily);
    }  

    return $this->_columnfamily[$columnfamily];
  }  

  public function uuid($ver = 1)
  {  
    return UUID::mint($ver);
  }  
}
?>[/code]
사실 uuid메서드에 대해서는 좀더 생각해 볼점이 있습니다. 자세한 내용은 PHPCassa의 columnfamily.php의 주석들을 참고하시기 바랍니다.

5. 테스트 컨트롤러 작성하기

제대로 작동하는지 테스트를 하기 위해 controllers/test.php 를 작성하도록 합니다.
[code php]<?
class Test extends CI_Controller
{
  public function __construct()
  {  
    parent::__construct();

    // 카산드라를 사용하기 위해 라이브러리를 로드합니다.
    $this->load->library(‘cassandra’);
  }  

  public function index()
  {
    // 사용을 하기 원하는 컬럼패밀리를 선택합니다.  
    $cf = $this->cassandra->cf(‘Standard1’);

    // 값 가져오기 (PHPCassa 메서드 참고)
    var_dump($cf->get(‘row_key’));

    // Timestamp UUID값 테스트
    echo $this->cassandra->uuid();
  }  
}
?>[/code]
사용자 삽입 이미지참고:
http://crlog.info/2011/04/07/apache-cassandra-phpcassa-code-igniter-large-scale-php-app-in-5-minutes/

[NoSQL/Cassandra] 카산드라에서의 인덱싱(Indexing) 전략

사용자 삽입 이미지
카산드라는 굉장히 특이합니다. 특이할수밖에 없는 것이 카산드라는 아마존의 다이나모(Dynamo)와 구글의 빅테이블(BigTable)의 장점만을 수용하여 발전한 형태인 NoSQL의 대표적인 DB입니다. 아마존의 다이나모에서는 클러스터 관리(Cluster Management), 리플리케이션(Replication), 결함허용(Fault Tolerance – 한국말이 더 어렵네요, 문제가 발생해도 시스템 운영 전반적인 운영에 영향을 끼치지는 않는 형태를 의미합니다)과 같은 장점을 가져왔고 구글의 빅테이블에서는 스파스(Sparse – 실제 사용량보다 더 많은 공간을 미리 차지하게 하는 기술입니다. 대용량 파일을 사용가능하게 합니다), 주상 데이터 모델(Columnar Data Model – 데이터의 시작점과 끝이 연결되는 원형으로 저장을 합니다. 범위를 지정하여 데이터를 가져오는데에 도움이 됩니다), 저장소 설계(Storage Architecture)를 가져왔습니다.

지금까지의 RDB에서는 정규화라는 이름의 과정을 거친 정형화된 데이터를 보관해두고 SELECT라는 엄청난 부가적인 기능을 제공하는 쿼리문을 사용하여 자신이 원하는 다양한 형태로 데이터를 가져올 수 있었습니다. 하지만 카산드라는 조금 예시가 다릅니다. 카산드라는 항상 원하는 형태로 데이터를 이미 보관하고 있다가 있는 그대로를 꺼내주게 됩니다. 이러한 형태의 설계가 가능한점은 카산드라는 읽기보다 쓰기가 더 빠르기 때문입니다. 쓰기가 엄청나게 빠르게 때문에 읽기 쉬운 형태로 데이터를 가공하여 저장을 해둔후에 그대로 꺼내 쓰기 때문에 결과적으로 읽기에도 엄청나게 큰 이득을 얻게 됩니다.

결과적으로 카산드라는 인덱스 생성킷이 됩니다. 이것이 무슨말이냐 하면 쓰기가 유용하기 때문에 언제든지 읽고 싶은 형태로 저장을 해도 됩니다. 언제 어떻게 쓰일지 모르는 RDB의 인덱스들에 비해서는 설계를 어떻게 하느냐에 따라 엄청나게 큰 효과를 얻을 수 있습니다. 우선 다음의 이야기를 이해하기 위해 다음의 것들을 다시한번 짚고 넘어가도록 하겠습니다. 컬럼과 슈퍼컬럼에 대한 이해가 부족하실 경우 다음의 글을 읽어보시면 도움이 될 것 같습니다.

[code]// Two-Level Map (Column Family)
key: {
  column: value,
  column: value,
  …
}

// Three-Level Map (Super Column Family)
key: {
  supercolumn: {
    column: value,
    column: value

  },
  supercolumn: {
    …
  }
}[/code]

각각의 컬럼들은 CompareWithCompareSubcolumnsWith 옵션에 의해 정렬이 결정됩니다. 이러한 타입에는 제 글들에 항상 언급되어서 또 쓰기 그렇지만 UTF8Type, LongType, ASCIIType, LexicalUUIDType, TimeUUIDType등이 있습니다. 이제 간단한 정렬에 대한 예제를 보여드리겠습니다. 우선 파티셔너(Partitioner)에 대한 설명이 필요할것 같은데 그건 다음에 작성할 글에서 언급해 보겠습니다.

[code]<ColumnFamily Name=”Users”
              CompareWith=”UTF8Type”/>

“b”:       {“name”:”Ben”, “street”:”1234 Oak St.”,
            “city”:”Seattle”, “state”:”WA”}
“jason”:   {”name”:”Jason”, “street”:”456 First Ave.”,
            “city”:”Bellingham”, “state”:”WA”}
“zack”:     {”name”: “Zack”, “street”: “4321 Pine St.”,
             “city”: “Seattle”, “state”: “WA”}
“jen1982”: {”name”:”Jennifer”, “street”:”1120 Foo Lane”,
            “city”:”San Francisco”, “state”:”CA”}
“albert”:  {”name”:”Albert”, “street”:”2364 South St.”,
            “city”:”Boston”, “state”:”MA”}[/code]

이제 여기서 다음과 같은 쿼리의 결과를 가져올려면 어떻게 해야 할까요?
[code]SELECT name FROM Users WHERE state = “WA”[/code]

우선, RDB적인 접근 방식으로는 답이 안나옵니다. 내가 만약에 state로 데이터를 검색해야 하는 상황이 있다고 인지하였다면 거기에 적절한 형태의 인덱싱용 컬럼패밀리를 만들어주면 됩니다.

1. 첫번째 – 슈퍼컬럼 인덱싱(SuperColumn Indexing)

인덱싱을 위하여 다음과 같은 슈퍼컬럼을 포함하는 컬럼패밀리를 생성하도록 합시다.
[code]<ColumnFamily Name=”LocationUserIndexSCF”
              CompareWith=”UTF8Type”
              CompareSubcolumnsWith=”UTF8Type”
              ColumnType=”Super”/>[/code]
이제 이와 같은 슈퍼컬럼을 갖는 컬럼패밀리를 가지고 원하는 형태로 데이터를 맞추어 넣습니다. 우리는 state로 검색을 할것이므로 state를 로우의 키로하여 데이터를 다시 넣어줍니다.
[code]”CA”: { // Row Key
  “San Francisco”/*Super Column*/: {“Jennifer”/*Column*/: “jen1982″/*Value*/}
}
“MA”: {
  “Boston”: {“Albert”: “albert”}
}
“WA”: {
  “Bellingham”: {“Jason”: “jason”},
  “Seattle”: {“Ben”: “b”, “Zack”: “zack”}
}[/code]

이제 워싱턴(WA)에 사는 모두를 가져오기 위해서는 다음과 같은 쿼리 한번이면 됩니다. 참고로 앞으로 나온느 문법들은 Ruby의 문법입니다. 그냥 이해만 하신다는 느낌으로 봐주시면 될듯하네요.
[code]get(:LocationUserIndexSCF, “WA”)

// 결과

{
  “Bellingham”: {“Jason”: “jason”},
  “Seattle”: {“Ben”: “b”, “Zack”: “zack”}
}[/code]

2. 두번째 – 복합 키 인덱싱(Composite Key Indexing)

이번의 복합키 인덱싱에서는 Order Preserving Partitioner(OPP)와 범위쿼리(Range Queries)를 사용합니다. OPP에 대해서는 다음에 좀더 자세히 언급하겠습니다만 여기 예제를 보시다 보면 어떤것인지 느낌이 오실지도 모르겠네요.
[code]<ColumnFamily Name=”LocationUserIndexCF”
              CompareWith=”UTF8Type” />

// 보유 데이터
“CA/San Francisco”: {“Jennifer”: “jen1982”}
“MA/Boston”: {“Albert”: “albert”}
“WA/Bellingham”: {“Jason”: “jason”}
“WA/Seattle”: {“Ben”: “b”, “Zack”: “zack”}[/code]
위에서 알 수 있듯이 로우의 키를 복합적인 인덱스 활용을 위해 /를 붙여서 한꺼번에 입력한 것을 볼 수 있습니다. 여기서 키를 비교할때는 UTF8Type을 이용한다는것을 눈여겨 봐두시기 바랍니다.

이제 워싱턴(WA)에 사는 모두를 가져오기 위해서는 다음과 같은 범위쿼리 한번이면 됩니다.
[code]get_range(:LocationUserIndexCF, {:start: ‘WA’, :finish:’WB’})

// 결과

{
  “WA/Bellingham”: {“Jason”: “jason”},
  “WA/Seattle”:    {“Ben”: “b”, “Zack”: “zack”}
}[/code]
자 설명을 해보겠습니다. 위의 쿼리는 WA부터 WB사이의 모든 값을 반환합니다. UTF8Type으로 키를 구분하므로 WA/는 WA보다 더 다음의 순서입니다. 마찬가지로 WAA도 WA보다 더 다음의 순서입니다. 결과적으로 WA뒤에 그 어떤 문자가 더 붙더라도 WA보다 뒤의 순서가 됩니다. 그리고 또한 키의 이름을 [state]/[city]로 정의한 이상 WA만을 키로 갖는 경우는 존재하지 않습니다. 결과적으로 WA로 시작하는 모든 키가 여기에 포함됩니다.

그럼 다음으로 WB까지라는 조건에 대해서 생각해 보겠습니다. WB는 WA때와 마찬가지로 WB자신을 포함할 상황이 존재하지 않습니다. WA는 WB보다 이전의 순서인 키입니다. 마찬가지로 WAA는 WA보다는 뒤이지만 WB보다는 앞의 키입니다. WALAKJSDLKASJDLKJALKSDJSKLADJ 역시도 WB보다 앞의 키입니다.(UTF8Type이므로) 결과적으로 WA ~ WB범위의 값을 가져오라는 것은 워싱턴 전체의 데이터를 가져오라는 말과 같습니다. 그럼 다시 처음으로 돌아가서 워싱턴에서도 시애틀에 사는 사람만을 뽑아오고 싶다면?
[code]get(:LocationUserIndexSCF, “WA/Seattle”)

// 결과
{
  “WA/Seattle”:    {“Ben”: “b”, “Zack”: “zack”}
}[/code]
이런식으로 2차인덱스의 성격으로 자유롭게 활용할 수 있습니다. 슈퍼컬럼의 좋은 활용예이기도 합니다.

참고:
http://www.slideshare.net/benjaminblack/cassandra-basics-indexing (Thanks to Benjamin)