Upload
bj-jang
View
626
Download
0
Embed Size (px)
Citation preview
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 와의 궁합도 정말 좋다 . 하지만 특성을 알아야 하고 튜닝해야 한다 .
감사합니다 !!!