버티카의 독창성

Vertica는 대량의 데이터를 고속으로 분석 할 수있는 열(컬럼) 지향 데이터베이스입니다. 

요즘 수많은 열(컬럼) 지향 데이터베이스 제품이 출시되고 있습니다. 

또한 기존의 행 지향 데이터베이스도 열 지향 기능이 추가되기 시작해(EXADATA의 스토리지 영역)
지금 열 지향 데이터베이스는 당연하게 사용되는 시대가되었습니다. 

단,  어떤 제품 (서비스)을 선택해야할지 고민스러운 상황이되고 있습니다. 

이번장 에서는 Vertica와  일반적인 열 지향 데이터베이스와의 차이 및 특수성을 소개합니다.

완전히 당연하게 된 열 지향 데이터베이스

여러분은 Vertica 라는 데이터베이스를 아십니까? 

Vertica는 대량의 데이터를 분석하는 등
정보계 시스템에서 사용되는 데이터베이스에서 '열 방향(컬럼나)"로 분류됩니다. 

가장 유명한 것이 2012 년 미국 대통령 선거에서의 사례 에서
민주당의 버락 오바마를 지원하는 Web 사이트 

"Obama for America"의 데이터 분석에 Vertica가 사용되었습니다. 

그리고 빅 데이터 분석뿐만 아니라 이른바 기업의 DWH로의 활용 실적도 많이 있습니다. 

"지금 무슨 일이 일어나고 있는지" "앞으로 무슨 일이 일어날 것인가?"라는 

전략적이고 신속한 의사 결정을 지원하는 것이 Vertica 데이터베이스입니다.

단, 열 지향하는 구조 자체는 더 이상 희귀 한 것은 아닙니다. 

몇 년 전이라면 확실히 "행 지향보다 ○○ 배 빠른 '같은 키워드가 선전했지만 

현재는 시장의 성숙과 함께 행 지향 데이터베이스가 열 지향 기능을 도입하거나
클라우드에서 열 지향 데이터베이스를 PaaS로 제공하는 플레이어가 증가하고 왔습니다. 

한때 주류였던 DWH 전용 어플라이언스형을 도입 한 기업도 시대의 변화와 함께
다시 제품을 선정하는 움직임이 늘고있는 것처럼 느낍니다.

이러한 선택의 증가는 사용자들에게 반가운 일이지만, 

반대로 제품이나 서비스가 너무 증가해서
일반 개인 유저들은 좋고 나쁨과 특징을 이해하기가 어려워지고 있습니다. 

예를 들어, 열 지향 데이터베이스 제품 소개 프리젠테이션 자료를 보면
대부분 비슷한 특징이 적혀 있기 때문에, 카탈로그 스펙에서의 비교는 매우 어렵습니다. 

벤치 마크 결과의 공개를 금지하는 제품이 대부분이고, 가격이 비공개 인 경우도 있습니다. 

가뜩이나 정보계 시스템은
정당한 투자 비용을 산출하여 예산화하는 것이 어려운 것으로 알려져 있는데, 

제한된 정보로 검토를 진행시켜 나가면 제품선정까지의 여정은 쉽지  않을 것 으로 보입니다. 

버티카의 특장점 몇가지는 다음과 같습니다.

Write Once 아키텍처

Vertica는 한 번 쓰기를 한 영역에 대해 업데이트를하지않는
Write Once라는 아키텍처를 채용하고 있습니다.
이는 단순한 트랜잭션 관리를 실현하고 있습니다.
DML 처리를 한 경우에는 각각 다음과 같은 처리가 내부적으로 실행됩니다.

INSERT의 경우

1) 대상 테이블에 대해 INSERT 문을 실행하면 밑바닥 부분에 행이 추가됩니다.

DELETE의 경우

1) 대상 테이블에 DELETE 문을 발행하면 해당 행은 논리젹으로 삭제됩니다. 

2) 논리 삭제 된 데이터는 정기적으로 물리 삭제됩니다. 　

  ※ 논리 삭제는 데이터를 남긴 채 해당 행을 "Deleted"로 표시하는 동작입니다.

UPDATE의 경우

1) 대상 테이블에 대해 UPDATE 문을 발행합니다. 

2) 갱신 대상의 행을 직접 업데이트하지 않고 업데이트 된 데이터를
   새로운 행으로 추가 (INSERT)합니다. 

3) 갱신 대상의 행에 대해서는 논리 삭제 (DELETE)를 실시합니다. 

4) 논리 삭제 된 데이터는 정기적으로 물리 삭제됩니다. 　

  ※ 논리 삭제는 데이터를 남긴 채 해당 행을 "Deleted"로 표시하는 동작입니다.

Projection 

Vertica 에서 Table은 논리적인 구조 입니다 .

물리적으로 저장되는 그리고 다른 dbms에는 없는 Projection 이라는 개념 및 실체가 있습니다.

