블로그 이미지
평범하게 살고 싶은 월급쟁이 기술적인 토론 환영합니다.같이 이야기 하고 싶으시면 부담 말고 연락주세요:이메일-bwcho75골뱅이지메일 닷컴. 조대협


Archive»


 
 

CouchDB Overview


어제 SSAG 에서 정명훈 이사가 강의한 CouchDB에 대한 내용 정리


CouchDB 일반 특징

CouchDB Apache 프로젝트로 MongoDB와 같은 Document DB의 형태를 띄며, NOSQL CAP이론중 AP 에 해당 한다. (장애에 매우 강하다.) 단 Consistency는 Eventual Consistency를 제공한다. (버전으로 하는 방식), Eventual Consistency 모델이기 때문에 Locking을 사용하지 않는다. (Optimistic Lock)


유사 프로젝트

유사 프로젝트로 CouchBase와 BigCouch, Cloudant등이 있다.

CouchBase는 memcached와 CouchDB를 합쳐놓은 제품으로, 앞단에 캐쉬가 있어서 성능이 매우 빠르다. BigCouch는 CouchDB가 single instance만 지원하는데 반해서, 클러스터링 기능을 가지고 있다. Cloudant는 이 BigCouch를 기반한 제품으로 DBaaS 형식의 서비스로, DB 서비스를 제공하고, 운영을 대행해준다. 향후 BigCouch와 CouchDB가 합쳐져서 클러스터링 기능을 제공할 예정이다.

그 외에도 mobile에 탑재 가능한 버전의 CouchDB들이 있다.


Secondary Index

재미있는 특징중의 하나가 Sencondary Index를 지원하는 데 이는 내부적인 Map & Reduce를 통해서 구현되는데, 2nd index search시마다 MR이 도는 것이 아니라, 2nd index를 만들어 놓은 다음에 이를 View와 같은 형태로 저장해놓고, 이 index 내에서 검색을 한다. 또한 새로운 데이타가 추가되거나 변경이 되더라도 전체 index를 rebuild하는 것이 아니라, incremental 방식으로 변경된 부분만 재 생성한다.

물론 이 index를 rebuild하는 과정에서 서버가 부하를 받아서 성능이 다소 떨어질 수 있으나, 초당 수천건 정도의 index 변경은 수용할 수 있는 수준이라고 한다.


Replication

CouchDB의 강력한 기능중의 하나가 복제 기능인데, 단방향, 양방향 복제, 1:N, M:N 그리고 필터나 룰 기반의 복제(서브셋만 복제하는 기능)도 가능하다. 1회성으로 복제하는 시나리오와 지속적으로 복제하는 시나리오도 가능하면, 네트워크에서 끊어졌다가 나중에 붙어도 복제 및 Sync만 하는 것도 가능하다.

무엇보다 CouchDB는 모바일 버전이 있기 때문에, 이를 이용하면 쉽게 단말과 서버간의 Sync 시나리오를 구현할 수 있다. 오픈 소스로 파일이나 이미지를 서버와 디바이스간에 복제하는 프로젝트가 있다.


Interface

인터페이스는 HTTP REST만 지원한다. 아쉬운 부분인데, 성능이 높은 Protocol Buffer등을 향후 지원했으면 한다.


보안

HTTPS와 OAuth 인증을 제공하며, HTTP Basic Auth도 지원한다. User Identity source (LDAP)등의 연동에 대해서는 자세하게 설명되지 않았는데, 앞단에 reverse proxy를 둬서 인증하는 방식으로 구현이 가능하리라 본다.


대략적인 아키텍쳐

기본적인 메카니즘이 append only 구조로, 일정 이상의 데이타가 쌓이면 내부적으로 자동 Compaction을 한다.

Erlang으로 구현되어 있으며, 그 위에 javascript를 제공하여, MR등은 javascript를 사용하여 구현한다.



저작자 표시
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

NoSQL 인기 순위

클라우드 컴퓨팅 & NoSQL/NoSQL 일반 | 2012.09.07 22:30 | Posted by 조대협

미국의 NoSQL 인기 순위를 분석해보니, mongodb가 앞도적인 1위, 2위권은 cassandra,hbase 그리고 다음이 redis 맨 아래로 riak,couchdb 등이 있다.

아무래도 기능이 편리한 mongodb 가 단연 인기고, 난이도는 있지만 확장성에 우위가 있는 cassandra,hbase가 그 뒤를 따른다. 


분석 방법은 indeed.com 이나 monster.com의 구인 광고중, 해당 기술별 구인 광고를 분석하였다.


<indeed.com 분석 결과>


  • mongodb 276
  • cassandra 149
  • hbase 146
  • redis 91
  • coherence 53
  • couchdb 40
  • riak 24

<monster.com 구직 분포>

저작자 표시
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

NoSQL 데이타 모델링 #2

Facebook Server Side Architecture Group
http://www.facebook.com/groups/serverside
조대협

NoSQL 데이타 모델링 패턴

NoSQL 데이타 모델링 패턴[1]Key/Value 저장 구조에 Put/Get 밖에 없는 단순한 DBMS에 대해서 다양한 형태의 Query를 지원하기 위한 테이블을 디자인하기 위한 가이드 이다.

특히 RDBMS에는 있는

“ Order by를 이용한 Sorting, group by를 이용한 Grouping, Join등을 이용한 개체간의 relationship 정의, 그리고 Index 기능

들을 데이타를 쿼리하는데, 상당히 유용한 기능인데, NoSQL은 이러한 기능들을 가지고 있지 않기 때문에, NoSQL 내에서 데이타 모델링을 통해서 이러한 기능들을 구현하는 방법에 대한 가이드를 제공한다.


1. 기본적인 데이타 모델링 패턴

NoSQL의 데이타 모델링을 할때, 가장 기본적으로 많이 사용되는 패턴들이다.


1)    Denormalization

Denormalization은 같은 데이타를 중복해서 저장하는 방식이다.
Denormalization
을 하면, 테이블간의 JOIN을 없앨 수 있다. NoSQL에서는 JOIN을 지원하지 않기 때문에, 두 테이블을 조인해서 데이타를 가지고 오는 로직을 구현하려면, 각 테이블에서 데이타를 각각 가져와서 애플리케이션에서 합쳐야 하기 때문에, 2번의 IO가 발생한다.

Denormalization을 적용하여, 하나의 테이블에 JOIN될 데이타를 중복 저장하게 되면 1번의 IO로도 데이타를 가지고 올 수 있다.

예를 들어서 사용자 정보를 저장하는 User 테이블과, 도시 이름을 저장하는 City 테이블이 있다고 하자,



이런 테이블 구조에서 사용자별로 이름,나이,성별,우편번호를 출력하는 쿼리는 다음과 같다.

select u.name,u.age,u.sex,c.zipcode from user u,city c where u.city = c.city

이 테이블 구조를 그대로 해서, NoSQL에서 구현하면

select $city,name,age,sex from user where userid=”사용자ID”

select zipcode from city where city=$city

식으로 구현해야 하는데, User 테이블에서 city값을 읽어온 후에, City 테이블에서 앞서 읽어온그래city값을 키로 해서 다시 zip code를 찾아와야 한다. 두번 쿼리를 발생 시킨다. 단순한 예이지만, Join을 해야 하는 테이블 수가 많을때는 NoSQL로의 IO수가 훨씬 더 늘어난다. IO 수를 줄이려면, 아예 처음부터 Join이 되어 있는 테이블을 하나 더 만들어 버리면 된다.



이런식으로 새로운 테이블을 추가하면 된다.

Denormalization을 이용하여 중복을 허용하였을 경우에 장단점은 다음과 같다.

장점은

Ÿ   성능 향상 – Join을 위해서 몇번씩 쿼리를 하지 않아도 되기 때문에, 당연히 쿼리 성능이 올라간다.

