KilJaeeun commented 2 years ago

파트

섹션6-2. hadoop으로 비관계형 데이터 저장소 사용(~57강)
발표자
오재욱
발표 기간
7월 14일 22:00 ~
마감 기한
7월 13일 23:59 까지
참고 링크
일정표 : https://www.notion.so/Hadoop-4f533d9016884066ae0c87199d2bf65d
하둡 완벽가이드: http://grut-computing.com/HadoopBook.pdf
udemy 강의 : https://www.udemy.com/course/best-hadoop/learn/lecture/28318946?start=30#overview

wookiist commented 2 years ago

스터디 내역

hyunju-song commented 2 years ago

jasonkang14 commented 2 years ago

JSYoo5B commented 2 years ago

Humongous Data에서 유래해서 이름 지음. 주요 특징으로는 문서 데이터 모델 CAP 분류에 따르면 HBase와 같이 Availability를 포기한 방향 (하지만 완전히 포기한 건 아니고, 잠시 Write가 불가능한 방식)

문서 데이터 -> 스키마 정의가 강요되지 않는다. 마치 JSON처럼 자체적으로 프라이머리 키를 만들어서 관리한다. 샤딩 등을 목적으로 indexing이 필요하다면 특정 키를 선택할 수 있다.

Availability를 포기한 방향, Primary(master)가 요청 받으면 그 기록을 바탕으로 secondary에서도 반영하여 replica 반영

Single Master 구조로 동작하며, Secondary 들 중 하나가 상황에 따라 Master가 될 수 있음. (선정 기준은 전체적인 node간 ping이 제일 낮은, 반응성이 가장 좋은 것을 선호)

Replica 구성과 새로운 Master를 구성하려면 투표를 해야하는데, 짝수면 투표 결과를 확정할 수 없으므로 홀수로 구성해야 함. (raft는 이거 해결하는 걸로 아는데)
이 문제를 해결하기 위해 Arbiter(결정권자 node)를 둘 수 있음.
MongoDB 사용 클라이언트는 primary 뿐만 아니라 secondary들도 알아야 함. (primary가 죽으면 새로 선출된 primary를 알아야내기 위해)
(이 문제는 3.6부터 DNS 시드 목록 연결 형식 기술로 해결됨)
주로 내구성만을 목적으로 하므로 scaling을 고려한 것이 아님.

Sharding

인덱싱을 기준으로 레플리카 셋을 나눠서 보관 (그림 보고 잘 이해가 안되는데, sharding마다 primary가 따로 있다는 뜻인가?)

주요 고려사항

KilJaeeun commented 2 years ago