1. PostGIS와 GeoServer를 이용한
대용량 공간데이터 기반 일기도 서비
스장병진, 금정우

2. Who am I
 Gaia3D Open Source GIS Technical Manager
 Open Source GIS Korean Localizer
 Risk Surfer

3. 이 PT의 목적
 석사과정 학생이 Oracle을 써서 느리면 학생 잘못
PostGIS를 써서 느리면 오픈소스 잘못!
 Oracle의 장점은 모든 것을 튜닝할 수 있는 것
Oracle의 단점은 모두 튜닝해야만 하는 것
 모든 서버에 다 통하는 격언
 오픈 소스 GIS를 써서 느린 것이 아니라
튜닝을 안 해서 느린 것이다!

4. 배경지식

5. 모바일 일기도 서비스
관측
자료
GRIB
Data
Vector
일기도기상모델 벡터화 이미지화
서비스
용
일기도

6. 시스템 사용자

7. 기상자료 특징
실시간 /
준실시간저해상도
잦은
생산주기다차원 자료
지리적 해상도 낮음
평면+높이(등압면)
+분석모델
+자료시간+예측시간
하루 수차례
~수백차례
항상
최신자료
필요

8. 극복과제

9. 서비스 아키텍처
벡터 일기도

10. 1일 사용자료
회 생산 (00, 06, 12, 18 UTC)
개 공간 테이블
장의 일기도
MB의 자료
행의 공간 데이터

11. 어떻게 이런 서비스를
…

12. 극복과제 3가지
데이터 수집이 느리다
데이터 유지관리가 안 된
다
데이터 조회가 느리다
DB
전범
위
문제

13. B & F
 튜닝전 상황
 자료 인서트에 5시간
 데이터파일 하루 35기가씩 커짐
 일기도 한 장 조회시 수십초
 개선목표
 30분 이내 인서트
 데이터파일 일정크기 유지
 수초 이내 일기도 조회

14. 임포드속도 개선

15. 대용량 Update
출처: http://novathin.kr/19
건건이 실행
Batch Size 만큼 모아
한번에 실행
SQL을 실행하는 시기에 따라 성능의 차이가 크다!

16. 실제 삽입 속도 비교
하나의 일기도 kml 파일  약 3000행  테스트 기준
 매번 executeUpdate 실행 – 109sec 소요(기존방식)
 addBatch() 100번 후, executeBatch(), 두 과정 30번 – 8.9sec
 addBatch() 500번 후, executeBatch(), 두 과정 6번 – 5.7sec
 addBatch() 1000번 후, executeBatch(), 두 과정 3번– 3.4sec
 addBatch() 3000번 후, executeBatch(), 두 과정 1번 – 1.1sec

17. ★임포트 개선 솔루션★
 JDBC 2.0의 addBatch(), exeuteBatch() 이
용 - JDBC 2.0을 지원하는 모든 DB에서 사
용가능
 기존의 1 insert / 1 commit 에서
 Kml파일 단위의(3000 insert) 마다 commit
으로 변경

18. 데이터 크기유지

19. PostgreSQL의 데이터관
리
 PostgreSQL은 추기형
 Update, Delete된 데이터 지우지 않음
 마킹만 하고 새 데이터를 아래에 기록
 장점
 속도가 빠름
 여러 버전의 데이터 관리가 가능
 단점
 데이터파일 크기가 심각하게 늘어날 수 있음
 파일크기 증가에 따른 성능저하 가능성
 일기도 DB 파일이 하루 35GB씩 커짐!!!

20. 스냅샷형 vs 추기형
테이블
A
B’
C
D
E
테이블
A
B X
C
D
E
B’
스냅샷
B
Transection 주인
기타 User
갱신전 레코드
갱신후 레코드
갱신전 레코드
갱신후 레코드
Oracle / MySQL PostgreSQL
Transection 완료 후

21. 일반 VACUUM
테이블
A
B X
C X
D
E X
B’
C’
테이블
A
B X
C X
D
E X
B’
C’
테이블
A
F
C X
D
E X
B’
C’
불필요
B X
C X
E X
FSM
불필요
C X
E X
FSM
VACUUM 실행 데이터 Insert
출처: http://www.geocities.jp/sugachan1973/doc/funto60.html
기상청 일기도용 PostgreSQL은 일반 Vacuum 만으로는 계속 데이터파일 증가

22. VACUUM FULL
기상청 일기도용 PostgreSQL은 Full VACUUM에 15시간 소요.
VACUUM FULL 수행 중 배타적 LOCK 발생
출처: http://www.devmedia.com.br/otimizacao-uma-ferramenta-chamada-vacuum/1710

23. Partitioning
 Partitioning 이란?
 개념적으로 하나인 테이블을 여러 개로 쪼개어 관리
 테이블당 자료량 줄어 인덱스 크기 감소, 검색속도 향상
일기도
일
기
도
_0
일
기
도
_1
일
기
도
_2
일
기
도
_3
일
기
도_4
일
기
도
_5
일
기
도
_6
일요일 Insert
월요일 Insert
화요일 Insert
일요일 Truncate
월요일 Truncate
화요일 Truncate
Truncate는 실행시간이 거의 초단위이며, VACUUM 없이 파일이 줄어듦