Ÿ   쿼리 로직의 복잡도가 낮아짐 – Join에 대한 로직이 필요 없이, 한번에 데이타를 가지고 오기 때문에, 쿼리 로직이 단순해 진다.

   반대로 다음과 같은 단점을 불러온다.

Ÿ   데이타 일관성 문제 발생 가능 – age,sex,zip code등을 insert하거나 update하였을때, User, City 테이블뿐만 아니라 UserZipCode 테이블도 업데이트 해줘야 한다. 만약에 같은 User 테이블을 업데이트 하다가 에러가 났을 경우, UserZipCode 테이블은 업데이트가 안된 상태이면, 양쪽 테이블에 데이타 불 일치성이 발생할 수 있다.

Ÿ   스토리지 용량 증가 : 데이타를 중복해서 저장하는 만큼 스토리지 용량이 증가 된다.

사실 보면 단점도 있지만, NoSQL의 경우 Join이 어렵고, 애플리케이션 적으로 구현을 한다고 해도 성능이 안나오거나 구현이 어려운 경우가 많기 때문에, Denormalization을 통한 중복은 상당히 효과적인 모델링 패턴이 된다.


2)    Aggregation

드롭박스나, 슈가싱크처럼 파일을 저장하는 개인 스토리지 서비스가 있다고 가정하자. 이 서비스는 파일에 대한 정보를 저장하고, 음악,동영상,사진 등의 파일의 종류에 따라서 추가적인 메타 정보를 저장한다. ERD를 기준으로 개체를 표현해보면 다음과 같다.



NoSQL의 재미있는 특성중의 하나가 Scheme-less 또는 Soft Scheme라는 특성인데, RDBMS의 경우 테이블에 데이타를 넣을때, 반드시 테이블의 구조에 맞도록 넣어야 한다. 컬럼수와 이름도 지켜야 하고, 각 컬럼에 해당 하는 데이타 타입도 준수해야 한다 또한 모든 ROW는 같은 컬럼을 가져야 한다반면 NoSQL의 경우에는 Key만 똑같다면, Row는 제멋대로라도 상관없다. 꼭 같은 컬럼을 가질 필요도 없고, 데이타 타입도 각기 틀려야 한다. Value에 저장되는 Row 데이타들은 한줄의 Row 구조를 가지기는 하지만, 전체 테이블에 대해서 그 Row 구조가 일치할 필요가 없다. 이를 데이타가 구조는 가지고 있지만, 구조가 각각 틀리는 것을 허용한다고 해서 Soft-Scheme 또는 Schemeless 라고 한다.

이 특성을 이용하면, 위의 데이타 모델을 하나의 테이블로 합칠 수 있다



1:N과 같은 복잡한 엔터티들의 관계를 손쉽게 하나의 테이블로 바꿀 수 있고, 이는 결과적으로 Join의 수를 줄여서 Query 성능을 높이는 방법이 된다.


3)    Application Side Join

NoSQL Join이 거의 불가능하다. (지원하는 제품도 있지만). 그래서 Denormalization이나 Aggregation 그리고 앞으로 설명할 데이타 모델링 패턴을 사용하는 것인데, 그래도 어쩔 수 없이 Join을 수행해야할 경우가 있다. 이 때는 NoSQL의 쿼리로는 불가능하고, NoSQL을 사용하는 클라이언트 Application단에서 로직으로 처리해줘야 한다.

예를 들어서 TABLE 1,2 두개의 테이블이 있고, TABLE 1의 컬럼중 하나가 Foreign Key로써 TABLE 2의 데이타를 가르키고 있다면, Application Join을 하려면, Table 1에서 Primary Key로 한 Row를 읽어온 후에, Table 2를 가르키는 컬럼의 값을 Key로 해서, 다시 Table 2에서 쿼리를 해온다.



Application Side Join Join이 필요한 테이블 수 만큼 NoSQL로의 Request/Response IO가 발생하는 만큼 다소 부담 스럽기는 하지만, 반대로 Denormalization등에 비해서는 스토리지 사용량을 절약할 수 있다.


참고 : Map & reduce 기능을 이용한 Server Side Join

Application Side Join이 있다면, 반대로 Server Side Join 기능도 있다. NoSQL에는 Join 기능이 없다고 했는데, Server Side Join은 무엇인가?


Riak이나 MongoDB와 같은 일부 NoSQL DB들은 RDBMS stored procedure [2]를 지원한다. Map & Reduce [3]라는 이름으로 이 기능을 지원한다. 즉 위에서 Application에서 수행한 로직을 NoSQL 서버들 내에서 수행해서 리턴하는 방식이다. 이 로직들은 NoSQL에서 지원하는 언어를 통해서 구현된후, NoSQL 엔진위에서 수행된다.




이렇게 하면, Application에서 NoSQL로의 호출이 Map & Reduce function 한번만 호출하면 되기 때문에, 네트워크 IO를 줄여서 성능을 향상 시킬 수 있다. 반면, Join에 대한 로직이 NoSQL 서버 쪽에서 수행되기 때문에, 반대로 NoSQL에 대한 부담이 가중된다.


2. 확장된 데이타 모델링 패턴

1)    Atomic aggregation

NoSQL에서 고민해야할 것 중의 하나의 두 개이상의 테이블을 업데이트 할때, 트렌젝션에 관리에 대한 문제이다. 그림과 같이 두개의 테이블을 업데이트 하는 시나리오에서, 1번 테이블을 업데이트 한 후에, 애플리케이션 로직이나 NoSQL의 장애로 인해서 2번 테이블이 업데이트가 되지 않는 문제가 발생할 수 있다.



이 경우 데이타의 일관성 문제를 야기하는데, 이에 대한 해결 방안으로 생각할 수 있는 것은, TABLE 1,2를 하나의 테이블로 합쳐 버리는 것이다.



하나의 테이블에 대해서는 NoSQL atomic operation(원자성)을 보장하기 때문에, 트렌젝션을 보장 받을 수 있다. 구현 패턴상으로는 Aggregation과 동일한데, Aggregation1:Nrelationship aggregate해서 join을 없애기 위함이고, Atomic Aggregation은 트렌젝션 보장을 통한 데이타 불일치성을 해결하기 위함이다.

예를 들어 사용자 정보가 UserAddress,UserProfile,UserId라는 이름의 3개의 테이블로 분산이 되어 있을때, 사용자를 생성하는 경우, 3개의 테이블에 Insert를 해줘야 한다. 그러나 테이블이 3개로 분산되어 있기 때문에, 앞에서 언급한 장애시 트렌젝션에 대한 보장이 되지 않는다. 이를 해결하기 위해서 atomic aggregation 패턴을 적용하여, 3개의 테이블을 User 테이블의 필드로 집어 넣게 되면, 하나의 테이블이기 때문에, 장애나 에러로 인한 트렌젝션 불일치 문제를 방지할 수 있다.



2)    Index Table

NoSQL RDBMS 처럼 Index가 없기 때문에, Key 이외의 필드를 이용하여 Search를 하면, 전체 Table Full Scan 하거나 아니면 Key이외의 필드에 대해서는 아예 Search가 불가능하다. 이 문제를 해결하기 위해서 Index를 위한 별도의 Index Table을 만들어서 사용할 수 있는데, 상당히 사용 빈도가 많은 방법이다.

예를 들어, 파일 시스템을 NoSQL에 저장한다고 했을때, 파일 테이블은 다음과 같은 구조를 갔는다.



여기서 특정 디렉토리에 있는 파일만을 리스트업 하고 싶다면, 별도의 Index Table을 다음과 같이 만들면 된다.



Cassandra Riak과 같은 일부 NoSQL에는 제품적으로 secondary Index라는 이름으로 Key 이외의 필드를 Index로 지정하는 기능을 가지고 있는데, 이 기능들은 아직까지 성숙되지 못해서, 여기서 설명하는 Index Table을 사용하는 것보다 성능이 나오지 않는다. 만약에 NoSQL에 있는 Secondary Index 기능을 사용할 예정이라면, 반드시 이 Index Table 패턴과 성능을 비교해보기를 추천한다. 당연히 Secondary Index를 이용하면 구현은 조금 편리해질 수 있지만, 성능 차이가 많이 날 수 있다.