(보통 dbms는 Table에 데이터를 물리적으로 저장합니다)

저도 처음에 이개념때문에 엄청 혼란스러웠는데요.

결론적으로 말씀드리면 일반적인 사용자들은 세부적인 내용을 알지못하더라도 크게 무방하나..

실은 성능개선과 같은 작업을 할 때 매우매우매우매우매우*100 중요한 참조정보가 되는 객체 입니다.

출처는 it월드http://www.itworld.co.kr/techlibrary (백서를 받아보기 위해 내 귀중한 개인정보를....)

해당 화면만 봐서는 딱 와닫는 느낌은 없습니다.(개인정보 얻어간거치고는 자료가 빈약하네요.)

그냥 열단위로 저장이 된다 거나 노드별(서버)로 나누어 저장된다 만 표현되어 

분산처리로 시간을 단축시킬 수도 있겠다 까지는 판단이 될거같습니다.

어떻게 분산시키는게 좋은지 잘못분산시키면 어떻게 되는지에 대해서는 언급이 없습니다.

Projection의 분산 스타일에 따라 컴퓨팅 노드에 분산합니다. 

쿼리를 실행하면 필요에 따라 결합 및 집계를 수행하는 쿼리 최적화 프로그램에서
(흔히 말하는 옵티마이저) 다시 컴퓨팅 노드에  분산처리하는 단계가 추가 될 수도 있습니다. 

Projection 분산 스타일의 선택은 쿼리를 실행하기 전에 데이터를 원하는 위치에 배치하고 유지해서 

추가 분산 단계의 영향을 최소화하는것이 좋습니다.

Vertica에서 데이터 분산의 원칙을 나타내고,
각 Projection에 적합한 분산 스타일을 선택하는 방법에 대해 설명합니다.

데이터 분산의 개념

Vertica 클러스터와 노드

Vertica 클러스터는 노드(서버)의 집합입니다. 

클러스터의 각 노드는 자신의 운영 체제 전용 메모리 및 전용 디스크 스토리지를 제공합니다. 

접속한 노드가 마스터노드 이며 다른 컴퓨팅 노드 에 데이터를 분산 및 쿼리 처리 작업을 관리합니다.

(다른 제품들은 별도의 리더노드 혹은 마스터노드가 있더군요)

컴퓨팅 노드의 디스크 스토리지는 하나이상의 디스크로 구성 되어 있습니다. 

클러스터에 속한 노드는
모두 병렬 쿼리 실행에 관여하고 최대한 균등하게 분산 된 데이터를 처리합니다. 

데이터 분산의 목표

데이터 분산은 다음의 두 가지 주요 목표를 설정됩니다.

클러스터 노드간에 워크로드를 균등하게 분산시키는 것. 

고르지 못한 분산이 이루어지면 (데이터 분산 스큐)
일부 노드의 작업량이 다른 노드보다 많아 전체적인 응답속도가 저하됩니다.

쿼리 실행중인 데이터 이동을 최소화한다. 

결합 또는 집계에 관여하는 행이 다른 테이블의 조인 열(컬럼)과 같은 노드에 있으면
쿼리 실행 중에 재 분산해야하는 데이터의 양은 없거나 많지 않을 것입니다.

어떤 분산 전략을 선택하냐에 따라 스토리지 요구 사항,
데이터로드 및 유지 관리에 커다란 영향을 줄 수 있습니다. 

각 테이블에 최선의 분산 스타일을 선택하여 데이터를 균등하게 분산하고
시스템 전체의 성능을 크게 향상시킬 수 있습니다.

분산 스타일

Projection 은 전체노드에 동일한 데이터를 저장하는 unsegment 방식과
특정 컬럼기준으로 데이터를 분산시키는 segment 방식등  2가지의 분산 스타일을 지원합니다.  

unsegment 방식

테이블 전체 데이터가 모든 노드에 복사됩니다. .

unsegment 방식은 클러스터의 노드 수만큼 필요한 스토리지가 증가하므로
데이터를로드하거나 갱신등 여러 테이블에 DML 작업을 할 때 더 많은 시간이 소요됩니다. 

unsegment 방식은 비교적 이동이 적은 테이블,
즉 갱신 빈도가 낮고 업데이트 범위가 넓지 않은 테이블에 적합합니다. 

segment 방식

특정 열(컬럼)에 포함 된 값에 따라 이루어집니다.
일치하는 특정 열(컬럼)값을 동일한 노드에 저장합니다. 

주로 대용량 Table에 적용을 합니다(Fact Table)

segment 정보를 확인하기위한 방법중 
" select export_objects('','스키마.오브젝트명');  " 구문을 사용하면

DDL 과 함께 segment 방식을 추출할 수 있습니다.

Segment 방식을 그림으로 표현하면 다음과 같습니다.

