Gpdb best practices v a01 20150313

© Copyright 2014 Pivotal. All rights reserved.© Copyright 2014 Pivotal. All rights reserved.
PIVOTAL
GREENPLUM DATABASE
BEST PRACTICES
2015. 03. 18
LEE, SANGHEE
SR. FIELD ENGINNER
PIVOTAL KOREA

© Copyright 2014 Pivotal. All rights reserved.
목차
1. INTRODUCTION
2. Data Model
3. Heap and AO Storage
4. Row and Column Storage
5. Compression
6. Distributions
7. Memory Management
8. Indexes
9. Partitioning
10. Vacuum
11. Loading
12. Resource Queues
13. Analyze
14. DATA TYPES
15. Local (co-located) Joins
16. Data Skew
17. Processing Skew
18. 기타 고려 사항

INTRODUCTION
 Greenplum database(GPDB)의 모범 사례에 대한 설명
 경험을 통해 발견되고 안정적으로 입증된 내용으로 기반
 Greenplum을 최적의 제품으로 사용할 수 있도록 지원하기 목적
- GPDB 상세 기능은 Greenplum 매뉴얼을 참조를 참조
 모범 사례를 학습함으로써 Greenplum Database를 이용한 프로젝트에서
성공적으로 완료 하기 위한 가이드
 원본 문서 : http://gpdb.docs.pivotal.io/gpdb-434.html

Data Model
 GPDB는 분석을 위한 MPP shared nothing database
- 고도로 정규화되고, 트랜잭션 처리를 위한 SMP 데이터베이스와는
다름.
- GPDB는 최상의 성능을 내기 위해서는 MPP 분석 처리를 위하여
비정규화된 스키마 설계 등가 필요합니다.
- Ex) Star schema, snowflake schema
- 대용량 Fact 테이블, 작은 dimension 테이블
 경험을 통해 발견되고 안정적으로 입증된 내용으로 기반
 테이블간의 조인 발생 컬럼은 동일한 데이터 타입으로 생성

Heap and AO(Append Only) Storage
 Heap / Append only 테이블 사용 구분
- 반복적인 배치와 Row 단위의 DML(update, delete, insert) 발생 시
HEAP 테이블 적용
- Concurrent update, delete, insert 발생 시 Heap 테이블 적용
- Row 단위의 INSERT/UDATE/DELTE 발생 되는 경우 AO 테이블
절대 금지
- Concurrent Batch UPDATE, DELETE 발생되는 경우 AO 테이블
절대 금지( 단, Concurrent INSERT 는 사용해도 됨.)
- AO 테이블에서 update, delete 되었을 때 해당 공간 recover, reuse
되지 않음.

Row and Column Oriented Storage
 Row / Column Oriented storage 사용 구분
 Row Oriented storage 사용
- 반복적인 update 트랜잭션 시와 빈번한 insert 작업이 발생될 경우
- 빈번하게 access 될 때 적용
- SELECT 시 많은 컬럼의 데이터를 가지고 올 때
- 일반적인 목적과 Mixed Workload 처리시
 Column Oriented storage 사용
- 데이터 저장 시 모든 컬럼이 파일로 쪼개어짐
- 대용량 테이블 일 때 고려 대상
- 자주 Access 되지 않을 때 적용
- 작은 개수의 컬럼으로 부터 select 할 때와 aggregation 이용 시
- Row 단위에서 한 개 컬럼의 데이터만 주기적으로 update되는 경우

Compression - 압축
 대용량의 AO 테이블, 파티션 테이블에 대해서 I/O 향상을 위할 때 압축 사용
 데이터 수준에서 압축율 적용
 압축율은 시간과 CPU cycle 을 고려하여 압축율 고려
 파티션 테이블일 경우 파티션 추가할 때에는 반드시 압출율을 정의해야 함.
 고객사의 데이터에 따라 압축 타입 및 압축 레벨에 대해서 테스트 필요

Distributions - 분산키
 MPP 기반의 DBMS 이기 때문에 데이터 분산이 가장 중요한 인자 임.
 명시적으로 모든 테이블에 대해서는 컬럼, 임의의 분포 정의
- 절대로 기본값을 사용 금지.
 데이터가 균등하게 모든 세그먼트에 걸치도록 데이터를 배포하는 하나의 열을 사용(만약 분산이 제대로
되지 않으면 여러 개 컬럼으로 분산키를 잡음)
 사용 금지 컬럼
