imported>rabierre |
imported>rabierre |
| (147 intermediate revisions by the same user not shown) |
| Line 1: |
Line 1: |
| __TOC__
| | 구글 빅테이블 |
| [[pagelist(^Bigtable/)]]
| |
| * 구글의 분산 데이터베이스 Bigtable 분석하고 설계하기
| |
| * http://nforge.zeropage.org/projects/bigtablet
| |
| ** 아 잘못만들었네
| |
| | |
| == 등록 ==
| |
| 신규 TS는 chubby에 자신의 정보를 등록한다
| |
| === 기능명세 ===
| |
| # chubby에 자신의 정보를 등록한다
| |
| ## 자신의 ip
| |
| ## 그 외의 시스템 전체가 공유해야 하는 정보는?
| |
| === 비기능명세 ===
| |
| # TS 시작시에 등록한다. 등록에 성공하지 못하면 다시 시도한다.
| |
| # 재시도할 때 마다 시간간격 늘림
| |
| # 일정횟수 이상시 멈춤(chubby의 부하 고려)
| |
| == 만기 ==
| |
| 유닛들은 스스로를 파기하지 않는다.
| |
| === 기능명세 ===
| |
| ## 없음
| |
| === 비기능명세 ===
| |
| ## 만기/실패시 복구
| |
| == 태블릿 할당 ==
| |
| === 기능명세 ===
| |
| ==== 신규 TS에 태블릿 할당하기 ====
| |
| 가장 load가 많은 TS의 태블릿을 신규 TS에게 할당한다
| |
| ** 마스터 역할
| |
| ## 신규TS(target) 탐지시
| |
| ## load가 가장 많은 TS(source)를 찾는다.
| |
| ## source에게 target의 ip와 전달할 태블릿개수 넘김.
| |
| ## 메타태블릿 갱신
| |
| ** TS 역할
| |
| ## source는 target에게 정해진 갯수만큼의 태블릿을 리스트로 이름전달
| |
| ## target에게서 제대로 전달받았는지 확인
| |
| ## 자신의 태블릿 리스트에서 전달한 태블릿들을 삭제
| |
| ## 마스터에게 전달 성공 메세지 보냄
| |
| ==== 로드 밸런싱 ====
| |
| 가장 load가 적은 TS에게 가장 load가 많은 TS의 태블릿을 할당.
| |
| * 마스터 역할
| |
| ## 가장load가 큰 TS(source)와 가장load가 적은 TS(target)와의 차이가 일정수준 이상일때
| |
| ## source 에게 target의 ip와 전달할 태블릿의 개수를 전달
| |
| ## 메타태블릿 갱신
| |
| * TS 역할
| |
| ## 소스 TS
| |
| ## source는 target에게 정해진 갯수만큼의 태블릿을 리스트로 이름전달 ( 연속된 태블릿을 전달한다)
| |
| ## 자신의 태블릿 리스트에서 전달한 태블릿들을 삭제
| |
| ## target에게서 제대로 전달받았는지 확인 (ISSUE. target이 제대로 전달받았는지 어떻게 알지?)
| |
| ## 마스터에게 전달 성공 메세지 보냄
| |
| ## 타겟TS
| |
| ## 전달받은 태블릿 리스트로 태블릿들을 읽어온다
| |
| ## 소스 TS에게 성공 메세지 보냄
| |
| * ISSUE
| |
| ## 로드 밸런싱 트리거는?
| |
| ## TS혼자서 커버할 수 있는 정도의 태블릿양도 클러스터 기준의 밸런싱이 필요한가?
| |
| ## 태블릿의 개수로 트리거 설정?
| |
| ## cpu와 메모리 사용량도 트리거에 포함될 수 있다.
| |
| ### cpu와 메모리 사용량이 많으면 태블릿을 split한다?
| |
| ## target이 제대로 전달받았는지 어떻게 알지?
| |
| ## target은 성공시 메세지를 source에게 성공 메세지, source가 다시 마스터에게 성공 메세지 전달?
| |
| ## target이 직접 마스터에게 자신의 태블릿 리스트를 전달하고 마스터가 target의 이전 태블릿 리스트와 현재 태블릿 리스트를 비교해 밸런싱이 잘 되었는지 확인.
| |
| ==== TS실패 복구 ====
| |
| TS가 다운되면 해당 TS가 가지고 있던 태블릿들을 다른 TS에 분산해 나누어준다.
| |
| * 마스터
| |
| ## 마스터는 주기적으로 TS들에게서 heartbeat를 받는다 (chubby였나?)
| |
| ## 마스터는 주기적으로 TS들의 태블릿 리스트를 스캔한다.
| |
| ## 스캔한 태블릿 리스트들과 메타태블릿(루트태블릿이었나?)과 비교해 누락된 태블릿 리스트가 있는지 검사
| |
| ### 누락된 태블릿 리스트가 있다면 해당 태블릿 리스트를 가지고 있는 TS가 만기된 것임.(<- 만기가 되지 않았다면?)
| |
| ### 해당 태블릿 리스트를 다른 TS들에게 할당해야함.
| |
| ### target들을 정한다. (어떤 기준으로? 몇개나?)
| |
| ### traget들에게 직접 태블릿 리스트를 전달한다.
| |
| * TS
| |
| ## 마스터에게 받은 태블릿 리스트로 GFS에서 태블릿들을 읽어온다.
| |
| ## 읽기 성공시 마스터에게 성공 메세지 전달
| |
| ## 실패시 마스터에게 실패 메세지 보냄
| |
| === ISSUE ===
| |
| # 메타데이터 태블릿 갱신이슈
| |
| ## 갱신 누가? -> 마스터가?
| |
| ## 갱신 언제? -> 마스터 업데이트 후에?
| |
| ## 마스터 업데이트 : target이 태블릿 리스트를 전달받고 GFS에서 태블릿 읽기에 성공하면 마스터에게 성공 메세지 전달.
| |
| ## 로드 밸런싱 중간에 target이 다운된다면 : 마스터는 로드밸런싱을 위해 다른 target을 선택. 이후 TS실패 복구를 한다.
| |
| ## 로드 밸런싱 중간에 source가 다운된다면?
| |
| # 소스TS는 전달할 태블릿을 어떻게 정할 것인가.
| |
| # GFS에서 태블릿 읽기 실패시 대처?
| |
| == Compaction ==
| |
| === Minor Compaction ===
| |
| * memtable이 일정 수준보다 커지면 SSTABLE로 변환. GFS에 쓴다.
| |
| === Major Compaction ===
| |
| * SSTABLE들을 합병하여 최근 기록만을 남긴다.
| |
| === ISSUE ===
| |
| # Minor/Major Compaction 시기?
| |
| == Split ==
| |
| * 태블릿의 크기가 일정 수준 이상 커지면 두개로 나눈다.
| |
| === 기능명세 ===
| |
| | |
| === ISSUE ===
| |
| # 태블릿을 나누는 크기는?
| |
| # 태블릿을 나눌 때 나눈 태블릿의 이름은?
| |
| # 태블릿은 SSTABLE로 이루어져 있다. 태블릿은 어떻게 SSTABLE을 가지고 있나? -> sstable의 이름을 리스트로
| |
| == 커밋로그 ==
| |
| === 기능명세 ===
| |
| # memtable에 쓰기를 하기 전
| |
| # 커밋로그에 sstable명과 쓰려는 값 기록
| |
| === 비기능 명세 ===
| |
| # 커밋로그는 GFS에 있다.
| |
| # TS당 한개.
| |
| | |
| == 복구 ==
| |
| 커밋로그에서 로그를 읽어와 memtable 복구하기
| |
| === 기능명세 ===
| |
| == SCAN ==
| |
| 마스터의 스캔요청에 대한 응답. TS가 관리중인 모든 태블릿의 리스트를 마스터에게 전달한다.
| |
| === 기능명세 ===
| |
| == 클라이언트의 요청 ==
| |
| === 기능명세 ===
| |
| ==== read ====
| |
| * 클라이언트 역할
| |
| ## B+트리에서 원하는 row를 가지고 있는 TS를 탐색
| |
| * TS역할
| |
| ## 클라이언트의 ROW의 읽기 요청이 들어온다 (ISSUE 6. 클라이언트는 어떤 형식으로 TS에게 ROW를 요청할 것인가)
| |
| ## TS는 자신이 가진 태블릿들에서 요청받은 ROW를 검색
| |
| ## 검색결과들을 merge한다.
| |
| ## String의 리스트로 클라이언트에게 돌려준다
| |
| ==== write ====
| |
| * 클라이언트 역할
| |
| ## (태블릿은 같은 ROW를 담고 있으므로 클라이언트는 트리탐색을 통해 TS를 할당받는다)
| |
| * TS 역할
| |
| ## 클라이언트에게 요청받은 row는 먼저 커밋로그에 기록 후 memtable에 쓴다.
| |
|
| |
|
