Flush
- Client Flush
- 데이터 쓰기 시 AutoFlush를 이용하는 경우 매 Put() 요청 마다 Flush가 수행됨
- AutoFlush를 해제하는 경우 Put() 요청은 클라이언트 측 버퍼에 임시 저장되어 RPC가 발생하지 않음
- flushCommits(), close(), put() 등의 메소드를 통해 명시적, 묵시적 비우기를 수행할 수 있음
- MemStore Flush
- CF 당 한 개씩 존재하며, 임계치가 되면 정렬된 KeyValue 데이터의 All Flush가 수행됨
- MemStore의 Flush 결과로 새로운 HFile이 생성됨
Compaction
- Minor Compaction
- HFile 임계 개수 초과 시 작은 파일들을 조금 큰 파일들로 재구성 하는 과정
- 마지막으로 추가된 저장 파일 몇 개만을 대상으로 하여 설정된 최대 크기까지만 취합
- Major Compaction
- CF 당 1개의 HFile로 전체를 재구성하는 과정으로 Tombstones Marker가 존재하는 데이터를 최종적으로 삭제함 (기본값 7일에 1번 수행)
- Major Compaction은 Disk I/O와 네트워크 트래픽을 많이 소모함
<Minor Compaction>
Recovery
- 어느 한 리전 서버가 중단되면 리전 서버(Crash)의 WAL을 분할하여 다른 리전 서버들(Active)의 RS로 복제 후 WAL 기반 재실행을 수행함
- 복구된 MemStore 데이터는 Flush를 통해 최종적으로 디스크에 저장됨
- RegionServer Failover time
- = zookeeper session timeout + split time + assignment/replay time
HBase 특징
- 장점
- 성능 이슈가 발생할 경우 계속 RegionServer만 추가하면 성능 유지
- Fail Over가 쉽고 관리 용이
- Hadoop MapReduce의 Input으로 사용하기 편함
- Region 분할에 따른 스케일링 자동화 가능
- WAL 기반의 복구 기능 제공
- 단점
- 적절한 HBase 설정을 하기 위한 팁들이 있으나 클러스터의 규모나 기본 Spec차이로 인해 성능 튜닝을 바로 적용하기 어려움
- 특정 RegionServer에 특정 Table의 Region이 집중되기 쉬우며, 이는 성능 저하로 이어짐
- Crash Recovery, WAL replay, Major Compaction 등이 상당히 느림
키 설계
- 잘못된 Row key 설계는 Hotspotting을 야기함
- 빠른 데이터 검색과 데이터 분할/분산을 위해 Tall-Narrow가 권장됨
- Small number of columns, Large number of rows
- Hotspotting을 피하기 위해 Salting (Randomly-assigned prefix)을 이용함
- 이 외에도 Row key로의 필드 승격 방식은 쓰기 부하 분산과 순차 읽기의 균형점을 찾을 수 있음 (ex) <metric-id><base-timestamp>
블룸 필터
- 특정 Row key를 포함하고 있는지 탐색할 때, 기존 블록 색인에 비해 불필요한 블록 로딩을 줄여 클러스터의 전반적인 처리량이 개선됨
- 셀 크기, 셀 개수, 데이터 저장 방식, 읽기 방식 등에 따라 블룸 필터를 선택
- HBase 문서에 따르면 왠만한 경우에는 BloomFilter를 사용하는 것을 권장함
버저닝
- 자동 버저닝
- 클러스터 내 서버 시간이 동일하지 않은 경우 버전 차이 발생 가능
- Put 메소드 수행 시 타임스탬프를 설정할 수 있으나 일반적으로 서버 내 자동 버저닝 권장
- 기본적으로 최근 3개 버전을 관리하지만 Major Compaction 기능이 긴 주기를 가지므로,
(아직 삭제되지 않은) 과거 버전이 여전히 존재할 수 있음 - 수동 버저닝
- 타임스탬프를 오버라이드하여 구현 가능
나뷜나뷜