- 쿼리의 WHERE 절에 사용되는 열을 가급적 사용 금지
- 날짜, 타임 스탬프 열 사용 자제
 동일한 컬럼에 대해서 분산키 및 파티션 키를 동시에 사용 절대 금지
 Local 조인이 발생하도록 유인 : 대용양 테이블과 조인 발생 시 특히 유의
- 일부의 경우에는 broadcast motion 이 redistribution motion 보다 빠름.
 최기 데이터 적재 및 Incremental Loads 후 분산도 검증 필요
 SKEW 가 발생되지 않는지 반드시 확인
 분산키를 Randomly 으로 했을 때 round robin distribution 방식은 아님. 하지만 10% 미만의 편차를 가짐

Memory Management
 OS 커널 설정
- /etc/sysctl.conf의 vm.overcommit_memory = 2 로 설정
- 거대한 pages 사용하지 않도록 OS 구성
 Database 레벨 메모리 설정 : gp_vmem_protect_limit
- 인스턴스 메모리 최대값 설정은 gp_vmem_protect_limit 파라미터 사용
- gp_vmem_protect_limit 를 너무 높거나 시스템 물리적인 초과 절대 금지
- gp_vmem_protect_limit 설정 값
: (SWAP + (RAM*vm.overcommit_ratio))* 0.9/number_segments_per_server
 DB 세션 레벨 메모리 설정 : gp_vmem_protect_limit
- 쿼리에서 메모리 할당은 statement_mem을 사용
 Resource Queue 설정
- ACTIVE_STATEMENTS 및 MEMORY_LIMIT 등 모두 설정
- 모든 사용자에 대해서 Default Resource Queue 사용 금지
- Resource Queue에서 할당된 메모리가 gp_vmem_protect_limit 초과 금지
- 작업 부하와 시간에 맞도록 Priority 설정(일별 operation flow 맞도록 RQ 설정)

Indexes
 일반적으로 GPDB에서는 Index를 필요로 하지 않음.
 높은 선택성을 가진 쿼리를 처리하기 위한 cardinality 높은 테이블에 대해서 싱글 컬럼에
대해서 인덱스를 생성
 빈번하게 update 되는 컬럼에서는 Index 생성 자제
 초기 데이터 로딩시에는 인덱스 삭제 후 데이터 로딩 후 Index 재생성
 선택적으로 B-Tree Index 생성 권고
 주의 사항
- UPDATE되는 컬럼에 대해서는 Bitmap index 생성 자제
- Unique 컬럼, cardinality 너무 높을 경우, 너무 낮을 경우에 Bigmap Index 사용 금지
- 트랜잭션 부하가 발생되는 테이블에 Bitmap index 사용 금지
- 파티션 테이블에 일반적으로 인덱스를 사용하지 않음.
- 파티션 테이블에서 인덱스 컬럼은 파티션 키와 달라야 함.

Partitioning
 데이터 Read 량을 줄이기 위해 사용 됨. 대용량 테이블에 대해서만 적용, 소용량 테이블에
대해서는 비적용 권고
- 파티션 테이블에 모든 파티션을 scan 하는 경우에는 비 파티션 테이블 보다 더 많은
소요시간이 걸림. (데이터 파일일 물리적으로 쪼개어 져 있기 때문)
 파티션 쿼리에서 반드시 immutable operators 사용해야 함.
- =, < , <= , >, >= , and <>
 Default 파티션을 사용 금지 : 항상 Scan 되기 때문에 성능 저하가 발생 됨.
 파티션 키와 분산 키를 동시에 사용 금지
 멀티 레벨 파티션 사용 자제 (관리 시 어려움 발생)
- 파티션을 차라리 잘 정리하는 것이 나음.
 GPDB에서 최대 파티션 개수는? 이론적으로 제한 없음(단, OS open file limit 제외)
- 하지만 너무 많이 쪼개었을 때 관리 이슈가 발생

Vacuum
 대량의 update, delete 발생 후 vacuum 실행
 사용자 테이블에 대해서 Vacuum Full 실행 금지
- Bloated 테이블에 대해서는 CTAS 또는 Reorg 실행
 시스템 카탈로그에 대해서는 빈번하게 Vacuum 실행 권고 (Bloat 방지 위함)
- 시스템 카탈로그 Bloat 발생되었을 경우 Vacuum Full 실행
 Catalog 테이블 Vacuum 실행 시 절대 프로세스 Kill 금지
 Vacuum analyze 실행 금지
- Vacuum과 Analyze를 분리해서 실행

