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


Archive»


 
 

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 구직 분포>

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의 데이타 모델링을 하기 위한 일반적은 데이타 모델링 패턴에 대해서 소개하기로 한다.


이 구성은 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 성능 향상) 관점에서 유리하다.

Riak이 좋은 이유 7가지

클라우드 컴퓨팅 & NoSQL/Riak | 2012.03.20 11:11 | Posted by 조대협
http://seancribbs.com/tech/2010/02/06/why-riak-should-power-your-next-rails-app/

'클라우드 컴퓨팅 & NoSQL > Riak' 카테고리의 다른 글

Riak이 좋은 이유 7가지  (0) 2012.03.20
Riak 장점 다시 정리  (2) 2012.03.12
Riak Performance  (0) 2012.03.12
Riak vs CouchDB  (0) 2012.03.12
NoSQL Riak Overview #1/2  (0) 2012.02.21
Riak관련 스터디 메모  (0) 2012.02.21
TAG Riak

Riak 장점 다시 정리

클라우드 컴퓨팅 & NoSQL/Riak | 2012.03.12 23:26 | Posted by 조대협
지금까지 파악한 Riak 장점

1. Masterless 아키텍쳐로 Single Failure Point가 없다.
2. Replication이 빵빵하다.
3. Multi data center replication이 빵빵 (유료 버전만 지원)
4. Full Text Search (Lucene을 내장하여 FTS를 그냥 지원.. 인스톨도 쉬움)
5. Secondary Index 지원
6. 상당히 향상된 Map & Reduce 지원. Erlang 기반이라서 훨씬 신뢰가 감
7. Basho의 Support도 좋음. (경험해본 결과 좋음)
8. Physical storage를 Basho의 bitcask, oracle innostore, google level db,memory 지원
9. Luwak을 이용하여, Big File 저장도 지원
10. REST IF도 지원하지만, Google의 Protocol Buffer도 지원한다. (테스트해본 결과 HTTP REST보다, protocol buffer 성능이 더 높음)
11. Scalability가 높음 --> Mongo나 Couch 랑 Riak 사이에서 고민들 하는 이유가 대부분 Scalability 이슈들이 많음

단점은
1. 일반적인 성능은 Mongo에 비해서 떨어짐
2. 아직 레퍼런스가 그리 많지 않음

조금 더 디테일한 성능 데이타를 뽑아봐야 하는데~~

'클라우드 컴퓨팅 & NoSQL > Riak' 카테고리의 다른 글

Riak이 좋은 이유 7가지  (0) 2012.03.20
Riak 장점 다시 정리  (2) 2012.03.12
Riak Performance  (0) 2012.03.12
Riak vs CouchDB  (0) 2012.03.12
NoSQL Riak Overview #1/2  (0) 2012.02.21
Riak관련 스터디 메모  (0) 2012.02.21

Riak Performance

클라우드 컴퓨팅 & NoSQL/Riak | 2012.03.12 23:21 | Posted by 조대협
http://blogs.digitar.com/jjww/2011/03/riak-vs-couchdb-for-storing-100000-coupons/

