JKUN

Welcome To The Jkun.net

블로그 포스트 검색결과


DataBase/NoSQL 에 해당되는 글 7개가 검색 되었습니다.

  1. 2016.07.26 [펌] NoSQL 종류
  2. 2013.11.27 몽고디비 - 초간단 가이드
  3. 2011.02.11 Database Technology for Large Scale Data, 박기은
  4. 2011.02.11 오 아름답도다. Cassandra
  5. 2011.02.11 Cassandra db 로컬설치
  6. 2011.02.11 Cassandra [출처] Cassandra - facebook|작성자 녹천
  7. 2011.02.11 아파치 분산 데이타 베이스 Cassandra 소개

Blog

[펌] NoSQL 종류

2016.07.26 11:45 DataBase/NoSQL



출처 : http://paraffa.tistory.com/47

----------------------------------------------------------------------------------------

1. MongoDB / C로작성 됨

----------------------------------------------------------------------------------------


1.1 MongoDB란?

  - MongoDB는 10gen 사에서 개발된 높은 성능과 확장성을 가지고 있는 데이터베이스 입니다.

    NoSQL 데이터베이스에서는 문서형 데이터베이스로 분류됩니다. C언어로 개발되었다.

    공식사이트 : http://www.mongodb.org


1.2 왜 MongoDB를 사용하는가?

  - 스키마를 고정하지않는다.

  - 시리얼라이즈 시키면 문제가 없어질까?

    - json등을 사용하여 시리얼라이즈시킨 데이터를 관계형 데이터베이스에 입력하면된다.

      > 가독성이 떨어진다.

      > 성능저하를 검토하여야한다.

  - 스키마 없는 데이터베이스

    - MongoDB는 스키마가없는 데이터베이스이다.

    - RDB와 마찬가지로 임의의 key값에대한 복잡한 검색이 가능하다.

    - RDB와 비교해 응답속도가 빠르고, 인덱스를 추가하여 처리속도를 더 빠르게 할 수 있다.


1.3 특징

  - MongoDB는 스키마를 정의할 필요가 없음.

  - 문서형 데이터베이스는 데이터를 입력할때 데이터 구조 정보를 포함하여 BSON(JSON을 바이너리화한것)

    형식으로 저장하고, 이것을 value로 key와 짝짓습니다.


1.4 장점

  - 스키마 없이사용이 가장 큰 장점입니다.

  - 스키마가 없기 때문에 프로그램 코드만 수정하면 됩니다.

  - 스키마와 프로그램 코드사이의정합성에 신경쓰지 않아도 된다.

  - 검색조건을 유연하게 지정할 수 있습니다. 

    > 정규표현을 통한 검색부터 배열 데이터에 특정 값이 포함되어 있는지등.


1.5 단점

  - MongoDB에서는 JOIN이나 트랜잭션성 처리가 불가능하다.

  - MongoDB에서는 데이터 갱신 및 입력시 바로 디스크에 쓰지 않는다는 것입니다.

    > 디스크에 쓰기가 비동기식으로 이루어진다. 때문에 경우에 따라 데이터가 유실될 가능성도 있다.

      이것과 트레이드오프로 빠른 응답속도가 가능한 것 입니다만 데이터가 사라질 수 있다는 점에 

      주의해야 한다.

1.6 도입사례

  - 해외의 도입사례

    > foursquare

    > preferred infrastructure

    > 아메바피아


1.7 구체적인 이용 예

1.7.1 샘플1

  - MongoDB의 구체적인 예로 앙케이트 응답 데이터를 다루는 경우를 생각해보겠습니다. 

    MongoMapper라는 라이브러리를 사용해서 구현하도록 하겠습니다. 먼저 앙케이트 응답 데이터를 다룰 answers콜렉션에 대한 모델을 정의합니다.

    클래스 정의 내부에 MongoMapper:Document를 include하고있는것 외에는 특별히 다른 부분은 없습니다.


  - 컬럼을 정의하지 않아도 MongoDB를 사용할 수 있습니다만 이번예에서는 user_id와 enquete_id를 명시적으로 정의해 두었습니다.

    컬럼을 정의하면 validation 가능(이번경우 user_id, enquete_id가 필수 항목이 됨), Accessor 설정, 대응클래서에 매핑됨

    이라는 잇점이 있기 때문입니다. 물론, 단순히 알기쉽고 관리가 편하다는 이유도 있습니다.


  - 여러 데이터 형식 입력 가능

  - 콜렉션을 다른 콜렉션에 추가

  - 응답 데이터를 저장한다.

  - 스키마 변경없이 대응 가능


1.7.2 샘플2

  - 다른 예로 분석 데이터 스토리지로 사용하는 경우에 대해 생각해 보겠습니다.로그 데이터를 분석하여 그 분석 결과를 MongoDB에 저장하는 케이스입니다.

    서비스이용 상태를 조사한다거나 서비스를 개선하기위해 로그데이터를 해서 PV나 UU, 그외 여러가지데이터를 만들어 내는 경우가 있을것 입니다만

    그 데이터를 어떻게 관리하면 좋을까요?

    

    > 관계형 데이터베이스에서의 운용

      - 단,로그 데이터 분석에서는 어떤 컬럼이 필요할지 알 수 없습니다. 이제까지 필요하지 않았던 컬럼도 어떤 분석에서는 필요해질 수 있습니다.

        그러므로 분석용 테이블을만들어서 해당 테이블에 모든 분석 테이터를 보존하고 필요할 경우 새로운 컬럼을 추가한다거나 아니면 다른 테이블을

만들어서 저장하는 방법이 있습니다.


      - 동일한 테이블에 모든 분석 데이터를 저장하고 필요할 때마다 새로운 컬럼을 추가한다면 운영이 번거로워지고 특정 분석에서만 사용하는 불필요한

        컬럼이 많아질 수 있습니다. 그렇다고 해서 분석 데이터만다 별도 테이블을 만든다면 테이블 수가 무척 많아지게 될 것 입니다.


    > MongoDB를 사용한 운용

      - 로그 데이터를 분석하면 여러가지 형식의 데이터가 얻어질 것이라고 생각합니다만, MongoDB라면 스키마에 신경쓰지 않고 여러 데이터를 저장 할 수

        있습니다. 새로운 데이터를 저장해야 할 경우에도 스키마 변경 없이 바로 추가해서 기록할 수 있는 유연함이 MongoDB의 가장 큰 장점입니다.

'이 데이터는 앞으로 이용 할 수도 있다'는 일시적으로 사용할 데이터도 가볍게 저장할 수 있어서 편리합니다.


1.7.3 Tip

  - MongoDB의 지리 공간 인덱스라고 불리는 인덱스를 사용하는 것이 가능합니다. (1.7.0 이상)위도와 경도정보를 인덱스로 사용하여 검색할 수 있습니다.

    최근 GPS를 사용한 서비스가 늘어나고 HTML5에서는 Geolocation  API를 제공하는 등 위치 정보가 점점 더 중요해질 것이라고 생각합니다. 

    

    # 지리 공간 인덱스를 이용하는 컬럼으로 "2d"를 지정

    # 복합 인덱스도 사용 가능

    > db.place.ensureIndex({location:"2d"})


    # 데이터 입력

    > db.place.find({location:{$near:[139.65,35.65]}}).limit(5)


----------------------------------------------------------------------------------------

2. Cassandra (key-value형 스토어) / 자바기반

----------------------------------------------------------------------------------------

2.1 Cassandra란?

  - Cassandra는 facebook에서개발하여 현재는 Apache프로젝트로 진행되고 있는 오픈소스 소프트웨어이다.

    NoSQL데이터베이스에서는 key-value형으로 분류된다. Google의 BigTable을 바탕으로 개발되고 

    컬럼 단위로 관리되어 컬럼형으로 분류하기도 한다.


2.2 왜 Cassandra를 사용하는가?

  - 대량의 데이터를 다루는데 효과적

    > 여러장소에 분산된 다수의 저가 서버를 이용하여 대량 데이터를 다루기 위해 만들어진 데이터 스토어로

      대량의데이터를 다루는 데특화되어 있습니다.다량의데이터를 다수의 서버에 분산시키며 분산된 데이터를 여러

      서버에 복제해 두는 방식으로, 읽기와 쓰기가 모두 뛰어나다. 또한 데이터를 메모리에 보관해 두고 일정 조건 후

      디스크에 입력하는 영속성과 휘발성 key-value가 혼합된 방식으로 관계형 데이터베이스에 비해 속도가 크게 빠릅니다.


    > memcached처럼 관계형 데이터베이스의 cache로 사용할 수 있지만, 다수가 이용하는 대랴의 데이터에 특화되어 개발된

      만큼 관계형 데이터베이스와 대등하게 단독 데이터베이스로 사용하는 경우가 많습니다.


2.3 특징과 사용케이스

  - Cassandra는 Row key를 인덱스로가지는 key-value형 스토어입니다. 또한 컬럼을 기본으로 데이터를 다루는 컬럼형 NoSQL

    데이터베이스로 행 중심인 관계형 데이터베이스와는 달리 디스크에 데이터를 컬럼 단위로 연속하여 저장한다.

    컬럼(열)단위로 관리되기 때문에 동일한 데이터라도 행단위로 관리하는 것보다 디스크에 많이 저장할수 있습니다


  - 컬럼이 기본 단위로 컬럼에는 컬럼 이름과 값, time stamp가 포합니다. Row key로 식별되는 한 행에는 여러 개의 

    컬럼이 포함될 수 있으며 한 Row에서 저장할 수 있는 컬럼 개수는 20억개 , 각 Row key의 최대 크기는 64KB이다.

    각 컬럼은 Column family에  속하며 Column family는 Keyspace에 포함됩니다. Column family 중 Super Column family는

    Column family를 자식 column으로 가질 수 있습니다. Keyspace는 관계형 데이터베이스에서 스키마나 테이블 스페이스라

    불리는 것과 유사합니다. Keyspace단위로 복제 및 관련 정책을 관리하여보통 어플리케이션 하나 당 Keyspace를 하나씩 

    생성합니다.


  - 어플리케이션에서 Column family의 정렬 기준을 시간이나 이름으로 지정할 수 있습니다.

    Cassandra의 또다른 특징은 분산된 환경에 적합하며 확장성이 뛰어나다는 것입니다.

    앞에서도 이야기했듯이 동일한 데이터가 여러 서버에 복제되어 있어 단위 서버에 문제가 발생하더라도 가용성이 보장됩니다.

    하지만 확장성과 가용성이 좋은 대신 관계형 데이터베이스에 비해 데이터 신뢰도는 떨어지는 편입니다.

    기본 구성에서는 데이터에 대한 입력이나 변경이 비동기식으로이루어지고 중앙에서 관리하는 서버가 별도로 없기 때문에

    분산된 데이터사이에 정합성이 맞지 않는 경우가 발생할 수 있습니다.

    이를 보완하기 위해 데이터 읽기 요청이 발생한 경우 해당 데이터를가지고 있는 여러 서버에 요청을 발행하여 결과값을 비교해 보고 time stamp가

    가장 최신인 데이터를 반환하는 등의 로직을 제공하고 있습니다. 이때 time stamp가 오래된 응답을 보낸 서버는 최신의 데이터로 갱신하도록 합니다.


  - 데이터의 신뢰도를 높이기 위해 동일한 데이터를 가지고 잇는 여러 서버에서 데이터를 가져와서 비교하다 보면 성능에영향을 미칠 수 있습니다.

    따라서 Cassandra에서는 읽기 및 쓰기에대한 각각의 Consistency Level을 지정하여 성능과 신뢰도 수준을 조정하도록 하고 있습니다.

    Consistency Level이 All인 경우에는 읽기 및 쓰기 요청이 발생할 경우 복제된 데이터를가진 모든 서버에서 응답을 보내와야 완료됩니다.

    이경우 데이터베이스의 유연성 및 성능은 떨어지지만 데이터 신뢰도는 높아지게 됩니다.

    Consistency Level이 One일경우에는 읽기 및 쓰기 요청이 발생하였을 때 해당 데이터를 가지고 있는 하나의 서버를 대상으로 해당 연산을

    처리하고 완료하게됩니다. 데이터 신뢰성은 떨어지게되지만 분산에 대한 유연도와 응답 성능은 높아집니다.

    마지막으로QUORUM으로 설정해 두면 읽기 및 쓰기 요청이 들어온 데이터를 복제하여 가지고 있는 일정 대술의 서버에서 응답을 보낼 경우 완료하게 됩니다.

    참고로 Facebook에서 권장하는 Consistency Level은 One이나 replication factor(복제 서버수)를 3으로 둔 QUORUM입니다.

    

    ※ consistency level

    > Level           Write                                    Read

    > ANY | 요청한 내용이 적어도 한 node에 저장됨 |             - 

    > ONE | 요청한 내용이 적어도 한 node의 commit log 및 table에 저장된 후 요청자에게 응답함 | 가장 가까운 고의 replica에서 응답을 받아서 반환한다. Read repair 설정이 되어 있으면 Cassandra는 백그라운드 스레드에서 신뢰도 체크를 실시.

    > QUORUM | 요청자에게 응답하기 전에 quorum of replicas에 저장됨 | quorum of replicas의 응답 중 가장 최근 time stamp의 응답을 반환 |

    > LOCAL_QUORUM |요청자에게 응답하기 전에 local데이터 센터 내의 quorum of replicas에 저장됨. 데이터 센터 사이의latency로 인한 지연을 줄이기위한 설정 | 단일 데이터 센터의quorum of replicas의 응답중 가장 최근 time stamp의 응답을 반환. 데이터센터 사이의 latency를 줄이기 위함 |

    > EACH_QUORUM | 각 데이터센터의 quorum of replicas에 저장한 후 요청자에게 완료를 알림.| 각 데이터 센터의 quorum of replicas의 응답중 가장 최근 time stamp의 응답을 반환|

    > ALL | 모든 replica가 저장해야 함. 그러지않으면 해당 연산은 실패 | 모든 replaica에서 준 응답중 가장 최근 time stamp 값을 반환.하나라도 응답이 오지 않으면 실패 | 


  - key-value형 스토어 데이터 분산에는 memcached 등과 마찬가지로 Consistent Hashing 방식을 이용하고 있습니다.


