by-nc-sa     개발자, DBA가 함께 만들어가는 구루비 지식창고!

1장 소개




1장 소개

관계형 데이터베이스 관리 시스템(RDBMS)은 1970년대 초에 등장하여 여러회사에 사용되며 여전히 유용하다.
관계형 모델이 그다지 적합하지 않은 세부적인 문제들도 존재한다.
왜 또 하나의 저장 구조가 출현하였는가?

1.1 빅데이터의 여명

기업들이 추천정보, 온라인광고 등 맞춤형 방식에 초점.
하둡은 페타바이트급의 데이터를 수집 보유가능하게 해줌. 기계학습 알고리즘의 발달로 데이터가 더 필요함.

데이터 분석하지 않는 기업은 경쟁에서 밀려날 것이다.
예전의 데이터보관방식, 최근 N일 데이터만 보관하고 그 이후는 삭제.
이러한 접근방식은 잠깐은 성공적일 수 있다. 하지만 전 기간에 걸친 수학적 모델을 구축하거나 , 이전의 데이터를 개선된 알고리즘에 적용해볼 기회를 상실 ( 뜨끔 )

구글과 아마존 중심으로 범용 하드웨어 기반의 확장성 있는 저장소 및 처리 시스템이 소개됨. 하둡 프로젝트 ; HDFS 와 맵리듀스
하둡은 데이터 저장공간을 무한히 제공하면서 필요한 데이터를 꺼내기 쉽다. ( 빅파일, 일괄처리, 스트리밍 접근에 최적화 )

하지만 random access 도 필요하다. (full scan vs index)
random access의 전통강자 RDBMS. RDMBS는 codd의 12법칙을 구현하려한다. 링크 : 커드의 12법칙
그런데 컬럼지향 데이터베이스 또는 대량 병렬처리 데이터베이스 등 최근에 대두된 다른 접근방식들도 있다.

컬럼 지향 데이터베이스

데이터를 컬럼 단위로 묶어 저장.
컬럼값은 디스크 상에 연속적으로 저장. ( 전통적으로 row연속적으로 저장되는것과 상반됨 )

특정 쿼리에 대해 row의 모든 데이터가 필요하지 않음.
이런 컬럼중심 데이터 사용은분석적 데이터베이스에서 자주 발생하는 경우.
데이터 특성이 유사하여 I/O만이 아니라 압축률도 좋아짐.

HBase는 전형적인 컬럼지향 데이터베이스가 아니라 디스크 상의 컬럼 저장 형식만을 활용했음.
컬럼식 데이터베이스 : 데이터에 대한 실시간 분석적 접근 기능을 제공
HBase : 특정 데이터 셀에 키 기반으로 접근, 어떤 범위의 셀에 순차적으로 접근하는데 탁월한 성능

페이스북은 매일 15TB간 넘는 데이터를 하둡 클러스터에 추가. 클릭-스트림 로깅, 메시징시스템
웹 지향성이 덜한 회사들도 데이터 수집양은 증가한다. (금융, 생물정보학, 등등)
페타바이트급의 데이터를 효율적으로 저장하고 갱신, 회수 성능을 원할히 유지하려면?

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

RDBMS는 비즈니스 애플리케이션 설계의 필수적이었고, 앞으로도 그렇다.
사용자, 상품, 세션, 주문 등 정보를 persistence layer에 저장하는 백엔드 시스템을 제공한다.
다만, 데이터양의 급격한 증가로 약점이 있는 부분이 있다.

문제도출 : 단축URL 생성기를 RDBMS로 구현

