1. 서론
Hadoop eco system에서 비관계형 분산 데이터 베이스로 많이 사용하는 Hbase에 대해 공부한 내용을 공유하고자 합니다.
책은 HBase 완벽 가이드 를 통해 공부하였습니다.
이번 포스팅에서는 1장인 소개부분을 진행하도록 하겠습니다.
2. 관계형 데이터 베이스 시스템의 문제점
책에서는 RDB에 대한 확장성 측면에서 문제점을 얘기하고 있습니다.
물론, RDB의 대표적인 MySql, Oracle, Postgres 등은 실제 서비스에서도 많이 사용되고 있는 DB이며,
현재는 확장성을 고려해 MySql, Postgres 등은 분산 클러스터 기능도 제공하고 있습니다.
DB 기반 서비스는 확장됨에 따라 DB 성능이 매우 중요해지게 됩니다.
이 성능을 올리기 위해 일반적으로 아래와 같은 방법을 사용할 수 있습니다.
- Read 질의를 위한 슬레이브 데이터 베이스 사용
- 멤캐시드와 같은 캐시 추가
하지만, 위 2가지 방법의 경우에는 Read를 위한 방법으로 Write에 대한 성능 향상은 아니며,
마스터/ 슬레이브 구조에서는 마스터와 슬레이브의 컴퓨팅 성능의 차이가 클수록 성능에도 악영향을 끼칠수 있게 됩니다.
결국, DB를 구성한 서버의 자원을 모두 올려야하는 비용이 들며, 캐시를 사용하게 되면 순간적인 데이터 일관성이 깨지게 되는 문제점이 발생할 수 밖에 없게 됩니다.
최종적으로는 RDB의 장점인 정규화를 없애고, 성능을 위해 비정규화를 하게 됩니다.
정규화는 결국 데이터를 분리하게 되는것입니다. 그렇다는것은 데이터를 가져오기 위해서 join연산을 수행해야 합니다.
하지만 RDB에서는 이 join 연산이 비싸기 때문에 성능을 올리기 위해서는 일반적으로 비정규화를 하게 됩니다.
3. RDBMS vs NoSql
RDBMS와 NoSql은 정반대의 관계가 아닙니다.
그 이유로는 상용에 있는 RDBMS와 NoSql 종류에 따라 저장 방식도 모두 다르고 지향하는 점이 다르기 때문입니다.
개인적으로, RDBMS와 NoSql의 구분은 스키마의 자유도로 나누면 된다고 생각합니다.
트랜잭션 강도를 제외한 이유로는 DBMS의 제품에 따라 NoSql 이라도 강한 제품이 있기 때문입니다.
그렇기에, 서비스에 맞는 DBMS를 선택해야 합니다. 책에서는 선택할 때 고려해야할 기준을 소개하고 있습니다.
1) 데이터 모델
데이터 모델로는 대표적으로 아래와 같이 있습니다.
- 키/값 방식
- 반 구조적
- 컬럼지향 방식
- 문서 지향 방식
2) 저장 모델
인메모리 방식인지, 영구저장 방식인지도 기준으로 들 수 있습니다.
영구저장의 경우 디스크에 쓰게되며, 이 경우 성능에 어떤 영향을 미치는지도 고려해야 합니다.
3) 일관성 모델
일관성 정책의 엄격함도 고려해야 합니다.
각 DBMS에 따라 느슨한경우와 엄격한 경우가 있기 때문입니다.
4) 물리적 모델
물리 장치가 단일한지 분산인지도 고려해야 합니다.
단일 장치의 장/단점과 분산 장치의 장/단점이 존재하기 때문입니다.
간단한 예로 분산의 경우는 네트워크 비용이 어쩔수 없이 들게 된다는 단점이 있지만,
수평 확장이 가능하여 저장 부분에서는 무한하다는 장점도 가지고 있습니다.
5) 읽기/쓰기 성능
현재 서비스는 DB에 읽기와 쓰기 중에 비율이 어떤지도 고려해야합니다.
아래 크게 3가지에 따라서 선택해야 하는 DBMS도 다르지만 DBMS의 정책도 달라지기 때문입니다.
- 읽기 > 쓰기
- 읽기 = 쓰기
- 읽기 < 쓰기
6) 보조색인
보조색인의 필요성도 고려대상에 포함됩니다.
보조색인이 필요 없다고 판단될 땐 확장성을 생각하여 어플리케이션에서 충분히 커버가 가능한지도 알아봐야 합니다.
7) 장애 처리
장애처리에 대해서 각 DBMS들은 어떠한 대처를 하는지도 알아봐야 합니다.
데이터가 인메모리 저장 방식의 경우 각 DB 서버는 graceful shutdown으로 디스크에 저장되도록 되어 있지 않다면 데이터 유실이 발생할 것 입니다.
8) 압축
압축이 기본적으로 제공되는지 혹은 필요시 플러그인으로 압축 기법을 사용할 수 있는지도 고려 대상에 포함됩니다.
9) 부하 분산
읽기/쓰기에 대한 부하를 DB 자체적으로 분산해주는지도 고려대상입니다.
(처리량이 많은 어플리케이션 구조에서 고려해보면 됩니다.)
10) 원자적 읽기, 갱신, 쓰기
원자적인 CRUD가 가능한지도 고려 대상입니다.
DB에서 제공하는지의 여부에 따라 클라이언트 측 어플리케이션의 복잡도에 영향이 가기 때문입니다.
11) 락걸기, 대기, 데드락
데이터 접근 시 어떤 유형의 락 모델을 제공하는지도 고려대상입니다.
이것은 성능에도 직접적인 영향이 있기 때문에 놓치지 않아야 하는 기준입니다.
4. 구성 요소
이제 Hbase에 대한 구성요소를 간단히 소개하겠습니다.
1) 테이블
Hbase에는 RDBMS와 동일하게 테이블이라는 구성 요소가 존재합니다.
2) 로우
로우는 유일한 키인 로우 키를 가지고 있습니다.
또한, 이 로우가 다수 모여 테이블을 이루게 됩니다.
추가로,로우는 로우키를 기준으로 사전 편찬식으로 저장되어 집니다.
아래는 scan했을때의 예입니다.
row-1 column=cf1:, timestamp=11111
row-10 column=cf1:, timestamp=11111
row-11 column=cf1:, timestamp=11111
row-2 column=cf1:, timestamp=11111
사전편찬식 정렬에서는 2진수 수준에서 바이트 단위로 왼쪽부터 비교하게 됩니다.
그로인해, 위와 같이 row-10, row-11이 row-2보다 위에 있게 됩니다.
3) 컬럼
컬럼은 상위에 컬럼패밀리라는 것을 가져야 합니다.
컬럼패밀리는 데이터를 의미적으로 분류하게 해주는 것으로, 이 컬럼 패밀리 단위로 압축이나 메모리 상주같은 설정이 가능하게 됩니다.
또한, 컬럼패밀리 안의 모든 컬럼은 HFile이라는 하나의 Hbase에서 관리하는 저수준 저장 파일에 함께 저장됩니다.
컬럼패밀리는 테이블 생성될 때 최소 하나 이상은 정의해야하며, 갯수가 많아서는 안되는 제약사항이 있습니다.
그래서, Hbase에서의 컬럼은 '컬럼패밀리:퀄리파이어' 로 표현할 수 있습니다.
여기서 퀄리파이어는 바이트 배열로 패밀리안에 속한 컬럼키라고 보시면 됩니다.
퀄리파이어의 경우 컬럼패밀리와 달리 갯수에 제약사항이 없어, 하나의 컬럼패밀리안에는 수백만개의 퀄리파이어를 저장할 수 있습니다.
또한, 데이터 타입이나 길이에도 제한이 없습니다.
4) 셀
셀은 컬럼의 값으로서 타임스탬프를 가지고 있습니다.
타임스탬프를 가지고 있다는 것은 컬럼의 값을 타임스탬프 기준으로 버저닝한다는 의미입니다.
타임스탬프는 사용자가 직접 지정할 수도 있으며, Hbase 내부적으로 부여할 수도 있습니다.
또한, 동일한 값은 타임스탬프 기준으로 정렬되어 항상 최신의 값을 먼저 읽을 수 있도록 되어 있습니다.
추가로, 셀의 경우 바이트 배열로 되어 있어, 클라이언트 측에서 어떻게 처리해야 할지 알고 있어야 합니다.
아래는 Hbase의 전체적인 구조를 나타낸 것입니다.
(Table, RowKey, Family, Column, Timestamp) -> Value
정렬의 기능을 추가하여 프로그래밍적으로 나타내게 된다면 아래와 같습니다.
SortedMap<RowKey, List<SortedMap<Column, List<Value, Timestamp>>>>
5) 원자성
Hbase는 로우 단위로 컬럼 수와는 무관하게 원자성을 보장하고 있습니다.
단, 여러 로우나 테이블에 걸친 원자성이나 트랜잭션을 보장하지 않습니다.
6) 자동 샤딩
Hbase에서는 확장성, 로드밸런싱을 위해 리전이라는 단위를 사용하고 있습니다.
리전은 단순히 특정 범위의 로우 집합으로 이해하면 되며,
리전은 사이즈가 커지게 되면 자동으로 분할하게 되며, 반대로 합쳐지기도 합니다.
최초 테이블 생성 시에는 하나의 리전이 존재하고, 시스템이 모니터링을 하다 특정 기준이 넘어가면 둘로 분리하게 됩니다.
각 리전은 하나의 리전서버에서 운용되며 각 서버는 수많은 리전을 운용할 수 있습니다.
리전의 특징으로는 아래와 같습니다.
- 서버 고장 시 리전을 다른 리전 서버로 이동시켜 재빨리 복구 가능
- 세밀한 로드밸런싱
5. Hbase 내부 동작 방식
hbase는 데이터 색인 방식으로 LSM(= Log Structured Merge) Tree 을 사용합니다.
hbase는 데이터를 HFile 이라는 파일에 저장하게 되고,
이 파일은 영구 저장, 정렬, 고정 불변의 키/값 쌍의 맵이라고 보시면 됩니다.
1) HFile
HFile은 연속적인 블록이며 블록에 대한 색인은 블록 끝에 저장되어 있습니다.
색인은 HFile이 열릴때 메모리로 로드되어 사용하게 됩니다.
또한, HFile은 위에서 설명한 LSM Tree를 기반으로하여 특정값 혹은 시작값~끝값의 range 스캔이 가능합니다.
추가로, 모든 HFile은 블록 색인을 갖고 있어 검색은 단 한번의 디스크 판독으로 수행될 수 있습니다.
검색하고자하는 키를 통해 블록 색인에서 이진탐색이 이루어지게 됩니다.
2) WAL
WAL은 Write-Ahead-Log로 Hbase는 데이터 갱신시 여기에 먼저 씌어지게 됩니다.
Hbase에서는 커밋로그 라고도 불립니다.
WAL에 먼저 쓰여지기 때문에 장애가 났을시에도 데이터의 유실은 있지 않습니다.
3) 멤스토어
WAL에 씌어진 다음에는 메모리인 멤스토어에 저장이 됩니다.
멤스토어에 있는 설정한 값을 넘게 되면 그때야 비로소 HFile에 쓰여지게 됩니다.
HFile에 쓰여진 이후에는 WAL에 있던 쓰여진 데이터도 삭제되어 집니다.
데이터를 읽을때에는 HFile과 멤스토어간의 데이터 정합이 안맞을 수 있어, 두 곳에서 데이터를 통합하여 반환하게 됩니다.
LSM 트리 구조상 삭제는 바로 할 수 없습니다. 하지만, 삭제표시를 해두어 읽기 연산 시 삭제된것처럼 데이터를 감출 수 있습니다.
4) 컴팩션
멤스토어에서 HFile로 write 할 때마다 파일의 수는 증가하기 때문에 Hbase는 내부적으로 컴팩션이라는 것을 수행하게 됩니다.
이 컴팩션은 부 컴팩션 과 주 컴팩션으로 구분할 수 있습니다.
1. 부 컴팩션
부 컴팩션은 작은 파일의 내용을 큰 파일에 병합시켜 파일의 갯수를 줄이는 행위입니다.
HFile은 내부적으로 정렬되어 있기 때문에 병합속도는 빠르게 이루어지며, 오직 디스크 입출력 성능에 영향을 받습니다.
2. 주 컴팩션
주 컴팩션은 하나의 리전안의 컬럼패밀리 하나를 구성하는 모든 파일을 새로운 파일 하나로 다시 쓰는 작업입니다.
부 컴팩션과의 차이로는 위에 설명한 삭제표시가 달린 데이터를 다시 쓰는 과정에서 제외시켜 영구적으로 삭제할 수 있다는 점 입니다.
6. Hbase 클러스터 구성
Hbase 클러스터는 마스터 서버 한대, 리전 서버 다수로 이루어져 있습니다.
1) 마스터서버
마스터 서버는 아래와 같은 역할을 수행합니다.
- 리전 서버에 리전 할당
- 리전 서버간의 리전의 부하 분산 처리
- 테이블 및 컬럼패밀리의 생성 같은 스키마 변경 사항 및 기타 메타데이터 작업 수행
위 역할들을 마스터 서버가 수행하기 위해서는 주키퍼라는 서비스를 필수로 사용해야 합니다.
2) 리전 서버
리전 서버는 클라이언트와 통신하며 데이터의 읽기와 쓰기를 담당하는 서버입니다.
쓰기도 담당하기 때문에 리전 분할의 역할도 이루어 집니다.
6. 마무리
이번에는 간략히 Hbase 소개에 대해서 포스팅하였습니다.
다음에는 2장인 설치 챕터이지만 해당 챕터는 Hadoop 설치 에서 사용한 cloudera manager를 사용하여 Hbase 서비스를 추가하는 것으로 대체하도록 하겠습니다.
'BigData > Hbase' 카테고리의 다른 글
| (5) 클라이언트 API : 관리 기능 (0) | 2020.06.02 |
|---|---|
| (4) 클라이언트 API : 고급 기능 (0) | 2020.04.19 |
| (3) 클라이언트 API : 기본 기능 (0) | 2020.04.09 |
| (2) 설치 (0) | 2020.04.08 |