Vertica 특징

DW용 DBMS 중 하나인 Vertica에 대한 특징 정리

Vertica 주요 특징

• MPP (Massively Parallel Processing)
  • 별도 마스터 노드 필요 없이 모든 노드에서 병렬로 쿼리 실행
  • 선형적으로 scale-out, 더 빠른 성능 또는 더 많은 사용자 지원
  • 각 노드들이 동시에 각자의 리소스를 가지는 shared-nothing (?) 아키텍처
• Columnar Storage
  • 필요한 데이터만(쿼리에서 참조된) 읽어서, 기존 ROW 기반 스토리지 시스템에 비해 쿼리 속도 향상
• Advanced Data Encoding 및 Compression
  • 컬럼별 고급 압축 인코딩 및 알고리즘 적용하여 Disk 공간 절감 → 디스크 I/O 비용 감소로 성능 향상
    • 적절한 인코딩 방법
      • 데이터 type, 데이터 카디널리티, 데이터 정렬 여부 등
      • 버티카는 기본적으로 type별 인코딩 방법을 제공함
    • 데이터 처리는 필요한 컬럼만 가지고 와서, 압축만 해제한 후 인코딩 된 상태로 수행

 

 

 

 

• Optimized Projections
  • Projection 이라는 최적화된 형식과 구조로 데이터를 저장하여 인덱스 불필요
• Hybird 스토리지
  • WOS/ROS
    • 9.3버전 부터 WOS는 Deprecate
• HA (High Availability)
  • 멀티노드 클러스터 구성(최소 3node)에서 데이터 복제본이 인접하고 있는 노드에 저장되고 있으므로, 특정 노드에 이상이 생겨도 서비스 지속 가능
• Automatic Database Design
  • 데이터베이스 설계에 대한 권장사항을 가이드하는 DBD라는 유틸 제공
• I/O 최적화 아키텍쳐
  • 버티카는 S/W전용 제품, 하드웨어와 분리된 소프트웨어 영구 라이선스 (DW 어플라이언스 제품들과의 차이)
  • 모든 DB는 I/O를 얼마나 최적화 시키냐에 따라 성능이 좌우함. 그래서 다수의 DW 제품들이 고가의 하드웨어 기반 아키텍쳐를 채택, but 버티카만의 독자적인 S/W기술로 I/O 최적화 되어 있다고 함
• 무중단 back-up 가능, 빠른 통계 작업 수행

Projection

• 실제 테이블 데이터가 저장되는 오브젝트
• 버티카 Table(anchor table) 에는 논리적인 구조를 정의만 함, 실제 데이터를 저장하는 것은 Projection이라는 물리적인 구조에 저장
  • 테이블과 다른 정렬순서로 데이터를 저장 할 수 있다.
  • order by 설정이 어떻게 되어 있느냐에 따라, 옵티마이저가 최적의 프로젝션을 선택
  • projection의 order by 설정은 오름차순(asc)으로만 지정
    • 내림차순으로 조회하면 정렬 단계 추가
• 기본 Projection 유형
  • Super projection (xxx_b0)
    • anchor table의 모든 컬럼 포함 (최소 하나 이상 존재해야함)
  • Query-specific projection
    • anchor table 중 일부 컬럼을 포함하는 프로젝션 (쿼리 성능 최적화를 위해)
  • Aggregate projection
    • SUM, COUNT 와 같은 식 또는 집계 함수가 포함된 쿼리를 이용해 미리 집계한 데이터를 저장하는 프로젝션
      • 이런게 있었구나..,
  • Buddy projection (xxx_b1)
    • 프로젝션 속성의 KSAFE로 데이터를 이중화 또는 삼중화 할때 다른 노드에 복제되는 프로젝션 (segmented projection 일 경우)

 

 

 

 

 

 

 

• 하나의 테이블에 2~4개 이내로 만들 것을 권장 (super 1~2개, Query-specific 2~3개 이내)
• 각 projection에는 개별적으로 실제 데이터가 저장되므로, 무분별한 생성은 적재 속도에 영향, 디스크 공간 비효율적 사용
• Projection Segmentation (분산)
  • SGMENTED BY HASH (C1,C2) ALL NODES;
  • 팩트 테이블과 같은 큰 테이블 데이터를 노드 전체에 고르게 분산 시킴
  • 노드별로 데이터를 고르게 갖고 있어 쿼리 실행시 부하를 여러 노드로 분산 시킬 수 있다,,
    • [ ] 사용자 접속하는 노드에 부하가 몰리는건,, segmentation 컬럼 설정이 잘못되어서 그런가..
  • 동일한 Segment key(분산 key)를 가진 테이블간의 조인 성능이 우수
