Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
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를 이용한 대용량 공간데이터 기반 일기도 서비스 구축 사례

2,595 views

Published on

[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. 감사합니다!!!

×