3)    Composite Key

이 글을 읽으면서 눈치가 빠른 사람이라면, Key를 정의하는데, “:” deliminator를 이용하여 복합키를 사용하는 것을 눈치 챘을 것이다. NoSQL에서는 이 Key를 어떻게 정의하느냐가 매우 중요하다. 특히 Ordered KV Store 의 경우에는 이를 이용하여 order by와 같은 sorting 기능이나 grouping을 구현할 수 있다. Composite Key는 하나 이상의 필드를 deliminator를 이용하여 구분지어 사용하는 방법으로 RDBMS의 복합키 (Composite primary key)와 같은 개념이라고 생각하면 된다. 단지 RDBMS의 경우에는 여러개의 컬럼을 묶어서 PK로 지정하지만 NoSQL은 한컬럼에 deliminator를 이용하여 여러개의 키를 묶어서 넣는다.

아래의 예제를 보자, PC의 디렉토리를 Ordered KV Store에 저장한다고 하자.
 windows
하위 디렉토리를 가지고 올때, “windows:etc” 부터 쿼리를 해서, 다음 row를 반복적으로 쿼리해서, key windows로 시작하지 않을때 까지 읽어오면, windows 디렉토리의 하위 디렉토리를 모두 가지고 올 수 있다.



노드가 추가,삭제되더라도, 내부적으로 sorting이 되기 때문에, 문제없이 사용이 가능하다.

, Key값을 선택할때 주의해야할 사항은 특정 서버로의 몰림 현상을 들 수 있다. NoSQL은 특성상, N개의 서버로 구성된 클러스터이다. 그리고 데이타는 Key를 기준으로 N개의 서버에 나눠서 저장이 된다. 예를 들어 Key Range A~Z 26개라고 가정하고, 클러스터의 서버 수가 26대라고 하면, 각 서버는 Key의 시작으로 사용되는 알파벳 키들의 데이타를 저장한다. 1번은 A로 시작되는 Key 데이타들, 2번은 B, 3번은 C로 등등.

Key 값을 “City:User Name”으로 했다고 가정하자, 우리나라에서는 5000만 인구중, 1/5 1000만이 서울에 살고 있다. 그래서 데이타중 약 20%의 키는 “Seoul:xxx”로 시작할 것이고 26대의 서버중에서 S로 시작하는 키를 저장하는 한대의 서버는 20%의 부하를 처리하게 될것이다. 서버가 26대이니까는 각 서버는 1/26 ( 3.8%)의 부하를 처리해야 하는데, 이건 예상치 보다 5배 이상 많은 로드를 처리하기 때문에 성능 저하를 유발할 수 있다. 이런 이유로, Key를 선정할 때는 전체 서버에 걸쳐서 부하가 골고루 분산될 수 있는 Key를 선정하는 것이 좋다.


4)    Inverted Search Index

검색엔진에서 많이 사용하는 방법인데, 검색엔진은 사이트의 모든 페이지를 검색 로봇이 검색해서 문서내의 단어들을 색인하여 URL에 맵핑해서 저장해놓는다.



검색은 단어를 키로 검색이 되기 때문에, 위의 테이블 구조에서는 value에 검색 키워드들이 들어가 있기 때문에, 효과적인 검색을 할 수 없다. 이 검색 키워드를 키로 해서 URLvalue로 하는 테이블을 다시 만들어 보면, 아래와 같은 식으로 표현되고, 검색 키워드로 검색을 하면 빠르게, 검색 키워드를 가지고 있는 URL을 찾아낼 수 있다.



이렇게 value의 내용을 key로 하고, key의 내용을 반대로 value로 하는 패턴을 inverted search index라고 한다.


5)    Enumerable Keys

NoSQL 솔루션에 따라서, RDBMS Sequence와 같은 기능을 제공하는 것들이 있다. 이 기능들은, 키에 대해서 자동으로 카운터를 올려주는 기능을 가지고 있다. (예를 들어 첫번째 키는 1, 두번째 키는 2,다음은 3,4,5 식으로 순차적으로 연속된 키를 부여해주는 기능).

이 기능은 데이타에 대한 traverse 기능을 제공한다. , 100번 키를 가지고 왔는데, 이 앞뒤의 값을 알 수 있다. Sequential한 키를 사용했기 때문에, 당연히 앞의 키값은 99, 다음 키값은 101로 해서 값을 가지고 올 수 있다.


3. 계층 데이타 구조에 대한 모델링 패턴

NoSQL들은 데이타 모델이 KV,Ordered KV,Document들 여러가지가 있기는 하지만, 기본적으로 row,column을 가지고 있는 테이블 구조 저장구조를 갖는다. 애플리케이션 개발중에는 이런 테이블 구조뿐만 아니라 Tree와 같은 계층형 데이타 구조를 저장해야 할 경우가 있는데, 테이블 구조의 저장 구조를 갖는 NoSQL의 경우 이러한 계층형 구조를 저장하는 것이 쉬운일은 아니다.

RDBMS의 경우에도 이런 계층형구조를 저장하기 위해서 많은 고민을 했는데, RDBMS 솔루션에서 기능적으로 자체 지원할 수 도 있고, 데이타 모델링을 통해서도 이러한 계층형 구조를 저장할 수 있다.

여기서 소개하는 NoSQL에서 계층형 구조를 저장하는 기법은 RDBMS에서 사용하는 기법들을 많이 참고하였다. 추가적인 기법은 RDBMS Tree구조 저장 기법을 참고하기 바란다.


1)    Tree Aggregation

Tree 구조 자체를 하나의 Value에 저장하는 방식이다. JSON이나 XML 등을 이용하여, 트리 구조를 정의 하고, Value에 저장하는 방식이다.

Tree 자체가 크지 않고, 변경이 많이 없는 경우에는 사용하기 좋다. “계층형 게시판의 답글 Tree 구조등을 저장하기에 용이하다.


2)    Adjacent Lists

Adjacent List 구조는, 전통적인 자료 구조에서 사용하는 Linked List와 같은 자료 구조형을 사용하여, Tree의 노드에 parent node에 대한 포인터와 child node들에 대한 포인터를 저장하는 방식이다.

Tree의 내용을 검색하려면, root 노드에서 부터 child node child node 포인트를 이용하여, 값을 가져오는 방식이다. (이를 Tree traversing 이라고 한다.)

특정 노드만 알면, 해당 노드의 상위, 하위 노드를 자유롭게 traversing할 수 있어서 traversing에는 장점을 가지고 있지만, 반대로, 하나의 노드를 이동할 때마다, 포인터를 이용해서 매번 쿼리를 해와야 하기 때문에, Tree의 크기가 크다면 NoSQL로의 IO가 엄청나게 많이 발생한다. (트리의 노드 수가 N이면, N번 쿼리를 해야 한다)

아래 그림을 보자, 파일 디렉토리를 저장하는 자료 구조를 만든다고 했을때, Directory라는 테이블을 정의하고, 이 테이블에는 directory 명과, 해당 directory의 상하위 디렉토리 이름을 저장하도록 한다.

이를 바탕으로 테이블에 저장된 데이타를 보면 아래와 같다.



구현이 쉬운 편이긴 하지만 Tree 구조 traverse에 많은 IO를 유발하기 때문에, Tree구조를 저장하거나 잦은 read가 있을때는 권장하지 않는다.

     RDBMS 의 경우에는 이런 Tree 구조 traversing을 지원하기 위해서 recursive 쿼리에 대해서 native recursive function을 지원함으로써, tree 구조 저장을 지원하는 경우도 있다.


3)    Materialized Path