2.5 장점

  - 대량의 데이터를 다수의분산된 서버에서관리해야 할 경우 적합합니다. 특히 많은 사람들이 이용하며 대량으로 쓰기가 발생하는 서비스에 좋습니다.

    데이터는 일단 메모리에 쓰여지며 데이터가 일정 크기가 되면 디스크로옮겨지게 됩니다.


  - Consistent Hashing 방식을 이용하여 데이터를 분산한다. Consistent Hashing방식에 로드 밸런싱을 위한 알고리즘을 더하여 요청이 적은 서버를

    요청이 많은 서버 구간으로 옮기는 방식으로 로드 밸런싱을 구현하고 있습니다. 따라서 대량의 요청이 소수의 서버에 몰리는 것을 막아 장애를방지하고

    성능을 높일 수 있습니다. 또한 신규로 서버가 추가되는 경우 로드 밸런싱을 고려하여 요청이 많은 구간에 우선 추가되어 부하 관리가 효율적으로 

    이루어지게 됩니다.


  - 신규 서버를 분산 시스템에 추가할 경우 서비스 중단없이 손쉽게 추가할 수 있는 것도 큰장점 입니다. 서비스 요청이 많아져서 신규로 서버를 추가하는경우,

    중앙에서 관리하는 별도 서버가 없기 때문에 새로 추가되는 서버만 기동하면 서비스에 해당서버가 추가되게 됩니다. 즉, 기존에 서비스를 제공하던 서버를

    재기동해야 하는 등의 서비스 중단이 필요 없습니다.


  - 아마존 다이나모 방식을 구현하여 데이터 일관성 대신 연속적인 서비스제공에 중점을 둔 구조로 가용성이 굉장히 뛰어납니다. 데이터 복제 설정도 동일한

    서버 랙을 사용하지 않는 서버에 복제본을 둔다거나 다른 데이터 센터에 복제본을두는 등 다양하게 구현할 수 있습니다.중앙에서관리하는 별도 서버가 없고

    데이터 복제를 기본으로 하고 있기 때문에 단일 노드의 장애 발생시 서비스에미치는 영향이 거의없습니다. Consistency Level을 통해 업무 특성에 맞춰 가용성과

    신뢰도의 정도를 조정할 수 있습니다.


  - Apache Foundation에서개발하고 있으며 여러 사이트에서 활용하고 있어 커뮤니티가 활발하며 사용 사례가 많습니다.따라서우녕ㅇ시 참고할 만한 자료가 다른 

    NoSQL데이터베이스에 비해 풍부한 편입니다. 커뮤니티가활발하여 문제발생시 유사 사례를 찾거나 의견을 구하는 것도 비교적 쉬운 편입니다.


2.6 단점

  - 컬럼형 데이터베이스로 Row형 데이터베이스인 관계형 데이터베이스와는 다른생소한 개념이라 진입장벽이 높습니다. 따라서많은 사용자를 대상으로 대량 데이터를

    다루는 서비스가 아닐 경우 굳이 Cassandra를 고집할 필요는 없을 것입니다.

  

  - 복잡한 조건의 검색이 불가능 합니다. Row key와 컬럼 두가지에대한 인덱스만 가능하기 때문에 데이터는 대량이지만 검색 조건은 단순한 서비스에 적합니다.

  

  - Super Column family의하위 컬럼에 대한 인덱싱은 불가능합니다.

    key 값을 토한 범위 검색은 데이터 분산 방식을 OrderPresservingPartitioner로 설정하여 key값을 통해 데이터를 서버에분배했을 때문 가능하는 등의

    검색 관련 제약사항이 있습니다.


  - 데이터에 대한 갱신 및 입력시 Atomic한 처리가 어렵습니다. 데이터에 대한Lock을 사용하려면 Zookeeper와 같은 전체분산 서버를 관리하는 프로그램을 추가해서

    별도로 설정해야 합니다. 데이터에 대한 동시 갱신 요청이 발생할 가능성이 높거나 Atomic한 트랜잭션이 필요한 서비스에서는다른 데이터베이스를 고려하는 것이 

    좋을 겁니다.


  - 지금 버전 1이 정식으로 나오지 않은 안정적이지 않은 시스템이라느 것도 불안요소가 될수 있습니다.

    커뮤니티가 매우 활발하여 계속해서새로운 기능을 추가하고이슈를 해결하고 있지만 그만큼 새로운 내용에 항상 촉각을 세우고 있어야한다.


2.7 도입사례

  - Facebook을 비롯하여 여러 유명 해외 서비스에서 사용하고 있습니다.

    > Facebook

    > Twitter

    > Digg

  또한 대량 데이터를 다루는 많은 사이트에서 도입을 검토하고 있습니다.


  - 사용케이스 : 시작은 Facebook에 최적화 되어 개발되었기 때문에 다수의 쓰기가 발생하는 대형 웹서비스에 적합합니다.

    앞서 이야기했듯이 Atomic한 처리가필요한 서비스보다는 동일 row에 대한 동시 갱신 요청이 적은 경우나 높은 데이터 신뢰도가 필요하지 않은 서비스에

    적합할 것입니다. 대량 데이터의 입력 성능이 뛰어나기 때문에 실시간 입력 요청이 많은 서비스에 좋습니다. 또한 대량의 데이터의 실시간 분석에도 적합니다.

    Twitter에서는 실시간 분석에 활용하고 있습니다.

    > 사용자가 많으며 사용자에의한 데이터입력이 빈번하게 발생하는 대량의데이터를 다루는 시스템

    > 빈번하게 변경되는 데이터에대한 실시간 분석용 시스템

    > 대량의데이터를 다루며 신뢰성보다 가용성이 중요한 시스템


  - 다른 key-value형 NoSQL 데이터베이스와는 달리 Cassandra는 관계형 데이터베이스를 대체하는 대량 데이터용 스토어로 사용되는 경우가 많습니다. 

    대량의 데이터를 다수 서버에 분산하여 많은 사용자가접속하여 쓰는 구성은 관계형 데이터베이스를 통해서는 효율적으로 지원하기 어렵습니다.

    대량 데이터 분산 처리용으로 나온 NoSQL데이터베이스에서는 HBase와 함께 Cassandra가 가장 앞서나가고 있습니다.


2.8 구체적인 이용 예

2.8.1 사용자 검색 정보 스토리지

  - 많은사용자가 이용하는 대규모 검색 사이트의 경우를 생각해 보겠습니다. 사용자가 많고 실시간으로 기록되눈 데이터(검색시도)가 많으며 데이터는 대부분

    텍스트 데이터로 이루어집니다. 검색 사이트에서 검색 정보를 기록하여 활용한다면 어떤 데이터베이스를 이용하는 것이 좋을까요?


  - 관계형 데이터베이스에서의 운용

    물론 관계형 데이터베이스로 관리하는 방법도 생각할 수 있습니다. 하지만 1000만명의 사용자가 하루 12시간, 시간당 20만건만 검색한다고해도

    1000000x20x12, 즉 24억 행의 데이터가 매일 추가됩니다. 매일 24억 행씩 증가하는 데이터라면 입력하려는 프로세스 간 경합으로 성능이 많이 떨어지게 될것입니다.

    뿐만 아니라 관계형 데이터베이스 응답 시간과 데이터 규모를 고려한다면 고가의 장비를 도입해야 할 것입니다.


    고가의 장비를 도입해서 관계형 데이터베이스로 해당 데이터를 관리한다고해도테이블 구조가 간단할 뿐더러 높은 실시간 데이터 일관성이 필요하거나 join등의 복잡한

    연산이 필요한 서비스가 아니기 때문에 낭비라는 생각이 자꾸 듭니다.

  

  - Cassandra를 사용한 운용

    이런 경우에는 Cassandra가 좋은 대안이 될 것입니다. 실시간으로 정확하게 제공하는 서비스가 아니기 때문에 높은 신뢰도를 제공하는 데이터베이스일 필요가 없습니다.

    검색 정보 데이터를 활용할 때도 데이터 구조가 간단하기 때문에 JOIN이나 복잡한 연산보다 통계성 분석이 주를 이룹니다. 대량의중요도가 높지 않은 데이터를 모두 저장해

    서 의미있는 비지니스 데이터로 활용하기 위해서는 저비용으로 대량의 데이터를 관리하며 고가용성과 유연성을 제공하는 Cassandra가 좋을 것입니다.



----------------------------------------------------------------------------------------

3. HBase (컬럼형 스토어) / 자바기반

----------------------------------------------------------------------------------------

3.1 HBase란

  - HBase란 2006년 차드 월터스와 짐 캘러만에 의해 시작되어 현재는 Apache 프로젝트로 개발이 진행되고 있는 오픈소스 소프트웨어입니다.

    NoSQL 데이터베이스에서는 컬럼형 데이터베이스라고 분류됩니다.

    공식 사이트 : http://hbase.apache.org


3.2 왜 HBase를 사용하는가?

  - 대용량 데이터를 안정적으로다루는 데 효과적

    > HBase는 Cassandra와 마찬가지로 Bigtable의 영향을받은, 대량 데이터를 효율적으로 다루기 위한 목적으로 개발된  NoSQL 데이터베이스

      입니다. 대용량 데이터를 다루는 NoSQL 데이터베이스중 Cassandra와 함께 가장 많이 사용되고 있습니다만, Cassandra와는 구별되는 뚜렷한

      특징을 가지고 있습니다. Cassandra는 성능을 우선시 할 경우 데이터 일관성이 보장되지 않을 수 있다고 말씀 드렸습니다. 대량 데이터를

      우수한 성능으로 데이터 일관성을 보장하면서 다뤄야 할 때는 어떻게 해야 할까요? 이부분에서 장점으로 가지고 있는 것이 HBase입니다.

      

      HBase는 중앙에 전체 분산 시스템을 통제하는 마스터를 두고 복제된 전체 데이터의 일관성을 관리 하기때문에 분산된 복제 데이터 사이의

      일관성을 보장하며 제약이 있지만 트랜잭셔성 처리도 지원이 가능합니다.


  - 대량 데이터분석 처리지원에 적합

    > 대량 데이터 분석 및 처리를 위해 사용되는 Hadoop의 산하 프로젝트로 시작된 데이터베이스로 HDFS 및 MapReduce등과 함께 사용하기에

      최적화 되어 있습니다. MapReduce를 지원하는 다른 데이터베이스도 있지만 별도로 개발되었기 때문에 HBase처럼 HDFS를 사용하며 

      MapReduce의 기능을 적합하게 사용하는 예는 없습니다.


      대량 데이터를 분삭하여 의미 있는 값을 만드는 데 있어 널리 사용되고 있는 MapReduce와 함께 효율적으로 이용할 수 있다는 것이 큰 

      장점 입니다.


3.3 특징과 사용 케이스