Loading
 GPDB 에서 load, unload 시 gpfdist 실행 권고 (gpload 포함)
 병렬 처리를 최대화하기 위해서는 세그먼트 수를 올려야 함. (세그먼트 수가 많을 수록 Loading 속도가
증가)
 ETL 서버 노드가 많게하여 데이터를 분산시키면 더 빨리 로딩을 할 수 있음.
 큰 파일일 경우에는 파일을 균등하게 쪼개어서 많은 파일 시스템에 분산 시킴
 파일 시스템별 두개의 gpfdist 데몬을 실행 시킴
 가급적이면 gpfdist를 실행할 때 많은 Interface를 사용해야 함.
 Gp_external_max_segs 파라미터로 gpfdist server를 컨트롤 할 수 있다.
 gp_external_max_segs 수는 항상 짝수로 설정해야 함.
 데이터 로딩시에 인덱스를 삭제하고 로딩 후에 index 재생성 권고 (대용량으로 적재할 경우)
 데이터 로딩 후에 analyze 실행 권고
 로딩하는 동안에는 gp_autostats_mode를 NONE으로 설정해서 자동으로 통계 정보를 쌓지 않도록
권고
 로딩 에러시 vacuum 실행 권고(recover space)

Resource Queues
 부하관리를 위해서는 Resource Queue 사용 해야 함.
 모든 유저에게 user defined resource queue 를 설정해야 함.
 동시 쿼리 수를 제한하기 위해서는 ACTIVE_STATEMENTS 사용
 전체 메모리 양을 관리하기 위해서는 MEMORY_LIMIT 사용
 모든 리소스 큐에 MEDIUM 으로 설정 하지 말아야 함(workload 효과가 없기 때문)
 부하가 발생될 때와 시간에 대해서 매칭할 수 있도록 Resource Queue 를 가변적으로 적용

Analyze
 전체 Database에 대해서 analyze 실행하면 안됨.
 필요한 테이블 레벨에서 선택적으로 실행 해야 함.
 데이터 로딩 후에는 analyze 항상 실행
 Insert, update, delete 이후에 많은 데이터가 변경되었을 때 analyze 실행
 Create index 실행 후에 analyze 실행
 대용량 테이블에 analyze 실행할 경우 시간이 오래 걸릴 경우, 조인 조건, where 절, sort,
group by, having 절에 있는 컬럼만에 대해서 analyze 실행

DATA TYPES
 가급적이면 최소한의 공간을 사용하는 data type 을 사용
 Character data type를 사용할 때 성능 차이가 없더라도, CHAR 보다는 TEXT 또는
VARCHAR Type 권고
 Numeric data type를 사용할 때 가장 작은 숫자형 data type 를 사용.
 테이블간 조인시에는 컬럼에 데이터 Type 이 같아야 함.
- Data type이 다를 때 GPDB는 정확하게 비교하기 위해서 data type 변환 함.
 Numeric data type를 사용할 때 가장 작은 숫자형 data type 를 사용.
 테이블간 조인시에는 컬럼에 데이터 Type 이 같아야 함.
 일부 조건에서는 다른 공통 오브젝트와 조인이 발생될 경우 data type size를 크게 해야 할
경우 발생 됨.

Local (co-located) Joins
 대용량 테이블 조인이 발생될 경우 최적의 성능을 내기 위해서는 Local Join을 해야 함. (단,
해쉬 분산되어 있을 경우)
 Local Join은 세그먼트 내에서만 조인이 발생되기 때문에 다른 세그먼트와 독립적으로
수행(네크워크 자원 사용하지 않으며, 다른 세그먼트간의 통신도 하지 않음)
 Local Join 을 하기 위해서는 조인되는 테이블 간의 같은 컬럼이 분산키로 잡혀져 있어야 함.
(컬럼 Data Type, 순서도 동일해야 함).
 컬럼 Data Type이 다르면 디스크 레벨에서 다르게 저장이 되어 다른 값으로 Hash 됨.

Data Skew
 Data Skew 는 Read 성능 뿐만 아니라 데이터 프로세싱에도 영향을 미침
- join, group by 실행 등
 Data Skew 는 쿼리 성능에 직접적인 원인일 수 있고, 메모리 부족 현상을 발생 시키기도 함
 데이터 분산을 점검하는 것은 정말 중요하며, 초기 로딩 이후 에 반드시 분산도를 체크해야
함.
 분산도 체크 쿼리
SELECT 'Example Table' AS "Table Name", max(c) AS "Max Seg Rows", min(c) AS "Min
Seg Rows", (max(c)-min(c))*100.0/max(c) AS "Percentage Difference Between Max & Min"
FROM (SELECT count(*) c, gp_segment_id from facts group by 2) AS a;

