NoSQL 간단한 소개

NoSQL 간단한 소개
myrisinsun@gmail.com

시작하기전에..
NoSQL Distilled 
- 빅데이터 세상으로 떠나는 간결한 안내서 
프라모드 사달게이, 마틴 파울러 저
사용법이 아닌 개념서를 찾던 중 
저 이름과 아래의 서문을 보고 선택!!
“우리는 이 책이 비행기를 타고 가며 읽을 수 있을 
정도여야 한다고 생각한다.”

그래서 
신규 프로젝트를 시작하는 아키텍처의 고민은...
“MySQL 쓸까? Oracle 쓸까?”
데이터 베이스
관계형
데이터베이스==
지난 수십년간 학교와 현장에서 진리?로 여기던것은...

Relational
Database관계형 데이터베이스가 군림할 수 있었던 이유는
데이터 저장에 있어서 파일 시스템 대비 뛰어난 융통성을
제공하여 쉽고 빠르게 사용이 가능하고, 동시성에 있어서는 트랜잭션
메커니즘이 복잡성을 억제하는데 도움을 주었고, 여러 애플리케이션들
이 한 데이터베이스를 사용함으로서 통합 방법을 제공했고 벤더가
달라도 SQL 구문이나 트랜잭션 동작이 비슷한 표준 모델을 제공.

하지만 개발자에게 불만, 스트레스로 다가온것은 바로... 
메모리 내 데이터와 관계형 모델의 구조간 차이
'객체-관계 불일치'
주문자 정보
주문상품#1
주문상품#2
주문상품#3
결재정보
배송지 정보
TB_USR 
TB_USR_ADDR 
TB_USR_ORDER_MASTER 
TB_USR_ORDER_DETAIL 
TB_USR_ACCNT 
... 
.. 
.

1990년대 
객체지향 프로그래밍이 등장하고 성장하면서 
객체지향 데이터 베이스도 등장 
 
하지만, 
객체지향 언어는 주류가 되었고, 
객체지향 데이터베이스는 세상에서 잊혀짐.
“OODB의 성장과 몰락에 대한 이야기” 
http://hkpark.netholdings.co.kr/web/inform/default/inform_view.asp?
menu_id=9730&id=24304&parent_id=24303

(저자가 말하길) 
관계형 데이터 베이스가 
객체 지향 데이터 베이스를 
물.리.치.다.!
바로 
‘통합 데이터베이스’로서 큰 역할을 했기 때문에. 
 
'통합 데이터베이스'?

'통합 데이터베이스' 
 
여러 팀의 애플리케이션들이 데이터베이스를 공유. 
개별 업무팀간의 데이터 전달, 공유가 간편해짐
IntegrationDatabase by Martin Fowler 
http://martinfowler.com/bliki/IntegrationDatabase.html
사용자관리
배송관리
결재관리
포인트관리

'통합 데이터베이스’는 장점과 함께 단점도 있음.
• 여러 애플리케이션을 모두 고려 
설계가 복잡해짐
• 데이터와 스키마를 공유 
업무별 최적화된 구조를 사용할 수 없음. (인덱스, 필드등..) 
스키마 변경시 다른 팀과의 협의 필요
그래서.. 좋은 해결방법은? 
 
'애플리케이션 데이터베이스’!!

'애플리케이션 데이터베이스' 
 
각 애플리케이션마다 사용/관리하는 데이터베이스를 가짐 
애플리케이션간의 데이터 공유는? API(http)!!
ApplicationDatabase by Martin Fowler 
http://martinfowler.com/bliki/ApplicationDatabase.html
사용자관리
배송관리
결재관리
포인트관리
API

그러나.. 
 
평화롭던 관계형 데이터베이스 생태계를 
클러스터가 위협하기 시작!
웹의 규모가 극적으로 성장하기 시작 
-> 대규모 처리, 대량의 데이터 발생 
-> 가성비가 좋은 클러스터 환경 사용. (Scale-Out) 
 
문제는 바로.. 
 
'관계형 데이터베이스'

관계형 데이터베이스는 클러스터와 맞지 않음.
클러스터에서 동작하도록 설계된게 아님. 
Oracle RAC 가 있지만 '공유 디스크 개념'을 사용. 
클러스터를 인식할 수 있는 파일 시스템을 사용하며 
디스크 서브시스템에 기록을 하게 되는데 이 지점이 SPOF!
샤딩도 가능은 하겠지만.... 
어플리케이션 차원에서 구현해야 하는 번거로움.
라이센스 비용도 문제

