반응형
PostGIS, Oracle Raster 기능비교
이번 글에서는 postgresql (PostGIS)와 Oracle DB (GeoRaster)의 각 래스터 기능에 대해서 알아보도록 하겠다.
먼저 둘은 저장방식이 완전히 다르다. postgis는 하나의 RASTER type에 일렬로 데이터를 저장하고, (이 때 TOAST가 적용) oracle은 최대한 분할해서 blob으로 관리한다. 이 차이에서 오는 가장 큰 결과는 모자이크와 타일링을 대하는 태도이다.
postgresql은 각각의 이미지를 wkb 포맷으로 그대로 저장하고 있기에, 하나의 RASTER TYPE에는 하나의 타일 이미지를 저장하기에 적합하다. 즉, 타일링을 해서 WMF, WMC와 같은 서비스를 하려면 한 테이블에다가 각 RASTER 타일을 row 단위로 관리하는 것이 적합하다.
오라클은 피라미드 레벨과, 타일링 을 모두 종합한 논리적인 개념을 래스터로 정의하고 있다.
따라서 GeoRaster라는 유저가 접근하는 개념 내부에 피라미드 레벨, 낱개의 타일들이 관리되고 있다.
따라서 타일링 수준이나 피라미드 레벨에 상관없이, 논리적으로 같은 이미지라면 하나의 GeoRaster로 관리하는 것이 더 적합하다.
Postgis Raster
Postgresql (PostGIS)
- 단일 Raster Column에 HexWKB 데이터를 저장함
- Raster Column은 postgresql의 TOAST로 관리됨, BLOB과 비교되는 특징은 전용 table space 분리를 할 수 없다는 것, 압축(LZ Compression) 지원
- raster2 pgsql이라는 자체 제작한 import 툴을 제공함.
- 피라미드에 대해서는 별도의 테이블로 관리하도록 설계가 되어있음.
- 기본적인 기능들은 대부분 지원함.
- 기능들은 GDAL(MIT) 라이브러리 함수를 사용하고 있는데, 싱글 스레드로만 작동하고 있음
- serial 데이터 형식이라 매번 단일 HexWKB 전체를 로딩해야 하므로, 오라클 대비 성능상으로 뒤쳐짐
Oracle Raster
Oracle (Oracle GeoRaster)
- SDO_Raster(유저가 접근하는 래스터), SDO_GeoRaster(시스템이 접근하는 분할된 데이터)라는 두 개의 오브젝트 형 칼럼으로 관리함
- SDO_Raster는 XML로 래스터 전체의 메타데이터를 관리함
- SDO_Raster는 SDO_GeoRaster로 이루어진 테이블의 이름을 저장하고 있음(Raster Data Table / RDT)
- 피라미드에 대해서도 한 SDO_Raster로 관리하도록 설계가 되어있음
- SDO_Raster 컬럼은 (rowBlock#, colBlock#, bandBlock#, pyramid#, raster_id)를 pk로 갖고, 나머지 필드로 mbr과 데이터 blob을 갖고 있음
- SDO_Raster의 Block을 쪼개는 기준은 Import 단계에서 유저가 설정이 가능함 (디폴트 : 512, 512, inf), 해당 값으로 픽셀을 나누는 개념.
- SDO_Raster의 MBR Field에서도 pixel 인덱스를 ordinate로 삼는 mbr을 갖고 있음
- SDO_Raster의 blob 영역은 공통 메타를 제외한 실제 픽셀 데이터 값만 들어있음, 인터리빙 방법에 따라 다르게 저장됨 (BIP, BSQ, BIL)
- SDO_Raster의 Blob data column은 압축(JPEG-F, DEFLATE)이 가능
- JAI, GDAL-based, in_db 세 가지 방식의 import/export 툴을 제공함
- 자체 포맷으로 관리하는 만큼, 사용법이 유저 친화적이진 않음, 오라클 raster toolkit을 제공함
- PostGIS 대비 훨씬 많은 기능들을 제공하고, 멀티 프로세싱과 멀티 스레딩도 지원함.
반응형
댓글