Materialized Path Tree 구조를 테이블에 저장할때, root에서 부터 현재 노드까지의 전체 경로를 key로 저장하는 방법이다.

이 방법은 구현에 드는 노력에 비해서 매우 효율적인 저장 방식이다. 특히 Key에 대한 Search를 할때, Regular Expression을 사용할 수 있으면, 특정 노드의 하위 트리등을 쿼리해 오는 기능등 다양한 쿼리가 가능하다. 일반적은 KV Ordered KV에서는 적용하기는 힘들지만, MongoDB와 같은 Document DB Regular Expression을 지원하기 때문에, 효과적으로 사용할 수 있다.



4)    Nested Sets

Netsted Set의 기본원리는 Node가 포함하는 모든 Child Node에 대한 범위 정보를 가지고 있다. 먼저 예를 보고 설명하자. Node는 배열이나 리스트에 Sorting된 형태로 저장되어 있다.

Node는 자신이 포함하는 모든 Sub Tree (Child Node)들이 포함된 start end index를 저장한다.

아래 A는 전체 Sub Tree를 포함하기 때문에 2~9번에는 A Sub Tree의 내용이 된다.
C
노드의 경우 자신이 포함하는 모든 Child Node 4~9에 포함되어 있기 때문에, Index 4~9로 저장한다.



각 노드만 안다면, Sub Tree start,end index만 있으면 쭈욱 읽어오면 되기 때문에 매우 빠른 성능을 보장할 수 있다. 단 이 데이타 구조 역시 update에 취약하다. update가 발생하였을 경우, Index를 다시 재배열해야 하기 때문에 이에 대한 로드가 매우 크다.

위의 예제에서 B 노드 아래에 J 노드를 추가해보자, J 노드의 index 3이 되어야 하고, 3 Index부터는 모두 +1 씩 더해져야 하며, Child Node의 값 역시 모두 변화 되어야 한다.



트리 생성 후에, 변화가 없는 대규모 트리등을 저장하는데 유용하게 사용할 수 있다

.

결론

지금까지 몇가지 NoSQL 적용시 사용할 수 있는 데이타 모델링 패턴에 대해서 살펴보았다. 기본 패턴은 대부분의 NoSQL 솔루션에 적용할 수 있으며, 확장된 모델링 패턴의 경우에는 NoSQL이 지원하는 기능이나 데이타 구조 (KV, Ordered KV,Document etc)에 따라서 적용할 수 있다.

NoSQL을 이용한 시스템을 개발할때는

1.     데이타 모델링이 80% 이상이다. 선정한 NoSQL과 애플리케이션의 특성에 맞는 데이타 모델링에 집중하자.

2.     NoSQL은 어떤 솔루션이 좋다, 나쁘다가 없다. 어떤 솔루션이 특성이 어떻다는 것만 있기 때문에 반드시 데이타 모델과 내부 아키텍쳐 두 가지를 파악한 후에, 애플리케이션의 특성에 맞는 NoSQL을 선정해야 한다.

3.     하나의 NoSQL로 전체 데이타를 저장하려고 하지 마라. NoSQL은 데이타 구조가 매우 다눈하지만, 애플리케이션들은 하나의 단순한 데이타 구조로 저장할 수 없는 데이타가 반드시 존재한다. RDBMS와 혼용하거나, 다른 NoSQL과 혼용하거나 성능면에서는 캐슁 솔루션과 혼용하는 것을 반드시 고려 해야한다.

NoSQL은 놀라온 성능과 확장성을 제공하지만, 많은 연구와 노력이 필요하다. Oracle과 같은 데이타베이스를 사용할때도, 전문 DBA를 두고, 튜닝에 시간을 두고, 데이타 모델을 가꾸고, 튜닝을 하지 않는가? NoSQL이 오픈소스를 중심으로 사용되고 있지만, 오픈 소스라서 쉬운게 아니다. 그만큼 많은 투자와 연구와 노력이 필요한 만큼, 신중하게 검토하고 도입을 결정하기를 바란다.



[2] RDBMS에서 프로그래밍 언어를 이용해서 구현된 사용자 정의 데이타 Query 함수. 예를Oracle 들어 RDBMS의 경우에는 PL/SQL이라는 프로그래밍 언어를 이용하여, 데이타 베이스에 대한 비지니스 로직을 구현해서 저장해놓고, 클라이언트에서 이 함수를 호출해서 사용하게 할 수 있다.

[3] Map & Reduce Input 데이타를 여러 조각으로 쪼갠 후, 여러대의 서버에서 각 데이타 조각을 처리한후(Map), 그 결과를 모아서 (Reduce) 하나의 결과를 내는 분산 처리 아키텍쳐 이다.




링크 

NoSQL 데이타 모델 및 데이타 모델링 절차 : http://bcho.tistory.com/665

참고 자료 http://www.pearltrees.com/#/N-u=1_752336&N-p=53126547&N-play=1&N-fa=5793524&N-s=1_5827086&N-f=1_5827086


저작자 표시
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

NoSQL 데이타 모델링 #1

Facebook Server Side Architecture Group
http://www.facebook.com/groups/serverside
조대협

빅데이타,클라우드,NoSQL은 요즘 기술적인 화두중에 하나이다. 그중에서도 NoSQL은 많은 사람이 관심을 갖고 있음에도 불구하고, 기존의 RDBMS 데이타 모델링 관점에서 접근을 하기 때문에, 많은 문제를 유발한다. NoSQL은 데이타 베이스이기도 하지만 RDBMS와는 전혀 다른 성격을 가지고 있고, 접근 방식도 틀리다.

특히 테이블 구조를 정의 하는 데이타 모델에 따라서 NoSQL의 성능은 하늘과 땅차이만큼 차이가 난다. 이 글에서는 NoSQL의 데이타 모델링 기법에 대해서 소개하고자 한다.
※ 깨지는 그림은 클릭해서 봐주세요.

NoSQL 데이타 모델

데이타 모델링에 앞서서 NoSQL이 어떤 구조로 데이타를 저장하는지를 먼저 이해할 필요가 있다. NoSQL의 데이타 모델링 패턴은 아래와 같이 크게 3가지 패턴정도로 구분된다.

1.     Key/Value Store

가장 기본적인 패턴으로, 대부분의 NoSQL은 다른 데이타 모델을 지원하더라도, 기본적으로 Key/Value의 개념을 지원한다. Key/Value Store, Unique Key에 하나의 Value를 가지고 있는 형태를 이야기 한다. Put(Key,Value), Value := get(Key) 형태의 API로 접근한다.


Value String이나 Integer와 같은 Primitive 타입이 될 수 도 있지만, 이정도로는 우리가 일반적으로 사용하는 테이블 형태의 데이타를 저장할 수 없기 때문에, 조금 더 확장된 개념을 사용하는데, Column Family라는 개념을 사용한다. Key 안에 (Column,Value) 조합으로 된 여러개의 필드를 갖는데, 이를 Column Family라고 한다.


예를 들어, 사용자 프로필을 저장하는 시나리오가 있을 때, 사용자의 이름을 KEY로 한다면, 성별,주소,나이들은 각각의 Column이 될 수 있다. Key 필드는 RDBMS에서 Primary Key, Column 필드들은 RDBMS의 일반 데이타 필드로 이해하면 된다. 프로그램 언어와 비교해서 생각한다면, Key/Value Store Map 데이타 구조와 유사하다.
Oracle Coherence
Redis와 같은 NoSQL이 이 데이타 모델을 기본 모델로 사용한다.

2.     Ordered Key/Value Store

Key/Value Store의 확장된 형태로 Key/Value Store와 데이타 저장 방식은 동일하나, 데이타가 내부적으로 Key를 순서로 Sorting되서 저장된다.



Sorting이 별거 아닌것 같지만, NoSQL 관점에서는 대단히 중요한 기능을 제공하게 된다. 뒤에 데이타 모델링 기법에서도 다루겠지만, NoSQL RDBMS Order By와 같은 기능을 제공하지 않기 때문에 결과값을 업데이트 날짜등으로 소팅해서 보여주는 것은 이 Ordered Key/Value Store가 절대적으로 유리하다.

