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

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

Software