it개발자스터디공간

NoSQL의 이점

탄력적인 크기조정(Elastic Scaling)

- RDBMS의 스케일 업: 더 큰 용량과 서버 필요

- NoSQL의 스케일 아웃: 여러 호스트에 데이터를 고르게 분산

DBA전문가

- RDMS은 데이터베이스 모니터링에 고도로 훈련된 전문가가 필요함

- NoSQL은 관리 소요가 적고, 자동 수리기능과 간단한 데이터모델을 갖춤

빅 데이터

- 데이터 양이 대폭 증가함

* RDMS : 용량 및 최대 데이터량이 제한됨

* NoSQL : 빅 데이터용으로 설계됨..

신축적인 데이터 모델

- RDMS 스키마의 변경관리 (Change management는 신중히 관리돼야 함.)

- NoSQL 데이터베이스는 데이터 구조 측면에서 더욱 유동적임

* 데이터베이스 스키마를 쉽게 변경할 수 있음.

* 정형화되지 않은 스키마를 다루는 응용프로그램

경제성

- RDMS는 값비싼 서버를 사용해서 데이터를 관리한다.

- NoSQL은 저렴한 상용서버로도 데이터 및 트랜잭션을 관리할 수 있다.

- NpSQL의 1GB당 비용 또는 초당 트랜잭션은 RDBMS보다 낮을 수도 있다.

복제 세트

- 리던던시와 페일오버

- 업그레이드 및 유지에 따른 정지시간 없음

- 마스터 슬레이브 복제

* 강한 일관성

* 지연된 일관성

- 공간 정보 (Geospatial features)

Host1: 10000

Host2: 10001 Host3:100002

replica1 Client 9

NoSQL은 RDBMS과 어떻게 다른가?

- 스키마(Schema)의 정의가 더 느슨함.

- 특정 문서 및 데이터 처리를 위한 응용 프로그램.

* 데이터 대신 스키마 정의를 인식하는 애플리케이션

- 대규모의 분산 데이터베이스를 다루기 위해 설계됨

- 상충관계(Trade-offs)

* 즉석쿼리(ad hoc queries)지원은 제한적

* 데이터베이스 속도 및 확장에 맞게 설계됨

- API를 사용한 쿼리언어

* ACID 속성의 완화

데이터 샤딩(Sharding)

- 서버 클러스터에 단일 논리데이터베이스 시스템을 분산

- 특정 샤드키(ShardKey)에 다라 문서를 분배하는 범위 기반 파티셔닝(Partitioning) 사용

- 자동으로 각 샤드와 관련된 데이터의 균형을 맞춤

- 콜렉션(table)단위로 켜고 끌 수 있음.

NoSQL의 CAP 이론

CAP이론의 핵심내용

- 오류의 수를 제한할 수 없고 모든 요청을 서빙(serving)해서 서버로 연결하려면, 일관성을 유지할 수 없다.

CAP이론의 의미

- 결국 오류와 구조변경(reconfiguration)을 받아들이거나, 일관성이나 가용성을 포기해야한다.

NoSQL이론 : CAP이론

GIVEN: 주어진것들 (다수의 노드(Nodes))

- 노드에는 복제된 데이터 파티션(partitions)이 포함됨

- 일관성(Consistency)

* 복제품(replicas)의 데이터 버전은 모두 같음

* 클라이언트는 노드에 관계없이 같은 데이터로 취급함.

- 가용성(Availability)

* 노드 오류에도 시스템은 계속 작동함

* 클라이언트는 항상 읽고 쓸 수 있음

- 파티션 허용(Partition tolerance)

* 다중 입력 지점(Entry Points)

커뮤니케이션 오류(systec split)에도 시스템은 계속 작동함.

* 물리적 네트워크 분할에도 시스템은 원활히 작동함

INVERTED INDEX V3

Version3 - Partitioner

Partition시 WordID에서 Word만 보고하도록 구현

Version 3- GroupingComparator

- 같은 리듀서로 모인 키/밸류페어들을 그룹핑할 때 쓰이는 Comparator로 역시 여기서는 Word만 보고 그룹핑이 이뤄져야한다.

Version3- SortingComparator

- 같은 키로 묶인 밸류들을 소팅할때 쓰이는 Comparator로 여기서는 DocID를 보고 소팅해야한다. 여기서는 그냥 WordID의 Comparator에게 비교를 맡긴다.

Version3의 문제

- 이 방식은 MapReduce 프레임웍의 힘을 이용해서 문제를 해결하기에 메모리에러등의 가능성은 적지만 대신 네트웍 통신양은 Version 2에 비해 크다.