그래서.. 
 
일부 조직은 데이터 저장을 위한 다른 대안을 고려하기 시작. 
 
특히 Google, Amazon.
그리고 
그들과 같은 데이터 규모가 아니더라도 
점점 더 많은 데이터를 수집, 활용하기위한 연구를 하면서 
같은 문제를 경험하기 시작

이제부터 NoSQL 이야기..
NoSQL 
1998년 'NoSQL' 용어가 처음으로 등장.
하지만 지금 우리가 말하는 의미의 NoSQL이 아님.
RDBMS 형태의 NoSQL 
http://en.wikipedia.org/wiki/Strozzi_NoSQL_(RDBMS)

지금 사용하는 NoSQL 단어의 어원(?)은 
2009년 조핸 오스카슨이 
단순히 모임의 이름을 정하면서 시작
당시 모임을 위한 이름의 조건은 
-트위터 해시 태그로 쓰기 좋고 
-짧고 기억하기 쉽고 
-구글 검색시 동명의 다른 결과가 적은것
최초의 NoSQL 은 
지금처럼 기술 동향 전체를 뜻하는 의미가 아니었음.

NoSQL은 
일반적으로 통용되는 정의가 없고, 
정의를 내리는 권위자도 없음.
모임의 주요 주제는 
'open source, distributed, non-relational’등 이었고, 
Voldemort, Cassandra, Dynomite, HBase, Hypertable,
CouchDB등이 발표됨.
NoSQL은 한줄로 '정의'하는것보다 
공통적인 특성을 아는것이 더 유용.
san francisco nosql meetup 
http://www.eventbrite.com/e/nosql-meetup-tickets-341739151 
http://www.johnandcailin.com/blog/john/san-francisco-nosql-meetup

NoSQL의 공통적인 특징
• 관계형 모델을 사용하지 않는다
• 클러스터에서 잘 동작한다
• 오픈소스다
• 21세기 웹 환경을 위해 구축되었다.
• 스키마가 없다

NoSQL이 성장하고 큰 관심을 받고 있지만 
관계형 데이터베이스는 앞으로도 계속 사용될것임. 
(친숙함, 안정성, 다양한 기능, 기술 지원의 이유로..)
하지만! 가장 중요한 변화는 
 
 
관계형 데이터베이스가 
'필수'에서 '선택적'으로 바뀐것.

