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

Who am I

Gaia3D Open Source GIS Technical Man-ager

Open Source GIS Korean Localizer Risk Surfer

이 PT 의 목적

석사과정 학생이 Oracle 을 써서 느리면 학생 잘못PostGIS 를 써서 느리면 오픈소스 잘못 !

Oracle 의 장점은 모든 것을 튜닝할 수 있는 것Oracle 의 단점은 모두 튜닝해야만 하는 것 모든 서버에 다 통하는 격언

오픈 소스 GIS 를 써서 느린 것이 아니라튜닝을 안 해서 느린 것이다 !

배경지식

모바일 일기도 서비스

관측자료

GRIBData

Vector일기도기상모델 벡터화 이미지화

서비스용

일기도

시스템 사용자

기상자료 특징

실시간 /준실시간저해상도

잦은생산주기다차원 자료

지리적 해상도 낮음평면 + 높이 ( 등압면 )

+ 분석모델+ 자료시간 + 예측시간

하루 수차례~ 수백차례

항상 최신자료

필요

극복과제

서비스 아키텍처

벡터 일기도

1 일 사용자료

46

35,0005,332

67,000,000

회 생산 (00, 06, 12, 18 UTC)

개 공간 테이블

장의 일기도

MB 의 자료

행의 공간 데이터

어떻게 이런 서비스를…

초기

요구

사항

파악

실패

극복

정신

극복과제 3 가지

데이터 수집이 느리다

데이터 유지관리가 안 된다

데이터 조회가 느리다

DB전범위

문제

B & F

튜닝전 상황 자료 인서트에 5 시간 데이터파일 하루 35 기가씩 커짐 일기도 한 장 조회시 수십초

개선목표 30 분 이내 인서트 데이터파일 일정크기 유지 수초 이내 일기도 조회

임포드속도 개선

대용량 Update

출처 : http://novathin.kr/19

건건이 실행

Batch Size 만큼 모아한번에 실행

SQL 을 실행하는 시기에 따라 성능의 차이가 크다 !

실제 삽입 속도 비교

하나의 일기도 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

★ 임포트 개선 솔루션★

JDBC 2.0 의 addBatch(), exeuteBatch() 이용 - JDBC 2.0 을 지원하는 모든 DB 에서 사용가능

기존의 1 insert / 1 commit 에서 Kml 파일 단위의 (3000 insert) 마다

commit 으로 변경

데이터 크기유지

PostgreSQL 의 데이터관리

PostgreSQL 은 추기형 Update, Delete 된 데이터 지우지 않음 마킹만 하고 새 데이터를 아래에 기록

장점 속도가 빠름 여러 버전의 데이터 관리가 가능

단점 데이터파일 크기가 심각하게 늘어날 수 있음 파일크기 증가에 따른 성능저하 가능성 일기도 DB 파일이 하루 35GB 씩 커짐 !!!

스냅샷형 vs 추기형

테이블

A

B’

C

D

E

테이블

A

B X

C

D

E

B’

스냅샷

B

Transection 주인

기타 User

갱신전 레코드

갱신후 레코드

갱신전 레코드

갱신후 레코드

Oracle / MySQL PostgreSQL

Transection 완료 후

일반 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 만으로는 계속 데이터파일 증가

VACUUM FULL

기상청 일기도용 PostgreSQL 은 Full VACUUM 에 15 시간 소요 . VACUUM FULL 수행 중 배타적 LOCK 발생

출처 : http://www.devmedia.com.br/otimizacao-uma-ferramenta-chamada-vacuum/1710

Partitioning

Partitioning 이란 ? 개념적으로 하나인 테이블을 여러 개로 쪼개어 관리 테이블당 자료량 줄어 인덱스 크기 감소 , 검색속도 향상

일기도

일기도_0

일기도_1

일기도_2

일기도_3

일기도_4

일기도_5

일기도_6

일요일 Insert월요일 Insert

화요일 Insert

일요일 Truncate월요일 Truncate

화요일 Truncate

Truncate 는 실행시간이 거의 초단위이며 , VACUUM 없이 파일이 줄어듦

★ 데이터 유지 솔루션★

요일단위 파티셔닝 Insert 시 각 요일별 테이블에 삽입 조회시 부모 데이블을 이용 날짜 연산을 통해 N 일 단위 파티셔닝도 가능

데이터 삭제 Truncate 를 이용해 자식 테이블 단위 삭제 항상 N-1 일치 정도의 자료량 유지 가능

조회속도 개선

PostgreSQL 의 쿼리특징

통계를 적극 이용해 쿼리 실행 이용할 인덱스 강제 지정 불가 쿼리 실행시 통계 데이터 참조

Optimize Oracle 10g 보다 우수 통계는 일반적으로 자동 갱신

(Auto Vacuum 과 함께 ) Analyze 명령으로도 갱신 가능 재대로 된 인덱스 생성이 가장

중요

출처 : http://helloworld.naver.com/helloworld/227936

조회속도 개선 과정

데이터 현황 분석

쿼리 찾기

쿼리 플랜분석

인덱스 개선

데이터 현황분석

테이블별 행 수 파악 select count(*) ta-

ble_name 은 정말 무식한 방법

통계 테이블을 이용하면 대략적인 행수 파악 가능

pg_class 테이블에 의미 있는 자료들이 보관됨

실행시간 1 초 내외

select relname as table_name, to_char(reltuples, '999,999,999') as row_countfrom pg_class where relnamespace = (select oid from  pg_namespace where nspname = 'public')and relam = 0order by 2 desc, 1;

GeoServer SQL 뷰

SQL 문을 Layer 로 취급

Geo DB 가 데이터 소스인 경우만 사용 가능

다음 난제 해결에 유용 복잡한 조건을 Layer

로 좌표계 변환 여러 테이블 Join 필요 속성을 공간객체로 변환

쿼리 찾기

통계 테이블을 통해 실행중인 SQL 확인

pg_stat_activity 테이블 이용

튜닝을 위한 필수 과정 실행에 걸린 시간도 확인

가능 PostgreSQL 버전에 따라

쿼리 차이 존재select query_start, current_queryfrom pg_stat_activitywhere 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));

쿼리플랜 분석

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

인덱스 개선 개선 원칙

Where 절에 있는 컬럼 모두 묶어 인덱스 구성 공간컬럼은 별도 인덱스 포함된 데이터 종류가 많은 컬럼을 먼저 써줘야 가능한 한 등위연산자로 비교되는 항목부터 불필요 인덱스 제거 – 인서트시 영향

개선 적용 예-- contour_0DROP 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 배의 속도 개선 (큰 테이블이 효과 큼 )

★ 조회속도 개선 솔루션★

적절한 인덱스 생성 자료량 확인 GeoServer 가 생성하는 쿼리 확인 쿼리플랜 확인 데이터 분포 고려한 인덱스 생성

개선결과

결과 종합

데이터 인서트몇 건마다 실행할 지가 중요 사용 시스템에 따른 최적조건 찾기 필요 100 배 정도 성능 개선

데이터파일 크기 파티셔닝과 Truncate 의 조합 N-1 일치 안정적 유지

조회 시간 쿼리에 맞는 적절한 인덱스 20 배 정도 속도 개선

시연

결론

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

감사합니다 !!!