사용자 테이블 생성 (index : 유저명), sql join으로 사용자의 단축 URL을 가져온다. + 고객의 세부정보까지 가져올 수 있음.
stored procedure로 클라이언트별 데이터 일관성 보장됨
ACID 보장
이하 우리가 잘아는RDBMS특징들 생략
그런데 사용자가 증가하기 시작 CPU와I/O부하가 언제까지 버틸 수 있을까..
슬레이브 서버 추가하여 read를 분산.
memcached를 추가하여 읽기 부하를 더 분산. (DB-캐시간 데이터 일관성은 점점 벌어짐)
쓰기 부하가 증가하여 더 빠른 디스크 탑재한 서버로 교체 , 슬레이브도 마스터를 따라가기위해 같이 교체 ... 2배 3배 비용들어감.
데이터 양이 많아지면 join이 느려짐. 스키마 비정규화 시작 ㅠ => 본질적인 최적화를 위해 데이터베이스의 기능을 줄임
더더...증가...secondary index삭제;;; ㄷㄷ PK만 사용
데이터베이스 sharding...샤딩을 관리하는것은 악몽과 같다. (저장구조 재설계, 또 한계이면 재샤딩)

그런데.. 페북,구글도 우리도 잘 쓰고 있긴 하다.

1.3 비관계형 데이터베이스 시스템, Not-Only SQL인가 NoSQL인가?

앞의 언급된 문제공간의 혁신으로 NoSQL솔루션이 출현
버클리DB, Coherence, GT.M , 객체지향DB 등 발상자체가 새로운것은 아니다.
NoSQL은 SQL에 내린 천벌? ㅎㅎ (Nemesis Of SQL)
새로운 저장 시스템들이 SQL 대신 단순한 API를 제공했기 때문에 NoSQL의 이름이 잘 맞아떨어짐.

RDBMS, NoSQL의 실질적 차이
스키마, ACID에 준하는 트랜잭션 속성, 실제 저장 구조
특히 NoSQL들은 확장성을 우선으로 고려 (CAP의 P)

일관성 모델

*엄밀한 일관성
데이터에 가해지는 변경사항은 원자성을 가지며, 즉시 반영되는 것 처럼 표시된다. 가장 강력한 형태의 일관성이다.

*순차적 일관성
모든 클라이언트가 모든 변경 사항을 적용된 순서대로 동일하게 바라본다.

*인과적 일관성
인과적으로 연관된 변경사항에 한해 모든 클라이언트가 순서대로 동일하게 바라본다.

*최종적 일관성
일정 기간 동안 갱신이 이루어지지 않으면 최종적으로 모든 갱신 내역이 시스템 전체에 전파되어 모든 사본이 동일한 내용을 지니게 된다.

*약한 일관성
모든 갱신 내역이 전파되리라는 보장도 없고, 갱신 사항이 각 클라이언트에서 뒤죽박죽 섞여 표시될 수 있다.

..중략..

일관성을 느슨하게 하면서 대신 가용성을 획득하자는 제안은 매우 설득력이 있다. 그러나 이 방식은 비일관성에 대한 대처를 애플리케이션 계층에 전가하여 복잡성을 증가시킬 위험도 있다.

마치 RDBMS가 아니면 무조건 NoSQL로 간주하는 시각은 잘못된 이분법적 태도를 양산할 수 있다. (각 시스템별로 흥미로운 기술적 가능성이 있다.)
시스템의 특성을 다각도로 분류할 수 있는 수많은 기준이 있다.