3.3.1 특징

  - 컬럼형 NoSQL 데이터베이스로기본 단위는 컬럼입니다. 여러 컬럼이 Row Key에 할당되고 이러한 Row key가 모여 테이블을 이룹니다.

    테이블 내의 Row key는 정렬되어 저장되며 해당 데이터베이스 내에서단일한 값을 가져 index와 비슷한 역할을 수행하게 됩니다.


    컬럼이 모여 Column family를 이룹니다. Column family 내의 모든 컬럼은 동일한 스토리지 파일에저장되고 데이터 압축 등 성능 개선을 위한 튜닝은

    Column family단위로 이루어 집니다. Column family내의 컬럼수에 대한제한은 없으며, 컬럼 값의 데이터 타입이나 길이에대한 제약도 없습니다. 앞서

    이야기한 것처럼 컬럼 단위로 디스크에 저장하기 때문에 행중심 데이터베이스에 비해 동일한 데이터라도 사용하는 디스크가 적습니다.


    데이터가업데이트되면 우선 commit log에 해당 내용을 저장하고 다음으로 HBase에서 사용하고 있는 메모리 상의데이터베이스(memstore)에 데이터를

    저장합니다. 이 때 commit log는 여러 무리적인 서버에 복제되기 때문에 변경된 데이터가 사라질 확률이 낮습니다. memstroe의 데이터가 미리 지정한

    크기를 넘어서면 디스크에 저장되며 저장 된 데이터에 대한 commit log는 삭제됩니다.


    분산 구성시 Master-Region 구조를 이룹니다. Region은 분산을 이루고있는기본 단위로, 연속한 row데이터를 가지고 있습니다. 구성파일에 정의해둔

    maximum size 값을 초과하면 자동으로 해당 region에서관리하고 있는 데이터의 절반을 key값을 기준으로 새 region에 분배합니다.

    참고로 현재 하나의 물리적인 서버에서 관리하는 region은 10~1000개, region 당 데이터는 1~2GB를 권고 하고 있습니다.


    HBase에서 Region의 정보를 관리하는 Master(HMaster)를 별도로 두고 있습니다. 데이터에 대한 읽기나 쓰기 요청이 발생하면 Master에서 어느 region에서

    해당 Rwo key를 관리하는지에 대한 기초 정보를 제공해 줍니다. Maste는 Region에 할당된 Row key값을 재분배 해줍니다. 장애를 예방하기 위해 Master는

    여러 대로 구성할 수 있습니다.


3.3.2 장점

  - HBase의 가장 큰 장점은 대량의데이터를 분산된 환경에서관리함녀서도 데이터일관성을 보장해 준다는 점입니다. 대량 데이터를 다루면서 일관성이 필요한

    환경에서 일관성이 완벽하게 보장되지 않는 데이터베이스를 사용한다면 프로그램 코드를 통해 데이터의 일관성을 보장해야 하므로 코딩의 복잡도가 크게

    올라가게 될것이다. HBase에서는 데이터의 일관성 보장에 초점을 맞추고 있으므로 이러한 경우에는 HBase를 사용함으로써 수고를 많이 줄일 수 있을것이다.


  - 데이터를 효율적으로 압축 할 수 있습니다. 행 기반에 비해 컬럼 기반으로 데이터를 저장하는 것이 데이터 압축을 더 효율적으로 할 수 있습니다. 일반적으로

    사용되는 행 기반으로 데이터를 입력하는 경우, 행에서 가지고 있는여러 컬럼 값은 서로 다른 데이터 타입의 차이가 큰 값일 가능성이 높습니다. 하지만

    가지고 있는 여러 컬럼 값은 서로다른 데이터 타입의 차이가 튼 값일 가능성이 높습니다. 하지만 컬럼 기반의 경우컬럼을 기준으로 데이터가 함께 저장되기

    때문에 근접 데이터 사이의 값의 차이가 크지 않아행 기반에 비해 데이터 압축률이 높습니다. 따라서 대량 데이터를 보다 경제적으로 관리할 수 있고, 대량

    조회가 발생할 경우 압축된 데이터를 가져오기 때문에 bandwidth 측면에서도 득을 볼 수 있습니다.


  - 이전 버전의 데이터 값도 관리가가능하다는 것도 장점 입니다.각기 다른 버전의 값을 통해 변경 빈도 등의데이트럴 분석 할 수 있습니다. 어느 버전까지 데이터를

    유지 할 것인지는 설정 파일을 통해 지정할 수 있브니다. 지난 버전 데이터를 통한 통계나 변경내용에 대한 분석도 가능합니다.


  - 한 행에 대한 Atomic한 처리가 가능합니다. 즉, 단일 행에 대해서는 트랜잭션성 처리가 가능하다는 장점을 가지고 있습니다. 대량 데이터를 다루면서 트랜잭션성

    처리가 필요할 경우 매우 요긴한 기능입니다. 또한 웹 콘솔을 통해 관리 및 모니터링 할 수 있는 기능을 제공하고 있습니다.


3.3.3 단점

  - 다수의 프로그램으로 이루어진 데이터베이스로다른 NoSQL 데이터베이스에 비해 이해하기가 복잡합니다. 효율적으로 관리하기 위해서는 HDFS, Zookeeper등 HBase뿐만

    아니라 다른 시스템에 대해서도 알아두어야 합니다. 단일 구조에 비해 설치 및 운영 시 시스템들의 연계로 인한 문제가 발생할 가능성이 높습니다. 뿐만 아니라 아직

    생소한 컬럼형 구조를 사용하고 있어 조기 진입에 벽이 높습니다.


  - 특정 범위의 key 값에 저장 요청이 집중되는 경우에도 문제가 발생할 수 있습니다.

    Region별로 저장되는 데이터는 Row key값에 따라 정해집니다. 즉, 일정 범위의 Row key가 Region에 함께 저장되는 구조로, 연속된 Row key를 가진 요청이 들어올 경우

    모든요청이 한두 Region에 집중되어응답 속도가 느려지는 등의 문제가 생길 수 있습니다.


  - HDFS를 파일시스템으로사용하기 때문에 HDFS의 파일 정보를 관리하는 Namenode에서 장애가 발생하거나, Namenode가 구동되어 있는 서버가 다운될 경우 HBase에도 문제가

    생기게 됩니다. 아직 Namenode는 이중화솔류션을 완벽하게 제공하지 않기때문에 전체 HDFS에서 Namenode는 하나뿐입니다. 따라서 Namenode가 중단되면 전체 서비스 중단이

    발생하게 됩니다.


  - Cassandra와 마찬가지로 현재 0.9.4로 아직 버전 1이 나오지 않은 안정적이지 않은 시스템입니다.

    신규 버전이 기존 버전에서 많이 변경되어 불편이 생길수도 있습니다.


3.3.4 도입사례

  - 최근 Facebook에서 데이터 일관성 보장을 이유를 들어 MySQL을대신하는 주 데이터베이스로 도입하기도 하였습니다.

    > Facebook

    > eBay

    > WorldLingo

  이외에도 Adobe 등에서 분석등의 용도로 HBase를 사용 하고 있습니다.


3.3.5 사용 케이스

  - 대량 데이터를 다루면서 데이터 일관성이 요구되는 서비스에서사용하는 것을 권장하고 있습니다. 또한 hadoop을 사용하여 대량 데이터를 분석하는 서비스의 대용량

    데이터베이스로 사용하는 경우도 많습니다.

    > 대량 데이터를 관리하는 사이트 중에서도 쓰기보다는 읽기 요청이 많은 사이트에 적합

    > 대량 데이터를 관리하면서 데이터 일관성 및 트랜잭션성 처리가 필요한 사이트

    > Hadoop을 사용하여 대량 데이터를 분석해야 하는 경우

  

  - HBase에서는 적어도 5대 이상의 서버에서 수백만행 이상의 데이터를 다루는데 사용 할 것을 권고 하고 있습니다.

    대량 데이터 중에서도 동시에 다수의 쓰기가 발생하는 성격의 업무보다는 DW성 데이터 처리에 적합하다고 합니다.


4.1 구체적인 이용 예

4.1.1 대형 SNS서비스의 주 스토리지

  - 대규모 SNS 서비스의 주 스토리지로 사용하는 것도 좋을것입니다. 이미 Facebook에서 주 스토리지로 도입하여 사용하고 있습니다.


  - 대량의 쓰기/읽기 요청

    > Twitter나 Faceboo, 카카오톡에서 제공하는 주 서비스를 생각해 보면 수천만 사용자가 실시간으로 데이터를 입력하고 검색하는 요청이

      계속해서 들어오게 됩니다. 하지만 데이터의 구조는 매우 간단하며 사용자와 키워드 검색이 주를 이룹니다. 새로 업데이트된 데이터에 대한

      읽기 요청이 계속해서 발생하기 때문에 데이터 일관성은 보장되어야 하며 쓰기 성능뿐아니라 검색 성능도 매우 중요합니다.


  - 관계형 데이터베이스를 사용한 운용

    > 수백,수천만의데이터 쓰기가 계속해서 요청되는 상황에서는 계속해서 Lock이 발생하여 데이터 읽기와 쓰기 모두 적합한 성능을 보이기 어려울

      뿐더러 관계형 데이터베이스를 이용해서 데이터의 급속한 증가를 관리하는 데는한계가 있습니다. 또한 이러한 대량 데이터를 조회하여 대량의 

      결과가 나와야 하는 경우, 분산에 한계가 있는 관계형 데이터베이스에서는 소수의 서버의 적은 자원으로 대량 요청을 처리해야 하므로 속도와

      성능이 좋지 못하고, 다른 요청을 처리하기도 어려울 것으로 보입니다.


  - HBase를 사용한 운용

    > 다수의 저가 서버(PC)를 분산해서 사용할 수 있는 HBase를 통해 관계형 데이터베이스에서 나타나는 이러한 이슈를 대부분 해결할 수 있습니다.

      테이블의 데이터 입력에 대한 Lock이 발생하지 않으며 데이터가 급속히 증가하더라도 단일 데이터 입력의 비용이 저렴할 뿐 아니라 많은 수의

      서버로 분산되어 부담을 줄일 수 있습니다. 데이터의 일관성이 실시간으로 필요하며 대량 데이터를 다룬다면 HBase를 도입해서 사용하는 것이

      좋을 것입니다.



저작자 표시
신고
현재 0 개의 댓글이 있습니다.
Comment

Blog

몽고디비 - 초간단 가이드

2013.11.27 13:09 DataBase/NoSQL


출처 : http://bcho.tistory.com/742


초간단 Mongo DB Quick Start Guide

조대협 (http://bcho.tistory.com)

 

Mongo DB는 NoSQL 중에서 가장 널리 사용되는 인기있는 제품이다. 사용과 운영이 다른 시스템에 비해서 매우 쉽고, JSON 기반의 Document를 제공하기 때문에, 데이타 구조에 대한 이해 및 사용이 쉽다. 또한 index나 search와 같은 feature를 제공하고 있고, 근래에는 Text Search와 GridFS를 이용한 파일 저장 그리고, 위치 정보 저장 및 쿼리등 다양한 기능을 제공하고 있다.

 

Mongo DB는 10gen이라는 회사에서 개발되어서, 현재 오픈소스로와 상용 버전으로 공급되고 있다.

이 글에서는 Mongo DB에 대한 이해를 돕기 위해서 간단한 설치에서 부터, 자바 기반의 프로그래밍 샘플까지 소개하도록 한다.

 

1.설치

1) 다운로드 하기

mongodb는 http://www.mongodb.org/downloads 에서 다운로드 받을 수 있다. 여기서는 Windows 64-bit Production Release 버전을 기준으로 한다.

zip 파일을 다운로드 받은 후에 C:\dev\mongodb-win32-x86_64-2.4.3 디렉토리에 압축을 풀었다.

2) Mongodb 구동

C:\dev\mongodb-win32-x86_64-2.4.3 에서 다음과 같은 명령어를 이용하여 구동한다.

.\bin\mongod --dbpath C:\dev\mongodb-win32-x86_64-2.4.3\data

3) 콘솔 확인

구동후에, http://localhost:28017 을 접속하면 아래와 같이 mongodb의 기본 관리 화면을 접속할 수 있다.



2.간단한 테스팅

인스톨이 끝났으면 간단한 테스트를 해보자, ./bin/mongo.exe를 수행하면 Java Script 기반의 쉘이 수행된다. 이해를 돕기 위해서 하나의 테이블에 Insert , select, delete, update를 수행하는 명령을 SQL 문장과 비교해서 소개한다.

 

Insert

SQL              : insert into users ("name","city") values("terry","seoul")

Mongo DB     : db.users.insert({_id:"terry",city:"seoul"})

 

Select

SQL              : select * from users where id="terry"

Mongo DB     : db.users.find({_id:"terry"})

 

Update

SQL              : update users set city="busan" where _id="terry"

Mongo DB     : db.users.update( {_id:"terry"}, {$set :{ city:"Busan" } } )

 

Delete

SQL              : delete from users where _id="terry"

Mongo DB     : db.users.remove({_id:"terry"})

 

간단하게 나마, mongodb query에 대해서 설명하였다.

조금 더 자세한 쿼리에 대한 설명은 http://docs.mongodb.org/manual/crud/ 를 참고하기 바란다.

 

3. 자바로 간단한 프로그램 작성하기

