GreenplumDatabase
- greenplum은 구조적으로 병렬 아키텍처
1. Greenplum Fundamental Concepts
1) Greenplum Architecture
(0) 스케일업과 스케일 아웃
Scale up
- 시스템 리소스에 대한 요구가 증가하게 될 경우, 하나의 물리 서버의 리소스 크기(CPU, Memory)를 늘리는 방법
Scale Out - (Greenplum Architecture)
- 시스템 리소스에 대한 요구가 증가하게 될 경우, 여러 서버를 증설하는 방법
- 하나의 서버는 각 서버와 독립적으로 테스크를 수행
- Scale Out 구조의 GPDB를 정상적으로 동작하게 하려면 운영 방법에 대한 이해가 필요
[네트워크] 스케일 업(Scale-Up)과 스케일 아웃(Scale-Out)
이용자의 증가, 사업 확장 등 여러가지 이유로 더 많은 서버 용량과 성능이 필요할 때, 스케일 업과 스케일 아웃을 통해 시스템 확장이 가능 스케일 업(Scale Up) - 수직 확장 방식 - 하나의 서버 자
dheldh77.tistory.com
(1) Greenplum Architecture
- master host와 각 segment host로 나뉘어져 있음
- 각 segment instance 는 engine process
- engine process 단위로 병렬 처리
- 즉, 하나의 물리 host 안에 db engine process가 여러개 띄어져있고 각 istance는 병렬적으로 처리
- master는 segment host가 잘 동작하도록 관리
a. Master Host
- 시스템의 진입점(End User는 Master Host를 통해 접근)
- Listener process
- 모든 User Connection 관리
- 실행 계획을 세우고 세그먼트 호스트에 일을 시킴
b. interconnect
- 각 세그먼트 host의 통로 역활
- 필요에 따라 하나의 세그먼트 호스트에서 다른 세그먼트 호스트로 데이터를 넘길 필요가 있음
c. segment host
- 고유의 서버를 가지고 있음
- 일반적으로 엔드 유저가 직접 접근하는 케이스는 없음
*쿼리 실행 시나리오
Master Host
- 요청이 들어올 경우, master host 도착
- parser를 통해 syntax 검사
- optimizer를 통해 실행 계획을 세움
- Query Dispatcher를 통해 실행 계획을 각 Segment Host에 전달
Segment Host
- 각 Segment Host는 본인이 가지고 있는 데이터에 대해 쿼리 실행
- 각 segment instance에 별도의 실행계획을 던지는 것이 아님
- 하나의 플랜을 가지고 동시에 일을 잘 처리하기 위해선 데이터를 골고루 잘 분산 시켜야함 (Distributed by)
System Catalog
- 테이블의 정보를 가지고 실행계획을 세움
- 테이블 정보는 어디서 얻을 것인가? (master에도, 각 segment host에도 카탈로그 정보는 존재)
- 실행 계획 자체를 세우는 시간을 줄이기 위해서 master host에 있는 catalog만 참고
- segment host의 catalog를 잘 반영하기위해서 수행하는 작업이 통계 정보 갱신 (analyze)
Distributed Transaction Management
- 분산 트랜잭션 관리자를 통해 전체가 Commit 되어야 하나의 트랜잭션으로 판단
- 어느 한 세그먼트가 액세스가 되지 않는다면 그 트랜잭션은 정상적으로 수행되지 않음
- 이러한 처리들을 분산 트랜잭션 관리자가 수행 -> 데이터 무결성. 정합성
2) High Availability
(1) Master
a. 전통적인 Master Mirroring
- 별도의 백업 서버를 준비
- Master 서버가 장애가 발생할 경우, 백업 서버를 실행
b. Standby Mirroring
- 동기화 작업 수행
- Master Server가 장애가 발생할 경우 역할을 바꿈
(2) Segment
a. mirroring(optional)
- 한 세그먼트 호스트의 세그먼트 인스턴스를 다른 세그먼트 호스트의 인스턴스에 복제
- 한 인스턴스가 죽었을 때, 다시 살린 뒤 Recovery 프로세스(동기화 작업)가 필요
3) Database Structure & Access Control
(1) Database Structure
a. Database
- GP는 Mutiple databases 구조
- GP에서 하나의 클러스터 안에 여러개의 DB를 만들 수 있음
- database 안의 데이터들은 서로 공유할 수 없음
- default로 template0, template1, postgres이 있는데 template0, template1은 메타 데이터베이스
- GPDB의 데이터 오브젝는 세그먼트 호스트에 걸쳐서 존재 -> 특정 데이터 베이스가 특정 세그먼트 호스트에 존재하는 것이 아님
b. Schemas
- Database 내에서 논리적으로 데이터를 조직화하는 단위
- 오라클에서 스키마는 유저와 관련이 있지만 greenplum은 유저와 전혀 관련이 없음
- 하나의 Schema에는 테이블, 인덱스 등의 데이터 오브젝트를 포함
- 다른 스키마 내에 똑같은 테이블 명이 존재할 수 있음. 따라서 쿼리를 실행할 때, 스키마.테이블명으로 작성
- 'search path'를 통해 스키마명이 지정되지 않은 쿼리를 특정 스키마의 테이블을 가르치도록 지정해줄 수 있음
- 'search path'는 세션 단위로 고정이 됨. 그게 불편하면 데이터베이스 단위로 설정해줄 수 있음
- connection(client) = session(server) < transaction
(2) Access Control
a. Security
b. Roles and Privileges
- 로그인할 수 있으면 유저, 할 수 없으면 그룹
- Role은 데이터베이스에서 생성되는 오브젝트 중에 하나이기 때문에 OS 단의 유저와 그룹과는 무관
c. User Roles
- 로그인 가능한 Role
- CREATE ROLE, ALTER ROLE
d. Superuser
- 다른 유저에게 Superuser role을 줄 수 있음
e. Group Roles
- 유저 간의 묶음
- 권한 관리를 그룹 단위로 처리 가능
4) Host Base Authentication
(1) pg_hba.conf
- 사용자 세션에 대한 권한 관리
- connection 처리를 해줄 거인지에 대한 데이터를 해당 파일이 가지고 있음(파일로 관리)
- $MASTER_DATA_DIRECTORY 안에 저장되어 있음
- >$ gpstop -u : configuration을 reload하는 command
5) Tables
- DW Engine에서는 Fereign key에 대한 제약사항을 걸지 않는다.
(1) Create table : Storage model
a. Heap Storage (default)
- Row Based
- 빈번한 Insert, update, delete가 발생
- Primary Key, Unique Index를 만들 수 있음
- GP 6 이후 row 단위 locking이 가능
b. Append-Optimized Storage
- Row Based
- Column Based
- Compression : Disk I/O를 줄이는데 목적. Disk I/O에 발생하는 work load를 줄이고, Memory, CPU에 더 많은 Load를 주기 위함
- 빈번한 변경 가공이 발생하지 않는 데이터
- Primary Key, Unique Index를 만들지 못함
c. compress를 사용하는 테이블
- Disk I/O가 많이 발생하는 테이블
- 일단은 Primary Key나 Unique Index가 필요하지 않는 경우 적용해볼 것
- 단, storage policy를 적용한 테이블의 경우, alter table 방식을 적용할 수 없고 테이블 drop 후, 새로 생성해야함
d. 테이블 생성 -> default policy 지정 가능
- Object level
- Role level
- Database level
- System level
6) Distribution
(1) Distribution Overview
- GPDB의 모든 테이블은 Distribution Key를 기준을 모두 분산 저장됨
- 하나 이상의 컬럼의 해시값으로 세그먼트 단위로 분산
- 높은 카디널리티(특정 데이터의 유니크 집합의 개수)를 가질 수 있음
- 즉, 각 세그먼트에 데이터를 골고루 분산시키기위한 목적
a. distributed by (column1, [column2])
- 분산키로 컬럼 조합의 해시값을 사용
- 명시적으로 컬럼을 지정하지 않으면 묵시적으로 기본키를 분산키로 사용
b. distributed by randomly
- 어떤 컬럼을 기준으로 애매할 때 사용
- 데이터를 RR(Round Robin) 방식으로 골고루 분산 시킬 수 있다
- 대량의 데이터에 대해서는 권장하지 않음
c. distributed by replicated
- 각 세그먼트에 똑같은 데이터를 복제해서 저장
(2) Data Distribution : The key of parallelism
- 분산의 목적을 각 세그먼트가 테스크를 효율적으로 병렬처리하기 위함
'CS > Database' 카테고리의 다른 글
| [GPDB Administrator 교육 2일차] (0) | 2022.12.14 |
|---|---|
| [데이터베이스] 객체관계매핑(ORM, Object-Relational Mapping) (0) | 2020.06.24 |
| [데이터베이스] Statement와 Prepared Statement (0) | 2020.06.24 |
| [데이터베이스] 인덱스(Index) (0) | 2020.06.24 |
| [데이터베이스] 샤딩(Sharding) (0) | 2020.06.24 |
댓글