1.3.1기준
  • 데이터 모델
    • 데이터 저장방식 : 키/값, 반구조적 방식, 컬럼지향방식, 문서 지향 방식
    • 애플리케이션이 데이터에 어떻게 접근하는가? 스키마는 시간이 흐름에 따라 변화가능한가?
  • 저장 모델
    • 인메모리, 영구저장 등
  • 일관성 모델
    • 일관성 정책의 엄격한 정도, 성능에 영향
  • 물리적 모델
    • 장치가 분산되는가 단일한가
    • 분산구조는 클라이언트에서 직접 구현하는가?
    • 사용자 확장에 영향
  • 읽기/쓰기 성능
    • 읽기/쓰기 부하는 어떠한가?
    • 범위 검색이 필요한가?
  • 보조색인
    • 보조색인으로 다양한 필드의 정렬을 지원하는가?
    • 애플리케이션에서 자체적으로 에뮬레이트 할 수 있는가?
  • 장애처리
    • 장치 고장의 대비 계획
    • 서버 고장을 어떻게 처리하는가? 일관성 모델과 관련있음.
    • 장치 한대를 잃은 후 복구할때 100%가동률 회복이 용이한가? (클러스터에서 서버 제거하는 경우도 동일)
  • 압축
    • 압축 플러그인을 지원하는가?
    • 어떤 종류의 압축을 지원하는가?
  • 부하 분산
    • 읽기/쓰기 부하량을 분산
  • 원자적 읽기,갱신,쓰기
    • RDBMS에서 풍부한 제공을하는 반면 분산시스템은 힘들다.

*락 걸기,대기, 데드락

    • 어떤 락모델을 지원하는가? 무제한 대기 허용하여 데드락에 빠질 가능성이 있는가?
1.3.2확장성

RDBMS는 트랜잭션에 적합, 대규모 분석 작업에는 그리 적합치 않음.
수직적 확장으로 부족하고, 락획득에 비용이크다. 샤딩도 구현 비용이 크다.
성능을 위해 관계형 기반 기능을 아예 없애야하나? (비정규화를 통해 락 걸기를 최소화 해야하나?)

데이터가 많아져도 파티션 재분배가 필요없는 수평적 확장이 내장된 방식으로, 확장성 구조를 이용해 fault tolerance와 데이터 가용성도 확보하자 = HBase

1.3.3데이터베이스 (비)정규화

확장된 환경의 색다른 스키마 = DDI (Denormalization, Duplication, Intelligent Keys)

테이블을 두 개 이상 복제하여 스키마를 비정규화 (읽기시 추가 데이터 취합 필요없음)
관계형을 컬럼 지향형에 적합한 형태로 변환하는 기본 원리..9장에서 자세히 다루겠음.

shorturl: 단축url을 가짐.
click : 단축url의 클릭 카운터를 가짐.
user : 사용자 정보
연결된 페이지의 제목을 긁어와 url의 title에 저장.
같은 긴url이더라도 각자의 사용량 통계는 다르므로 shorturl의 별개항목으로 저장됨.
refshortid : 원본URL이 동일한 shorturl들의 통계를 보기위한 원본shorturl. ??


shorturl:단축url 저장. 사용량 통계 데이터도 저장. 별도 컬럼 패밀리에 다양한 시간 범위 저장.
url:장황한 텍스트를 압축해서 저장
user-shorturl:특정 사용자 소유의 단축Id를 빠르게 찾을 수 있는 룩업 테이블. 사용자의 홈페이지로 사용
user:사용자의 실제 세부정보

clicks테이블은 shorturl 테이블로 흡수. 통계를 위한 컬럼은 날짜를 키로 사용. 20110502같이 순차적으로 접근.
추가된 user-shorturl테이블은 외부키 관계를 대체.

데이터 정규화할 필요성을 없애주며, join 연산도 없애준다.
인텔리전트키를 이용하여 어디에, 어떻게 데이터를 저장할지 결정 내림.
천만개까지 확장하면서도 쓰기/읽기 성능 유지가 가능하다.

1.4 구성요소

HBase의 계보에 관한 배경지식
데이터 모델의 일반적 개념과 저장 API
고수준 구현 계층의 개요

1.4.1배경

구글의 GFS : 확장가능한 분산 파일 시스템
MapReduce : GFS와 조합으로 전체 검색 색인등 대용량 데이터 처리의 중추

미비한점 : 임의적이고 실시간에 준하는 데이터 접근기능
GFS는 수백만 개의 작은 파일 처리에 부적합
기본CRUD 기능의 단순한 API 사용 큰단위의 키범위나 전체 테이블 scan기능 추가.