지금까지 설치와 간단한 쿼리 수행을 해봤다. 그러면 이번에는 다음 단계로 간단한 자바 클라이언트를 구현해보자, RDBMS를 이용하기 위해서 JDBC 드라이버를 사용한다면, mongodb는 전용 드라이버 mongo-java-driver 를 제공한다.

이 예제에서는 별도로 설치하기 보다는 아래와 같이 maven 빌드 스크립트에 dependency를 추가하여, 빌드시에 자동으로 라이브러리가 로딩 되도록 한다.

 

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">

  <modelVersion>4.0.0</modelVersion>

 

  <groupId>mongodb</groupId>

  <artifactId>simplemongo</artifactId>

  <version>0.0.1-SNAPSHOT</version>

  <packaging>jar</packaging>

 

  <name>simplemongo</name>

  <url>http://maven.apache.org</url>

 

  <properties>

    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>

  </properties>

 

  <dependencies>

        <dependency>

               <groupId>org.mongodb</groupId>

               <artifactId>mongo-java-driver</artifactId>

               <version>2.10.1</version>

        </dependency>

  </dependencies>

    <build>

        <plugins>

               <plugin>

                       <groupId>org.apache.maven.plugins</groupId>

                       <artifactId>maven-compiler-plugin</artifactId>

                       <version>2.3.1</version>

                       <configuration>

                              <source>1.6</source>

                              <target>1.6</target>

                       </configuration>

               </plugin>

                <plugin>

                       <groupId>org.apache.maven.plugins</groupId>

                       <artifactId>maven-eclipse-plugin</artifactId>

                       <configuration>

                              <downloadSources>true</downloadSources>

                              <downloadJavadocs>true</downloadJavadocs>

                       </configuration>

               </plugin>

 

        </plugins>

  </build>

</project>

 

 

다음은 localhost에 있는 mongodb instance에 하나의 document(RDBMS로 치면 row)를 insert하는 클라이언트 프로그램 예제이다.

package com.terry;

import com.mongodb.BasicDBObject;

import com.mongodb.DB;

import com.mongodb.DBCollection;

import com.mongodb.MongoClient;

import com.mongodb.ServerAddress;

 

public class SimpleMongo {

       

        MongoClient mongoClient = null;

        DB db=null;

       

        public void mongoTest(String ip,int port,String dbname) throws Exception{

              

               mongoClient = new MongoClient(new ServerAddress(ip,port));

               db = mongoClient.getDB(dbname);

              

               DBCollection userTable = db.getCollection("userTable");

               BasicDBObject doc = new BasicDBObject("name""MongoDB").

                append("type""database").

                append("count", 1).

                append("info"new BasicDBObject("x", 203).append("y", 102));

 

               userTable.insert(doc);

        }

       

        public static void main(String args[]) throws Exception{

               SimpleMongo testRunner = new SimpleMongo();

               testRunner.mongoTest("localhost", 27017, "testdb");

        }

}

 

간단한 예제이기 때문에 몇가지만 설명을 하면

com.mongodb.DB는 mySQL의 DB등과 같이, RDBMS의 DB의 개념을 표현한다. 그래서 mongoDB에 연결한후에, db를 getDB를 통해서 연결한다.

mongoDB에서 테이블은 collection이라는 개념으로 존재한다. Table에 insert를 하기 위해서는 getCollection 메서드를 사용해서 해당 테이블 객체를 가지고 온후, Json Object를 만들어서 Table (Collection)에 insert를 하면 된다.

저작자 표시
신고
현재 0 개의 댓글이 있습니다.
Comment

Blog

Database Technology for Large Scale Data, 박기은

2011.02.11 09:58 DataBase/NoSQL



출처 : http://blog.naver.com/naverdev/120113715336


Large Scale Data를 처리하기 위한 네 가지 접근법

인터넷 서비스는 전 세계를 고객으로 한다.
고객이 요구하는 데이터의 양도 많다.
이렇게 많은 양의 데이터 처리는 RDBMS로는 역부족이다. 
이렇게 많은 양의 데이터를 처리하는 새로운 방법이 필요하다. 
Large Scale Data를 다루기 위한 접근법 네 가지를 다루어보도록 하겠다.



“The End of Architectural Era”
우리가 흔히 접하고 있는 다양한 웹 서비스는 전세계의 사용자를 대상으로 언제 어디서나 접근 가능하게 되면서 사용되는 데이터의 규모가 눈깜짝할 사이에 엄청난 규모로 늘어 나게 된다. 최근에 스마트폰의 확산으로 버스 정보 앱이 퍼지면서 버스 정보 제공 사이트에 감당 못할 트래픽이 몰렸다는 사실은 이러한 점을 뒷받침하기도 한다.
더불어서, 급속도로 발전하는 웹 서비스 기술들은 전통적인 데이터베이스 이론들에 대한 반론들을 불러왔다. 더 이상 몇 대의 DB 서버가 SAN 스토리지를 사용하는 물리적인 환경에 국한되지 않고, 더 이상 트랜잭션 하나 하나와 레코드 하나 하나의 처리 결과보다 전체적인 효율과 서비스 가용성이 더 중요하게 되면서, 흔히 말하는 Big Data, 즉 Large Scale Data를 관리하고 사용하는 방식은, 전통적인 데이터베이스 이론과 현재의 RDBMS에는 적합하지 않다는 주장이 많이 제기되고 있다.
데이터베이스 계의 거장인 Michael Stonebraker가 2007년 VLDB에 기고한 논문인 “The End of Architectural Era”는 이러한 사실들을 지적하고 있다. 70년대 후반부터 발전하기 시작해 80년대 말에 꽃을 피운 relational DBMS 관련 기술은 “one size fits all” 형태의 범용 DBMS, 즉 OLTP이건, DW이건, Scientific이건, Web이건 어떠한 유형의 응용이건 데이터 저장 관리라면 무조건 사용될 수 있는 시스템을 만드는 것이 목표였으나 (그리고, 그 동안 어느 정도 잘 해오고 있었으나) 이제는 25년이 넘은 낡은 코드를 버리고 새로 시작해야 할 때라고 주창한다.
현재의 RDBMS는 다음과 같은 특징들로 규정될 수 있다.
  • 관계형 데이터 모델 (Relational Data Model) – 모든 데이터는 테이블 형태로 보여지며 상호 관계를 표현할 수 있다.
  • SQL의 사용 – 선언적 (declarative) 언어이기 때문에 질의 최적화기 (query optimizer) 기술이 많이 발달했다.
  • 디스크 기반의 저장 – 레코드들을 연속된 디스크 블록에 차례로 저장하고, 디스크 기반 색인 기법인 B-tree를 구현했다.
  • 동시성 제어 및 로그 기반의 복구 – 잠금(lock)이나 다중 버전(multi version)을 통해 한 데이터에 대한 동시 조작을 허용하면서도 무결성(integrity)를 보장한다.
이러한 특성을 모두 만족하며 “one size fits all”을 추구하는 범용 DBMS들은 텍스트 처리나 DW 등의 특정 영역에 특화된 시스템에 비해 성능은 떨어지고 기능도 부족하다고 여겨지고 있다. 특히나, 대량의 데이터를 다루는 웹 로그 분석이나 BI, 혹은 전세계 IDC들을 통해 운영되기 때문에 데이터 응답 속도가 더욱 중요한 대형 웹 서비스들의 경우, 기존 데이터베이스 기술의 총아인 상용 RDBMS만으로는 부족하다. 하루에 수백 기가에 해당하는 로그를 제 시간 내에 분석하기 위해서, 미국에 있는 사용자가 (DB 서버에) 저장한 블로그를 데이터를 영국에 있는 (웹 서버를 통해) 사용자가 실시간으로 읽을 수 있게 하기 위해서 새로운 데이터베이스 기술들이 연구되고 있다.

Database Technology for Large Scale Data
최근 5년 동안 각각의 영역별로 특화된 DBMS들이나 새로운 형태의 저장 구조를 갖는 데이터베이스 시스템들이 많이 연구 개발되고 있는데[1], 이들을 기술 유형으로 나누어보면 다음과 같다.

  • Massively Parallel Processing or Parallel DBMS – DBMS의 질의 수행을 병렬화하고, 질의를 쪼개 여러 대의 DBMS 노드에 분배해 동시에 수행하는 방식의 대량 연산이 가능한 시스템
  • Column-Oriented Database – 데이터를 디스크에 저장하는데 기존의 ow 방식, 즉 레코드 단위의 저장이 아니라 column 방식, 즉 같은 필드의 값들을 모아서 저장하는 시스템
  • Streaming Processing (ESP or CEP) – 시간의 흐름에 따라 데이터베이스의 내용이 계속 변한다는 개념으로, 끊임없이 입력되는 데이터를 대상으로 자료 처리(혹은 이벤트 처리)를 하는 시스템
  • Key-Value Store (with MapReduce programming model) – 관계형 데이터 모델보다 더 단순한 Key-Value 데이터 모델을 채택해서 단일 레코드 읽기 성능에 더욱 집중하는 저장 시스템


Massive Parallel Processing / Parallel DBMS
80년대부터 단일 프로세서에서 수행되는 DBMS로는 테라 바이트(TB) 규모에서 10,000 TPS 수준의 데이터 처리는 어려우니, SMP 하드웨어에서 “병렬 질의 처리 (Parallel Query Processing)”을 구현하는 기술들이 많이 발전하였다. 예를 들어 DB에서 항상 많은 시간이 걸리는 sort나 아니면 hash join은 자주 병렬 처리로 변경되고는 한다. 복잡 난해하고 긴 SQL 질의를 차례 차례 수행하는 것 보다는 pipelining 형태로 각 단계를 병렬화하는 것도 중요하게 사용되는 테크닉 중 하나이다. 병렬 처리 기술은 BI와 같은 데이터 분석에 많이 사용되고 있다.

이러한 병렬 DBMS 기술은 단일 노드 SMP 하드웨어를 넘어 shared-nothing 구조의 클러스터를 기반으로 하는 Massively Parallel Database 시스템으로 발전하고 있다. 예를 들어 6.5 PB 규모의 eBay의 DW DB나 10 규모의 데이터 분석을 위한 Yahoo의 Everest Architecture 등이 MPP 구조와 기술에 기반하고 있다. 

MPP DBMS의 또 다른 예로 오픈 소스 DBMS인 PostgreSQL을 이용하여 개발된 Greenplum과 Aster Data를 들 수 있다. Greenplum 시스템은 DW 시장에 강점을 보이고 있으며, eBay에 적용되어[2] 유명세를 탄 적이 있다. Greenplum과 Aster Data는 모두 기존의 관계형 데이터 모델과 SQL이라는 사용자에게 친숙한 도구를 그대로 살리면서 병렬 클러스터를 이용해서 대용량 데이터 처리를 수행한다. 데이터는 각 DB 노드에 적절하게 분할(partition 혹은 shard)되어 있고, 데이터 분석 SQL을 각 노드에서 병렬로 수행하는 구조이다.
이는 최근 많이 사용되는 MapReduce 프로그래밍 모델과 유사하며, Greenplum과 Aster Data 모두 SQL과 MapReduce를 결합해서 사용하는 기능을 제공한다. 다음은 Greenplum에서 사용하는 SQL과 처리 단계를 보여준다. 각 조건에 따라 데이터들이 분할되어 있으므로 각 DB 노드는 로컬 데이터에 대해서 SQL을 수행하고 (Map 단계로 생각할 수 있다.), 그 결과를 차례로 병합한다. (Reduce 단계로 생각할 수 있다.)



이러한 MPP 혹은 Parallel DBMS와 마찬가지로 대용량의 데이터 분석에 사용되는 기술이 구글이 발표한 MapReduce[3] 방식이다. Yahoo에서 MapReduce 방식의 프레임워크를 구현한 것이 Hadoop이다. 표 1은 Parallel Database와 Hadoop 시스템의 특징을 비교한  것이다.


Hadoop과 RDBMS의 결합 중의 주목할 만한 오픈 소스 프로젝트로 HadoopDB가 있다. HadoopDB는 SQL과 RDBMS를 기본으로 하고 MapReduce를 추가한 Greenplum이나 Aster Data와 달리 Hadoop 시스템을 기본으로 하고 HDFS 대신에 RDBMS를 사용하는 방식이다. HadoopDB가 SQL과 MapReduce를 결합하는 방식 중에 MapReduce 엔진 위에 SQL 기능을 얹은 방식이라면, Aster Data는 In-Database MapReduce라는 개념으로 불리며 SQL 질의에서 MapReduce 함수를 사용하는 방식이다. 좀 더 상세하게는 HadoopDB는 HDFS/Hadoop 시스템에 SQL-like 질의를 해주는 스크립팅 엔진인 Hive(Facebook이 개발하였다.)의 기능을 사용하면서 Map 함수의 입력을 HDFS 파일이 아닌 RDBMS 사용하는 방식이다.



