0
PostGIS와 GeoServer를 이용한
대용량 공간데이터 기반 일기도 서비
스장병진, 금정우
Who am I
 Gaia3D Open Source GIS Technical Manager
 Open Source GIS Korean Localizer
 Risk Surfer
이 PT의 목적
 석사과정 학생이 Oracle을 써서 느리면 학생 잘못
PostGIS를 써서 느리면 오픈소스 잘못!
 Oracle의 장점은 모든 것을 튜닝할 수 있는 것
Oracle의 단점은 모두 튜닝해야만 하는 것...
배경지식
모바일 일기도 서비스
관측
자료
GRIB
Data
Vector
일기도기상모델 벡터화 이미지화
서비스
용
일기도
시스템 사용자
기상자료 특징
실시간 /
준실시간저해상도
잦은
생산주기다차원 자료
지리적 해상도 낮음
평면+높이(등압면)
+분석모델
+자료시간+예측시간
하루 수차례
~수백차례
항상
최신자료
필요
극복과제
서비스 아키텍처
벡터 일기도
1일 사용자료
회 생산 (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(),...
★임포트 개선 솔루션★
 JDBC 2.0의 addBatch(), exeuteBatch() 이
용 - JDBC 2.0을 지원하는 모든 DB에서 사
용가능
 기존의 1 insert / 1 commit 에서
 Kml파일...
데이터 크기유지
PostgreSQL의 데이터관
리
 PostgreSQL은 추기형
 Update, Delete된 데이터 지우지 않음
 마킹만 하고 새 데이터를 아래에 기록
 장점
 속도가 빠름
 여러 버전의 데이터 관리가 가능...
스냅샷형 vs 추기형
테이블
A
B’
C
D
E
테이블
A
B X
C
D
E
B’
스냅샷
B
Transection 주인
기타 User
갱신전 레코드
갱신후 레코드
갱신전 레코드
갱신후 레코드
Oracle / MySQL ...
일반 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 FULL
기상청 일기도용 PostgreSQL은 Full VACUUM에 15시간 소요.
VACUUM FULL 수행 중 배타적 LOCK 발생
출처: http://www.devmedia.com.br/otimiza...
Partitioning
 Partitioning 이란?
 개념적으로 하나인 테이블을 여러 개로 쪼개어 관리
 테이블당 자료량 줄어 인덱스 크기 감소, 검색속도 향상
일기도
일
기
도
_0
일
기
도
_1
일
기
도...
★데이터 유지 솔루션★
 요일단위 파티셔닝
 Insert시 각 요일별 테이블에 삽입
 조회시 부모 데이블을 이용
 날짜 연산을 통해 N일 단위 파티셔닝도 가능
 데이터 삭제
 Truncate를 이용해 자식 테...
조회속도 개선
PostgreSQL의 쿼리특
징
 통계를 적극 이용해 쿼리 실
행
 이용할 인덱스 강제 지정 불가
 쿼리 실행시 통계 데이터 참조
Optimize
 Oracle 10g 보다 우수
 통계는 일반적으로 자동 갱신
...
조회속도 개선 과정
데이터
현황 분석
쿼리
찾기
쿼리 플랜
분석
인덱스
개선
데이터 현황분석
 테이블별 행 수 파악
 select count(*)
table_name 은 정말 무
식한 방법
 통계 테이블을 이용하
면 대략적인 행수 파악
가능
 pg_class 테이블에 의미
있는 자료들이 ...
GeoServer SQL 뷰
 SQL 문을 Layer로 취
급
 Geo DB가 데이터 소
스인 경우만 사용 가능
 다음 난제 해결에 유용
 복잡한 조건을 Layer로
 좌표계 변환
 여러 테이블 Join 필요...
쿼리 찾기
 통계 테이블을 통해 실행중인
SQL 확인
 pg_stat_activity 테이블 이용
 튜닝을 위한 필수 과정
 실행에 걸린 시간도 확인 가
능
 PostgreSQL 버전에 따라 쿼
리 차이 존재
...
쿼리플랜 분석
 PostgreSQL은 쿼리 분석기능 기본 탑재
 pgAdmin III-쿼리-분석설명 메뉴
 Explain Analyze 명령 – 이 방법이 분석 용이
인덱스 개선
 개선 원칙
 Where 절에 있는 컬럼 모두 묶어 인덱스 구성
 공간컬럼은 별도 인덱스
 포함된 데이터 종류가 많은 컬럼을 먼저 써줘야
 가능한 한 등위연산자로 비교되는 항목부터
 불필요 인덱스...
★조회속도 개선 솔루션★
 적절한 인덱스 생성
 자료량 확인
 GeoServer가 생성하는 쿼리 확인
 쿼리플랜 확인
 데이터 분포 고려한 인덱스 생성
개선결과
결과 종합
 데이터 인서트
 몇 건마다 실행할 지가 중요
 사용 시스템에 따른 최적조건 찾기 필요
 100배 정도 성능 개선
 데이터파일 크기
 파티셔닝과 Truncate의 조합
 N-1일치 안정적 유지
...
시연
결론
 PostgreSQL은 정말 훌륭한 DBMS다!
 GeoServer와의 궁합도 정말 좋다.
 하지만 특성을 알아야 하고 튜닝해야 한다.
감사합니다!!!
Upcoming SlideShare
Loading in...5
×

[Foss4 g2013 korea]postgis와 geoserver를 이용한 대용량 공간데이터 기반 일기도 서비스 구축 사례

615

Published on

0 Comments
9 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
615
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
35
Comments
0
Likes
9
Embeds 0
No embeds

No notes for slide

Transcript of "[Foss4 g2013 korea]postgis와 geoserver를 이용한 대용량 공간데이터 기반 일기도 서비스 구축 사례"

  1. 1. PostGIS와 GeoServer를 이용한 대용량 공간데이터 기반 일기도 서비 스장병진, 금정우
  2. 2. Who am I  Gaia3D Open Source GIS Technical Manager  Open Source GIS Korean Localizer  Risk Surfer
  3. 3. 이 PT의 목적  석사과정 학생이 Oracle을 써서 느리면 학생 잘못 PostGIS를 써서 느리면 오픈소스 잘못!  Oracle의 장점은 모든 것을 튜닝할 수 있는 것 Oracle의 단점은 모두 튜닝해야만 하는 것  모든 서버에 다 통하는 격언  오픈 소스 GIS를 써서 느린 것이 아니라 튜닝을 안 해서 느린 것이다!
  4. 4. 배경지식
  5. 5. 모바일 일기도 서비스 관측 자료 GRIB Data Vector 일기도기상모델 벡터화 이미지화 서비스 용 일기도
  6. 6. 시스템 사용자
  7. 7. 기상자료 특징 실시간 / 준실시간저해상도 잦은 생산주기다차원 자료 지리적 해상도 낮음 평면+높이(등압면) +분석모델 +자료시간+예측시간 하루 수차례 ~수백차례 항상 최신자료 필요
  8. 8. 극복과제
  9. 9. 서비스 아키텍처 벡터 일기도
  10. 10. 1일 사용자료 회 생산 (00, 06, 12, 18 UTC) 개 공간 테이블 장의 일기도 MB의 자료 행의 공간 데이터
  11. 11. 어떻게 이런 서비스를 …
  12. 12. 극복과제 3가지 데이터 수집이 느리다 데이터 유지관리가 안 된 다 데이터 조회가 느리다 DB 전범 위 문제
  13. 13. B & F  튜닝전 상황  자료 인서트에 5시간  데이터파일 하루 35기가씩 커짐  일기도 한 장 조회시 수십초  개선목표  30분 이내 인서트  데이터파일 일정크기 유지  수초 이내 일기도 조회
  14. 14. 임포드속도 개선
  15. 15. 대용량 Update 출처: http://novathin.kr/19 건건이 실행 Batch Size 만큼 모아 한번에 실행 SQL을 실행하는 시기에 따라 성능의 차이가 크다!
  16. 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. 17. ★임포트 개선 솔루션★  JDBC 2.0의 addBatch(), exeuteBatch() 이 용 - JDBC 2.0을 지원하는 모든 DB에서 사 용가능  기존의 1 insert / 1 commit 에서  Kml파일 단위의(3000 insert) 마다 commit 으로 변경
  18. 18. 데이터 크기유지
  19. 19. PostgreSQL의 데이터관 리  PostgreSQL은 추기형  Update, Delete된 데이터 지우지 않음  마킹만 하고 새 데이터를 아래에 기록  장점  속도가 빠름  여러 버전의 데이터 관리가 가능  단점  데이터파일 크기가 심각하게 늘어날 수 있음  파일크기 증가에 따른 성능저하 가능성  일기도 DB 파일이 하루 35GB씩 커짐!!!
  20. 20. 스냅샷형 vs 추기형 테이블 A B’ C D E 테이블 A B X C D E B’ 스냅샷 B Transection 주인 기타 User 갱신전 레코드 갱신후 레코드 갱신전 레코드 갱신후 레코드 Oracle / MySQL PostgreSQL Transection 완료 후
  21. 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. 22. VACUUM FULL 기상청 일기도용 PostgreSQL은 Full VACUUM에 15시간 소요. VACUUM FULL 수행 중 배타적 LOCK 발생 출처: http://www.devmedia.com.br/otimizacao-uma-ferramenta-chamada-vacuum/1710
  23. 23. Partitioning  Partitioning 이란?  개념적으로 하나인 테이블을 여러 개로 쪼개어 관리  테이블당 자료량 줄어 인덱스 크기 감소, 검색속도 향상 일기도 일 기 도 _0 일 기 도 _1 일 기 도 _2 일 기 도 _3 일 기 도_4 일 기 도 _5 일 기 도 _6 일요일 Insert 월요일 Insert 화요일 Insert 일요일 Truncate 월요일 Truncate 화요일 Truncate Truncate는 실행시간이 거의 초단위이며, VACUUM 없이 파일이 줄어듦
  24. 24. ★데이터 유지 솔루션★  요일단위 파티셔닝  Insert시 각 요일별 테이블에 삽입  조회시 부모 데이블을 이용  날짜 연산을 통해 N일 단위 파티셔닝도 가능  데이터 삭제  Truncate를 이용해 자식 테이블 단위 삭제  항상 N-1 일치 정도의 자료량 유지 가능
  25. 25. 조회속도 개선
  26. 26. PostgreSQL의 쿼리특 징  통계를 적극 이용해 쿼리 실 행  이용할 인덱스 강제 지정 불가  쿼리 실행시 통계 데이터 참조 Optimize  Oracle 10g 보다 우수  통계는 일반적으로 자동 갱신 (Auto Vacuum과 함께)  Analyze 명령으로도 갱신 가능  재대로 된 인덱스 생성이 가장 중요 출처: http://helloworld.naver.com/helloworld/227936
  27. 27. 조회속도 개선 과정 데이터 현황 분석 쿼리 찾기 쿼리 플랜 분석 인덱스 개선
  28. 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. 29. GeoServer SQL 뷰  SQL 문을 Layer로 취 급  Geo DB가 데이터 소 스인 경우만 사용 가능  다음 난제 해결에 유용  복잡한 조건을 Layer로  좌표계 변환  여러 테이블 Join 필요  속성을 공간객체로 변 환
  30. 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. 31. 쿼리플랜 분석  PostgreSQL은 쿼리 분석기능 기본 탑재  pgAdmin III-쿼리-분석설명 메뉴  Explain Analyze 명령 – 이 방법이 분석 용이
  32. 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. 33. ★조회속도 개선 솔루션★  적절한 인덱스 생성  자료량 확인  GeoServer가 생성하는 쿼리 확인  쿼리플랜 확인  데이터 분포 고려한 인덱스 생성
  34. 34. 개선결과
  35. 35. 결과 종합  데이터 인서트  몇 건마다 실행할 지가 중요  사용 시스템에 따른 최적조건 찾기 필요  100배 정도 성능 개선  데이터파일 크기  파티셔닝과 Truncate의 조합  N-1일치 안정적 유지  조회 시간  쿼리에 맞는 적절한 인덱스  20배 정도 속도 개선
  36. 36. 시연
  37. 37. 결론  PostgreSQL은 정말 훌륭한 DBMS다!  GeoServer와의 궁합도 정말 좋다.  하지만 특성을 알아야 하고 튜닝해야 한다.
  38. 38. 감사합니다!!!
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×