대표적인 제품으로는 Apache Hbase, Cassandra 등이 있다.

3.     Document Key/Value Store

Key/Value Store의 확장된 형태로, 기본적으로는  Key/Value Store이다. Key에 해당하는 Value 필드에 데이타를 저장하는 구조는 같으나, 저장되는 Value의 데이타 타입이 Document 라는 타입을 사용하는데, Document 타입은 MS-WORD와 같은 문서를 이야기 하는것이 아니라, XML,JSON,YAML과 같이 구조화된 데이타 타입으로, 복잡한 계층 구조를 표현할 수 있다.



아울러, Document Store 기반의 NoSQL은 제품에 따라 다르기는 하지만 대부분 추가적인 기능 (Sorting,Join,Grouping)등의 기능을 제공한다.

대표적인 제품으로는 MongoDB,CouchDB,Riak 등이 있다.


그리고 여기서는 구체적으로 다루지 않지만 Graph Tree구조와 같은 데이타 구조를 저장하기 위해서 최적화된 Neo4J등의 NoSQL이 있다. 만약에 테이블 구조의 데이타가 아니라 Graph 구조의 데이타를 저장하고자 한다면 Neo4J를 한번 체크해보기 바란다.


RDBMS NoSQL의 차이

NoSQL DBMS라고 생각해서 RDBMS와 같은, 또는 떨어지지만 유사한 기능을 제공할것이라고 생각하면 큰 오산이다. NoSQL은 데이타를 저장한다. 그리고 Key에 대한 Put/Get만 지원한다. RDBMS로 치자면

Put : Insert into TABLE VALUES(KEY,value1,value2,…,valuen)

Get : Select * from TABLE where KEY=”key”

만 딱 지원한다. 물론 제품에 따라서 기능에 대한 지원 범위는 다르기는 하지만, 공통적으로 고민해야 하는 기능은

Ÿ   Sorting (SQL Order By)

Ÿ   Join (RDBMS에서 두개의 Table Foreign Key를 이용하여 join)

Ÿ   Grouping (SQL문의 group by)

Ÿ   Range Query (where key>”start” and key<”end” 와 같이 일정 범위내의 내용을 쿼리해오는 기능)

Ÿ   Index (RDBMS Index를 지정하여 select query 성능을 높이는 기능)

이다. RDBMS에서는 너무나도 익숙하게 사용했던 기능들이기 때문에, 막상 이 기능들을 빼고 데이타를 다루고자 하면 매우불편하다. 여기서는 이러한 기능들을 “NoSQL 데이타 모델링 패턴소개를 통해서 NoSQL에서 어떻게 구현할 수 있는지 알아볼 것 이다.

NoSQL 데이타 모델링 시작하기

NoSQL 데이타 모델링이란, NoSQL에 저장할 데이타들의 구조, 즉 테이블 설계를 하는 것을 정의한다. NoSQL DBMS이기는 하지만, 우리가 지금까지 익숙하게 사용해왔던, RDBMS와는 그 특성이 매우 다르기 때문에 접근 방법을 바꿔야 한다.

NoSQL RDBMS의 데이타 모델링 차이

NoSQL을 사용해서 데이타 모델링을 하려면 근본적인 사상 2가지를 바꿔야 한다.

1)     개체 모델 지향에서 쿼리 결과 지향 모델링

RDBMS의 모델링 기법은, 저장하고자하는 도메인 모델을 먼저 분석한 후에, 개체간의 관계(relationship)를 식별하고, 테이블을 추출해내고, 테이블을 이용하여 쿼리를 구현하여 결과를 뽑아내는 방식이다.

NoSQL의 경우에는 이 접근 방법을 역순으로 진행해야 한다.

RDBMS가 도메인 모델 à [테이블 à 쿼리] 순서로 진행을 했다면, NoSQL은 도메인 모델 à [쿼리 결과 à 테이블] 순서로 테이블을 디자인해야 한다. RDBMS의 경우 여러가지 최적화된 기능으로 테이블을 가지고 자유롭게 쿼리 결과를 뽑아낼 수 있지만, NoSQL의 경우 복잡한 쿼리 기능이 없기 때문에, 반대로 도메인 모델에서 어떤 쿼리 결과가 필요한지를 정의한후에, 이 쿼리 결과를 얻기 위한 데이타 저장 모델을 역순으로 디자인해야 한다.

2)     정규화(Normalization)에서 비정규화(Denormalization)

RDBMS 모델링에서는 데이타의 일관성과 도메인 모델과의 일치성을 위해서 데이타 모델을 정규화한다. 그중에서도 같은 데이타가 두개 이상의 테이블에 중복되게 저장하는 것을 제거 하는데, NoSQL은 반대의 접근 방법이 필요하다. 쿼리의 효율성을 위해서 데이타를 정규화하지 않고, 의도적으로 중복된 데이타를 저장하는 등의 비정규화된 데이타 모델 설계 방식으로 접근해야 한다.

NoSQL 데이타 모델링 절차

그러면, RDBMS NoSQL의 두가지 결정적인 차이를 인식하고, NoSQL 기반의 데이타 모델링 절차를 살펴보자.

1.     도메인 모델 파악

먼저 저장하고자하는 도메인을 파악한다. 어떤 데이타 개체가 있는지 개체간의 관계는 어떻게 되는지등을 분석하고 ERD를 그려서 도식화 한다. RDBMS의 모델링 접근 방법이고, NoSQL에서는 이렇게 하지 않고 바로 애플리케이션 관점으로 접근하는 경우도 많은데, 도메인 모델 분석 없이 필자의 경우에는 이런 방식에는 반대이다. NoSQL도 데이타베이스이고 저장할 데이타에 대한 명확한 이해 없이는 제대로된 데이타 모델이 나올 수 없다.

다음은 간단한 블로그 시스템의 데이타 도메인 모델이다. 이 블로그 시스템은

Ÿ   사용자 ID 기반으로 블로그의 분류(Category)를 가지고 있고,

Ÿ   분류별로 글을 작성할 수 있으며,

Ÿ   글에 파일을 첨부할 수 있고,

Ÿ   댓글을 달 수 있는 블로그이다.

Ÿ   이번 예제에서는 검색이나 페이징 기능은 제외한다. (단순화 하기 위해서)



2.     쿼리 결과 디자인 (데이타 출력형태 디자인)

다음으로 가장 중요한 과정인 쿼리 결과 디자인이다. “도메인 모델을 기반으로 애플리케이션에 의해서 쿼리 되는 결과값을 먼저 정해야 한다.

앞서 예를 든 블로깅 시스템을 다시 살펴보자



     화면 좌측 상단에는 블로그 사용자의 포스팅 분류명들을 목록 식으로 출력한다.

     포스팅 출력 화면에는 상단에, 포스팅의 분류명과 제목을 출력하고 다음에는 포스팅 날짜, 본문 내용을 출력한다.

     다음에는 첨부파일들을 출력하는데, 첨부파일 업로드 날짜와 파일명을 차례대로 출력하고, 파일에 대한 링크를 출력한다.

     마지막으로 댓글을 출력하는데, 댓글에는 작성일과, 작성자 이름과 댓글 내용을 출력하고, 작성자 이름에는 이메일을 링크한다.

이 출력 형식을 기반으로, 어떤 쿼리가 필요한지를 정의해보자

     전체 분류 출력

select categoryID,name from Category where userID=”사용자ID”

     포스팅의 분류,제목,날짜,본문 출력

select po.postID,po.Contents,po.date,ca.name
from Category ca,Post po
where userID=”
사용자ID”
order by date desc

     첨부 파일 출력

select fileID,filename,date,fileLocation
from Attachment
where userID=”
사용자ID” and postID=”현재 포스팅 ID”
order by date desc

     댓글 출력