Aster Data에서 사용되는 SQL/MR의 예는 다음과 같다. Java로 sessionize() MR 함수를 구현하고 이를 SQL 질의에 사용한 예이다.


Microsoft에서는 SCOPE라는 프로젝트를 발표한 적이 있는데, Windows와 .NET 환경에서 Hadoop과 같은 MapReduce 처리를 구현한 것이다.

Column-Oriented Databases
Column-oriented DBMS는 데이터를 row 순으로 저장하지 않고 column 순으로 저장하는 시스템이다. 일반적으로 RDBMS의 저장 시스템[4]은 아래 그림과 같이 테이블의 row 즉 레코드를 저장 관리한다. 하나의 디스크 페이지에 여러 레코드가 저장되는 구조이다. 

column store는 테이블의 동일 column 값들을 연속해서 저장 관리한다. 컬럼 별로 파일이 생성되고 디스크 페이지에는 동일 컬럼의 값들이 연속으로 저장되는 구조이다.




다음 표에서 나타낸 row store와 column store의 특징을 보면 column store는 읽기 위주의 대용량 데이터베이스인 DW나 BI, 혹은 IR 응용에 적합한 것을 알 수 있다. 그러나, 쓰기가 빈번한 경우에는 적합하지 않으며, 여러 조건이 주어지더라도 컬럼 하나씩 처리하게 되므로 질의 수행 중의 중간 결과의 크기가 row 방식의 질의 처리에 비해 크고 여러 단계를 거치게 되는 비효율적인 부분도 있다.



Column store의 단점을 보완하기 위해서 (1) Compression, (2) Late materialization[5], (3) Block iteration[6], (4) Invisible join 등의 기법이 사용된다. 그림 5 는 column store에서 SQL이 수행되는 과정을 표현한 것이다.

이상에서 살펴본 바와 같이 column store와 row store가 특성이 다르므로 일반적으로 어느 한 쪽이 일방적으로 좋다고 할 수는 없고 상호 보완적인 관계로, 실질적으로는 둘을 병합하여 사용하는 경우가 많다. Write 오퍼레이션은 row store DBMS에서 수행하고 어느 정도 모아서 column store로 옮긴 후 (이 때 컬럼 압축 등을 수행한다.) read 위주의 분석 작업 등을 수행하는 방식이다.



Stream Processing / ESP or CEP
Stream Processing 혹은 Event Stream Processing 혹은 Complex Event Processing은 실시간으로 변화되는 성격의 데이터를 데이터베이스 형태로 처리하고자 하는 데서 시작되었다. 이를 위해 SQL을 확장한 StreamSQL 표준이 제시되고 있으며, 대표적인 업체인 Truviso는 Continuous Analysis라는 개념으로 snapshot query와 continuous query 기능을 지원한다.[7] 반면에 일반적인 데이터 처리 방식은 외부 이벤트를 데이터베이스에 (변환을 거쳐) 저장하고, 저장이 완료되면 분석 질의를 수행하고, 이후 결과를 얻는 store-first-query-later 방식이라고 할 수 있다.
SQL이 일정 개수의 레코드가 있는 테이블에 대한 연산이라고 한다면 StreamSQL은 테이블을 튜플이 끊임없이 생산되는 (즉 일정 시간에 모든 데이터가 존재하지 않는다.) 스트림으로 보고 처리하는 SQL이다. 다음 그림은 StreamSQL의 시초라고 할 수 있는 Aurora 시스템의 구조를 나타낸 것이다.

요즘은 Stream Processing의 개념을 웹 서비스에 적용하기도 한다. 보통 웹 서비스는 미리 준비된 서비스 DB의 내용을 제공하거나 UCC 데이터를 DB에 저장하고 조회하게 되는데, 이 경우 DB의 변경이 그리 빈번하지는 않다. (아래 그림의 첫 번째) 그러나, 검색이나 로그 분석과 같은 대용량 데이터를 다루는 경우, 실시간 처리를 지향하면서 입력 데이터가 다 주어질 때까지 기다리는 것이 아니라 데이터 입력과 처리가 끊임없이 계속되는 시스템을 만들기도 한다. (아래 그림의 세 번째) 나아가서 웹 서비스의 경우도 센서 디바이스를 통해 데이터가 끊임없이 생산되거나 스마트 폰과 같은 다수의 사용자가 데이터를 생산하고 소비하는 모델에서는 stream processing이 필요하게 된다.




Key-Value Store / MapReduce
요즘의 Key-Value Store의 대명사는 Google의 BigTable 혹은 Amazon의 Dynamo (simpleDB) 일 것이다. 그러나, key-value store는 RDBMS가 있기 전부터 존재하던 아주 전통적인 저장 시스템이다. 예를 들어 UNIX의 dbm 라이브러리라든지 좀 더 발전된 BerkelyDB 등은 꽤 오래 전부터 존재했고 어찌 보면 RDBMS의 전신이라고 할 수도 있다. 요즘은 UNIX의 dbm 라이브러리를 새로 구현한 Tokyo Cabinet이 새로이 주목을 받기도 한다.
전통적인 key-value store와 최근에 웹 서비스 분야에서 각광을 받는 key-value store의 차이는 아마 DFS 기반인가 아닌가 일 것이다. BigTable이나 Dynamo 그리고 Yahoo의 PNUT 등도 모두 분산 환경을 지원한다.  단일 하드웨어 서버(혹은 SAN 같은 스토리지 시스템)로는 필요한 데이터 용량을 감당하지 못하고, 다량의 서버를 사용하는 분산 스토리지가 요구되었고, 분산 스토리지는 서비스 가용성과 부하 분산, 그리고 비용 효율 측면에서 RDBMS에 비해 경쟁력이 있는 저장 시스템이다. 따라서, 웹 서비스 혹은 단수 자료 처리 등에서 사용하기 위해 single key – value pair 정도의 기능을 갖는 extendible hash 형태의 distributed key-value store가 등장하였고 주목을 받고 있다.
Key-value store는 그 특성상 SQL과 같은 강력한 선언적 (declarative) 질의를 사용할 수 없으므로, 이를 보완하고자 MapReduce라는 형태의 프로그래밍 모델도 제안되어 많이 사용되고 있다. 그리고, Amazon의 Dynamo (simpleDB)나 Yahoo의 PNUT (Sherpa)의 예에서 볼 수 있듯이 key-value store는 웹 서비스 개발을 위한 클라우드 DB 서비스로 적합한 구조를 가지고 있다. 대부분 single value 조회이므로 Get/Set 함수와 같은 기본 조작 함수만으로도 사용이 충분하며, HTTP나 REST와 같은 웹 서비스 프로토콜로 인터페이스를 제공하기도 편리하기 때문이다. Key-value store는 단순한 조작과 빠른 성능, 그리고 확장성(scalability)과 가용성(availability)가 중요한 경우에 아주 유용한, RDBMS와는 확연히 다른 영역에 대한 데이터베이스 기술이라고 할 수 있다.
마치며
데이터베이스의 규모가 커짐과 동시에 더욱 빠른 성능이 요구되면서 기존의 전통적인 데이터베이스 기술을 넘어서는 다양한 노력이 진행되고 있다. 하지만, 아직은 Oracle과 같은 상용 RDBMS나 MySQL과 같은 오픈 소스 RDBMS 들이 좀 더 넓은 영역에서 사용되고 있다는 사실만으로도 RDBMS의 몰락을 섣불리 논의할 수는 없다. 오히려 RDBMS를 기반으로 하는 다양한 해법들이 제시되고 있다고 할 수도 있다. 다만, Google의 BigTable이나 Amazon의 Dynamo, 그리고 BerkelyDB나 Tokyo Cabinet 같은 다양한 key-value store, 특히 distributed key-value store의 경우 기존에 없던 다양한 활용 가치가 있는 것은 사실이다. 


1 물론 연구 단계를 넘어 오픈 소스화 하거나 상용화에 성공한 케이스도 많이 있다. 또, 큰 회사들이 자체적으로 만들어 사용하는시스템 들도 많이 있다. 그렇지만, 아직까지는 대표적인 상용 RBDMS인 Oracle을 이겼는가에 대한 답은 하기가 어렵다.

2 Greenplum 자료에 의하면 DB 96 노드로 6.5 PB 크기에, 17 trillion 레코드 규모(매일 150 billion 레코드가 새로 생김)를 처리하고 있다고 한다.

3 MapReduce를 새로운 기술이나 시스템으로 보기 보다는 일종의 프로그래밍 모델 혹은 패턴과 프레임워크라고 하는 것이 적절하다. MapReduce 논문이 특허로 채택되었을 때 컴퓨터 과학에서 수십 년 된 Divide & Conquer 알고리즘 방식과 무슨 차이냐는 논란이 일었었다.

4 DBMS는 저장 시스템(Storage System)과 질의 수행기(Query Processor)로 이루어진다고 볼 수 있다. 저장 시스템은 디스크에 데이터를 효율적으로 저장하는 파일 구조와 일관성을 보장하기 위한 트랜잭션 로깅 및 동시성 제어 등의 기능을 가지고 있다.

5 질의 처리 중간 결과를 매번 생성하지 않고 position (컬럼 내에서의 해당 값 위치) 리스트를 생성해 다음 단계로 넘기는 방식으로 materialization, 즉 디스크에서 실제 데이터를 읽는 비용을 줄이는 기법

6 Vectorized processing 이라고도 함

7 Truviso 역시 PostgreSQL 오픈 소스 DBMS를 확장하여 사용하고 있다. 

