8. HBase 소개 - 1

8. HBase 소개 - 1

 

1.1 빅데이터의 여명

하둡같은 시스템은 이제 기업들이 페타바이트급의 데이터를 수집하고 보유할 수 있게 해주었고, 지금보다 훨씬 더 많은 데이터를 수집해야 할 필요성은 새로운 기계학습 알고리즘의 발달과 함께 점차 증가하는 추세

 

이제는 기업에서 생산되는 모든 의미있는 데이터를 저장하고 분석할 필요성이 점점 증가

 

예쩐에는 수집된 데이터를 보유하려면 데이터의 일부를 잘라내는 수밖에 없었다.

 

구글 - 범용하드웨어 기반에서 확장성 있는 저장소 및 처리 시스템을 구축(HDFS, 맵리듀스)

hadoop - 임의적, 반구조적, 구조가 없는 데이터도 저장

- 사용자가 데이터를 분석하는 시간에 그 데이터를 어떻게 해석 할지 스스로 결정

- 데이터를 분류하는 방식을 언제든지 변경가능

- 데이터를 저장할 수 있는 공간을 무한히 제공하면서도 필요한 데이터를 필요할 때 꺼낼 수 있다

- 큰 파일 저장, 일괄처리 작업, 스트리밍 접근에 최적화

 

- 컬럼 지향 데이터베이스

데이터를 컬럼 단위로 묶어 저장, 컬럼값은 디스크 상에 연속적으로 저장

특정 쿼리에 대해서는 로우의 모든 데이터가 필요하지 않다는 가정에 기반

I/O가 줄며, 높은 압축률도 있다.

 

HBase는 전형적인 RDBMS 방식의 컬럼 지향 데이터베이스가 아니라 디스크 상의 컬럼 저장 형식만을 활용

컬럼식 데이터베이스는 데이터에 대한 실시간 분석적 접근 긴으을 제공하는데 강점

HBase는 특정 데이터 셀에 키 기반으로 접근하거나 어떤 범위에 셀에 순차적으로 접근하는데 탁월

 

1.2 관계형 데이터베이스 시스템의 문제점

RDBMS는 레코드 수가 제한적일 때는 잘 작동하나, 쌓여 가는 데이터양이 급격히 증가하면 일반적인 데이터베이스 시스템의 세부 구현 구조에서 약점의 징후를 보이게 됨

RDBMS는 ACID라는 속성을 통해 강력한 일관성 보장

참조무결성은 다양한 테입르 스키마 간의 강제적인 관계를 관리

SQL언어로 복잡한 쿼리를 만들 수 있게 해줌

실제로 데이터가 어떻게 저장되는지 사용자가 직접 처리할 필요 없고, 애플리케이션 코드가 참조할 수 있는 고정된 데이터 배치 방식을 정의하는 테이블 스키마 같은 고수준 개념만 관리

 

RDBMS가 잘 작동하지만 정보가 많아질수록 서버의 데이터는 많아지고 CPU I/O는 늘어난다

방법 1. slave DB server늘림 -> 그러나 서버고장, 사용자수 늘어남..

방법 2. memcahed -> 그러나 일관성 보장을 못함

메모리에 데이터 보존

모든 데이터를 메모리에 두므로 데이터의 입출력이 굉장히 빠름

그러나 가동 중이던 memcached가 정지되면 데이터가 지워짐

또한 메모리 크기를 넘어서는 양의 데이터는 다룰 수 없음

 

위의 방법으로 해결 할 수 있지만 계속해서 데이터의 양이 증가되면 비용이 너무 많이 든다.

한가지 더 대안으로 샤딩이 있지만 샤딩을 관리하는 일과 비용을 감당할 수 없다.

 

- 샤딩

기존에 하나로 구성될 스키마를 다수의 복제본으로 구성하고 각각의 샤드에 어떤 데이터가 저장될지 샤드키를 수평적 파티션에 레코드를 논리적으로 분할하는 것을 의미

데이터를 서로 인접하게 저장하지 않고 다중 저장소 파일(혹은 서버)에 분산하기 위해서 나타남

파티션에 데이터를 분산하는 작업은 파티션 간에 고정된 경계선을 지정하여 수행

-> 각 데이터를 적절한 장소로 라우팅하기 위해 규칙을 미리 정함

-> 수평적 파티션 중 하나의 용량이 가득 차면 재샤딩(데이터 저장 구조를 다시 작성해야됨)해야되는데 어려움

 

이 문제를 가상 샤드를 통해 어느정도 완화 가능

 

- 가상 샤드

매우 큰 키 분할 범위를 정의

실제 서버 수와 관계없이 필요한 만큼의 가상 샤드를 생성

각 서버에 가상 샤드를 균등하게 분배