1. 데이터 분산
- 각 세그먼트/노드별 데이터 분산이 성능에 가장 중요.
- 분산키는 명시적으로 정의 (ex, distributed by (컬럼1))
- PK, UK 있을 경우: PK/UK 컬럼 중 분산도가 좋고, Join 이 많은 컬럼을 대상으로 1~2개 컬럼
- PK, UK 없을 경우: 분산도가 좋고, Join 이 빈번하게 발생할 컬럼
- Ex) Device ID, 회원 ID
- 분산도 확인: Select gp_segment_id, count(*) from Tablename group by gp_segment_id
2. 데이터 모델
- 비정규화된 스키마 설계 필요(성능적인 측면 고려 시)
- 매번 여러 개의 디멘젼 테이블이 조인 될 경우 통합 디멘전 테이블 생성
- 테이블간의 조인 발생 컬럴은 동일한 데이터 타입으로 생성
- Char Type (사용 금지) => Varchar Type 사용 (함수 사용시 형변환 때문)
- Database Object는 10만개 미만 권고(select count(*) from pg_class)
3. 압축
- Row 단위의 트랜젝션 처리: Insert / update /delete 되는 테이블에는 비압축(마스터성 테이블)
- 대용량 단위의 트랜젝션 처리: insert/update/delete 되는 테이블에 압축 적용(Fact 테이블)
- 압축시 옵션: Compress level 5, zlib 으로 적용
4. 파티션
- 파티션은 Range Partition 으로 구성
- 서브 파티션은 가급적 미적용 – 관리상 어려움 발생
- 테이블당 파티션을 200개 미만을 권고
- 파티션에 인덱스를 2~3개 이상 사용시에는 파티션을 구간을 줄이는 것을 권고Ex) 월 파티션 => 일 파티션대용량/Index 테이블에 여러개 Index가 있을 경우 Data Loading 시 부하 발생 때문
- Default 파티션 비적용 권고(모든 쿼리실행 시 Default 파티션 scan 발생)
5. 인덱스
- 인덱스는 가급적 적게 사용 (short 쿼리에 대해서만 적용)
- 파티션 테이블의 인덱스 컬럼과 파티션 컬럼은 달라야 함. (Local Index 이기 때문에 굳이 파티션 컬럼 사용할 필요 없음)
- B-Tree index 사용
6. 쿼리
- 쿼리 유형
|
비권고
|
권고
|
|
In, not
in, exists, not exists
|
Join,
left outer join
|
|
Subquery,
inline view
|
Join 절로 변환
|
|
With 절
|
Temp
Table 로 변환
|
|
Distinct
|
Group by
|
|
decode
|
Case when 절로 변환
|
|
Where 절 파티션 컬럼에 Like 절
사용
Where
substr(yyyymmdd, 1,6) = ‘201601’
Where yyyymm like ‘201601%’
|
파티션 쿼리 수행시 Immutable operation 사용
Where yyyymmdd >=
‘20160101’ and yyyymmdd < ‘20160301’
Where yyyymmdd between ‘20160101’ and ‘20160228’
|
- Short Query 튜닝
- Index scan 및 nested loop 옵션 설정
- 쿼리 또는 계정별 옵션 설정
- Enable_nestloop = true;
- Random_page_cost = 1;
7. 사용자 테이블 배치 관리 (ETL에 포함할 사항)
- Analyze
- Greenplum Database는 Cost Based Optimizer사용으로 통계 정보가 중요
- 모든 배치 작업 뒤에는 Analyze 수행, 테이블/파티션 레벨
- Vacuum
- Delete / update 발생된 테이블은 Dirty Block 발생 방지 용도
- Dirty Block 재 사용을 위하여 Vacuum 수행
- 모든 배치 작업 뒤에는 Analyze 수행, 테이블/파티션 레벨
- Reorg
- Delete / update 발생된 테이블은 Dirty Block 발생 후에 조치 방법
8. 시스템 카탈로그 관리 (DBA 시스템 관리 목적)
- 배치 관리(일배치) : Vacuum Analyze 카탈로그 테이블 수행
- 모든 배치 작업 뒤에는 Analyze 수행, 테이블/파티션 레벨
- 반년/연간계획: Vacuum Full Analyze 카탈로그 테이블 수행
9. ETL 방법
- Data Loading
- 권고 사항: Gpload 또는 external table 사용
- 비권고 사항: ODBC 를 이용한 데이터 적재
- Gpload 수행 후 vacuum 테이블 수행
- ETL 수행 순서: Extract => Load => Transform
- Gpload 수행 후 vacuum 테이블 수행
10. DBA
- Resource Queue 설정
- 계정별 Resource Queue 설정(동시 쿼리 수행수, Max Cost, Max Memory 설정)
- 상세 설정은 DBA 지원 필요
11. 쿼리 플랜
- 쿼리 플랜 확인 방법
- Pgadmin 에서 F6 수행 또는 쿼리 제일 앞에 explain를 기입하고 실행
12. 성능 이슈 발생 시 확인 사항
- 프로젝트 종료 후 몇 개월 후에 배치가 서서히느려질 경우
- Dimension Table이 Bloated 된 경우, 즉 Vacuum 이 제대로 수행되지 않은 경우
- 잘 수행되는 배치가 갑자기 느려질 경우
- 통계 정보가 제대로 수행되지 않아, 쿼리 플랜이 변경 된 경우
- Analyze 가 수행이 되었는지 확인 필요
- 디스크 IO Busy 때문에 전반적으로 수행이 느린 경우
- 테이블 압축 여부 확인
- 테이블에 Index 개수 확인
- 불 필요한 인덱스 삭제
- Index Rebuild 검토
- Fact 파티션 테이블일 경우 – 파티션 기간을 조절하여, Index 부하를 줄임.
- Short 쿼리가 느린 경우
- 다른 세션에서 Disk IO를 많이 일으킬 경우 발생 가능
- Index 테이블에 데이터 적재하는 경우 발생 가능성 있음.
- Index 테이블 사이즈를 최소화 함.(파티션 기간 조정)
- 쿼리툴 접속이 느려지는 경우
- Resource Queue 의 Active session 확인
- 시스템 카탈로그 테이블 사이즈 검토 및 Vacuum, index rebuild 검토