빅테이블, 구조화된 데이터용 분산 저장 시스템
빅테이블은 거대하게 확장할 수 있도록 구조화된 데이터를 관리하는 분산 저장 시스템이다.
데이터는 수천 대의 범용 서버에 페타바이트급으로 확장된다.
...희소하고, 분산형이며, 영구 저장식 다차원 정렬맵이다.

HBase는 이 논문의 빅테이블 저장구조를 충실히 구현.(차이점은 부록F)

1.4.2테이블,로우,컬럼,셀

가장 기본적인 단위는 컬럼.
하나 이상의 컬럼이 모여 하나의 row를 만든다. row는 row key라는 유일한 주소를 가진다.
row가 다수 모이면 테이블. 컬럼은 여러개의 버전을 가질 수 있는데, 버전의 값은 각각 별도의 셀에 저장된다.

'각 셀의 다중 버전을 허용하여 추가적인 차원을 제공' RDBMS와 다른점.

예제1.1
hbase(main):001:0> scan 'table1'
ROW COLUMN+CELL
row-1 column=cf1:, timestamp=1297073325971 ...
row-10 column=cf1:, timestamp=1297073337383 ...
row-11 column=cf1:, timestamp=1297073340493 ...
row-2 column=cf1:, timestamp=1297073329851 ...
row-22 column=cf1:, timestamp=1297073344482 ...
row-3 column=cf1:, timestamp=1297073333504 ...
row-abc column=cf1:, timestamp=1297073349875 ...
7 row(s) in 0.1100 seconds

row의 정렬은 row key에 의해 사전식 정렬 (RDBMS의 PK같은기능)
row key는 바이트배열이며, HBase는 보조 색인 가능

row는 컬럼으로 이루어지고 컬럼은 컬럼패밀리로 그룹화 된다.
컬럼패밀리는 데이터를 의미적, 주제별 분류하게 해준다.
컬럼패밀리 안의 모든 컬럼은 HFile이라는 하나의 저수준 저장 파일에 함께 저장된다.

컬럼패밀리는 테이블이 생성될 때 정의되어야 하며, 빈번히 변경되지 말아야 하며, 수가 너무 많아도 안된다.
There are a few known shortcomings in the current implementation that force the count to be limited to the low tens, but in practice it is often a much smaller number (see Chapter 9 for details).
컬럼패밀리는 바이트가 아니라 출력가능한 문자여야 한다.

컬럼은 '패밀리:qualifier' qualifier는 바이트가능
컬럼패밀리와 달리 컬럼수는 제한이 없음. 수백만 컬럼도 가능. 컬럼값의 데이터 타입이나 길이제한없음.


태그를 붙여나가는 형식이고 NULL 저장의 비용이 없다....RDBMS와는 다르다...RDBMS와는...
태그를 통해 정보를 찾을수있다.

컬럼값(cell)은 타임스탬프를 갖는다.
내림차순 정렬이라 최근의 값을 먼저 읽을 수 있다. 최근값을 선호하는 읽기 유형에 최적화

SortedMap< // 테이블
	RowKey, List< // rowkey, 컬럼패밀리 리스트
		SortedMap< 
			Column, List< // 컬럼(키) : 값
				Value, Timestamp // 버전
			>
		>
	>
>


셀이 씌여질때의 타임 스탬프 tn을 사용하여 시간적 요소를 시각화


데이터가 다른 시점에 추가되고 여러 버전으로 존재하지만, 사용자가 row를 살펴볼때는
모든 컬럼과 각 값의 최신 버전, 즉 각 컬럼에서 가장 높은 tn을 갖는 값의 조합으로 보일 것이다.
(특정 타임 스탬프, 혹은 특정 타임스탬프 이전의 값 조회, 여러 버전의 값 조회 가능 - 3장)

