MongoDB란?

 

- 2007년 창설된 10gen이 개발

 

- 문서 지향형 NoSQL 데이터베이스

  해쉬기반(Hash-based) 무 스키마 데이터베이스

 

- 데이터 정의 언어 불필요

- 실제로 데이터 정의 언어가 불필요하므로 아무 값이나 키를 골라 해시를 저장할 수 있음

   키는 기본 데이터 타입이지만 실제로는 스트링(strings)으로 저장됨

   문서 식별자(_id)가 각 문서마다 생성되어 시스템에 필드네임이 보존됨

 

- 애플리케이션이 스키마 및 맵핑(Mapping)을 추적함

 

- BSON 포맷 사용함

   JSON에서 "B"는 Binary를 의미함

 

- C++로 쓰여짐

 

- 여러 컴퓨터 언어에서 API 드라이버를 지원함

   JavaScript, Python, Ruby, Perl, Java, Java Scala, C#, C++, Haskell, Erlang

 

 

 

 

'빅데이터 > NoSQL' 카테고리의 다른 글

NoSQL공부하기 6_1 MongoDB  (0) 2015.01.06
NoSQL공부하기 6 MongoDB  (0) 2015.01.05
NoSQL공부하기 5 RDB ACID to NoSQL BASE  (0) 2014.12.29
NoSQL공부하기 4 NoSQL의 문제점  (0) 2014.12.26
NoSQL공부하기 4 NoSQL의 이점  (0) 2014.12.24

 

 

 

RDB ACID to NOSQL BASE

 

Pritchett, D.: BASE: An Acid Alternative

 

 

 

NOSLQ공부하기... 5번째글.. ^^

'빅데이터 > NoSQL' 카테고리의 다른 글

NoSQL공부하기 6 MongoDB  (0) 2015.01.05
NoSQL공부하기 6 MongoDB란?  (0) 2014.12.30
NoSQL공부하기 4 NoSQL의 문제점  (0) 2014.12.26
NoSQL공부하기 4 NoSQL의 이점  (0) 2014.12.24
NoSQL공부하기 3  (0) 2014.12.22

NoSQL공부하기 4 NoSQL의 문제점

 

지원(Support)

- RDMS 판매자는 고객에게 수준 높은 지원을 제공

 

높은 인지도

- NoSQL은 주로 신생기업들이 지원하는 오픈 소스 프로젝트임

 

아직 확고하지 않은 인지도

 

성숙도(Maturity)

- 성숙한 RDMS 제품: 안정적이고 믿을 만함/

 

최첨단도 아니고 매력도 없는 낡은 것이란 뜻이기도 함.

- NoSQL은 아직 기본 기능 세트를 구현 중

 

관리

- RDMS는 관리자가 잘 정의돼 있음

- NoSQL은 관리자가 필요 없지만 여전히 유지관리 노력이 필요하다.

 

전문인력부족

- 훈련 받고 숙련된 RDMS개발 인력

- NoSQL 개발자 채용 진행중..

 

자료분석 및 비즈니스 인텔리전스

- 니치(Niche) 처리를 위해 개발된 RDMS.

- NoSQL은 즉석 데이터 쿼리가 아닌 웹 2.0 애플리케이션의 요구에 따라 개발됨

 

자료분석 및 비즈니스 인텔리전스를 위한 툴(Tools)도 개발 중임

 

 

 

'빅데이터 > NoSQL' 카테고리의 다른 글

NoSQL공부하기 6 MongoDB란?  (0) 2014.12.30
NoSQL공부하기 5 RDB ACID to NoSQL BASE  (0) 2014.12.29
NoSQL공부하기 4 NoSQL의 이점  (0) 2014.12.24
NoSQL공부하기 3  (0) 2014.12.22
NoSQL공부하기 2 데이터 샤딩(Sharding)  (0) 2014.12.22

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 속성의 완화

 

 

 

NoSQL의 CAP이론

 

 

 

데이터 샤딩(Sharding)

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

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

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

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

 

 

'빅데이터 > NoSQL' 카테고리의 다른 글

NoSQL공부하기 5 RDB ACID to NoSQL BASE  (0) 2014.12.29
NoSQL공부하기 4 NoSQL의 문제점  (0) 2014.12.26
NoSQL공부하기 4 NoSQL의 이점  (0) 2014.12.24
NoSQL공부하기 3  (0) 2014.12.22
NoSQL공부하기 1 NoSQL의 CAP이론  (0) 2014.12.16

 

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출력물의 압축이 반드시 필요

 

 

 

 

+ Recent posts