24. ★데이터 유지 솔루션★
 요일단위 파티셔닝
 Insert시 각 요일별 테이블에 삽입
 조회시 부모 데이블을 이용
 날짜 연산을 통해 N일 단위 파티셔닝도 가능
 데이터 삭제
 Truncate를 이용해 자식 테이블 단위 삭제
 항상 N-1 일치 정도의 자료량 유지 가능

25. 조회속도 개선

26. PostgreSQL의 쿼리특
징
 통계를 적극 이용해 쿼리 실
행
 이용할 인덱스 강제 지정 불가
 쿼리 실행시 통계 데이터 참조
Optimize
 Oracle 10g 보다 우수
 통계는 일반적으로 자동 갱신
(Auto Vacuum과 함께)
 Analyze 명령으로도 갱신 가능
 재대로 된 인덱스 생성이 가장
중요 출처: http://helloworld.naver.com/helloworld/227936

27. 조회속도 개선 과정
데이터
현황 분석
쿼리
찾기
쿼리 플랜
분석
인덱스
개선

28. 데이터 현황분석
 테이블별 행 수 파악
 select count(*)
table_name 은 정말 무
식한 방법
 통계 테이블을 이용하
면 대략적인 행수 파악
가능
 pg_class 테이블에 의미
있는 자료들이 보관됨
 실행시간 1초 내외
select relname as table_name,
to_char(reltuples, '999,999,999')
as row_count
from pg_class
where relnamespace = (select oid
from pg_namespace where nspname
= 'public')
and relam = 0
order by 2 desc, 1;

29. GeoServer SQL 뷰
 SQL 문을 Layer로 취
급
 Geo DB가 데이터 소
스인 경우만 사용 가능
 다음 난제 해결에 유용
 복잡한 조건을 Layer로
 좌표계 변환
 여러 테이블 Join 필요
 속성을 공간객체로 변
환

30. 쿼리 찾기
 통계 테이블을 통해 실행중인
SQL 확인
 pg_stat_activity 테이블 이용
 튜닝을 위한 필수 과정
 실행에 걸린 시간도 확인 가
능
 PostgreSQL 버전에 따라 쿼
리 차이 존재
select query_start, current_query
from pg_stat_activity
where username = ‘mobile’
and current_query not like ‘<IDLE>%’
orde by query_start desc;
SELECT
"val",encode(ST_AsBinary(ST_Force_2D("geom
")),'base64') as "geom"
FROM (
select mdl, mdl_var,
placemark_name, val, lyrs_cd,
forecast_time,
create_time as anal_time,
ST_Transform(the_geom, 7188) as geom
from contour
where mdl_var = 'TMP'
) as "vtable"
WHERE (((("mdl" = 'GDAPS' AND "lyrs_cd" =
'A925.0') AND "forecast_time" =
'2011.06.27 00:00') AND "anal_time" =
'2011.06.27 00:00') AND "geom" &&
ST_GeomFromText('POLYGON ((-1056768 -
2105344, -1056768 -1040384, 8192 -1040384,
8192 -2105344, -1056768 -2105344))',
7188));

31. 쿼리플랜 분석
 PostgreSQL은 쿼리 분석기능 기본 탑재
 pgAdmin III-쿼리-분석설명 메뉴
 Explain Analyze 명령 – 이 방법이 분석 용이

32. 인덱스 개선
 개선 원칙
 Where 절에 있는 컬럼 모두 묶어 인덱스 구성
 공간컬럼은 별도 인덱스
 포함된 데이터 종류가 많은 컬럼을 먼저 써줘야
 가능한 한 등위연산자로 비교되는 항목부터
 불필요 인덱스 제거 – 인서트시 영향
 개선 적용 예
-- contour_0
DROP INDEX index_createtime_contour_0;
DROP INDEX index_forecasttime_contour_0;
DROP INDEX index_lyrscd_contour_0;
DROP INDEX index_mdl_contour_0;
DROP INDEX index_mdlvar_contour_0;
CREATE INDEX index_contour_0_all
ON contour_0 (forecast_time ASC NULLS LAST, mdl_var ASC NULLS LAST, lyrs_cd ASC NULLS LAST, create_time DESC
NULLS LAST, mdl ASC NULLS LAST);
 결과
 개별적 인덱스 삭제 후 통합 인덱스 생성으로 데이터 용량 20% 감소
 테이블별로 6~25배의 속도 개선 (큰 테이블이 효과 큼)

33. ★조회속도 개선 솔루션★
 적절한 인덱스 생성
 자료량 확인
 GeoServer가 생성하는 쿼리 확인
 쿼리플랜 확인
 데이터 분포 고려한 인덱스 생성

34. 개선결과

35. 결과 종합
 데이터 인서트
 몇 건마다 실행할 지가 중요
 사용 시스템에 따른 최적조건 찾기 필요
 100배 정도 성능 개선
 데이터파일 크기
 파티셔닝과 Truncate의 조합
 N-1일치 안정적 유지
 조회 시간
 쿼리에 맞는 적절한 인덱스
 20배 정도 속도 개선

36. 시연

37. 결론
 PostgreSQL은 정말 훌륭한 DBMS다!
 GeoServer와의 궁합도 정말 좋다.
 하지만 특성을 알아야 하고 튜닝해야 한다.

38. 감사합니다!!!