[Hbase] 소개

HBase는 Hadoop Database의 축약으로, 대규모 데이터를 다루기 위한 분산 데이터베이스 시스템이다.

이름 그대로 Hadoop의 파일시스템 구조 HDFS에 기반해서 만들어졌고, Java로 만들어졌다. Google의 Bigtable가 모티브다.

탄생 시기는 2008년.

SQL은 지원하지 않는 NoSQL 시스템이다. 터프한 raw query 구조를 가졌다.

특징

대규모 서비스에 사용하는 메인 DB로 적합한 포지션이다.

매우 높은 실시간 쓰기/읽기 처리량을 제공하는 고성능 DB에 속한다.
그리고 NoSQL로서는 특이하게 꽤 강력한 트랜잭션과 일관성 수준을 제공한다. (다만 완전한 ACID 수준을 보장하지는 않음)

페타바이트 단위의 큰 데이터를 관리하기 위한 시스템이기 때문에, 디스크 저장 효율 자체도 꽤 괜찮은 편이다.
다른 DB들보다 데이터 압축을 잘 해준다.

클러스터 구조에 있어서는 요즘 분산 DB들과는 다르게 Master-Slave 구조를 가진다. 단일 Master를 통해 클러스터가 관리된다.

아키텍쳐

내부 아키텍쳐나 동작방식은 다소 복잡한 편이다.
단일 기술스택이 아니라, 양파처럼 겹겹이 쌓아올린 기형적인 시스템이라 더 그렇다.

일단 최상위 관리자로는 HMaster와 Zookeeper가 존재한다.
Zookeeper는 장애지 감지/복구 등을 감독하고, HMaster는 좀 더 세부적인 장애처리나 로드밸런싱, 데이터 coordinatin 등을 감독한다. 감독자가 둘이라서 좀 괴물같긴 한데... 아무튼 그렇다.

실제로 데이터를 쓰고 읽는 주체는 Region Server다. 저게 각각의 Slave Server인 셈이다.
Client가 쿼리를 날리면, 적절한 Region Server로 쿼리가 전달된다. Region 서버는 쿼리를 해석해서 HDFS 파일시스템에 데이터를 저장하거나 읽는다.
Region Server 자체에 데이터가 영구적으로 저장되지는 않는다. Worker Node일 뿐이다.

vs CassandraDB

HBase의 가장 강력한 대적자는 CassandraDB라고 할 수 있을 것이다.
페북을 위시로 CassandraDB의 영향이 퍼져나가면서 HBase는 약간 옛날 기술처럼 취급받는 기조가 있다.

실제로도 많은 부분에서 CassandraDB보다 많이 쳐지긴 한다.
거의 유일한 장점은 하둡의 강력한 에코시스템들을 활용할 수 있다는 것 정도다.

운영능력

일단 HBase를 비롯한 하둡 스택들은 하나같이 운영 난이도가 높은 편이다. 환경 자체가 쇠퇴하는 것도 있고, 계층이 쓸데없이 복잡하다.
Cassandra-like 시스템들은 커뮤니티도 꽤 잘 굴러가고, 기술의 운영 복잡도가 비교적 낮은 편이다.

수평 확장

CassandraDB는 수평 확장이 꽤 자유롭고 편한 편이다. P2P라서 모든 노드가 평등하고, 추가하는 것도 쉽다.
HBase는 확장 자체도 손이 많이 가고, 고려할 것도 많다. HDFS가 병목이면 하둡 수준에서 확장을 고려해야 하고, 연산이 병목이라면 Region Server를 확장해야 한다. 둘 다 해야할 수도 있고, 관리지점이 과도하게 복잡하다.

가용성

CassandraDB는 p2p 기반의 평등한 노드 구조라서, 특정 노드가 죽었다고 해서 전체적인 장애로 이어질 확률은 낮다. 모범 사례만 잘 따른다면.
하지만 HBase는 분명한 단일 지점이 존재하기 때문에 가용성이 낮은 편이다. 당장 ZooKeeper나 HMaster 중 하나만 죽어도 전체 장애가 발생하는 것이다.

성능

사실 실성능은 CassandraDB가 대체로 더 빠른 편이다. 쓰기/읽기 모두.

파티션

CassandraDB는 파티션 키를 기준으로 실제 파티션 데이터를 생성한다. 특정 파티션 내의 조회는 매우 빠르게 처리되는 것이 특징이다. 그래서 파티션 키를 잘 잡아서 데이터가 잘 분산되게 하는 것이 주요 최적화 포인트가 된다.

반면 HBase에는 파티션이라는 개념이 없다. Row Key라는 것을 기준으로 정렬되어 저장되는데, 그래서 Row Key 기준으로 범위 스캔을 하는 것이 가장 빠르게 동작한다. 하지만 CassandraDB처럼 특정 파티션 그룹(예를 들면 특정 user)의 데이터만 빠르게 스캔한다는지 하는건 비교적 느리다.
이걸 효율화하려면 Row Key를 기괴하게 설계해야 한다. 같은 가상-파티션 단위끼리는 동일한 문자열 값을 prefix로 넣어서 정렬할때 뭉쳐서 나오게 한다든지.

참조
https://aws.amazon.com/ko/what-is/apache-hbase/
https://www.geeksforgeeks.org/dbms/architecture-of-hbase/