select userID,email,Contents,date
from Comment
where userID=”
사용자ID” and postID=”현재 포스팅 ID”
order by date desc

대략적으로 4개의 쿼리가 필요하다. (물론 RDBMS 실제 구현에서는 좀더 최적화 할 수 있겠지만, 이해를 돕기 위해서 단순 구현하였다.) 그러면, 어떤 형태의 데이타 테이블들이 출력되는가?



위와 같이 애플리케이션의 출력형태에 따른 데이타를 정리할 수 있다. 사실 이것이 가장 중요하다. 앞에서도 설명했듯이, NoSQL의 데이타 모델링은 도메인 모델을 중심으로 하는 것이 아니라, 이 애플리케이션의 데이타 출력 내용을 기반으로 하기 때문이다.

3.     패턴을 이용한 데이타 모델링

애플리케이션 데이타 출력 내용을 디자인 했으면, 이제 이 내용을 가지고 NoSQL에 정의될 데이타 모델링을 들어간다. NoSQL Sorting,Grouping,Join 등의 RDBMS 기능을 제공하지 않기 때문에 이를 배제하고 Put/Get으로만 데이타를 가지고 올 수 있는 형태로 데이타 모델 즉 NoSQL내의 테이블을 재 정의 해야 한다.

이 데이타 모델링을 돕기위해서 다음 챕터에서는 NoSQL 데이타 모델링 기법을 다시 설명한다. 이 때 가장 중요한것은 Demoralization이다. 데이타를 가급적 중복으로 저장하여, 한번에 데이타를 읽어오는 횟수를 줄이도록 한다. ( IO자체가 엄청난 부담이기 때문에)

위의 블로깅 시스템 데이타를 일반적인 NoSQL 스타일로 바꾸면 다음과 같다.



특히 Key 부분을 주목해 볼 필요가 있는데, Join을 없애기 위해서, 아예 userID postID“:”로 구분되는 deliminator로 하여 Key에 포함시켜 버렸다. 이는 Join을 없애는 것 이외에 다른 이유가 또 있는데, Ordered Key/Value Store의 경우에는 Key를 기반으로 소팅을 하기 때문에 첫번째, 포스트 ID Sequential하게 증가 시켜 나가면, 같은 사용자의 글의 경우에는 Sorting 이 가능하다. 두번째, Grouping인데, 포스팅을 출력하는 사용자에 대해서 posting을 쭈욱 출력해 나가면, 순차적으로 Post가 출력이 되다가, 해당 사용자의 포스팅 데이타가 끝이나면, Key의 맨앞 userID가 다른 사용자id로 바뀌기 때문에 where문장이 없이도, 특정 사용자의 포스팅을 순차적으로 출력할 수 있다. 뒤에서 설명한 데이타 모델링 패턴에서 Enumerable Key Composite Key Index 패턴을 참고하기 바란다.


4.     최적화를 위한 필요한 기능들을 리스팅

자아 이제 약간은 NoSQL스럽게 디자인이 되었다. 이제는 NoSQL의 특성을 반영하여, 조금 더 디테일한 디자인을 할 수 있다. 다시 애플리케이션 및 데이타의 특성을 다시 한번 들여다 보자

첨부 파일 (Attachment) 파일의 경우에는 포스팅이 작성되었을 때 레코드가 추가되며, 변경이 거의 없다. 그리고 첨부파일의 수는 그리 많지 않기 때문에, 하나의 필드에 모두 몰아서 저장할 수 있다. 이렇게 하나의 필드에 여러개의 데이타를 저장할 경우에는 Document Store를 고려해 볼 수 있다.

그리고 앞에서도 언급했지만 블로그 포스트,첨부파일,댓글은 소팅이 되어야 하기 때문에, Ordered Key 형태가 필요하다.

현재 데이타 모델은 포스팅이 포스트된 순서대로만 출력하는 형태인데, 분류 개념이 있기 때문에, 분류에 따라서 포스팅을 출력하려면 분류 필드가 별도 필드로 들어가야 하고, 이 필드에 따라 where문으로 select할 수 있는 기능이 있어야 한다. 마치 RDBMS Index같은 개념이 필요한데, 이러한 기능을 NoSQL에서는 Secondary Index라고 한다.



이런 옵션등을 적용해보면 Posting 테이블은 위와 같이 변경해볼 수 있다.

여기서 고려해야 할점 하나를 짚고 넘어가자..!!

NoSQL 제품들은 KV, Ordered KV, Document Store등 데이타 모델로는 3가지 분류로 분리가 되긴 하지만, 세세한 내부 아키텍쳐나 기능들은 매우 다르다아주 자세하게는 아니더라도, 어떤 NoSQL 제품군이 있고, 대략적인 기능이 어떻게 되는지를 알아야, 이 정도 수준의 설계를 할 수 있다. 물론 이 단계까지 설계되더라도 아직까지 완벽하지 않다.

솔루션들이 스펙상에 “OOO 기능이 있다.” 하더라도, 그 기능이 제대로 돌아가는 건 아니다. Secondary Index의 경우 Cassandra Riak에서 지원은 하지만 실제 부하를 줘 가면서 테스트를 해보면 성능이 잘 안나오는 경우가 많고, 내부 구조상으로도 고성능을 내기가 어려운 구조이다. 그래서 이런 부가 기능들은 직접 내부 구조를 분석하고, 테스트를 해봐야 사용 가능 여부를 판단할 수 있다.

예전의 RDBMS, 워낙 레퍼런스도 많고, 벤더 지원도 있기 때문에, 써야할, 쓰지 말아야할 기능이 명확하지만 NoSQL의 경우는 제품도 많을 뿐더라, 기술도 신기술이기 때문에 서적조차 드물다. 직접 분석하고 테스트해보는 방법 밖에 없다.


5.     후보 NoSQL을 선정 및 테스트

앞에서 언급한 바와 같이, 모델링한 데이타 구조를 효과적으로 실행할 수 있는 NoSQL을 찾아야 한다. 이는, NoSQL에 대한 구조 및 특성 분석 후에, 실제로 부하 테스트, 안정성, 확장성 테스트를 거친 후에, 가장 적절한 솔루션을 선택해야 한다.

경우에 따라서는 하나의 NoSQL이 아니라, 여러개의 NoSQL을 복합해서 사용할 경우도 있다. 트위터나,페이스북같은 대규모 서비스들은 하나의 NoSQL만을 사용하지 않고 데이타의 성격과 업무의 목적에 맞는 다수의 NoSQL을 선정하여 사용한다.


6.     데이타 모델을 선정된 NoSQL에 최적화 및 하드웨어 디자인

마지막으로 선정된 NoSQL을 기반으로 다시 데이타 모델을 최적화 하고, 이에 맞는 애플리케이션 인터페이스 설계와 하드웨어에 대한 디자인을 진행해야 한다.


지금까지 간단하게나마 NoSQL의 데이타 모델링 절차에 대해서 알아보았다. 다시 한번 강조하지만 NoSQL의 데이타 모델링 방식은 RDBMS가 데이타 자체의 관계를 중요시 하고, 데이타에서부터 출발한다면, NoSQL은 애플리케이션이 출력하고자 하는 데이타 출력 내용에 따라서 데이터 모델링이 완성된다. RDBMS와 역순으로 진행되어야 하고, 데이타 중심이 아니라, 애플리케이션 중심으로 모델링을 진행해야 한다.

그리고 NoSQL은 신 기술 분야이면서 오픈 소스 진영이 주를 이르고 있기 때문에, 기술 지원을 받기가 매우 어렵다. 물론 외국에는 NoSQL에 대해서 유상으로 기술 지원을 해주는 업체들이 있기는 한데, (Cassandra의 경우 DataStax가 기술 지원을 하고, Riak Basho, MongoDB 10gen 등이 기술 지원을 한다.). 국내 실정상 외국엔지니어를 불러다가 기술 지원을 받기도 힘들뿐더러, 기술 지원 회사의 규모가 작기 때문에 숙력된 엔지니어를 필요할때 마다 부르기도 어렵다.