CouchDB와 비교한 Performance Report가 있는데
Riak 0.14 버전 기준 작년 3월(1년전)이니 많은 변화는 있었겠지만 얻을만한 데이타가 많다.
  • Indexed insertion is 91% slower than storing just the key data.
  • MapReduce with indexes is 20% faster than MR on the data keys alone.
  • MapReduce with indexes and key filters is 32% faster than MR on the data keys alone.
  • Adding Riak nodes substantially reduces query time. Adding 3 more nodes speeds up queries by 40%.

    1. 2'nd index를 사용할시 2배 정도 느리다. (아마 W VALUE를 2정도로 해놓고 테스트 한게 아닌가 싶고)
    2. MR 사용시 2'nd index를 사용하면 더 빨라진다.
    3. Riak Node가 늘어날 수 록  Query Time이 빨라진다. (이건 좀 이상하네..)
    4. 결정적으로 MR (Map & Reduce)의 경우 2'nd index를 적절히 사용하면 CouchDB 이상의 성능을 낼 수 있다.
  • Mongo에서도 더 높은 성능을 낼 수 있을까?

    ==
    첨부

    내일 조금 더 찾아봐야 겠지만, 위의 테스트 결과도 그렇고, Riak MR은 "Filtered set of key"를 이용해서 Mongo 보다 높은 Performance를 내는거 같은데... 이 filtered set of keys가 몬가..... Mongo는 무조건 coverage query 사용하는 것 같고..

    http://nosql.mypopescu.com/post/7011323761/brief-mongodb-and-riak-comparison
    The advantage of Riak over Mongo is that Riak automatically replicates and rebalances.

    The advantage of MongoDB over Riak is that Mongo supports secondary indexes and a more robust query language.

    Both Riak and MongoDB support MapReduce via JavaScript, and both use the SpiderMonkey JavaScript engine. However, Riak’s MapReduce framework is more powerful than MongoDB’s framework because Riak allows you to run MapReduce jobs on a filtered set of keys. By contrast, in Mongo, you have to run MapReduce jobs across an entire database.

    결과적으로, Insert 성능은 Mongo에 비해서 떨어질 수 있지만, Read intensive하고, complexity가 좀 있는 복합 쿼리의 경우 Mongo,Couch 대비 Riak이 filtered set of keys를 써서 Query 성능을 더 올릴 수 있다는 것 같은데...
    내일 라슨씨한테 좀 물어봐야 겄다.

    '클라우드 컴퓨팅 & NoSQL > Riak' 카테고리의 다른 글

    Riak이 좋은 이유 7가지  (0) 2012.03.20
    Riak 장점 다시 정리  (2) 2012.03.12
    Riak Performance  (0) 2012.03.12
    Riak vs CouchDB  (0) 2012.03.12
    NoSQL Riak Overview #1/2  (0) 2012.02.21
    Riak관련 스터디 메모  (0) 2012.02.21

    Riak vs CouchDB

    클라우드 컴퓨팅 & NoSQL/Riak | 2012.03.12 22:58 | Posted by 조대협


    CouchDB의 Kick-ass replication만 기억에 남네 그랴.

    '클라우드 컴퓨팅 & NoSQL > Riak' 카테고리의 다른 글

    Riak 장점 다시 정리  (2) 2012.03.12
    Riak Performance  (0) 2012.03.12
    Riak vs CouchDB  (0) 2012.03.12
    NoSQL Riak Overview #1/2  (0) 2012.02.21
    Riak관련 스터디 메모  (0) 2012.02.21
    Riak Quick Review  (0) 2011.12.19

    짧으나마 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 등)
    MongoDB 깜빡 잊고 있었다. Read / Write 성능이 빠를 수 밖에 없다는 걸..
    Mongo는 Write시에, Memory에 먼저 Write후에, 1분 단위로 Flushing하는 Write Back 방식을 쓴다. 즉 메모리에만 쓰면 되니까는 Write가 무지 빠르다. 반대로 Read시에는 파일의 Index를 메모리에 로딩해놓고 찾는다(memory mapped file). 이러니 성능이 좋을 수 밖에, 단 Flushing전에 Fail이 되면 데이타 유실에 의해서 Consistency 가 깨지는 문제가 발생하고, Configuration 구조상 메모리 사용량이 많으며, 확장성에 제약이 있다.
    특히 Write 구조에서는 비동기 식으로 Write를 하기 때문에 Disk 성능에 덜 Sensitive하다. 즉 이 말은 DiskIO성능이 상대적으로 낮은 클라우드에서 더 잘돌아간다는 이야기.

    이에 비해서 Cassandra(같은 Dynamo 계열인 Riak도 마찬가지) 는 Write Back이나 Memory Mapped file을 사용하지 않기 때문에 MongoDB에 비해서 성능이 낮을 수 밖에 없다. 더군다나, Write나 Read시 1개 이상의 Node에서 값을 읽거나(R Value) 쓰기 때문에(W Value) Consistency가 mongoDB에 비해서 나으며, 당연히 확장성도 더 높다.

    즉 확장성+일관성 vs 성능간의 Trade Off 구조다.
     
    한국 내 정도 서비스 할 수준이라면 걍 mongo가 났겠네.. 대규모 서비스라면 Cassandra 고민해봐야 할듯 하고.

    분산 환경 기반의  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 설명에 같이 추가)

    NoSQL Riak Overview #1/2

    클라우드 컴퓨팅 & NoSQL/Riak | 2012.02.21 18:21 | Posted by 조대협

    Riak 계보

    Riak은 이미들 잘 알고 있는 NoSQL 데이타 베이스이다. Basho.com이라는 회사에서 만들어서 배포하고 있고, 무료 버전인 Community version과 상용 기술 지원을 받을 수 있는 Enterprise version을 지원하고 있다.

    NoSQL 계보는 크게 두 가지로 나눠지는데,  Google Big Table 논문을 기반으로 한 HBase,HyperTable 등과, Amazon Dynamo 논문을 기본으로 한 Cassandra등의 계열로 나뉘어 지며, Riak Dynamo 계열에 속한다.

    데이타 모델에 있어서는 Key,Value 저장형식을 취하는데, Value JSON 문서가 저장되는 문서 저장형 데이타 베이스 형식을 취하며, 이는 MongoDB CouchDB와 유사한 데이타 모델을 갖는다.

    이런 특성 때문인지, MongoDB로 부터 Migration되는 사용자가 많은 것으로 알려져 있다.

    Riak의 기술적인 특징

    Ring 구조 기반의 아키텍쳐

    Riak은 앞에서 언급했듯이, Dynamo 계열의 구조를 가지기 때문에 데이타를 분산 저장 시키는 구조에 있어서 Ring 구조를 갖는다. Hash 알고리즘에 의해서, 데이타 Key에 따라서, 적정 노드를 찾아가는 구조로 되어 있다.


    Riak의 클러스터링 단위는 크게 node vnode로 나눌 수 있는데, node는 물리적인 서버를 지칭하며, vnode는 논리적인 서버로 하나의 인스턴스 개념정도로 생각하면 된다. 하나의 물리서버에는 여러개의 논리서버 (vnode)를 설치할 수 있다.

    Riak은 이 Ring 구조를 Runtime 시에도 동적으로 재 설정할 수 있다. (node를 추가하거나 뺄 수 있다. )이 과정에서 Riak이 자동적으로 데이타를 변형된 Ring 구조에 따라서 재배포 한다.

    마스터 노드가 없는 아키텍쳐

    Mongodb등은 데이타를 저장하는 노드와, Request를 라우팅하는 (mongos,mongod)로 구성된다. master-slave 개념이 있는 아키텍쳐인데 반해서, Riak은 별도의 마스터 노드를 가지지 않는다. 이 말은 Single Failure Point (단일 장애 지점)이 없다는 것을 의미한다. 각 노드로의 로드밸런싱은 앞단에 L4 스위치를 넣거나 Apache NginX와 같은 웹서버를 이용하여 소프트웨어 로드밸런서(Reverse Proxy)를 사용하여 구성할 수 있다.

    ※ 앞단의 로드밸런서는 Riak vnode의 장애상태를 판단할 수 없기 때문에, Riak에서 제공되는 Client SDK를 사용하면, 신속한 장애 감지가 가능하며, 이에 더하여 Connection Pooling등을 이용하여 성능 향상과 자원 사용의 효율성을 높일 수 있다.

    데이타 복제 (Replication)

    NoSQL 답게 내부적으로 데이타를 복제하는 구조를 가지고 있다. 몇개의 데이타를 복제하느냐를 “N-Value”라고 하는데, 일반적으로 디폴트 설정이 3개의 복사본을 가지는 것을 정책으로 한다.

    일반적으로 근래에 나오는 분산 저장 시스템은 3개의 복사본을 가지는 것이 유행인데, 3개를 갖는 이유는 1개의 데이타 본에 대해서 작업을 진행하고 있을때, (확장이나 삭제) 장애가 났을때를 대비해서 2개의 노드가 Active상태인 것을 유지하기 위함이다.

    당연히 노드간의 데이타 복제가 이루어 지는데, 이 데이타 복제는 실시간으로 이루어지는 것이 아니기 때문에 데이타의 consistency가 정확하게는 보장되지 않는다. 즉 데이타를 WRITE하고나서, 다른 노드에서 READ를 할 경우 복제가 이루어지기 전에 READ하면 예전 데이타가 READ될 수 있다는 의미이다. (millisecond 단위이기는 하지만)

    CAP 이론

    CAP 이론은 2002년 버클리 대학의 Eric Brewer 교수에 의해서 발표된 분산 컴퓨팅 이론으로, 분산 컴퓨팅 환경은 Consistency, Availability, Partitioning 3가지 특징을 가지고 있으며, 이중 두가지만 만족할 수 있다는 이론이다.


        Consistency는 분산된 노드중 어느 노드로 접근하더라도, 데이타 값이 같아야 한다는 기능적 특징이다. (데이타 복제 중에 Query가 되면, Consistency를 제공하지 않는 시스템의 경우 다른 데이타 값이 Query 될 수 있다)

        Availability는 클러스터링된 노드중, 하나 이상의 노드가 FAIL이 되더라도, 정상적으로 요청을 처리할 수 있는 기능을 제공하는 특징이다.

        Partition Tolerance는 클러스터링 노드간에 통신하는 네트워크가 장애가 나더라도 정상적으로 서비스를 수행할 수 있는 기능이다.

     

    Riak은 이중에서 A P를 지원하는 방향으로 구현되어 있다..

    Riak의 데이타 구조

    Bucket

    Bucket RDBMS database로 보면 된다. 일종의 컨테이너로 여러개의 keyspace (RDBMS로 치면 table)를 담고 있으며, Bucket 마다 Property로 특성을 정의할 수 있다. (복제되는 Replica의 수나, 실제 저장되는 물리 스토리지 타입등)

    Data Structure

    Riak은 다른 NoSQL과 유사하게 Key-Value 형태의 저장 구조를 갖는다. (Hash Table을 생각하면 쉽게 이해할 수 있을 듯). Key는 해당 Bucket에서 Unique해야 하며, Value JSON Document 또는 Binary 데이타를 저장할 수 있다. 특이 사항은 데이타 구조에 Header 부분을 포함하고 있는데, Header는 사용자가 정의하는 메타데이타나 또는 Riak에서 제공하는 Index 지정, Object와의 Link 관계등을 정의한다.

     

    Riak Architecture

    지금까지 Riak의 일반적인 특성에 대해서 알아보았다. 조금 더 깊게 들어가서 Riak의 아키텍쳐 및 몇몇 기술적인 특징에 대해서 살펴보도록 한다.


    <그림 Riak Architecture Stack>

    Storage BackEnd

    Riak은 데이타를 저장할 때, 물리적인 저장소를 선택할 수 있는데, 다음과 같이 크게 4가지 저장소 타입을 지원한다.


    BitCask

    Bitcask Basho에서 만든 스토리지로, Erlang을 베이스로 한다.
    Key Index
    를 메모리에 올리기 때문에 빠른 성능을 제공하지만 반대로, 다른 스토리지 백엔드에 비해서 많은 메모리를 필요로 한다
    .
    Bitcask
    append only 데이타베이스로, 데이타에 대한 삭제나 변경이 불가능하기 때문에, 데이타의 삭제 변경이 일어나면 새로운 버전을 저장하고 History를 관리하는 형태를 취한다. 이 때문에, 예전 버전을 주기적으로 삭제하는 Garbage Collection 작업을 수행한다.

    InnoStore

    Innostore Oracle InnoDB Wrapping한 스토리지로 대용량 저장에 강점이 있다고 한다. InnoDB, 이미 MySQL Backend로도 검증이 된 만큼 신뢰성도 높고, Oracle쪽으로 부터 Commercial Support도 받을 수 있으니, 안정성 측면에서 조금 더 높은 보장이 가능하지 않을까 하는 개인적인 생각이다.

    InnoStore는 기본적으로 Riak에서 그리 추천하지는 않으나, BitCask의 경우는 메모리를 많이 필요로 하는 반면 InnoStore는 메모리를 많이 필요로 하지 않기 때문에 이런 시나리오에서 사용이 가능하다. InnoStore 설계시 주의점중의 하나는 InnoDB DB 파일과 Log 파일을 별도의 Disk에 나눠서 저장해야 제 성능을 발휘 할 수 있다.

    LevelDB

    LevelDB Google에서 얼마전에 발표한 DB, BigTable 이론에 근간을 두고 구현되었다.

    마지막으로 Memory가 있는데, Memory는 현재 문서상으로 봤을때는 테스트등의 용도로 주로 사용이 되며, Redis Memcached와 같은 메모리 캐쉬 용도로도 사용이 가능하리라 판단된다. (주관적인 생각)

    Riak에서는 용도와 목적에 따라서 이 4가지 Storage BackEnd를 하나의 Riak Cluster에서 혼합하여 사용할 수 있도록 한다.

    문서상에는 4개의 Storage BackEnd에 대한 특징이나 선택 방법에 대해서 명확한 가이드를 주고 있지는 않으며, Default로는 BitCask를 추천하고 있으며, Secondary Index를 사용하고자 할때는 BitCask + LevelDB를 추천하고 있다.

    Riak KV

    Riak KV Key Value Storage, Riak의 메인 데이타 저장 구조를 담당하는 부분이다. Key : Value Pair로 데이타를 저장한다. 데이타를 Query하는 면에서 두 가지 방식을 지원하는데, Secondary Index MR (Map & Reduce)를 지원한다.

    Map & Reduce

    MR은 데이타 검색에 관련된 작업을 여러개의 vnode로 나눠서 작업을 한후 (Map), 결과를 합쳐서 리턴해주는 형태(Reduce)를 사용한다. MR을 사용할때, Map Function Reduce Function을 정의해서 request에 함께 보내는데, Map Reduce Function Erlang 또는 JavaScript 기반으로 작성이 가능하다.

    (참고 : Riak MR - http://wiki.basho.com/MapReduce.html)

    Map 예제) 데이타에서 “High” 필드가 600 이상인 값을 찾는 Map Function (JavaScript 버전)

    Function(value, keyData, arg) {

      var data = Riak.mapValuesJson(value)[0];

      if(data.High && data.High > 600.00)

        return [value.key];

      else

        return [];

    }

    실제로 Riak에 호출할때는 REST+JSON을 이용하여 HTTP Request를 다음과 같이 보낸다.

    {"inputs":"goog",

     "query":[{"map":{"language":"javascript",

                      "source":"function(value, keyData, arg) { var data = Riak.mapValuesJson(value)[0]; if(data.High && parseFloat(data.High) > 600.00) return [value.key]; else return [];}",

                      "keep":true}}]

    }

     

    Map & Reduce 예제) 다음 예제는 Map Reduce를 포함한 예제이다.
    Map
    을 이용하여, 매월별 매출의 편차(최고-최소:data.High-data.Low)를 계산하고, Reduce 단계에서 매월 매출 편차가 가장 큰 값을 찾는 예제이다.

    /* Map function to compute the daily variance and key it by the month */

    function(value, keyData, arg){

      var data = Riak.mapValuesJson(value)[0];

      var month = value.key.split('-').slice(0,2).join('-');

      var obj = {};

      obj[month] = data.High - data.Low;

      return [ obj ];

    }

     

    /* Reduce function to find the maximum variance per month */

    function(values, arg){

      return [ values.reduce(function(acc, item){

                 for(var month in item){

                     if(acc[month]) { acc[month] = (acc[month] < item[month]) ? item[month] : acc[month]; }

                     else { acc[month] = item[month]; }

                 }

                 return acc;

                })

             ];

    }

     

    Secondary Index

    이번 릴리즈에서 Riak의 새로운 강력한 기능 중에 하나가 Secondary Index를 지원하는 기능이다. 쉽게 이야기 하면, RDB로치자면 Primary Key 뿐만 아니라, 테이블 상에 여러개의 Column Index를 걸어서 특정 Record Query할때 빠른 응답 시간을 보장한다. (Riak은 하나의 KeyStore에 여러개의 Index를 동시에 걸 수 있다.)

    Riak에서 Index를 정의하는 방법은 REST PUT/POST 메서드를 이용해서 데이타를 입력하거나 수정할때, 헤더 부분에 “x-riak-index-{인덱스명}_{데이타타입}:{인덱스 데이트} 형식으로기술 한다. 다음은 user 라는 Key Value Store“twitter”“email”이라는 필드를 인덱스로 지정하는 예제이다.

    curl -X POST \

    -H 'x-riak-index-twitter_bin: rustyio' \

    -H 'x-riak-index-email_bin: rusty@basho.com' \

    -d '...user data...' \

    http://localhost:8098/buckets/users/keys/rustyk

     

    Index를 이용해서 데이타를 쿼리 하는 방법은 HTTP GET /{버킷명}/index/{인덱스명}/{인덱스값} 으로 서술하면 된다. 아래는 “users”라는 버킷에서 “twitter_bin” index에서 “rustyio”라는 값을 가지는 Object를 쿼리 해오는 예제이다.

    localhost:8098/buckets/users/index/twitter_bin/rustyio

    2012 2월 현재 Riak Secondary Index는 몇 가지 제약사항을 가지고 있다. 먼저 여러개의 Index를 동시에 사용하여 검색을 할 수 없으며, 검색 결과에 대한 Sorting이나 Paging은 지원되지 않는다. (Range Search는 가능-예를 들어 나이가 20~30세 사이를 갖는 Object에 대해서 Index를 가지고 검색 가능)

    Index 정보는 파일 형태로 Object가 저장되는 동일한 vnode에 저장되며, Index 정보는 내부적으로 Google LevelDB storage backend에 저장된다. Key/Value의 경우 Ring Topology를 기본으로 Key값에 대해서 Hash 값을 기반으로 특징 vnode를 찾아가기 때문에, 그 특정 vnode request를 받는데 반해서, Index 기반의 Query의 경우, Index 값이 어느 vnode에 저장되었는지 찾을 수 가 없다. (앞서 설명하였듯이, Object에 대한 Index Object가 저장된 동일한 vnode에 저장이 되기 때문에, Index값을 기반으로 Hash 등의 검색이 불가능 하다. ) 이런 이유로 index Query를 수행하게 되면 전체 vnode Query가 분산 되서 수행되기 때문에, Index 기반의 Query는 전체 노드에 부담을 준다. (1/N vnode에서 수행됨)

    Riak Search

    Riak Search Value의 내용을 가지고 검색을 가능하게 해주는 Full Text Search (FTS) 기능이다. Riak Search Apache FTS Lucene (http://lucene.apache.org)을 기본으로 구현되었고, Riak Erlang으로 구현되어 있고 원래 Lucene Java로 구현되어 있기 때문에 Riak에 최적화하기 위해서 Lucene의 일부를 Erlang으로 재구현하였다.

     설명에 앞서서 앞에 아키텍쳐 다이어그램에서는 Riak Search Riak KV와 분리해서 표현하였지만, 물리적으로 Riak Search Riak KV의 일부이다. (KV를 설치하면 안에 Search가 들어가 있다.) 이는 Riak의 디자인 사상과도 결부되는데, Search를 별도의 모듈로 분리하지 않고 합침으로써 운영에서 많은 컴포넌트를 관리해야 하는 부담을 덜어준다.

    먼저 Search에 대해서 이해하기 이해서 Search 가 어떻게 Search Index를 저장하는지를 이해할 필요가 있다. Riak Search Index 저장 방식은 “Term Partitioning” 이라는 기법을 사용한다. Key/Value안에 있는 Value Text Parsing Term 단위로 나눈다. 이때 Term 단위로 잘라내는 것을 Analyzer가 담당하는데, 단순하게 탭이나 스페이스 단위로 잘라서 Term을 추출할 수 도 있고, 아니면 검색 Dictionary 기반을 사용하는 등 여러가지 방법을 사용할 수 있으며, 사용자 요구 사항에 따라서 직접 Analyzer를 제작할 수 도 있다.
    http://wiki.basho.com/Riak-Search---Indexing.html

    Term이 추출이 되면 이 Term Index로 사용하는데, Term을 전체 Cluster에 걸쳐서 분산해서 저장한다. Key-Value 저장 방식과 거의 동일한 방식으로 나눠서 저장하며 N-Value에 따라서 복제본 역시 같은 형태로 저장한다.

    이렇게 Term Partitioning을 사용함으로써, Query시에 Search Keyword가 들어오면 단일 단어의 경우 어느 vnode에 저장되는지 Hash값을 통해서 찾을 수 있기 때문에, 전체 노드에 걸쳐서 Search 연산이 일어나지 않는다. (Secondary Index와 비교되는 부분). wild card 문자를 사용하거나 AND,OR등의 기타 연산문을 사용할 경우 경우에 따라 1~1/N개의 vnode에 걸쳐서 Query가 분산되어 수행될 수 있다.

    Map & Reduce, Secondary Index, Search 비교

     

    MapReduce

    Riak Search

    Secondary Indexs

    Query Types

    Map Reduce Function을 이용하여 쿼리 구현

    Lucene SOLR 쿼리를 사용하여, 텍스트 검색, wildcard 모델과 Boolean 검색(AND,OR) 사용

    동일값 비교(Equality), 범위 기반의 쿼리(Range Query)지원

    Index Locality

    N/A

    Search Index N개의 vnode에 분산되어 저장됨 Riak KV와 동일한 백앤드를 사용

    Object가 저장된 동일한 vnode Index가 저장됨
    Data Storage Backend
    LevelDB를 사용함

    Vnodes Queried

    Depends on input

    Map & Reduce 로직에 따라서 Query가 수행되는 vnode가 결정됨

    1 per term queries; 1/N for trailing wild card

    하나의 “Term”으로 검색할 경우, “Term Index”가 저장된 vNode에서 수행됨.

    Wildcard 검색을 할 경우 전체(1/N) vNode에 걸쳐서 수행됨

    1/N per request (aka coverage query)

    전체(1/N) vnode에 걸쳐서 분산 수행됨

    Supported Data Types

    Map Reduce를 위해서 Erlang JavaScript 사용, JSON 사용

    Integer, Date and Text

    Binary and Integer

    Suggested Use Cases

     

    Value 내의 Full Text Search

    Tag 기반 검색

    Poor Use Cases

    많은 수의 Object에서 복잡한 연산을 하는 케이스

    Searching for common terms in documents

     

    Limitation

     

     

    Backend Storage LevelDB 를 사용해야함

    동시에 여러개의 Index를 사용하는 Query는 불가능함

    Anti-Entropy Fault Tolerance

     

     

     

    Extraction

     

     

     

     

    '클라우드 컴퓨팅 & NoSQL > Riak' 카테고리의 다른 글

    Riak 장점 다시 정리  (2) 2012.03.12
    Riak Performance  (0) 2012.03.12
    Riak vs CouchDB  (0) 2012.03.12
    NoSQL Riak Overview #1/2  (0) 2012.02.21
    Riak관련 스터디 메모  (0) 2012.02.21
    Riak Quick Review  (0) 2011.12.19

    Riak관련 스터디 메모

    클라우드 컴퓨팅 & NoSQL/Riak | 2012.02.21 12:09 | Posted by 조대협

    Vnode
    - vnode - process (One Erlang process per partition in the ring)
      partition - data
    - Vnode는 MR 처리를 하는 Worker가 따로 있음
    - VNode Master
     : Receieve msg from request corrdinator
    - FSM (Finate State Machine)
      1) Type 1 : Preference list-based : single key
      2) Coverate based : entire keyspace


    W+R > N : Consistency 를 보장할 수 있다.
    (W : Write Replica 수)
    (R : Read Replica 수)

    Java SDK 에 Load Balancing  Logic 이 들어있다.


    Vector Clock
    - Every node has an ID (changed in ID)
    - Send last-screen vector clock in every "put", "delete" request
    - Riak tracks updates
     1) auto-reslves stale version
     2) Lets you decide conficts

    ※ Vector Clock 이 동일한 값이 나오는 경우가 Sbling 이 발생하고, 사용자가 풀어서 결정해야 한다.
    - Conflict는 Network partition이 발생했을 때, 발생할 가능성이 높음
    - vClock 을 update할 때, 인위적으로 같은 vClock을 동시에 넣을때 발생함
      (vClock을 GET하고, 다시 PUT할때)

    Search

    ==============
    Storage Backend
    1. Bitcask
    - append only KV store
    - All key is stored in memory
    - copaction을 통해서 garbage collection. (Stop 하지 않고 async로 발생, 언제 발생할지도 설정할 수 있다)
    - 1 compaction process가 추가로 필요하다.

    2. Innostore
    -  Write Ahead log + B tree
    - 순차대로 데이타가 insert될때, 유리 하다.
    -  메모리에 Key를 안 올린다. 그래서 Bitcask에 비해 메모리 사용률이 적다.

    3. LevelDB
    - Append Only
    - Mutiple leve of SSTable-like structure
    - Secondary Index를 지원함. (BitCask는 지원 안함)
    - Performance 가 Bitcask에 비해서 more variable
    =======


    /etc/riak/vm.config --> Erlang VM Configuration
    /etc/riak/app.config --> Riak Config

    ====
    FileSystem : ext3/4, ZFS 파일 시스템을 사용할것
    Innostore 사용시 log 데이타 disk를 분리할것


    ===

    Riak MR --> Memory를 사용하고, Disk를 사용 안함 (smallish scale)
     (무거운 MR은 Riak Hadoop Connector를 사용해서 Hadoop에서 실행)

    >Pre-reduce : MAP 단계에서 Final Reduce가 발생하기 전에, pre-reduce수행
    >reduce의 수행 횟수를 조정할 수 있음 : (Paging에 활용 가능) 1000개 합치는거가 100개씩 10번 수행되면 1번씩 수행해서 10개 페이지로 나눌 수 있음 (reduce_phase_only_1 옵션)
    >reduce_phase_batch_size


    - Riak의 하나의 Client 처럼 동작함

    ===

    Secondary Index
    --> 1/N node에서 수행되는게 문제가 아니라, 하나의 Server로 network traffice이 모이고, 나가기 때문에, Network IO (bandwidth)가 더 문제가 된다.
    --> TCP retry time out 시간을 50ms 로 줄이는게 났다.
    --> 결과는 Sorting되서 오지 않는다. (왜냐하면, 여러 vNode에서 오기 때문에)

    =====
    Riak Search
    뒷단에 Index 저장은 별도의 데이타 구조체를 사용한다. (Cassandra와 유사함)

    ====
    모니터링


    =====

    ☆ Ring Size는 Cluster 초기 설정시에만 정할 수 있고 나중에는 바꿀 수 없다.
    --> 6개월후에는 업그레이드 될것, (Dynamo 아키텍쳐의 약점)
    --> Manual로는 가능

    Erlang은 Each Process가 heap을 별도 가지고 있다.
    Java 처럼 Heap을 share하지 않기 때문에 GC 문제도 안나고
    모니터링도 Physical memory만 하면 된다.

    =====
    덤프 툴 같은 것도 있고
    Erlang Shell로 붙어서 모니터링도 가능

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


    데이타 모델링 관점
    서버 셋업,운영 (장애 대처 및 튜닝)


    '클라우드 컴퓨팅 & NoSQL > Riak' 카테고리의 다른 글

    Riak 장점 다시 정리  (2) 2012.03.12
    Riak Performance  (0) 2012.03.12
    Riak vs CouchDB  (0) 2012.03.12
    NoSQL Riak Overview #1/2  (0) 2012.02.21
    Riak관련 스터디 메모  (0) 2012.02.21
    Riak Quick Review  (0) 2011.12.19

    Riak Quick Review

    클라우드 컴퓨팅 & NoSQL/Riak | 2011.12.19 09:03 | Posted by 조대협
    요즘 대규모 분산 환경이나 빅데이타 관련해서 NoSQL중에서 Riak이 많이 언급되는데...
    생각보다 괜찮은 듯
    http://nosql.mypopescu.com/post/632057783/riak-search-and-riak-full-text-indexing

    주요 특징은
    - Cassandra와 같은 Dynamo 계열
    - ★ Secondary Index가 지원 된다.. (메이져 NoSQL 중에 유일하지 않을까?)
    - ★ FTS (Full Text Searching)도 지원된다.

    그리고, Commercial Support도 가능하다.

    ====
    최근 포스팅한 좀더 자세한 Riak 정보 http://bcho.tistory.com/621
     

    '클라우드 컴퓨팅 & NoSQL > Riak' 카테고리의 다른 글

    Riak 장점 다시 정리  (2) 2012.03.12
    Riak Performance  (0) 2012.03.12
    Riak vs CouchDB  (0) 2012.03.12
    NoSQL Riak Overview #1/2  (0) 2012.02.21
    Riak관련 스터디 메모  (0) 2012.02.21
    Riak Quick Review  (0) 2011.12.19

    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와 특성은 유사하나 내부 기술 구조는 다름