row 데이터에 접근은 atomic 하다. 여러개의 row나 테이블에 걸친 그 이상의 원자성이나 트랜잭션 기능은 보장하지 않는다.
원자적 접근은 강력한 일관성에 기여하는데, 동시 다발적인 읽기 및 쓰기 연산이 row 하나의 상태에 대해 안전한 가정을 할 수 있기 때문이다. (영민생각: 이것 만으론 일반적인 RDBMS에서의 일관성에 비하면 isolation level이 너무 낮은게 아닌가)

1.4.3자동샤딩

region은 HBase 확장성 및 로드 밸린싱의 기본단위이다.
최초 테이블에 리전이 하나이다. 데이터가 늘어나면 설정된 크기를 넘으면 중간 row키를 기준으로 대략 동일한 크기의 두개의 리전을 생성
(예를 들어 서버당 리전개수는 10~1000개 , 리전 크기는 1~2G 수치는 서버의 처리성능에 따라 다름)
다른 시스템에서의 샤딩을 자동으로 해주는것 같을 것이다. 서버 고장시 복구, 서버 부하 분산도 같은 원리 이다.

자세한건 8장에서

1.4.4저장소API

테이블 및 컬럼 패밀리 생성, 삭제. 압축여부, 블록크기등 메타데이터 변경함수
값을 생성 삭제, row 키를 이용해 조회

'scan'은 로우의 특정 범위를 효과 적으로 조회하는 API이다. 반환될 컬럼이나 각 셀의 버전 개수를 제한할 수 있다.
필터로 컬럼을 비교할 수 있고, 시간범위로 버전선택가능

단일 로우 트랜잭션을 지원하는데, 원자성을 갖는 읽고-변경하고-쓰는 순차연산 가능(로우간, 테이블간 트랜잭션 제공안함)
셀 값은 카운터로 사용가능하다. 원자적갱신된다.분산 구조적 태생에도 불구하고 클라이언트에서 강력한 일관성을 갖는 순차적인 전역 카운터를 구현가능하다.

클라이언트 코드를 서버에서 실행가능한 옵션도 있다. 이 기능을 지원하는 서버측 프레임웍은 coprocessor라고 불리운다.(보조처리기) 이코드는 서버의 로컬데이터에 접근할 수 있고 경량 일괄처리 작업에 쓰인다. 연산자를 활용하여 표현식(expression)으로도 쓰인다. (0.91.0부터가능)

테이블을 맵리듀스 잡의 입력값으로 변환하여 타깃을 선출하는 래퍼(wrapper)를 제공한다.
SQL이 없어 선언적이지 않고 API를 통한 명령적이다. 주로 자바로 구현되지만, 다른 프로그래밍 언어에서 접근가능한 방법들이 있다.

1.4.5구현 (8장에 자세히한다고 함)

데이터는 HFile에 저장되는데 영구적이고, 정렬되며, 고정불편의 키 값/쌍의 맵이다.
이 파일은 연속적이고 블록에 대한 색인이 끝에 저장된다. 색인은 HFile이 열릴때 로드되어 메모리에 저장된다.
블록크기의 기본값은 64KB이다.

모든 HFile이 블록 색인을 갖고 있으므로 검색은 단 한번의 디스크 판독으로 가능.
검색하고자하는 키를 가질 것으로 예상되는 블록을 지정 -> 메모리의 블록 색인에서 이진 탐색 -> 디스크에서 블록을 읽어 실제 키를 얻음.

파일은 HDFS에 있음.

데이터 갱신되면 WAL(Write Ahead Log)에 씌어진다. 커밋로그라고 한다.
데이터는 이후 memstore에 저장된다.
메모리 상의 데이터가 설정된 최대값을 넘어서면 디스크에 HFile로 flush된다.
플러시 이후는 커밋 로그에서 플러시된 부분을 삭제할 수 있다. 멤스토어를 디스크로 플러시 하는 동안에도 읽기 쓰기 연산을 중단없이 수행 할 수 있다.
=>이래서 같은 블록에 올라오는 '집약성'이 중요하다.