- 하둡의 병목중의 하나는 바로 네트웍

* Map출력물의 압축이 반드시 필요

Version 3

- 여기서 시도할 방식은 흔히 Secondary Sorting이라는 것이다.

- 보통 reducer로 넘어오는 밸류 리스트는 특별한 순서가 없이 랜덤하다. 앞에서 보았던 SortingComparator를 보면 키값 비교를 위해 단순히 키만 비교하기 때문

- 만일 밸류리스트에 순서를 줄 수 있다면 이 문제를 reducer단에서 해결가능!

* 즉 같은 단어를 갖는 DocID의 리스트를 소팅된 상태로 받을 수 있다면 간단하게 같은 DocID에서 넘어온 단어들을 한번만 출력가능

* 또한 Inverted index의 문서 리스트가 ID로 소팅이 되기때문에 다른 연산 (AND연산등)이 간단해진다.

Version 3 - 새타입사용

- Secondary sorting을 하려면 커스텀타입이 키로 사용되어서 밸류가 키로 들어가야함

* 그래야 나중에 GroupingComparator가 그룹핑시 밸류는 무시하고 SortingComparator는 소팅시 밸류를 염두에 둘수 있다.

- WordID라는 타입을 정의

* WritableComparable에서 계승

* 다음 2개의 멤버변수를 가짐

Version 3 - main

- partitoner, SortingComparator, GroupComparator를 모두 커스텀클래스로 교체

Version 2

- 앞에서 설명했듯이 이 버전은 Mapper에서 단순무식하게 (word.docID)쌍을 출력하는 것이 아니라 HashSet을 이용한 unique한 (word.docID)쌍을 내보낸다.

- StringTokenizer를 이용해 파싱이 끝나면 루프를 돌면서 단어들을 HashSet에 집어넣은 다음에 HashSet을 iteration하면서 나온 단어들과 해당문서의 docID를 Reducer로 넘긴다.

Version2 -map

Version2의 문제

- 버전 2는 버전1에 비해 Mapper에서 Reducer로 넘어가는 데이터의 크기가 훨씬작음

- 하지만 아주 큰 텍스트를 가진 문서들이 많은 경우 HashSet의 크기가 커져 역시 메모리에러의 가능성 존재

- 다른 방식은 Version 1 처럼 Mapper/Reducer를 구현하고 중간의 Shuffling/Sorting 방법을 바꿔보는 것이다.

INVERTED INDEX V1

이번에는 앞서 보았던 데이터파일중의 하나인 2M.ID.CONTENTS파일을 이용해 Inverted Index를 만들어봅니다.

예를들어 hadoop이란 단어가 들어간 문서들의 리스트를 모아보는 것인데 이를 모든 단어들에 대해 수집합니다.

기본적으로 텍스트검색엔진이 수행하는 일이 이것인데 보다 자세한 랭킹을 위해 단어가 나타난 위치 등등..의 세세 정보를 기록합니다.

V1 (Version 1)

- V1은 아무런 최적화작업없이 WordCount를 조금 바꾼 형태로 구현됩니다.

- WordCount에서는 텍스트부분을 파싱한 다음에 만들어진 토큰들에 대해 다음과 같이 reducer로의 출력쌍을 만들었습니다.

* context.write(word, new LongWritable(1));

- InvertedIndex에서는 context.write(word,new Text(docID));

- 위와같이 단어키에 대해 docID를 밸류로 내보낸다.

- Reducer 부분에서는 그냥 넘어오는 docID를 계속해서 스트링버퍼에 append한 후 결과물로 내보낸다.

Version1 -reduce

- Map 부분은 앞서 본 프로그램과 너무 비슷해서 건너뜁니다.

Version 1의 문제

실행해보면 아마도 Heap memory 에러와 같은 것을 볼 수 있을 것입니다.

이유는 특정 단어의 경우 한 문서에도 여러번 나오는등 빈도수가 아주 큰데 지금의 구현은 한 문서에 어떤 단어가 여러번 나올 경우 그 수만큼 반복하기 때문이다.

채결책!

JVM의 메모리 증가. 디폴트로 태스크마다 할당되는 JVM은 200M의 메모리를 사용. mapred-site.xml의 mapred.child.java.opts파라미터을 이용해 증가 (아래예는 1GB로 증가)

Mapper단에서 HashSet을 구현하여 같은 단어들이 여러번 나오더라도 한번만 emit하던지 아니면 빈도수를 문서 ID와 함께 내보냅니다.