[참고 자료]
Massive Parallel Processing / Parallel DBMS
Aster nCluster In-Database MapReduce, Aster Data Systems
SQL/MapReduce: A practical approach to self-describing, polymorphic, and parallelizable user-defined functions, Eric Friedman (Aster Data), VLDB 2009
Greenplum DW Appliance 소개: Technical View, Sun
Sun Oracle Exadata and Database Machine Overview, Oracle, 2009
MAD Skills: New Analysis Practices for Big Data, Jeffrey Cohen (Greenplum), VLDB 2009
HadoopDB: An Architectural Hybrid of MapReduce and DBMS Technologies for Analytical Workloads, Azza Abouzeid (Yale), VLDB 2009
Osprey: Implementing MapReduce-Style Fault Tolerace in a Shared-Nothing Distributed Database, Christopher Tang (MIT), http://www.dbms2.com
Parallel Database Systems: The Future of Database Processing or a Passing Fad?, David J. DeWitt (UW), 1991
Parallel Database Systems: The Furture of High Performance Database Processing, David J. DeWitt (UW), 1992
Hive - A Warehousing Solution Over a Map-Reduce Framework, Ashish Thusoo (Facebook), VLDB 2009 
HIVE Data warehousing using Hadoop, Facebook Data Team
Column-Oriented Databases
C-Store: A Column-oriented DBMS, Mike Stonebraker (MIT), VLDB 2005
Column-Oriented Database Systems, VLDB 2009 Tutorial
Column-Stores vs. Row-Stores: How Different Are They Really?, Daniel J. Abadi (Yale) , SIGMOD 2008
A Comparison of C-Store and Row-Store in a Common Framework, Alan Halverson (UW), VLDB 2006
Read-Optimized Databases, In Depth, Allison L. Holloway (UW), VLDB 2008
Integrating Compression and Execution in Column Oriented Database Systems, Daniel J. Abadi (MIT), SIGMOD 2006
Query Execution in Column-Oriented Database Systems, Daniel J. Abadi (MIT), MIT 2008
Performance Tradeoffs in Read-Optimized Databases, Stavros Harizopoulos (MIT), VLDB 2006
Database Architecture Evolution: Mammals Flourished long before Dinosaurs became Extinct, Stefan Manegold (CWI), VLDB 2009
MonetDB/SQL Meets SkyServer: the Challenges of a Scientific Database, M. Ivanova (CWI), SSDBM 2007
Sybase IQ, An Evaluation paper by Bloor Research, 2006
The Vertica® Analytic Database Technical Overview White Paper, Vertica Systems Inc, 2008
Key-Value Store / MapReduce
MapReduce: Simplified Data Processing on Large Clusters, Google, OSDI 2004
BigTable: A Distributed Storage System for Structued Data, Google, OSDI 2006
Hive - A Warehousing Solution Over a Map-Reduce Framework, Ashish Thusoo (Facebook), VLDB 2009 
HIVE data warehousing using Hadoop, Facebook Data Team
Hadoop Architecure and its Usage at Facebook, Dhruba Borthakur (Apache), 2009
Data Intensive Super Computing, Randal E. Bryant (CMU)
Cloud Architecture, Jinesh Varia (Amazon Web Services)
GAIA & Neptune, Joon Kim
Hadoop과 오픈소스 소프트웨어를 이용한 비지니스 인텔리전스 플랫폼 구축, 김영우 (다음 커뮤니케이션)
Stream Processing
Toward a Streaming SQL Standard, Namit Jain (Oracle), VLDB 2008
Big Data and Real-time Structured Data Analytics, Ben Lorica (O'Reilly), 2009
Aurora: A New Model and Architecture for Data Stream Management, Daniel J. Abadi (Brandeis University), VLDB 2003
Continuous Analytics technical whitepaper, Truviso, 2010
기타
Handling Large Datasets at Google: Current Systems and Future Directions, Jeff Dean (Google)
Challenges in Building Large-Scale Information Retrieval Systems, Jeff Dean (Google), WSDM 2009
A Large Scale Search Engine System in 2010, Shihua Ming (Yanbian), 2010
PNUTS: Yahoo!’s Hosted Data Serving Platform, Brian F. Cooper, (Yahoo! Research), VLDB 2008
Sherpa: Cloud Computing of the Third Kind, Raghu Ramakrishnan (Yahoo! Research and Platform Engineering Team)
PNUTS - Platform for Nimble Universal Table Storage, http://research.yahoo.com/project/212
Sherpa: Hosted Data Serving | Yahoo! Research, http://research.yahoo.com/node/2139
http://www.microsoft.com/windowsazure/sqlazure
Overview of Microsoft SQL Azure Database, Microsoft, 2009
Simiarities and Differences of SQL Azure and SQL Server, Microsoft, 2009
Introducing the windows azure platform, David Chappell, 2009
http://cassandra.apache.org
저작자 표시
신고
현재 0 개의 댓글이 있습니다.
Comment

Blog

오 아름답도다. Cassandra

2011.02.11 09:57 DataBase/NoSQL



출처 : http://blog.naver.com/naverdev/120116325495

 

마법과도 같이이 글을 읽고 난 여러분들은 다음과 같은 것들을 할 수 있게 됩니다.

 NoSQL 세계의 선봉장인 Cassandra 데이터베이스의 존재를 인지한다.

 Cassandra의 특징을 간략하게 이해한다.

 Cassandra를 간단하게 설치하고 기본 기능을 이용하는 방법을 안다.

 


 
 


Cassandra

NoSQL 세계에서 Cassandra의 위치는 절대적입니다. Voldemort, MongoDB, TokyoCabinet/Tyrant 등 쟁쟁한 NoSQL 제품군 중에서 왜Cassandra가 독보적인 위치를 점유하고 있는지 말씀드리고 싶습니다.

Cassandra는 원래 Facebook에서 만들었던 오픈소스 Distributed Database였습니다현재는 Apache 프로젝트로 자리를 옮겼습니다.

Cassandra의 가장 큰 장점은 ‘상대적으로 다른 NoSQL DB에 비하여 레퍼런스가 많고활발하게 개발되고 있다.’는 점입니다상당히 다양한 분야와 많은 기업에서 Cassandra를 사용하고 있으며, 2010년 아파치 Top-level project로 승격되었기 때문에 개발 과정이 매우 잘 관리되고 있다고 할 수있습니다.

Cassandra의 대표적인 활용 사례는 Facebook inbox search(페이스북 사용자 프로필 내부 검색)입니다여기서 사용하는  Cassandra클러스터 규모는 600개 이상의 CPU 코어와 120 테라바이트 이상의 용량을 포함하고 있습니다.[1] Twitter에서도 일부 서비스의 스토리지를 Cassandra로 전환하려는 움직임이 있으며[2]소셜 뉴스 사이트인 Digg.com(Alexa.com 순위 98)에서도 주요 서비스에 사용되고 있습니다.[3] 이 외에 텍스트 검색 오픈소스인 Lucene에 스토리지 부분을 Cassandra로 변환한 Lucandra도 만들어 지는 등[4] 여러 방면에서 사용된 경험이 많이 축적되어 있습니다.

 

특징

Cassandra는 구글에서 만든 BigTable[5]과 아마존에서 만든 Dynamo[6]의 특징을 합쳐서 생겨난 데이터베이스입니다구체적으로는BigTable의 특징인 Column-oriented model, memTable 그리고 SSTable 방식의 쓰기 방식을 채택하였고, Dynamo의 특징인 높은 가용성속도와 일관성 사이의 trade off 조절 기능을 도입하였습니다.[7]

 

Scalability

Scalability Cassandra의 가장 큰 특징입니다장비를 추가하고 제거하는 과정은 매우 단순합니다단지 새로운 장비를 추가하고 설정을 바꾼 후 Cassandra를 재시작하면 됩니다. Cassandra는 노드가 추가되면 자동적으로 Consistent hashing을 통해 각 노드가 가진 키의 개수를 맞춥니다.

 

Fault-Tolerant

Cassandra의 또 다른 특징은 single point of failure가 없다는 것입니다이 때문에 어떤 노드에 장애가 발생해도 전체 시스템은 멈추지 않습니다.

여러 노드가 한꺼번에 멈춰도 운 나쁘게 같은 데이터의 Replica가 모두 멈추는 것이 아니라면 read에는 문제가 없고, write replica에 관계없이 항상 가능합니다.

 

Consistency-Partition tolerance 사이의 균형

대부분의 NoSQL 데이터베이스들은 Availability Partition Tolerance를 달성하고, Consistency를 약하게 지원하는 방식을 채택했으나Cassandra Read replica count, write replica count를 설정하는 방식으로 Consistency Availability 사이의 균형을 사용자가 선택할 수 있도록 하였습니다설정하기에 따라 Consistency를 강화시켜 사용할 수도 있고, Availability를 강화시켜 사용할 수도 있습니다물론 두 가지 모두를 강화시키는 것은 불가능합니다.(CAP Theorem)

 

 

Column-oriented Data Model

Cassandra Column-oriented Data Model을 사용합니다.(Column-Oriented에 대한 설명은 'Database Technology for Large Scale Data편에 자세히 나와 있습니다.)


간단히 말해 RDBMS row를 레코드 형태로 저장하지만, Column-oriented Database에서는 Column을 모아 저장합니다당연히 연관된 데이터를 읽기에 적합합니다

각 컬럼은 name, value, timestamp를 가지고 있습니다. Timestamp를 제외하면 각 Key Java HashMap, 또는 HashMapHashMap 구조가 붙어있는 형태입니다.

 

아래 그림을 보면 이해가 빠를 것입니다.


 

데이터의 key ‘안일운’, ‘김정일이며, ‘안일운’ 키가 가진 컬럼들은 ‘’, ‘용돈이며 ‘김정일’ 키가 가진 컬럼들은 ‘’, ‘용돈’, ‘부인’, ‘차고입니다각 컬럼은 컬럼 제목(용돈)과 컬럼 값(178, 50만원)을 가지고 있습니다.‘김정일키에는 ‘안일운키에는 없는 ‘부인 ‘차고’ 컬럼이 있습니다. ‘차고’ 컬럼은 여러 개의 하위 컬럼을 또 가질 수 있습니다컬럼을 여러 개 포함하는 컬럼은 SuperColumn이라고 합니다.

            

178

용돈

50


15

용돈

30

부인

4

차고

2

람보르기니

4

벤츠

2

탱크

실제로 Cassandra에서 Column-oriented Data Model을 다루다 보면 Keyspace, Column Family과 같은 용어부터 Cassandra 고유의 자료형(Type) 등 관계형 데이터베이스 세계에서 경험이 많았던 분들에게는 생소한 것들이 많이 등장합니다더 자세한 설명과 용어 해설은Cassandra 위키 페이지[8] 및 기타 웹사이트들[9,10,11]를 통해 읽으실 수 있습니다.

 

High Performance

Write

Cassandra Read 연산보다 Write연산이 훨씬 더 빠릅니다키의 위치에 따라 데이터 파일 중간 중간에 row를 끼워 넣는 방식이 아니라, SSTable(Sorted String Table)에 데이터를 Append한 후 SSTable을 통째로 저장하기 때문입니다데이터를 넣을 위치를 찾을 필요가 없어 일반적으로 관계형 데이터베이스보다 더 빠른 쓰기 속도를 보여줍니다.

 

Read

Write 연산으로 만들어진 SSTable은 일정 크기가 되면 key에 따라 정렬된 후 디스크에 기록됩니다. Read 연산 역시 기존 관계형 데이터베이스와는 달리 SSTable bloom filter(어떤 데이터가 어떤 집합에 속해있는지 파악하기 위한 방법)를 통해 읽어올 데이터를 가지고 있는지 알아 낸 후 인덱스를 통해 정보를 읽어냅니다.

 

아직까지 공식적인 Read/Write 속도 테스트 결과는 없는 것으로 알고 있습니다다만 기존 관계형 데이터베이스(CUBRID, MySQL, Oracle)와의 속도 직접 비교는 무의미할 수 있습니다데이터를 다루는 용도 및 목적 자체가 관계형 데이터베이스와 크게 다를 수 있기 때문입니다.

 

Lockless

Read/Write 연산 모두 lockless, 즉 한 스레드가 연산을 수행하는 동안 다른 스레드가 해당 데이터에 접근하지 못하는 경우가 없습니다동시성 문제(concurrency issue)로 인한 성능저하는 발생하지 않습니다.

 

제약사항

특징들을 나열해 놓고 보면 마치 개발자들이 원하고 원하던 꿈의 스토리지처럼 들리지만제약사항도 있습니다.

무엇보다 Cassandra 1.0 버전이 아직 나오지 않은개발 중인 오픈 소스입니다상용화된 관계형 데이터베이스또는 MySQL같은 유구한 역사를 자랑하는 제품에 비해 기능 자체는 많이 부족한 상황입니다데이터를 Cassandra에 보관시켜놓고 운영 및 관리를 하다 보면MySQL의 편리한 도구들이 금방 그리워집니다버전 업 속도로 빠르고 기능추가기존 버전의 문제점 해결이 속속 이루어지고는 있으나 실제 서비스에 사용되는 코드의 일부가 되기에는 부족한 점이 많습니다. Cassandra를 활용하는 기업들도 주력이 아닌 2선급 서비스에 적용하거나백엔드 인프라로 활용하는 경우가 대부분입니다.

하지만 이런 단점에도 불구하고, Cassandra NoSQL 데이터베이스 중 가장 많은 기능을 가지고 있고 유망한 오픈 소스임에는 이의를 제기할 수 없다고 생각합니다.

 

Cassandra 설치와  동작

Cassandra의 설치는 비교적 간단한 편입니다.

Cassandra 홈페이지(http://cassandra.apache.org)에서 바이너리 파일을 다운로드 받은 후 압축을 풀기만 하면 됩니다.

Cassandra를 구동시키기 전 설정파일을 고쳐야합니다.

시험적으로 서버 1대만을 사용할 경우기본 설정 파일을 그대로 써도 문제가 없습니다다만 Cassandra 데이터 파일과 로그파일이 들어갈 디렉토리가 존재하는지 확인하고없다면 만들어 줄 필요는 있습니다.설정파일인 conf/storage-conf.xml을 보면CommitLogDirectory(로그 파일이 들어갈 디렉토리를 지정항목과 DataFileDirectories(실제 데이터 파일이 들어갈 디렉토리를 지정항목을 적절히 수정해 주면 됩니다.

<CommitLogDirectory>

     /home1/data/cassandra/commitLog

</CommitLogDirectory>

<DataFileDirectories>

  <DataFileDirectory>

   /home1/data/cassandra/dataFile

  </DataFileDirectory> 

</DataFileDirectories>

만약 서버 2대 이상을 사용하는  클러스터를 구성하고 싶다면각 서버에 Cassandra를 설치한 후 설정파일을 각각 고쳐주어야 할 필요가 있습니다클러스터 구성 시 추가적으로 고쳐주어야 할 설정은 시드 설정과 통신 설정입니다.

 

시드(Seed), Cassandra 클러스터에 새로 추가되는 노드가 들어올 때이 신입 노드에게 노드들이 연결된 링 구조를 가르쳐 주는 역할을 수행합니다설정파일의 Seeds 항목을 보면 이를 설정할 수 있습니다아래 예시에서는 krs1164.nhncorp.com 호스트를 가진 장비를 시드로 지정하였습니다여러 개를 지정할 수도 있습니다.

<Seeds>

  <Seed>krs1164.nhncorp.com</Seed> 

</Seeds>

또한 클러스터의 노드들이 서로 통신할 때 사용하는 Gossip(클러스터의 링 구조에 관한 정보를 주고 받는데 사용) Thrift(클러스터가 실제로 저장하는 데이터를 교환하는데 사용) IP 인터페이스를 설정해야 합니다이들은 각각 ListenAddress ThriftAddress 항목에서 지정할 수 있습니다.

아래 예시에서는 krs1164.nhncorp.com에서 다른 Cassandra 클러스터의 노드와 통신하기 위해 20007 20008 포트를 사용하도록 해 놓았습니다.

<ListenAddress>

  krs1164.nhncorp.com

</ListenAddress>

 

<StoragePort>20007</StoragePort>

<ThriftAddress>

  krs1164.nhncorp.com

</ThriftAddress>

<ThriftPort>20008</ThriftPort>

 

 

설정이 끝났으면 클러스터 내 모든 노드에서 각각 /bin/cassandra를 실행하면 됩니다기동되는 시간은 그리 길지 않습니다.

모든 노드가 정상적으로 가동되고 나면 Cassandra 클러스터가 제대로 동작하고 있는지 확인해 봅니다. /bin/nodetool을 사용하면 운영에 필요한 정보들을 얻을 수 있습니다아래 예시에서는 이미 어느 정도 사용한 Cassandra 클러스터의 링 구조를 보여주고 있습니다.

  


여기서 설명한 것 외에도설정파일에서는 많은 것들을 변경 할 수 있습니다. Memtable(Cassandra에서 key에 해당하는 value(Row)에 대한 cache) 크기나 응답대기 시간 같은 내부 동작 설정부터 데이터 저장 구조까지 모두 설정하도록 되어 있으므로 필요에 따라 많은 수정을 거쳐야 합니다.

 

설치와 설정파일에 관련된 정보가 완벽하게 정리된 가이드 같은 것은 아직 없습니다최신 버전이 0.7.0 beta인 오픈 소스라 어쩔 수 없는 상황이라고도 보입니다만 체계적인 문서화가 미흡한 점은 분명 아쉬운 부분입니다. Cassandra 개발 웹페이지(http://cassandra.apache.org)의 위키메일링 리스트 등을 열심히 탐독하다 보면 다양한 설정과 운영 방법에 대한 정보를 더 얻을 수 있습니다.

 

API 사용

Cassandra는 클라이언트와의 통신을 위해 Thrift API를 제공합니다. Thrift Facebook에서 개발한 RPC이며 다양한 언어를 지원합니다. Thrift도 현재 아파치 인큐베이터를 통해 개발되고 있습니다.

Cassandra 소스코드를 다운로드 받아놓았다면 이 소스코드에 포함된 Cassandra 클라이언트 패키지와 Thrift를 이용하여 클라이언트 프로그램을 작성할 수 있습니다.

 

Cassandra의 기본 설정파일인 conf/storage-conf.xml을 보면 Keyspace1이라는 키스페이스(MySQL Database에 해당하위에Standard1이라는 Column Family(MySQL Table에 해당)가 이미 정의되어 있습니다.

이 키스페이스에 값을 쓰고읽어오는 자바 소스코드는 다음과 같습니다[14]에서 발췌한 내용을 일부 수정하였습니다소스코드는 찬찬히 들여다보시면 어렵지않게 이해하실 수 있으실 것입니다.

 

 

자바 뿐 아니라 PHP, C++, Python 등에서도 Cassandra의 모든 기능을 사용할 수 있습니다다른 언어로 된 소스코드도 샘플코드 페이지(http://wiki.apache.org/cassandra/ThriftExamples )에서 찾아보실 수 있습니다.


 

package cassandra.clientest;

 

import java.io.UnsupportedEncodingException;

import java.util.Date;

import java.util.List;

 

import org.apache.cassandra.thrift.Cassandra;

import org.apache.cassandra.thrift.Column;

import org.apache.cassandra.thrift.ColumnOrSuperColumn;

import org.apache.cassandra.thrift.ColumnParent;

import org.apache.cassandra.thrift.ColumnPath;

import org.apache.cassandra.thrift.ConsistencyLevel;

import org.apache.cassandra.thrift.InvalidRequestException;

import org.apache.cassandra.thrift.NotFoundException;

import org.apache.cassandra.thrift.SlicePredicate;

import org.apache.cassandra.thrift.SliceRange;

import org.apache.cassandra.thrift.TimedOutException;

import org.apache.cassandra.thrift.UnavailableException;

import org.apache.thrift.TException;

import org.apache.thrift.protocol.TBinaryProtocol;

import org.apache.thrift.protocol.TProtocol;

import org.apache.thrift.transport.TSocket;

import org.apache.thrift.transport.TTransport;

 

public class Main {

 

  public static final String UTF8 = "UTF8";

 

  public static void main(String[] args) throws UnsupportedEncodingException,

                InvalidRequestException, UnavailableException, TimedOutException,

                TException, NotFoundException {

    // 접속할 노드를 지정하여 소켓을 정의합니다.

    // 접속할 호스트는 Cassandra 클러스터 중 어떤 것이 되어도 상관없습니다.

    TTransport tr = new TSocket("krs1164.nhncorp.com"20008);

    TProtocol proto = new TBinaryProtocol(tr);

    Cassandra.Client client = new Cassandra.Client(proto);

    tr.open();

 

    String keyspace = "Keyspace1";

    String columnFamily = "Standard1";

    String keyUserID = "1";

 

    // insert data

    long timestamp = System.currentTimeMillis();

 

    ColumnPath colPathName = new ColumnPath(columnFamily);

    colPathName.setColumn("fullName".getBytes(UTF8));

 

    client.insert(keyspacekeyUserIDcolPathName,

        "Chris Goffinet".getBytes(UTF8), timestamp, ConsistencyLevel.ONE);

 

    ColumnPath colPathAge = new ColumnPath(columnFamily);

    colPathAge.setColumn("age".getBytes(UTF8));

 

    client.insert(keyspacekeyUserIDcolPathAge"24".getBytes(UTF8),

                                timestamp, ConsistencyLevel.ONE);

 

    // read single column

    System.out.println("single column:");

    Column col = client.get(keyspacekeyUserIDcolPathName,

                                ConsistencyLevel.ONE).getColumn();

 

    System.out.println("column name: " new String(col.nameUTF8));

    System.out.println("column value: " + new String(col.valueUTF8));

    System.out.println("column timestamp: " + new Date(col.timestamp));

 

    // read entire row

    SlicePredicate predicate = new SlicePredicate();

    SliceRange sliceRange = new SliceRange();

    sliceRange.setStart(new byte[0]);

    sliceRange.setFinish(new byte[0]);

    predicate.setSlice_range(sliceRange);

 

    System.out.println(" row:");

    ColumnParent parent = new ColumnParent(columnFamily);

    List<ColumnOrSuperColumn> results = client.get_slice(keyspace,

                                keyUserIDparentpredicate, ConsistencyLevel.ONE);

    for (ColumnOrSuperColumn result : results) {

      Column column = result.column;

          System.out.println(new String(column.name, UTF8) + " -> "

                    new String(column.value, UTF8));

    }

    tr.close();

  }

}


가만히 살펴보면 범용 프레임워크인 Thrift를 이용해 Cassandra 노드와 통신하는 것은 그리 깔끔하지 못하다는 느낌을 받을 수 있습니다.

뿐만 아니라 한 대의 노드가 아닌 클러스터를 상대로 데이터 입출력 작업을 하다 보면 어떤 노드가 사용불능일 때의 처리, Connection Pooling 등의 기능이 필요해 질 때가 많습니다.

이러한 필요에 의해 Cassandra 클러스터에 접근하는 Thrift API를 한번 더 포장해서 만든 Cassandra 클라이언트 API도 공개되어 있습니다.  Cassandra 고수준 클라이언트 소개 페이지(http://wiki.apache.org/cassandra/ClientOptions)에서 찾아 볼 수 있으며자바용 클라이언트로는 Hector[15] Pelops[16]가 유명합니다개인적인 경험으로는 Pelops 쪽이 좀 더 깔끔한 클라이언트 코드를 만드는 데 도움이 되었으나, Cassandra 버전업에 의해 기능이 변경되거나 추가되는 것을 반영하는 속도는 Hector에 비해서 좀 느린 감도 있었습니다.

Reference

[1] http://www.facebook.com/note.php?note_id=24413138919

[2] http://nosql.mypopescu.com/post/407159447/cassandra-twitter-an-interview-with-ryan-king

[3] http://about.digg.com/node/564

[4] http://blog.sematext.com/2010/02/09/lucandra-a-cassandra-based-lucene-backend/

[5] Fay Chang, Jeffrey Dean, Sanjay Ghemawat, Wilson C. Hsieh, Deborah A. Wallach, Mike Burrows, Tushar Chandra, Andrew Fikes, and Robert E. Gruber, “Bigtable : A Distributed Storage System for Structured Data”, OSDI'06: Seventh Symposium on Operating System Design and Implementation, Seattle, WA, November, 2006.

[6] Giuseppe DeCandia, Deniz Hastorun, Madan Jampani, Gunavardhan Kakulapati, Avinash Lakshman, Alex Pilchin, Swami Sivasubramanian, Peter Vosshall and Werner Vogels, “Dynamo: Amazon's Highly Available Key-Value Store”, in the Proceedings of the 21st ACM Symposium on Operating Systems Principles, Stevenson, WA, October 2007.

[7] Avinash Lakshman, Prashant Malik, “Cassandra – Adecentralized Structured Storage System”,http://www.cs.cornell.edu/projects/ladis2009/papers/lakshman-ladis2009.pdf

[8] http://wiki.apache.org/cassandra/DataModel

[9] http://arin.me/blog/wtf-is-a-supercolumn-cassandra-data-model

[10] http://www.sodeso.nl/?p=108

[11] http://www.sodeso.nl/?p=207

[12] http://github.com/rantav/hector

[13] http://github.com/s7/scale7-pelops

[14] http://wiki.apache.org/cassandra/ThriftExamples

저작자 표시
신고
현재 0 개의 댓글이 있습니다.
Comment

Blog

Cassandra db 로컬설치

2011.02.11 09:48 DataBase/NoSQL


출처 : http://blog.naver.com/linesoft/140116791800

Cassandra db 를 내 컴퓨터 (window xp)에 설치 해보겠다.
Cassandra db 에 대한 설명은 구지 하지 않겠다. 최근에 페이스북, 트위터등 sns 서비스에서 사용하는 Nosql DB의 대표적인 오픈소스 DB 이다.

Cassandra apache URL
http://cassandra.apache.org

설치 파일 다운로드 url
http://cassandra.apache.org/download/
여기서 최신 버젼인 0.6.6. 버젼을 다운받는다.
http://www.apache.org/dyn/closer.cgi?path=/cassandra/0.6.6/apache-cassandra-0.6.6-bin.tar.gz

설치하기전에 jdk1.6 최신 버젼이 설치되어야 한다.(cassandra db는 java 기반이다.)
자신의 컴퓨터에 최신 jdk가 설치되고 환경변수 JAVA_PATH에 지정되있으면 된다.

다운 받고 해당 압축파일을 풀면
apache-cassandra-0.6.6 폴더가 생성된다. DB 위치다.
apache-cassandra-0.6.6/bin 폴더에 들어가면 cassandra , cassandra-cli 가 있다.
DB와 Client 실행파일이다.

cassandra 명령어를 실행하면

D:\heroes\dev\db\apache-cassandra-0.6.6\bin>cassandra
Starting Cassandra Server
... 중간생략
 INFO 21:49:45,515 Starting up server gossip
 INFO 21:49:45,578 Binding thrift service to localhost/127.0.0.1:9160
 INFO 21:49:45,609 Cassandra starting up...
 INFO 21:49:45,625 Compacted to D:\var\lib\cassandra\data\system\LocationInfo-9-Data.db.  1344/563 bytes for

이렇게 DB가 실행된다.

Client를 실행해보자.

D:\heroes\dev\db\apache-cassandra-0.6.6\bin>cassandra-cli
Starting Cassandra Client
Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/cassandra/cli/CliMain
Caused by: java.lang.ClassNotFoundException: org.apache.cassandra.cli.CliMain
        at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
Could not find the main class: org.apache.cassandra.cli.CliMain.  Program will exit.

실행해보면 이렇게 에러가 발생한다. 살짝 당황했다. 하지만 java 개발자라면 자주 보았던 
NoClassDefFoundError 가 발생한다. 왜 이럴까 생각한다. 라이브러리 누락되거나 위치가 잘못되어서
참조하지 못하고 있다.
cassandra-cli.bat 파일을 열어서
for %%i in ("%CASSANDRA_HOME%\lib\*.jar") do call :append "%%i" 구문을
for %%i in ("%CASSANDRA_HOME%\..\lib\*.jar") do call :append "%%i" 로 변경한다.

그리고 다시 실행하면 될것이다

D:\heroes\dev\db\apache-cassandra-0.6.6\bin>cassandra-cli
Starting Cassandra Client
Welcome to cassandra CLI.

Type 'help' or '?' for help. Type 'quit' or 'exit' to quit.
cassandra>


D:\heroes\dev\db\apache-cassandra-0.6.6\bin>cassandra-cli -host localhost -port 9160
Starting Cassandra Client
Connected to: "Test Cluster" on localhost/9160
Welcome to cassandra CLI.

Type 'help' or '?' for help. Type 'quit' or 'exit' to quit.
저작자 표시
신고
현재 0 개의 댓글이 있습니다.
Comment

Blog

Cassandra [출처] Cassandra - facebook|작성자 녹천

2011.02.11 09:42 DataBase/NoSQL


 

 

[카산드라 Overview]

ü 페이스북에 의해 개발되어 2008년 오픈소스로 공개되었으며현재는 Apache Software Foundation에서 관리하고 있는NoSQL 제품이다.
ü 페이스북과 트위터Digg등 유명 웹서비스에서 성공적으로 사용되고 있어 그 성능과 안정성을 인정받고 있다.
ü 자바로 구현되어 있으며 Apache licence로 운영되고 있다.
ü 대용량의 데이터 트렌젝션에 대해서 고성능 처리가 가능한 시스템이고 노드를 추가함으로써 성능을 낮추지 않고 횡적으로 용량을 확장할 수 있다.
ü 컬럼 그룹(Column Group)형태의 데이터 모델을 갖고 있으며업데이트 내역이 일단 메모리에 캐시된 후 디스크에 쓰여지고 주기적으로 데이터 파일이 재구성된다는 점에서는 구글 빅테이블 하둡 Hbase와 유사하다.
ü Eventually Consistent 개념을 도입하여 하나의 노드에 업데이트된 내용이 바로 다른 노드로 복사되지 않고 추후 각 노드의 데이터를 종합하는 방법으로 일관성을 갖추도록 하여 Update/Write 응답시간을 줄였다는 점과새로운 노드를 추가하거나 기존노드를 제거할 때 Consistent Hashing 기법을 이용해 노드 간의 데이터 재구성을 최소화 했다는 점에서는 아마존 다이나모(Amazon Dynamo)와 유사하다.
ü 카산드라는 구글의 BigTable 컬럼 기반의 데이터 모델과 아마존의 Dynamo의 분산 모델을 기반으로 하여 제작되었다.
ü 각 노드들은 Gossip 기반 알고리듬을 이용해 순수 P2P(Pure-P2P) 프로토콜로 마스터노드(Master-Node)없이 자신들의 상태를 교환하여 고장난 노드를 찾아내고 새로운 노드를 그룹에 가입시키는 방법을 사용한다이는 마스터노드가 존재하지 않으므로SPoF(Single Point of Failure)가 줄어드는 모습이 된다.
ü 타 NoSQL 제품들이 데이터 일관성(Data Consistency)에 대한 보증을 하지 못하는데 반해카산드라는 외부 환경변수를 통해 데이터 일관성 정를 사용자가 손쉽게 설정할 수 있도록 하고 있다이는 용이한 확장성을 유지하면서도 사용목적에 따라 데이터 일관성 정도를 조절할 수 있어 큰 장점으로 꼽힌다.

 

 

 

[NoSLQ 성능비교]

ü 2010년 6월 야후 리서치 팀(Yahoo! Reseach)은 MySQL과 대표적인 NoSQL 제품들의 성능을 비교한 클라우드 서비스 시스템 벤치마킹 결과를 정리한 논문을 발표했다.

        [그림 : 처리량 증가에 따른 읽기 성능 비교]              [그림 : 처리량 증가에 따른 업데이트 성능 비교]

 

ü 읽기 성능의 경우처리량이 증가할수록 MySQL 클러스터는 관계형 데이터베이스의 장점인 빠른 읽기 속도를 보이지 못하고 성능이 급격히 떨어지지만Hbase와 카산드라는 비교적 높은 처리속도를 보여준다.
ü Update/Write에 최적화되도록 설계된 Hbase와 카산드라의 특성상 매우 높은 처리량을 가능케 하는 모습을 보여주었다이는SNS나 대용량 로그처리처럼 끊임없이 새로운 데이터를 처리해야 하는 시스템에서 NoSQL의 장점이 십분 발휘될 수 있음을 말해준다.

 

 

 

[Seminar : Facebook Engineer - Avinash Lakshman ]

오디오 녹음이 너무 울려서 발음을 알아 듣기가 힘들어 세미나에서 사용된 ppt를 찾아서 첨부해 놓았습니다. 사실, 영어실력이 부족해서 안들리는 거겠지만.. ㅠ.ㅠ

 

 

 

[Jeremiah Peschka installs Cassandra]

[출처] Cassandra - facebook|작성자 녹천

저작자 표시
신고
현재 0 개의 댓글이 있습니다.
Comment

Blog

아파치 분산 데이타 베이스 Cassandra 소개

2011.02.11 09:40 DataBase/NoSQL


Introduction of Cassandra

카산드라는 구글의 BigTable 컬럼 기반의 데이타 모델과 FaceBook에서 만든 Dynamo의 분산 모델을 기반으로 하여 제작되어 Facebook에 의해 2008년에 아파치 오픈소스로 공개된 분산 데이타 베이스 입니다.기존의 관계형 데이타 베이스와 다르게 SQL을 사용하지 않는 NoSQL의 제품중의 하나이며대용량의 데이타 트렌젝션에 대해서 고성능 처리가 가능한 시스템이다.(High-Scale). 노드를 추가함으로써 성능을 낮추지 않고 횡적으로 용량을 확장할 수 있다.

 얼마전에 트위터도 MySQL에서 Cassandra로 데이타베이스를 전환하였다고 한다..

자바로 작성되었음에도 불구하고데이타베이스라는 명칭에 걸맞게 여러 프로그래밍 언어를 지원합니다. Ruby,Perl,Python,Scala,Java,PHP,C# 

데이타간의 복잡한 관계 정의(Foreign Key)등이 필요없고대용량과 고성능 트렌젝션을 요구하는 SNS (Social Networking Service)에 많이 사용되고 있습니다성능이나 확장성과 안정성이 뛰어나지만 안타깝게도 Global Scale (여러 국가에 데이타 센터를 분리 배치하여 배포하고데이타 센타간 데이타를 동기화 하는 요구사항은 지원하지 않습니다. Global Scale이 필요하다면, MySQL기반의 geo replicationSharding이 아직까지는 가장 널리 쓰이는 아키텍쳐 같습니다

Data Model

카산드라의 데이타 모델은 다음과 같다.

전통적인 관계형 데이타 베이스와 다른 구조를 가지고 있다.먼저 데이타 모델에 대한 개념을 잡아보면

Column
컬럼은 컬럼 이름과값으로 이루어진 데이타 구조체이다.

{name: “emailAddress”, value:”cassandra@apache.org”}
{name:”age” , value:”20”}

Column Family

컬럼 패밀리는 컬럼들의 집합이다관계형 데이타 베이스의 테이블을 생각하면 되는데약간 그 개념이 다르다차이점은 나중에 설명하기로 하고컬럼 패밀리는 하나의 ROW를 식별하기 위한 Key를 갖는다하나의 Key에 여러개의 컬럼이 달려 있는 형태가 컬럼 패밀리이다.

하나의 Row를 예를 들어보면

Cassandra = { emailAddress:”casandra@apache.org” , age:”20”}

과 같은 형태이다. Cassandra가 해당 Row에 대한 Key가 되고, emailAddress age라는 이름의 두개의 컬럼을 가지고 있으며 각 컬럼의 값은 “casandra@apache.org” 와 “20”이다.

여러개의 Row를 가지고 UserProfile이라는 이름의 컬럼 패밀리를 보면

UserProfile={
  Cassandra={ emailAddress:”casandra@apache.org” , age:”20”}
  TerryCho= { emailAddress:”terry.cho@apache.org” , gender:”male”}
  Cath= { emailAddress:”cath@apache.org” , age:”20”,gender:”female”,address:”Seoul”}
}

과 같이 표현할 수 있다여기서 주목할만한 점이 각 Row의 데이타 스키마가 다르다는 것이다. Cassandra Row emaillAddress age라는 컬럼을 가지고 있고, Terry.Cho emaillAddress gender라는 컬럼을 가지고 있다이 처럼 카산드라는 각 Row마다 다른 형태의 데이타 스키마를 가질 수 있는데이러한 특징은“Schemeless”라고 한다.(키에 바인딩되는 데이타 구조는 같은 컬럼 패밀리라도 각 키별로 다를 수 있다.)

KeySpace

KeySpace는 논리적으로 ColumnFamily를 묶어주는 개념입니다단지 묶어만 줄뿐 데이타 구조나 관계에서는 별다른 영향을 주지 않습니다.

Super Column & Supper Column Family

앞에서 설명드렸던 컬럼에서 컬럼의 Value String이나 Integer와 같은 Primitive형 뿐만 아니라 컬럼 자체가 다시 들어갈 수 있습니다. 예를 들어 이런 구조입니다.

{name:”username” 
 value: firstname{name:”firstname”,value=”Terry”} 
 value: lastname{name:”lastname”,value=”Cho”} 
}

username이라는 컬럼 안에 firstname lastname이라는 두개의 컬럼이 들어가 있는 구조입니다.

마찬가지 형태로 Column Family 안에도 Column Family가 들어가는 Super 구조가 가능합니다.

UserList={ 
   Cath:{ 
       username:{firstname:”Cath”,lastname:”Yoon”}
       address:{city:”Seoul”,postcode:”1234”}
           }
    Terry:{ 
       username:{firstname:”Terry”,lastname:”Cho”}
       account:{bank:”hana”,accounted:”1234”} 
           }
 }

UserList라는 Column Family 안에각각 Cath Key username address라는 Column Family를 가지고 있고, Terry라는 Key username account라는 Column Family를 가지고 있습니다.  

Data Model for Java Developer

간단하게 카산드라의 데이타 구조에 대해서 살펴보았는데자바 개발자분이시라면 HashTable이 떠오를겁니다. 데이타 모델을 HashTable과 비교해서 설명해보면 다음과 같은 형태가 됩니다.코드로 이야기 하면 대략 다음과 같은 형태가 되겠지요


앞서 들었던 Column Family의 데이타 구조를 자바 코드로 표현하면 다음과 같은 구조가 됩니다.

UserProfile={
  Cassandra={ emailAddress:”casandra@apache.org” , age:”20”}
  TerryCho= { emailAddress:”terry.cho@apache.org” , gender:”male”}
  Cath= { emailAddress:”cath@apache.org” , age:”20”,gender:”female”,address:”Seoul”}
}

자바 코드

class Keyspace{
           HashTable keyspaces = new HashTable();          

           createColumnFamily(String name){
                     keyspaces.put(name,new HashTable);
           }

           putValue(String columnFamily,String key,Object value){
                     Hashtable cf = keyspaces.get(columnFamily);
                     cf.put(key,value);
           }
}

 

class TerryVO{ // Terry is a Key
           String emailAddress; // each column
           String gender;
           // setter & getter
}

 class CathVO{ // Cath is a Key

           String emailAddress;
           String age;
           String gender;
           // setter & getter 
}

KeySpace myspace;
myspace.createColumnFamily("UserProfile");
myspace.putValue("UserProfile","TerryCho",new TerryVO("terry.cho@apache.org","male");
myspace.putValue("UserProfile","Cath",new CathVO("cath@apache.org","20","female")

 자바 개발자분들이시라면 쉽게 이해하실 수 있을것 같고
구조를 분석하다보니 오라클의 데이타 그리드 솔루션은 Coherence와 데이타 구조가 매우 유사합니다. 요즘 이게 유행인가 보네요

Cassandra Test

개념을 이해했으면 실제 테스트를 한번 해보도록 하겠습니다.

먼저 아파치 카산드라 프로젝트(http://incubator.apache.org/cassandra/에서 카산드라를 다운 받습니다압축을 푼후에 bin/cassandra.bat를 실행시킵니다. (클러스터로 기동할 수 도 있으나 여기서는 단순하게 하나의 노드만 뛰어보도록 합니다.)

이제 카산드라 커맨드 라인 인터페이스(CLI)를 시키고(/bin/cassandra-cli.bat) 다음 카산드라 노드에 연결합니다포트는 디폴트로 9160 포트가 지정되어 있으며 /conf/storage-conf.xml에서 Listen AddressPort를 변경할 수 있습니다.  

/conf/storage-conf.xml 파일에는 default Keyspace1이라는 이름으로 Keyspace가 정의되어 있습니다. Keyspace1에 지정되어 있는 Column Family(CF) 형식은 다음과 같습니다.


Standard2 CF Terry이라는 Key Gender라는 Column Male이라는 값을 넣고 다시 조회해보겠습니다.


다음번에는 Java Code를 이용하여 카산드라에 접근하는 방법에 대해서 알아보도록 하겠습니다.

참고 할만한 자료

저작자 표시
신고
현재 0 개의 댓글이 있습니다.
Comment