• Projection Replication (복제)
  • UNSEGMENTED ALL NODES;
    • UNSEGMENTED NODE 노드3 과 같이 특정 노드에만 데이터 저장도 가능
  • 모든 노드들이 동일한 데이터 복사본을 가지고 있는 것
  • 디멘젼 테이블과 같이 작은 테이블에 쓰이며, join시 유용 (10만건 이하)
  • Local Join
  • 디멘젼 테이블이 모든 노드에 복제 되어 있는 경우, projection 간의 조인은 각 노드에서 로컬로 수행되므로 쿼리 성능 향상

table과 projection object 계층구조

• Table object
  • 버티카는 논리적인 개념으로 table을 제공
  • 테이블에 대해 쿼리가 실행되면 Vertica는 최적으로 실행하는 projection을 선택

vertica projection 구조

데이터 저장 구조

(이미지 출처 - https://x2wizard.github.io/ )

Hybrid Storage

• WOS(Write Optimized Store) - Trickle Load
  • 메모리에 상주하는 데이터 저장소
  • 디스크 조각화 감소(ROS컨테이너) 및 적재 프로세스 빨라짐 소량의 데이터를 지속적으로 적재하는 경우
  • In memory, Unencoded, Unsorted, Uncompressed
  • 크기는 노드 메모리의 25% 또는 2GB 중 작은 것으로 제한됨
    • 이 크기를 초과하면 데이터가 ROS로 자동으로 spill 된다
  • 9.3 버전부터는 없어짐
• ROS(Read Optimized Store) - Bulk Load
  • 디스크에 상주하는 데이터 저장소
  • 대량 데이터 적재시 ROS에 직접 접근하면 훨씬 속도가 빠름
    • Direct DML 활용
    • COPY, UPDATE, DELETE, INSERT
    • 단, 빈번한 Direct DML은 ROS 컨테이너가 급증하여 ROS Pushback 발생의 원인이 됨
      • 노드별 Projection당 최대 1024개의 ROS 컨테이너를 가질 수 있음, 이 최대 값을 넘어설 경우 오류 발생
        • ROS Pushback 재현 예시
          • 한 건씩 ROS에 insert (direct 구문 사용)를 수행하여 1025건을 처리시 마지막 건에서 ROS pushback
            • v9.2 부터 MergeOutInterval 값에 관계 없이 필요에 따라 Tuple Mover가 mergeout 실행하도록 개선됨

 

 

 

 

Tuple mover

• Tuple mover 기능
  • Moveout : WOS → ROS
    • 디폴트 MoveOutInterval은 300sec (configuration parameter 에 의해 설정)
  • Mergeout : 소형 ROS 컨테이너 들을 합쳐서 큰 ROS 컨테이너로 결합
    • 많은 ROS 컨테이너에서 쿼리를 처리하면 속도 저하 될 수 있기에, 여러 컨테이너를 더 적은 컨테이너로 병합
    • 삭제된 데이터 purge
    • 디폴트 MergeOutInterval은 600sec
• 백그라운드에서 자동 실행 , 수동 실행 필요시 DO_TM_TASK()함수를 사용

Query Execution Workflow

• 버티카가 MPP를 구현하는 방법
  • 최초에 쿼리를 접수한 노드가 initiator 노드가 되고, 쿼리를 실행하는 노드들이 executor 노드가 된다. 모든 노드가 실행계획에 따라 각자의 메모리, CPU, 디스크를 가지고 병렬로 처리한다.

projection 추가 생성 절차

• 기존 테이블에 쿼리 튜닝 등의 목적으로 신규 projection 추가 생성 시 (온라인으로 가능)

1. 추가 projection 생성
2. refresh()함수를 통한 projection 동기화
3. make_ahm_now()함수를 통한 epoch시점 최신화(기존 projection 삭제시)
4. drop projection 문을 통해 삭제하고자 하는 projection 삭제(기존 projection 삭제시)

COPY 문

• 대량의 데이터를 DB로 로딩하기 위해 쿼리 레벨에서 제공하는 COPY문

--data-source가 버티카 클러스터에 존재하는 경우
COPY target-table FROM data-source ;

--data-source가 클라이언트에 존재하는 경우
COPY target-table FROM LOCAL data-source ;

• 파일 형식은 UTF8만 지원
• 그밖에 구문 옵션 많음

delete table 수행 절차

• 버티카 아키텍쳐 특성상 한번 기록한 데이터 파일은 변경하지 않는다
  • UPDATE, MERGE = [DELETE + INSERT] 로 내부적으로 취급
• delete시 곧바로 삭제되는 것이 아니라 DELETE_VECTOR에 기록하고 삭제한 레코드에는 삭제되었다고 mark 된다. (.gt파일에 마크?)
  • 삭제 mark된 데이터를 숨겨야 하는 추가 단계는 쿼리 응답시간을 증가 시킴
• DELETE_VECTOR는 데이터가 제거된 장소(.gt파일의 위치)와 시점(epoch)을 기록하는 튜플집합이다.
• DELETE_VECTOR의 별도 관리 및 버티카 성능상 delete문을 통한 여러개의 소량 데이터 삭제는 권장되지 않는다. (일괄 삭제를 권장)