저장 파일은 고정 불변으로 값을 삭제할 때 단순히 파일에서 키/값 쌍을 제거할 수는 없다.
대신 해당키가 삭제되었음을 나타내는 삭제 표시(툼스톤 마커라고 함)를 적어둔다.

읽기과정에서WAL은 사용되지 않는다. WAL은 오직 메모리에 저장된 데이터를 디스크에 쓰기 전에 서버가 고장 났을때의 복구를 위해 존재한다.

플러시하면 점점 많은 HFile이 생성되므로, 컴팩션을 이용해 파일들을 큰 파일로 병합하는 하우스키핑 기능이 존재한다.
부 컴팩션 , n-way merge를 수행하여 작은 파일의 내용을 그 개수는 적지만 더 큰 파일에 다시쓰는 방식으로 개수를 줄임. 정렬은 되어 있으므로 빠르고 디스크 IO만 사용
주 컴팩션 , 하나의 리전안의 컬럼 패밀리 하나를 구성하는 모든 파일을 새로운 파일 하나로 다시 쓰는 작업 수행. 키/값 쌍을 모두 탐색하므로 삭제 표시 달린 데이터 제거 가능. 만료값 삭제. 오래된 버전 삭제(영민:설정값이 있을거 같음)

이러한 설계는 LSM트리에서 온다. B-트리와 같은 구조로 배열된 다중 페이지 블록에 데이터를 저장한다.
컴팩션과 LSM트리 병합과는 약간 다르다.

클라이언트 라이브러리, 마스터서버 하나, 리전서버 다수 3개의 주요 구성요소가 있다.
마스터는 리전 서버에 리전을 할당하는데, 이 작업을 위해 '안전하고 고가용성을 보장하며 영구 저장식 분산형 조정 서비스' 주키퍼를 사용한다.


마스터는 리전 서버간 부하 분산 처리.
마스터는 컨트롤하므로 서버 부하는 가볍다. 추가적으로 테이블 및 컬럼 패밀리의 생성 같은 스키마 변경사항 및 메타데이터 작업을 수행한다.

리전 서버는 읽기 쓰기 작업을 하고 리전 분할도 한다.
클라이언트는 리전서버와 통신한다.

1.4.6정리

row 수십억개 * 컬럼 수백만개 * 버전 수천개 = 테라,페타바이트

테이블 스캔 O( n ), 로우키 탐색 데이터 변경 O( log n )

컬럼 지향 구조에서는 NULL을 저장하지 않으므로, 거대하고, 넓고, 희소한 테이블 설계이다.
row는 단 하나의 서버에서만 운용되므로 일관성이 강력하다. 다중 버전을 사용할 때와는 달리 충돌 회피할 수 있고 변경 이력을 유지 할 수 있다.

1.5 HBase : 하둡 데이터베이스

구글 빅테이블을 충실하게 구현. 하지만 미묘한 차이가 있다.

1.5.1역사

2007년 파워셋에서 만들어짐. 하둡 공헌 프로젝트의 일부로 그 이후 아파치 프로젝트.
하둡 버전과 연동하다가 독립함 0.20.x -> 0.89.x 0.90은 안정버전

1.5.2용어

빅테이블과 다른 용어확인가능하다.

1.5.3정리

앞의 '기준'으로 보면 HBase는 분산형, 영구 저장식, 엄격한 일관성, 입출력 채널의 포화도면에서 쓰기 준최적, 읽기탁월, 압축 제공.

보조색인제공, push-down predicate, 필터 제공(네트웍전송량 줄임)

선언적 SQL은 제공 안함. 트랜잭션지원 제한적.

부하이동, 장애처리 매끄럽고 투명. 확장기능이 내장, 클러스터는 live상태로 확장축소 가능. 클러스터 추가로 재분산 샤딩 없음.

문서정보

Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.