PolyglotPersistence 
http://martinfowler.com/bliki/PolyglotPersistence.html
다중 저장소 지속성(Polyglot Persistence) 
상황이나 용도를 고려하여 가장 최적화된 
각기 다른 데이터 저장소를 사용하는 것.
(Image. http://martinfowler.com/bliki/PolyglotPersistence.html

NoSQL 을 사용하면서 가장 큰 변화는 
'관계형 데이터 모델'과 멀어진다는것.
NoSQL 의 4가지 데이터 모델
키-값 문서 칼럼 패밀리 그래프
‘그래프’를 제외한 3가지는 ‘집합 지향’의 특징을 가짐. 
집합 지향?

집합 지향(Aggregate Orientation)
'집합' DDD(도메인 주도 개발)에서 나온 용어. 
'단위로 다루고 싶은 관련된 객체의 무리'를 뜻함.
기존 관계형 모델에서 사용하던 '튜플' 단위가 아닌 
리스트 형태나 중첩 레코드와 같이 복잡한 레코드 형태로 
만들어진 의미있는 구조.
(이 책에서 저자는) 
바로 이것(?)을 '집합(Aggregate)'이란 용어로 사용

오른쪽이 관계형 데이터 모델이라면 
왼쪽이 집합 개념. 주문 페이지를 위한 관련된 데이터의 모음
(Image. http://martinfowler.com/bliki/AggregateOrientedDatabase.html)

클러스터 환경에서 빛나는 
집합 지향
클러스터 환경은 데이터를 수집할 때 질의(Querying)해야 
하는 노드수를 최소화 해야함.
집합 구조를 사용하면 
하나의 집합은 하나의 노드에 저장됨을 데이터베이스가 보장. 
(저장 및 쿼리 가능)

조금 다른 트랜잭션 개념
관계형 데이터 베이스 
하나의 트랜잭션에서 여러 테이블들에 속한 행들을 조합해 조작 가능 
그리고 하나의 트랜잭션은 전체 성공 or 전체 실패 를 보장.
집합지향 데이터베이스 
여러 집합에 대한 트랜잭션을 지원하지 않음. 
하나의 집합에 대한 원자적 조작을 지원 
(여러 집합 조작시 애플리케이션 코드 차원에서 고려해야함)
*실제로는 원자성이 필요한 범위를 한 집합내로 한정 가능한 경우가
대부분. 
정말 고려해야할 부분은 데이터 '집합'을 어떻게 구성할지 고려하는것!

4개 모델의 특징
• 키-값 모델
• 문서 데이터 모델
• 컬럼 패밀리 모델
• 그래프 모델

• 키-값 데이터 모델(Key-Value)
(Image. http://scraping.pro/where-nosql-practically-used)

• 문서 데이터 모델(Document)
(Image. http://www.couchbase.com/cn/why-nosql/nosql-database)

키-값 모델, 문서 데이터 모델
공통점 
각 집합은 데이터를 얻는데 사용하는 키나 아이디가 존재
차이 
키-값 데이터베이스: 집합 구조가 불투명 
키로만 접근 가능. 집합의 일부를 질의하거나 꺼내올 수 없음.
문서 데이터 베이스: 집합 구조가 투명 
집합의 일부로 쿼리하고 일부만 꺼내올 수 있음.
문서 데이터 베이스는 집합에 허용되는 구조와 타입을 정의해서 들어갈 수 있
는 것을 제한 
키-값 데이터베이스는 불투명성을 가지며 집합안에 무엇이든 저장이 가능 
(예: String, int, hashMap, List...)

하지만.. 
키-값 저장소와 문서 데이터 베이스 간 구분이 조금 모호해짐.
문서 데이터베이스를 키-값 저장소처럼 사용하기 위해 ID필드
같은것을 넣거나 
리악(key-value)은 인덱스 생성이나 집합 간 연결을 위한 메타
데이터의 추가를 허용
그래도 기본적인 특성은.. 
키-값 데이터 베이스에서는 키를 통해 집합을 찾고 
문서 데이터베이스에서는 문서 내부 구조를 기초로 데이터에
접근

컬럼 패밀리 모델(Column Family)
관계형 데이터베이스의 table 처럼 보이지만, 
중첩된 HashMap 구조로 보는것이 정확함.
Row Key1
이름
ㅇㅇㅇ
이메일
abc@g
Column Key
Column Value
Column Family
Row Key2
이름
ㅇㅇㅇ
주소
서울시..
Column Key
Column Value
……
……

그리고.. Super Column Family가 적용된 다른 구조 
 
중첩된 컬럼구조를 가짐.
Row Key1
이름
ㅇㅇㅇ
이메일
abc@g
Super Column1
주문1
…
주문#2
…
Super Column2

칼럼 패밀리 데이터베이스는 
칼럼들이 모여 칼럼 패밀리로 구성.
중요한것은 
칼럼 패밀리로 모여진 데이터들은 
보통 함께 접근되는 데이터들로 구성됨.
또한 (투명구조! 이기 때문에) 
데이터의 공통 그룹에 대해 알고 있으므로, 
이 정보를 이용해서 데이터에 접근, 저장가능.

데이터를 바라보는 2가지 관점
행-지향 
각 행은 집합. 
칼럼 패밀리는 그 집합 안의 의미있는 데이터 덩어리(프로파일,
주문내역)을 표현
열(칼럼)-지향 
칼럼 패밀리는 레코드 타입을 정의 
행은 모든 칼럼 패밀리의 레코드를 연결한 것으로 생각.

그래프 모델(Graph)
'관계'에 특화된 모델. 
'그래프'란 막대형 차트나 히스토그램 같은게 아님. 
노드(네모)와 간선(직선화살표)으로 구성된 그래프를 뜻함.
나
스키장
ZionT
김ㅇㅇ정ㅇㅇ
FAVORITE
FAVORITE
FAVORITE
FRIEND
FAVORITE

관계 사이를 돌아다니는 작업의 대부분을 
쿼리 시점에서 입력 시점으로 옮겼다. 
입력 성능보다 쿼리 성능이 중요하다면 바로 이것!
클러스터 환경보다는 단일 서버에서 실행되는 경우가 많음
여러노드와 간선을 포괄하는 ACID트랜잭션 필요. 
데이터 일관성 유지 목적
NoSQL에 속하는 나머지 3가지 모델과 거리가 있음. 
 
굳이 공통점을 찾는다면 
-관계형 모델을 사용하지 않고 
-NoSQL이 주목받는 시기에 관심이 쏠렸다는것?

잠깐.. 스키마, 무스키마 이야기
무스키마 
데이터베이스에 고정된 스키마가 없다면?
-> 
스키마의 구속에서 해방. (컬럼, 타입..) 
(운영중) 데이터 저장 구조를 쉽게 변경 
의미없이 존재하는 불필요한 Null 컬럼 미발생
하지만.. 
문제가 있음.

무스키마의 문제
데이터에 접근하는 프로그램은 
어떤 형태든 암묵적 스키마에 의존해야함.
결국 
데이터베이스에서 -> 애플리케이션 코드로 
스키마가 이동한것!!
그래서 
데이터에 대한 확인을 애플리케이션 코드를 통해서 해야함. 
만약 코드 구조가 지저분하다면.. 스키마가 없어 더 고생?

그리고 '구체화 뷰'?
관계형 데이터베이스의 구체화 뷰(Materialized View)란 용어를
NoSQL에서도 사용.
관계형 데이터베이스에서는 
뷰의 계산 비용때문에 결과를 미리 디스크에 캐쉬하는 개념. 
NoSQL 역시 비슷한 의미로 사용.
NoSQL에서 구체화 뷰 생성방법 
-기본 데이터 변경시 구체화 뷰 변경. 
(쓰기보다 읽기가 많은 환경) 
-일정 간격으로 배치 작업으로 구체화 뷰 갱신 
(쓰기에 대한 오버헤드 감소)

분산 모델 or 분산 환경이 주목받는 이유는 단 하나. 
'싸다'
수직확장(scale up) 
하나의 서버를 성능업 하는데는 한계가 있고 비싸다.
수평확장(scale out) 
상대적으로 저렴한 서버를 여러대 배치 
1석 2조. 분산처리 + 장애상황 대응.
하지만 복잡성이 비용으로 작용! 
반드시 장점 대비 비용을 계산해봐야함.
그래서.. 가장 좋은것은 단일서버로 서비스 하는것~ :)

그리고.. NoSQL이 주목받는 이유는  
대규모 클러스터환경에서 동작이 가능하다는것.
클러스터를 고려한 데이터 분산 방법 지원
복제(Replication) 
같은 데이터를 여러 노드에 분산해서 복사.
샤딩(Sharding) 
데이터를 중복되지 않게 여러 노드에 나누어 저장.
복제와 샤딩은 
하나만 선택하거나 또는 함께 적용이 가능.

A ~ E
샤딩(Sharding)
데이터를 다수의 노드에 나누어 저장.
Node1
F ~ J
Node2
U ~ Z
NodeX
………
샤딩 전략
Apple
…
…
Juice
…
…
University
…
…

샤딩은 
 
샤딩을 데이터베이스가 담당. 개발자 부담 감소. 
쓰기에 대한 성능 향상. 여러 노드에 나뉘어 저장됨.
그리고
샤딩만 사용하면 데이터 유실 가능성.(데이터 복제본의 필요성) 
함께 접근되는 데이터(집합)는 같은 노드에 위치. 
유저와 가까운 (지역) 노드에 저장해야 유리. (global서비스)

복제#1. 마스터-슬레이브
모든 업데이트를 마스터가 수행. SPOF 
변경사항은 마스터->슬레이브 로 전파. 전파시간 필요 
읽기는 마스터, 슬레이브에서 수행. 읽기가 많으면 유용
M
S S
전파 전파
Read/Write
Read Read

복제#2. 피어-투-피어
모든 노드에서 데이터를 읽고, 쓰기 가능 
노드 간 쓰기 데이터를 서로 통신 
'쓰기 충돌’ 문제. 여러 노드에서 동일 데이터를 변경
Node
Node Node
전파 전파
전파

관계형 데이터베이스는 
강력한? 일관성을 제공 
 
트랜잭션!!!
하지만 
NoSQL에서는 일관성을 좀 다르게 취급.

업데이트 일관성 
쓰기 충돌(write-write conflict)
사용자A가 수정한 내용을 사용자B가 다시 덮어쓰는 문제 발생. 
(요청은 직렬화되어 차례대로 처리됨)
Node
사용자A
사용자B
Apple
…
…
사용자A사용자B

이러한 동시성 상황에서의 회피 방안
비관적 방법(Pessimistic) 
충돌이 발생하는 것을 사전에 방지. 
수정 대상에 Lock을 걸어두고 진행
보통은 비관적 방법을 선호. 
하지만.. 
회피 방지를 위한 Lock 메카니즘은 
응답성(클라이언트에 빠른 응답)이 떨어지고 
교착 상태 발생 가능

낙관적 방법(optimistic) 
충돌이 발생하도록 놔두고 충돌 발생시에 적절한 조치를 수행
업데이트시 자신이 마지막으로 읽은 후 값이 변경됬는지 검사하는 조건
적 업데이트 
 
또는 
 
두 업데이트를 모두 적용하고 충돌이 발생했다고 표시 
(버전관리 시스템의 diff,merge개념)
안정성(업데이트 출돌 회피)이 떨어짐
결국 
응답성과 안정성 사이에서 선택과 집중이 필요

읽기 일관성 
읽기-쓰기 충돌(read-write conflict) 
==비일관적 읽기(inconsistent read)
논리적 일관성 
다른 데이터 항목이 함께 의미를 가지도록 하는것 
(잔고와 거래내역)
관계형 데이터베이스는 '트랜잭션'으로 보장
잔고
거래내역
사용자A 관리자 
잔고는 처리완료
거래내역은 미처리 상태에서
데이터를 읽는다면?

복제 일관성
*결과적 일관성(Eventual consistency) 
특정 시점에는 노드마다 불일치가 있을 수 있지만, 
결국 모든 노드가 같은 값으로 업데이트됨
싱가폴
유럽 북미
사진 
업로드
복제 
완료
복제전 
(느림)
싱가폴
유럽 북미
복제 
완료
복제 
완료
데이터 불일치가 발생하는 시간 
비일관성 윈도우

자신이 비일관성을 겪는경우 
사진을 업로드한 직후에 페이지를 '새로고침' 
아직 복제되지 않은 다른 노드로 연결되면?
'세션 일관성' 
사용자 세션 내에서 자신이 쓴 것에 대한 일관성을 제공
방법은...?
싱가폴
북미
1.업로드
2.확인
사용자 유럽

스티키 세션(Sticky Session) 
세션이 유지되는 동안은 동일한 노드로 연결 보장. 
하지만, 부하 분산이 제대로 되지 않는 단점.
버전 스탬프 
저장소와 상호작용을 할때 
세션이 사용했던 가장 최근의 버전 스탬프를 포함. 
서버가 요청에 응답하기전 위 사항을 보장.
일관성은.. 보장하는것은 좋지만 
시스템의 다른 특성을 희생하는 '재앙'이 발생할 수 있음. 
(저자는) 이것은 피할 수 없는 타협.

CAP이론 
Consistency, Availability, Partition tolerance 의 첫글자.
일관성(Consistency) 
모든 노드는 요청 시점과 대상이 같으면 결과도 동일.
가용성(Availability) 
(일반적인? 의미와는 조금다른) 
클러스터 내 한 노드와 통신이 가능하면 
그 노드는 정상 동작이 가능.(읽기, 쓰기)
분단 허용성(Partition tolerance) 
클러스터 내 통신 단절/여러 조각으로 분단/서로 통신 불가능 
그래도 클러스터가 잘 동작해야한다는 의미.

CAP이론은..
'일반적으로 3가지중 두가지만 만족할 수 있다' 
라고 알고 있는경우가 많음.
네트워크로 연결된 클러스터 환경에서의 
실질적인 의미는..
분단 허용성을 기본적으로 보장하고 
일관성과 가용성 사이에서 절충해야 하는 것.
CAP Theorem, 오해와 진실 
http://eincs.com/2013/07/misleading-and-truth-of-cap-theorem/

일반적으로 (읽기,쓰기) 일관성을 
반드시 만족해야 하는 것으로 생각하지만,
요청에 대한 응답이 비일관적인 경우에도 
우아하게? 처리가능한 경우가 있다.
하지만 기술이 아닌 업무나 관련분야에 대한 지식을 
가지고 접근해야함.
예를 들자면..

비일관적 쓰기 
 
Amazon's Dynamo에서 언급된 
비일관적 쓰기를 허용하는 장바구니
네트워크 장애가 발생해도 장바구니에 쓰는것이 가능.
여러 개의 장바구니가 생길 수 있지만 
결제 과정에서 다수의 장바구니를 합치면 대부분 문제가 없고 
문제가 발생한 경우라도 
사용자가 주문을 완료하기전 체크가 가능

비일관적 읽기
금융분야와 같이 Read가 중요한 분야는 안되겠지만 
뉴스나 유머를 제공하는 서비스라면
몇분전의 페이지를 보더라도 아주 큰(?) 문제는 없을것임

지속성의 완화 
'일관성'에 대해서는 다들 100% 공감하지만 
'지속성'의 완화에 대해서는 어처구니 없다고 생각할 수 있음.
지속성의 완화란? 
데이터 저장소가 업데이트된 내용을 잃어버린다면...?
하지만.. 
성능을 위해 지속성 완화를 선택할 수 있다.
예를 들면 
세션을 저장하는 키-밸류 시스템이라면 
값에 대한 expire 정보를 통해 일정 시간 후 삭제 되도록 운영.

요청에 더 많은 노드가 관여하면 비일관성을 회피할 확률이 
더 높아짐.
그렇다면..  
강력한? 일관성을 얻으려면 
얼마나 많은 노드가 관여해야 하는가?
먼저, 쓰기 정족수(write-quorum)
쓰기에 참여하는 노드 수(W)는 
복제에 관여하는 노드 수(N)의 절반을 넘어야 함.
W > N / 2

읽기 정족수
읽기 정족수는 쓰기시 승인해야 하는 노드수에 영향을 받음. 
 
읽기 시 확인해야 하는 노드 수(R)과 
쓰기 시 승인해야 하는 노드 수(W) 
복제인수(N)
R + W > N
강력한! 읽기 일관성을 가질 수 있음.

복제인수 3에 대해서..
전문가들이 말하길 
좋은 복원력을 갖는데 복제인수는 3이면 충분.
노드 하나가 실패해도 읽기과 쓰기 정족수를 유지 가능
자동 재분배 기능으로 세번 째 복제본을 만드는데 오래 걸리지
않음.
복제본을 만드는 중에 두 번째 복제본을 잃을 확률은 극히 적음.

노드수의 조정
예.. 
읽기에 빠른 속도와 강력한 일관성이 모두 필요하다면 
쓰기에서 모든 노드의 승인을 받고, 읽기 시에는 노드 하나만
접근 
-> 쓰기가 느려지고, 하나의 노드라도 실패 허용이 불가능!
일관성과 가용성 사이의 절충은 
상당히 유동적이고 복잡한 문제!!

낙관적 오프라인 잠금?
트랜잭션을 커밋하기 전에 트랜잭션에서 사용하는 정보가 
읽어왔던 시점 이후로 변경되지 않았는지 다시 읽어
확인하는것.
실제 적용방법 중 하나는 
데이터베이스 레코드에 '버전 스탬프'를 포함시켜 사용.

버전 스탬프 종류
• 연번형태의 카운터 (중복을 피하기 위한 단일 마스터 필요)
• GUID (크기가 크고, 최신 비교가 불가능)
• Hash 알고리즘 이용 (GUID와 같은 단점 존재)
• 마지막 업데이트의 타임 스탬프 (노드의 시간 동기화 필요)
두 가지 이상의 방법을 조합해 버전 스탬프 생성 가능 
예: CouchDB는 카운터+콘텐츠 해시 조합

단일 노드에서 관리되면 버전 스탬프는 잘 동작 
(단일서버 or 마스터-슬레이브의 마스터에서 관리)
하지만 피어-투-피어 분산 모델에서는 
버전 스탬프를 제어하는 단일 지점이 없어서 안됨.
타임스탬프도 있지만 
모든 노드의 정밀한 시간 동기화는 어려움. 
(수밀리 초단위의 데이터 업데이트 발생?)

피어-투-피어 NoSQL 시스템에서는 주로 
벡터 스탬프를 사용
• '벡터 스탬프'는 저자가 만들어낸 용어
• 각 노드의 카운터로 구성된 카운터의 집합
• 동기화 방법에 따라 벡터 시계, 버전벡터등이 존재.
예 
각 노드는 자신만의 카운터를 개별로 가지며 변경시 카운팅. 
다른 노드와 통신할 때 벡터 스탬프를 동기화

벡터에 누락된 값이 있는경우 0으로 처리 
-> 신규 노드 추가시 기존 벡터 스탬프의 무효화 불필요
하지만.. 
벡터 스탬프는 
비일관성의 발견은 가능하지만 해결은 불가능.

맵-리듀스 패턴?
• 클러스터의 많은 장비의 장점을 활용
• 데이터가 위치한 노드에서 많은 처리
• 이러한 작업을 '조직'화 하는 방법

작업을 2단계로 나누어 수행
맵 작업: 집합을 입력받아 key-value 로 출력 
리듀스 작업: 맵 작업의 출력결과를 입력받아 다시 재결합
이름/수량/가격
이름/수량/가격
이름A/매출액 
이름B/매출액 
이름C/매출액
이름C/매출액
Node1
이름C/매출액
Node2
Map Reduce
주문내역
Map

분할
결합
Reduce
이름A/매출액
이름B/매출액
이름C/매출액 
이름C/매출액 병렬처리 
효율성!!
Map
이름A/매출액
Reduce이름A/매출액 
이름B/매출액
결합 
작업
데이터 전송량 감소

결합 가능한 리듀스 함수 
(Combinable reducer)
리듀스에서 결합한 출력 결과를 
다시 리듀스의 입력으로 보내서 처리. 
이런 함수를 결합 가능한 리듀스 함수
출력과 입력의 형태가 같은 리듀스 함수.
모든 리듀스 함수가 결합 가능하지는 않다.

맵-리듀스 계산 조합
맵 작업은 한 집합에 대해서만 적용가능 
리듀스 작업은 한 키에 대해서만 적용 가능
이런 제약 조건을 고려하려면 
프로그램의 구조를 다르게 생각해야 함. 
(=리듀스 연산의 개념에 맞춰서 고려해야함)
예를들면 
건수에 대한 처리는 그룹별로 단계적으로 집계가 가능하지만, 
 
평균은? 
그룹별로 산출된 평균을 전체 평균으로 만들기는 번거로움

맵-리듀스 파이프와 필터
맵-리듀스 계산이 복잡해지면, 파이프와 필터를 사용해 작업을 여러 단
계로 나눔. (유닉스의 파이프라인 처럼)
예) 올해와 작년의 월별 판매 실적 비교 자료. 2단계로 계산. 
1. 제품별 년/월 판매실적 집계 
2. 위의 결과를 입력받아 작년 수치와 비교하고 출력
Map(A) -> Reduce(B) -> Map(C) -> Reduce(D)
A. 월별 제품 판매량에 대한 key-value 생성 
B. A의 결과를 입력받아 제품별 판매수량으로 결합 
C. B의 결과를 입력받아 작년 자료를 key-value로 생성 
D. C의 결과를 입력받아 결합 (요구사항에 맞도록)

맵리듀스의 장점
복잡한 작업을 여러 단계의 작업으로 분해하면(맵-리듀스) 
'작성(구현)'이 쉬워진다.
중간 결과를 다른 작업에 재사용할 수 있다.
맵-리듀스 초기단계에서는 많은 데이터들에 접근하기 때문에 
이를 추후 재사용할 수 있도록 별도로 저장, 활용가능

맵-리듀스 구현
맵-리듀스 계산에 특화해 설계된 언어에 잘 맞음.
하둡의 기본 자바 라이브러리를 쓰는것 보다 
아파치 '피그'로 맵-리듀스 구현이 효율적임
아파치 '하이브'를 사용하면 SQL과 비슷한 문법으로 
맵-리듀스 프로그램의 구현이 가능

'점증적 처리'
새로운 데이터는 계속해서 들어옴. 
최신의 자료 유지를 위해 계산작업을 계속함.
변경된 데이터에 대한 처리만 하도록 
'점증적 업데이트'를 고려.
맵 단계는 비교적 수월 
변경된 입력 데이터에 대해서만 맵 함수를 재실행
리듀스 단계는 좀 더 복잡 
리듀스 단계의 병렬화 수준에 따라 부하가 달라짐.
리듀스를 위해 데이터를 파티션한다면 
변경되지 않은 파티션은 리듀스 작업이 필요 없음.

NoSQL 간단한 소개

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie NoSQL 간단한 소개

Ähnlich wie NoSQL 간단한 소개 (20)

NoSQL 간단한 소개