Processing Skew
 Data Skew 는 분산이 잘 안되었을 때 발생, 즉 분산키를 잘 못 잡았을 때 발생
 Processing SKEW는 쿼리 실행되는 시점에서 발생되기 때문에 detect가 쉽지 않음.
 MPP 아키텍처에서 Processing skew는 과도하게 한쪽으로 쏠리거나 일부 세그먼트에
사용되는 경우 문제가 된다.
- Greenplum Database에서도 process skew 가 발생될 경우에는 성능 저하가 발생이 된다.
 Processing SKEW 체크는 수작업으로 확인이 가능
1) database OID 확인
# select oid, datname from pg_database ;
oid | datname
-------+-----------
17088 | gpadmin
10899 | postgres
38817 | pws

Processing Skew
2) 각 세그먼트 노드의 용량 확인
[gpadmin@mdw kend]$ gpssh -f ~/hosts -e "du -b /data[1-
2]/primary/gpseg*/base/<OID>/pgsql_tmp/*" | grep -v "du -b" | sort | awk -F" " '{ arr[$1] = arr[$1]
+ $2 ; tot = tot + $2 }; END { for ( i in arr ) print "Segment node" i, arr[i], "bytes ("
arr[i]/(1024**3)" GB)"; print "Total", tot, "bytes (" tot/(1024**3)" GB)" }' -
Example output:
Segment node[sdw1] 2443370457 bytes (2.27557 GB)
Total 14856967207 bytes (13.8366 GB)

Processing Skew
3) 세그먼트 레벨에서 용량 확인(SKEW 확인)
[gpadmin@mdw kend]$ gpssh -f ~/hosts -e "du -b /data[1-
2]/primary/gpseg*/base/<OID>/pgsql_tmp/*" | grep -v "du -b" | sort | awk -F" " '{ arr[$1] = arr[$1]
+ $2 ; tot = tot + $2 }; END { for ( i in arr ) print "Segment node" i, arr[i], "bytes ("
arr[i]/(1024**3)" GB)"; print "Total", tot, "bytes (" tot/(1024**3)" GB)" }' -
Example output:
Total 14856967207 bytes (13.8366 GB)
지속적으로 디스크 사용량이 현격하게 차이가 발생될 경우 SKEW 점검이 필요 함.

Processing Skew
4) 디렉토리 레벨에서 SKEW 확인 (예제는 sort 시)
[gpadmin@mdw kend]$ gpssh -f ~/hosts -e "ls -l /data[1-
2]/primary/gpseg*/base/19979/pgsql_tmp/*" | grep -i sort | sort
[sdw1] -rw------- 1 gpadmin gpadmin 1002209280 Jul 29 12:48
/data1/primary/gpseg2/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_19791_0001.0
…
Sdw8 의 gpseg45 instance 가 문제

Processing Skew
5) lsof 으로 파일 확인 – 프로세스 ID 확인하기 위함.
[root@sdw8 ~]#
lsof /data2/primary/gpseg45/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_15673_0
002.1
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
postgres 15673 gpadmin 11u REG 8,48 1073741824 64424546751
/data2/primary/gpseg45/base/19979/pgsql_tmp/pgsql_tmp_slice10_sort_15673_0002.
1
6) 프로세스 ID로 해당 세션 및 쿼리 확인
[root@sdw8 ~]# ps -eaf | grep 15673
gpadmin 15673 27471 28 12:05 ? 00:12:59 postgres: port 40003, sbaskin bdw
172.28.12.250(21813) con699238 seg45 cmd32 slice10 MPPEXEC SELECT
root 29622 29566 0 12:50 pts/16 00:00:00 grep 15673
세션ID = con699238 , 쿼리 번호 : cmd32

기타 고려 사항
1. Object 개수
- Best Practice 에서는 노드 당 100,000개의 파일
=> 세그먼트 수 * 세그먼트당 평균 파일 개수 < 100,000
2. 고급 분석 적용
- madlib, pl/r, pl/java 등을 이용하여 고급 분석 적용
3. 주요 점검 사항
- SKEW ( Data, Process)
- Analyze
- Vacuum / Re-org
- Partition / Index
- Local Join ( Motion check : broadcast, redistribution)

Gpdb best practices v a01 20150313

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (16)

Similar a Gpdb best practices v a01 20150313

Similar a Gpdb best practices v a01 20150313 (20)

Gpdb best practices v a01 20150313

Notas del editor