그리고, Amazon등에서 검색해보면 알겠지만, NoSQL에 대한 서적도 그리 많지 않은 편이기 때문에 공부하기도 어렵다. 해외에서 이러한 NoSQL류를 쓰는 업체들은 스스로 내부 개발자들을 역량을 키워서 공부하고, 테스트해서 내재화된 기술을 기반으로 NoSQL을 운용하기 때문에, 단순하게 솔루션 도입 관점에서만 볼 것이 아니라, 기술 내재화 관점에서도 NoSQL 도입을 고려해야 한다.


다음글에서는 NoSQL의 데이타 모델링을 하기 위한 일반적은 데이타 모델링 패턴에 대해서 소개하기로 한다.

저작자 표시
신고
크리에이티브 커먼즈 라이선스
Creative Commons License


이 구성은 Cassandra나 Riak과 같은 Dynamo 계열에 공통 적용 가능하다. 다른 것들도 마찬 가지일테지만.

1. RAID 5 사용 : NoSQL 클러스터는 Quorum 사용을 통해서 노드에 (서버) 대한 FAIL을 방지 하지만 디스크 장애 자체에 대해서는 보장이 불가능하다. 고로 비용 대비 적정한 RAID 5 사용이 권장
2. IO Scheduler : NOOP 사용. NOOP은 IO Scheduling을 다른 계층이 한다는 것을 전제 한다. 즉 중간에 RAID 구성이나 iSCSI 를 사용하는 경우를 전제한다. 테스트용이나 개발용으로 사용하면서 RAID 구성등을 하지 않는다면, NOOP을 사용할 필요가 없다.
3. ext4 또는 XFS 파일 시스템 사용 : ext3는 1 volume의 max 사이즈가 2 TB를 넘지 못한다. ext4의 경우 16TB, XFS는 무제한(64bit 경우)
4. Log File과 Data File 디렉토리 분리 : Cassandra는 Transaction Log와 Data Log 파일이 분리되어 있다.물리디스크도 분리해서 Disk IO를 최적화 해야 한다.
 

=== 2012.04.12 첨언 ===

RAID 구성은 많은 수의 노드를 가지는 경우, 디스크 FAIL을 노드 FAIL로 간주하고, 전체 클러스터의 성능을 높이기 위해서 RAID5를 사용하지 않고 Stripping으로 구성하는 것이 경제성이나 (RAID 5 parity 디스크 사용 안함), 성능 (Stripping이기 때문에, 전체 IO 성능 향상) 관점에서 유리하다.

저작자 표시
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
NoSQL 하드웨어 구성에 있어서, DISK IO에 대한 메모.
RAID 구성은 5가 정답
NoSQL의 N-Value를 통한 장애 대처 능력은 노드간 장애를 대처하기 위함이지, 노드의 디스크 장애 극복은 불가능함.
아주 큰 클러스터가 아니면 RAID 5가 정답, 아니면 스트라이핑 기반의 RAID 0가 정답(대규모 클러스터의 경우, 단 이 경우, 디스크 장애는 해당 노드의 장애를 의미함, 검출도 어려울듯...)

IO Scheduler가 성능 튜닝 포인트라고는 하는데...
오늘 구글링에서 본 자료로는 Scheduler 바꾼다고 IO 자체 성능이 큰 차이가 없는 듯.. 이건 한번 테스트 해봐야 할듯.

결국은 네트워크 분리,캐쉬 튜닝을 어떻게 하느냐가 가능 큰 팩터가 될듯.

저작자 표시
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

짧으나마 NoSQL 경험해보고 배운 내용을 정리해보면

1. RDB는 Entity를 정의하고 데이타 모델링을 정의한 후에, 쿼리와 APP을 개발한다. 반대로 NoSQL은 App을 먼저 디자인하고, 필요한 쿼리 결과를 먼저 정의 한후에, 그에 맞춰서 데이타 모델링을 해야 한다.

2. 절대 Normalization은 하지 말고, DeNormalization을 할것. 데이타 중복을 허용하여 성능을 높이고, 데이타안에 데이타를 넣는 (Composition) 모델등을 사용하여 Query 수를 줄여야 한다.

3. 내 애플리케이션의 서비스 특성과 이에 맞는 NoSQL을 선택한다. BigTable 계열, Cassandra 계열, Document DB 계열등 많은 계열의 NoSQL이 있고, 그 특성도 매우 다르다 (언뜻 보면 다 같아 보이지만). 서비스를 이해하고, 사용하고자 하는 NoSQL을 완전히 이해한 다음에 시작해야 실수를 막을 수 있다.

4. NoSQL 쿼리가 실제 몇개의 물리 노드에 걸쳐서 수행되는지에 대한 이해가 있어야 제대로된 쿼리 디자인이 가능하다.

5. NoSQL 디자인은 DB 와 APP 뿐만 아니라 인프라 (네트워크,디스크)에 대한 디자인을 함께 해야 한다.

6. 대부분의 NoSQL DB는 인증이나 인가 체계가 없어서 보안에 매우 취약하기 때문에 별도의 보안 체계를 마련해야 한다. (방화벽이나 Reverse Proxy 등)
저작자 표시
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

분산 환경 기반의  NoSQL은 예전 포스팅에서도 설명했듯이 크게 Google의 BigTable 논문을 기반으로한 시스템과, Amazon의 Dynamo를 기반으로 한 시스템 두가지로 나뉘어 진다.
Dynamo 계열의 NoSQL의 장단점을 간단히 정리해보면

Dynamo 계열 NoSQL의 개요

1. Ring과 Consistent Hasing
먼저 Dynamo 계열 (Cassandra, Riak) 의 NoSQL의 특징은 Ring 토폴로지를 기본으로 하고 있다. Ring 구성이란, 전체 데이타를 1~N (2^160과 같이 큰 범위로) 이라는 특정 레인지로 정의한후 전체 데이타 저장 구조를 Ring 형으로 정의한 후에, 이 Ring을 피자 조각을 나누듯이 여러 Slice로 나눈다. 이를 Partition이라고 하는데, 각 Partition은 데이타를 저장하는 구간 정보를 가지고 있다. 예를 들어 전체 Ring이 1000개의 데이타를 저장한다고 하고, 각 Partition의 수를 10개로 지정하면 첫번째 파티션은 0~999, 두번째는 1000~1999 까지의 키를 가지는 데이타를 저장한다. 이르 통해서 저장하고자 하는 데이타의 키를 알면 어느 파티션에 저장할 수 있는지 쉽게 찾아갈 수 있기 때문에, 각 Partition을 저장하는 하드웨어(Node)에 부하를 분산 시킬 수 있는 구조를 갖는다. 이런 방식을 Ring 기반의 Consistent Hashing이라고 이야기 한다.

2. N-Value & Quorum
이 경우 특정 파티션을 저장하고 있는 Node가 장애가 났을때, 특성 파티션의 데이타 유실이 발생할 수 있는데, 이를 방지하기 위해서 Node간의 데이타 복제를 수행한다. 몇 개의 복제본을 갖느냐를 정해야 하는데, 이 복제본의 수를 보통 "N-Value" 또는 "Quorum" 이라고 정의하며, 이 Quorum의 수는 일반적으로 3개 정도로 지정한다.
이 N-Value를 3으로 지정하는 이유는 여러가지가 있겠지만, 장애 대응면에서 최소한 하나의 복제본을 가져야하기 때문에 2개의 복제본이 필요하고, 예측된 작업(패치,서버 교체)시에도 장애를 대응하기 위해서 최소한 두개의 복제본을 유지해야 하기 때문에 일반적으로 3개의 복제본을 생성한다. (이 N-Value는 NoSQL 설정에서 조정할 수 있다.)

