imported>rabierre |
imported>rabierre |
| (204 intermediate revisions by the same user not shown) |
| Line 1: |
Line 1: |
| __TOC__
| | 구글 빅테이블 |
| [[Bigtable/*]]
| |
| * 구글의 분산 데이터베이스
| |
|
| |
| == 등록 ==
| |
| 신규 TS는 chubby에 자신의 정보를 등록한다
| |
| * 기능명세
| |
| ## chubby에 자신의 정보를 등록한다
| |
| ## 자신의 ip
| |
| ## 또뭐?
| |
| * 비기능명세
| |
| ## TS 시작시에 등록한다. 등록에 성공하지 못하면 다시 시도한다.
| |
| ## 재시도할 때 마다 시간간격 늘림
| |
| ## 일정횟수 이상시 멈춤(chubby의 부하 고려)
| |
| | |
| == 만기 ==
| |
| TS는 스스로를 파기하지 않는다.
| |
| * 기능명세
| |
| ## 없음
| |
| * 비기능명세
| |
| ## 없음
| |
| | |
| == 태블릿 할당 ==
| |
| ** 기능명세
| |
| ** 신규 TS에 태블릿 할당하기 : 가장 load가 많은 TS의 태블릿을 신규 TS에게 할당한다
| |
| ** 마스터 역할
| |
| ### 신규TS(target) 탐지시
| |
| ### load가 가장 많은 TS(source)를 찾는다.
| |
| ### source에게 target의 ip와 전달할 태블릿개수 넘김.
| |
| ** TS 역할
| |
| ### source는 target에게 정해진 갯수만큼의 태블릿을 리스트로 이름전달
| |
| ### target에게서 제대로 전달받았는지 확인 (ISSUE. 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한다?
| |
| # ISSUE. 메타데이터 태블릿 갱신이슈
| |
| # 갱신 누가? -> 마스터가?
| |
| # 갱신 언제? -> 마스터 업데이트 후에?
| |
| # 마스터 업데이트
| |
| # 로드 밸런싱 중간에 target이 다운된다면?
| |
| # 로드 밸런싱 중간에 source가 다운된다면?
| |
| ISSUE 4. 소스TS는 전달할 태블릿을 어떻게 정할 것인가.
| |
| ISSUE 5. 태블릿의 이동 후 메타테이블의 갱신은?
| |
| * 비기능명세
| |
| | |
|
| |
| == 클라이언트의 요청응답 ==
| |
| * 기능명세
| |
| ** read
| |
| ** 클라이언트 역할
| |
| ## B+트리에서 원하는 row를 가지고 있는 TS를 탐색
| |
| ** TS역할
| |
| ## 클라이언트의 ROW의 읽기 요청이 들어온다 (ISSUE 6. 클라이언트는 어떤 형식으로 TS에게 ROW를 요청할 것인가)
| |
| ## TS는 자신이 가진 태블릿들에서 요청받은 ROW를 검색
| |
| ## 검색결과들을 merge한다.
| |
| ## String의 리스트로 클라이언트에게 돌려준다
| |
| ** write
| |
| ** 클라이언트 역할
| |
| ### (태블릿은 같은 ROW를 담고 있으므로 클라이언트는 트리탐색을 통해 TS를 할당받는다)
| |
| 클라이언트에게 요청받은 row는 먼저 커밋로그에 기록 후 memtable에 쓴다.
| |
| * 비기능명세
| |
| | |
| | |
| == 커밋로그 ==
| |
| 클라이언트의 write요청 시 memtable에 쓰기 전에 커밋로그에 먼저작성. 커밋로그는 GFS에 있으며 TS당 한개.
| |
| | |
| * 기능명세
| |
| * 비기능명세
| |
| | |
| | |
| == Compaction ==
| |
| === Minor Compaction ===
| |
| * memtable이 일정 수준보다 커지면 SSTABLE로 변환. GFS에 쓴다.
| |
| === Major Compaction ===
| |
| * SSTABLE들을 합병하여 최근 기록만을 남긴다.
| |
| | |
| ISSUE 8. Minor/Major Compaction 시기?
| |
| | |
| * 기능명세
| |
| * 비기능명세
| |
| | |
| | |
| == Split ==
| |
| * 태블릿의 크기가 일정 수준 이상 커지면 두개로 나눈다.
| |
| ISSUE 9. 태블릿을 나누는 크기는?
| |
| ISSUE 10. 태블릿을 나눌 때 나눈 태블릿의 이름은?
| |
| ISSUE 11. 태블릿은 SSTABLE로 이루어져 있다. 태블릿은 어떻게 SSATBLE을 가지고 있나?
| |
| | |
| * 기능명세
| |
| * 비기능명세
| |
| | |
| | |
| == 복구 ==
| |
| 커밋로그에서 로그를 읽어와 memtable 복구하기
| |
| | |
| * 기능명세
| |
| * 비기능명세
| |
| | |
| = 태블릿 서버(이하 TS) =
| |
| = Master Server =
| |
| == 메타태블릿 갱신 ==
| |
|
| |
|