4개의 컬럼중 회원번호로 데이터를 분산저장 하도록 지정[ HASH(회원번호) 절] 

균등하게 저장된다는 가정하에 6건의 데이터를 각노드당 2건씩 분산저장한 모습입니다.
(실제 기업 데이터는 더 많겠죠..)

다른 MPP 제품도(예들 들어 아마존의 red shift)  도 비슷하거나 같은 개념을 가지고 있지만 

차이점이 있다면

첫번째 테이블은 논리적인객체이고 프로젝션이 실제 물리적인 객체다 라는점
( 이것만 가지고는 큰차이를 느낄 수 없지만.) 

두번째는 프로젝션이 물리적인 객체이기 때문에
하나의 테이블에 여러 형태의 프로젝션을 구성할 수 있다는 겁니다.

두번째의 이유때문에 위의 그림에서 회원번호로 분산한 프로젝션 만아니라
SQL 형태에 따라 이름,혹은 나이등 다른컬럼을중심으로 그에 맞는 프로젝션을 구성 할 수가 있습니다.(이게 성능에 어마어마한 영향을 주는 요소입니다.)

데이터 재분배

테이블에 데이터를로드하면 해당 테이블의 
분산 스타일(Projection 구성)에 따라 데이터의 행을 각 노드로 분산합니다. 

쿼리 계획의 일환으로 쿼리 최적화 프로그램은 쿼리를 최적화하는 데 필요한 Projection을 결정합니다. 

그 후 쿼리 실행 중에 데이터가 물리적으로 이동 (즉 재 분산)하거나 자신의 서버에서 처리 됩니다. 

재분배는 결합하는 특정 행을 전송하거나 테이블 전체를 모든 노드에 브로드 캐스트 할 수 있습니다.

데이터 재 분배는 쿼리 비용의 상당 부분을 차지할 가능성이 있고 

또한 재분배에 의해 생성되는 네트워크 트래픽이 다른 데이터 작업 처리에 영향을 미치거나 
시스템 전체의 성능저하를 불러올 수 있습니다. 
(그럼에도 위와 같은 작업을 하는이유는 각각의 레코드들이 대상을 찾기위해 노드간 여기저기 둘러보는것을 막기위함 입니다.) 

먼저 데이터를 어떻게 배치하면 가장 효과적인지 예측하여 구성하면 
데이터 재분배의 영향을 최소화 할 수 있습니다.

 

Hybrid 스토리지 아키텍처 

OLTP 제품들이 DW 제품군 들에게 공격하는것 중에 하나가 OLTP를 지원하지 않는다는겁니다.

그약점을 보완하고자 WOS영역과 ROS영역으로 나누어진 저장방식을 가지고 있습니다.

이 둘간의 데이터 병합등은 TUPLE MOVER라는 프로세스가 처리를해줍니다.

WOS를 사용하더라도 일반적인 OLTP업무자체는 무리라고 보여지고 어느정도 준 실시간 혹은 

작은단위 작업처리는 WOS에서 하는것이 성능 및 TUPLE MOVER등의 부하를 줄여줄 수 있습니다.

https://vertica.tistory.com/45 부분도 같이 보시면 좋을 것 같습니다.(작은단위의 파일을 최대한 덜 생성하려고 노력하는것 같습니다.)

TUPLE MOVER :  Vertica의 비동기 프로세서 

WOS -> ROS :
WOS(메모리영역)에서 저장되는 구조는 전통적인 RDBMS처럼 record 형태이며 비압축되어 있습니다.

분석을위해 대량의 SQL(Select)를 사용할때 전체 컬럼을 읽는 경우는 적기때문에

TUPLE MOVER는 특정시간마다(기본값5분) record 형태의 데이터를
컬럼단위로 분리하고 ROS에 내려씁니다.

이것을 Vertica 에서는 MOVEOUT 이라고 합니다.

ROS -> ROS :
위에 Write Once 아키텍처에서 설명하였지만 버티카는 파일을 한번쓰면 수정하지 않습니다(하둡처럼)

앞만보고 달리는 말과 같죠.. 

그래서 ROS의 파일갯수는 계속적으로 늘어나게 됩니다.

이걸 관리하지 않는다면 데이터를 읽어올때 많은 파일들을 읽어야 원하는 결과집합을 얻게되겠죠.

그러한 불합리함을 해소하고자 TUPLE MOVER는 특정시간마다(기본값10분)
ROS 를병합하여 새로운 파일을 생성하고 기존파일을 지우는 작업을 합니다.
이것을 Vertica 에서는 MERGEOUT 이라고 합니다.

  

그외에도 여러가지가 있지만 위에 나열한 부분들에 파생되는 부분이 있고 

스크롤이 길어져서 설명 충 소리를 들을 수 있으므로 다른 페이지에 내용을 넣도록 하겠습니다.

감사합니다.