3. R-Value, W-Value
앞에 설명한 것 처럼, N-Value의 복제본을 가지게 되는데, Dynamo Architecture는 R-Value와 W-Value라는 특성을 유지 한다. 이 값은 "성능과, 데이타 정합성간의 Trade-Off"를 위한 값인데, 데이타 복제는 실시간으로 이루어지지 않는다. 약간의 Delay가 발생한다 (수 밀리세컨드, 데이타 센터간에는 조금더 길 수 있다.)
N-Value를 3이라고 가정하자. 첫번째 Node에 Write를 한후에,  두번째 Node와 세번째 Node에 데이타가 복제 되어야 한다. 이 복제과정에서 데이타를 읽을때, 이 3 노드 중에서 데이타를 몇개의 노드에서 데이타를 읽어올지를 결정하는 것이 R-Value이며. 동시에 몇개의 Node에 Write할것인가를 결정하는 것이 W Value이다.
만약에 W-Value가 2이면 Write시에 동시에 두개의 Node에 Write한다. R-Value가 1보다 클 경우 R-Value 노드 에서 데이타를 읽어오고, 두 개의 데이타가 다를 경우 최근 데이타를 사용한다.

이런 이유로 R-Value + W-Value > N-Value이면 Data Consistency가 보장된다.
예를 들어 N=3일때, R=2,W=2이면, Write시 적어도 두개의 복제본에 썼기 때문에, 하나가 복제가 안되어 있다하더라도, R-Value가 2이기 때문에, 꼭 하나는 새로운 데이타가 읽어지게 되고, 새로운 데이타를 Winning하는 정책 때문에 항상 최신의 데이타를 읽을 수 있다. (여기서 새로운 데이타를 판단 가능하게 하는 방법을 Vector-Clock이라고 한다. 이는 나중에 따로 포스팅 예정)

참고 : http://wiki.apache.org/cassandra/ArchitectureOverview 

Consistency

See also the API documentation.

Consistency describes how and whether a system is left in a consistent state after an operation. In distributed data systems like Cassandra, this usually means that once a writer has written, all readers will see that write.

On the contrary to the strong consistency used in most relational databases (ACID for Atomicity Consistency Isolation Durability) Cassandra is at the other end of the spectrum (BASE for Basically Available Soft-state Eventual consistency). Cassandra weak consistency comes in the form of eventual consistency which means the database eventually reaches a consistent state. As the data is replicated, the latest version of something is sitting on some node in the cluster, but older versions are still out there on other nodes, but eventually all nodes will see the latest version.

More specifically: R=read replica count W=write replica count N=replication factor Q=QUORUM (Q = N / 2 + 1)

  • If W + R > N, you will have consistency

  • W=1, R=N
  • W=N, R=1
  • W=Q, R=Q where Q = N / 2 + 1

Cassandra provides consistency when R + W > N (read replica count + write replica count > replication factor).

You get consistency if R + W > N, where R is the number of records to read, W is the number of records to write, and N is the replication factor. A ConsistencyLevel of ONE means R or W is 1. A ConsistencyLevel of QUORUM means R or W is ceiling((N+1)/2). A ConsistencyLevel of ALL means R or W is N. So if you want to write with a ConsistencyLevel of ONE and then get the same data when you read, you need to read with ConsistencyLevel ALL.



4. Masterless Architecture
또다른 특징 중에 하나는 Masterless 아키텍쳐이다. Ring을 구성하고 있는 아무 Node에나 요청을 보내도 처리가 되고, 전체 설정 정보를 가지고 있는 마스터 노드나 Admin 노드가 없다.
10개의 노드를 가지고 있는 Ring의 아무 Node에나 Request를 하더라도, 각 Node는 해당 데이타가 다른 어느 Node에 저장되어야 하는지를 Consistent Hash를 통해서 알 수 가 있고, 해당 노드로 Request를 Routing한다. 이때 자기가 데이타를 가지고 있지 않더라도 첫번째 요청을 받은 Node가 데이타를 처리하는 이 노드를 Coordinator Node라고 정의한다.

지금까지 대략적인 Dynamo 아키텍쳐의 특성에 대해서 알아보았다. 그러면 어떤 장단점이 있을까?

장점
1. High Availibility & Partition Tolerence
위와 같은 특성 때문에, 분산 시스템의 CAP 이론에서 A와 P에 최적화 되어 있다. 특정 노드가 장애가 나더라도 서비스가 가능하며 (A-Availibility) Node간의 네트워크 통신이 끊어지더라도 서비스가 가능하다 (P-Partition Tolerance : Vector Clock을 이용하여 데이타의 정합성을 처리가 가능하고 각 노드가 독립적으로 서비스가 가능

2. No Sigle Failure Point. No Master Node
그리고 Masterless 아키텍쳐로 인해서 Single Failure Point (SFP)가 없다. 이는 대규모 분산 환경에서 아주 큰 장점 중의 하나인데, 무제한 확정된 클러스터라도, 특정 노드 장애에 대해 종속이 되어 버리면 시스템의 안정성에 많은 영향을 미친다.

단점
반대로 단점은
1. Cannot Change Ring Size
일반적인 Dynamo 기반의 아키텍쳐는 Ring Size (Partition 수)를 변경할 수 없다. 데이타가 이미 Partition 별로 분산 저장되어 있기 때문에 파티션의 개수를 변경하면 다시 데이타를 변경된 파티션 수 에 따라 재 분배해야 한다. 이는 데이타의 이동을 초래하고, 많은 IO 부하를 유발하기 때문에 운영환경에서는 거의 불가능하다고 봐야 한다.

2. Data InConsistency
앞에서 설명한 바와 같이 데이타 복제가 실시간이 아니기 때문에 데이타에 대한 불일치가 발생한다. 물론 R,W Value를 조정해서 Consistency를 보장받는 방안은 있지만, 이 값을 높일 경우 동시에 여러 노드에 Read 또는 Write를 해야 하기 때문에 성능저하가 발생할 수 있고, 또한 Node간에 네트워크가 단절되는 Partitioning이 발생했을 때도 서비스는 되기 때문에, 다시 장애가 극복되었을때는 당연히 Data InConsistency가 발생하게 된다.

3. Sibling (Data Conflict 발생)
특히 네트워크 Partitioning이 발생하거나 또는 동시에 두개의 Client가 Write를 했을때, Vector-Clock 값이 똑같아서 어느 데이타가 더 최근 데이타인지 판단할 수 없는 Data Conflict (Sibling현상)이 발생한다. (Sibling의 자세한 개념은 나중에 Vector Clock 설명에 같이 추가)
저작자 표시
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

NoSQL 계보 정리

클라우드 컴퓨팅 & NoSQL/NoSQL 일반 | 2011.11.14 17:45 | Posted by 조대협

Google의 BigTable에서 시작된 것들
- HBase (Java)
- HyperTable (C++)
주로 대규모 분산처리 특히 Map&Reduce에 알맞고, 동시 대규모 클라이언트를 지원하는데 뛰어 나다

Amazon Dynamo 로 부터 시작된 것들
- Voldemork
- Riak

FaceBook에서 시작된것
- Cassandra
Write에 Optimize되었으며, Read는 Write에 비해 느림. 대규모 데이타 저장에 최적화됨

그밖에 Mongo 계열
-MongoDB 쉽다. 그리고 AutoSharding과 Balacing 제공. 10gen에서 Commercial Support
-CouchDB : MongoDB와 특성은 유사하나 내부 기술 구조는 다름
저작자 표시
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

No-SQL DB Comparison

클라우드 컴퓨팅 & NoSQL/NoSQL 일반 | 2011.01.06 09:51 | Posted by 조대협
http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis

Mongo DB,Cassandra,HBase 등 NoSQL에 대해서 비교를 해놨음

저작자 표시
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
http://research.microsoft.com/en-us/people/sriram/raghuramakrishnan.pdf
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
 

티스토리 툴바