Jackpine: 공간 데이터베이스 성능평가 연구(2011)

논문 소개

Jackpine: A benchmark to evaluate spatial database performance

이 논문은 2011년에 IEEE Conference에서 발표된 문헌이다. 공간 데이터베이스의 성능을 평가하기 위한 데이터 출처와 쿼리 표를 제공하였으며, 실제로 일부 데이터베이스(PostgreSQL, Informix, MySQL)에서 지원하는 공간 쿼리의 성능을 평가 및 분석하였다.

 

이어서 실제 논문을 구성하는 순서에 따라 핵심이 될 만한 내용을 중심으로 설명해보도록 하겠다.

 

Abstract

공간 쿼리의 성능은 데이터베이스마다 다르다. 그러나 이들간의 성능을 평가할 수 있는 지표가 없었다. 그래서 이 연구를 통해 Jackpine이라는 성능평가 기법을 소개하고자 한다. 

 

성능평가를 위한 쿼리 표는 크게 Micro Benchmark와 Macro Benchmark로 구성되어 있다.

• Micro Benchmark: DE-9IM을 이용한 위상적 관계 계산 성능 및 간단한 공간 분석 함수의 성능을 검증한다.
• Macro Benchmark: 지도 검색, 지도 탐색, 지오코딩, 역지오코딩, 홍수피해분석 등의 고급 분석 성능을 검증한다.

 

이 문헌에서는 2개의 오픈소스 DB와 1개의 상업 DB를 대상으로 직접 실험해보고, 성능을 평가해보았다.

 

1. Introduction

공간 데이터는 계속해서 생성되고 있으며, 그 쓰임새는 날로 다양해지고 있다고 한다. 실제로 NASA에서는 매일 1TB 가량의 데이터를 생성 중이며, 비즈니스 데이터의 약 80%는 공간 데이터가 포함되어 있다고 한다.

 

GIS에서 사용되는 공간 쿼리는 유의미한 데이터를 발견할 수 있는 기능으로, 일반적으로 공간 데이터베이스라는 용어는 공간 데이터를 일반 데이터처럼 활용할 수 있는 관계형 데이터베이스를 가리킬 때 사용된다.

 

이러한 공간 데이터베이스의 성능은 True Geodetic(바로가기) 지원여부, 지원하는 공간 함수 및 공간 인덱싱 종류와 구현 형태에 따라 매우 다르다. 각 항목에 따라 나열하면 다음과 같다:

• True Geodetic 지원여부:
  • 지원: Oracle, DB2, SQL Server
  • 미지원: MySQL, Ingres
  • 부분 지원: PostgreSQL(Point-Point 거리 측정시에만 지원), Informix(유료 버전에서만 지원)
• Spatial Function 관련:
  • OGC 제안 함수 + Custom Geodetic 함수: SQL Server, Oracle, DB2, Informix, PostgreSQL
  • OGC 제안 함수 + MBR 활용: MySQL
• Spatial Index 관련:
  • R-Tree: 대부분(PostgreSQL은 Generalized R-Tree Index, GiST)
  • Grid: SQL Server

 

이렇게 다양한 공간 데이터베이스의 성능을 비교하고자 하는 수요는 있지만, 정작 이를 위한 연구는 미흡했다. 트랜잭션을 위한 성능평가 연구 및 공간 데이터 자체에 대한 성능평가 연구는 존재해왔으나 공간 데이터베이스 성능을 평가하는 데에는 도움이 되지 않아왔다.

 

2. Related Work

2.1. Non-Spatial DB Benchmarks

일반적으로 데이터베이스의 성능을 평가하기 위해서는 특정 도메인에서 자주 사용되는 질의를 한정하여 평가한다. 이 논문에서는 다음과 같은 데이터베이스 성능비교 연구들을 언급하고 있다: Wisconsin Benchmark, TPC, PolePosition, OSDB, SEPCweb2009, ..

 

위 성능비교 연구들은 공간 데이터를 위한 비교를 하고 있지 않았다.

 

2.2. Spatial DB Benchmarks

이어서 공간 데이터를 위한 성능비교 연구에 대해서 언급하였다.

 

SEQUOIA 2000(1993)은 그나마 잘 알려진 공간 데이터 관련 성능비교 방법이다. 그러나 오늘날 많이 사용하는 벡터 기반의 데이터가 아닌 래스터 기반의 데이터를 대상으로 삼고 있으며, 지구과학 분야의 연구라서 공간정보 분야와는 사뭇 다른 느낌이다.

 

VESPA(2000)는 개선된 방법으로, 벡터 데이터를 대상으로 삼았으며, 비교적 많은 공간 연산 작업을 포함하여 성능비교를 하였다. 그러나 비교하는 연산들이 모든 공간 데이터베이스의 기능을 다루지 못하였으며, 실제 GIS 작업 사례를 모델링하지 않았기에 현실 상황을 반영한다고 보기 어렵다고 한다.

 

심지어 최근 몇 년동안은 공간 데이터를 다루는 성능비교 연구 사례가 거의 없었다고 한다. 그나마 있었던 Power(2009)는 데이터셋이 작다고 직접 언급하였으며, Dynamark(2003)와 BASIS(1999)는 공간 인덱싱 구조에 대한 평가지표였기에, 이 연구의 목적과는 다른 분야의 연구였다.

 

3. The Benchmark

Micro Benchmark는 공간 조인 쿼리, 위상적 관계 및 공간 분석 쿼리, 로딩 쿼리를 대상으로 평가하는 지표였고, Macro Benchmark는 6가지의 실제 공간분석 사례를 기반으로 사용되는 쿼리를 대상으로 평가하는 지표였다.

 

(3.1. 건너뛰기)

 

3.2. Data Model

TIGER/Line Shapefiles

 

데이터는 TIGER(Topologically Integrated Geographic Encoding and Referencing) 데이터셋 활용하였다. 현재도 위 링크를 통해 원하는 미국 지역에 대해 시기별로 공간+속성 데이터를 얻을 수 있다.

 

논문에서는 미국에서 가장 큰 State임과 동시에 다양한 공간적 특징을 지닌 Texas State를 대상 지역으로 삼았다. 또한 Macro Benchmark를 위해 Austin 과 Travis County에 대한 정교한 GIS 데이터셋을 사용했다고 한다. 어느 시기의 데이터를 얻었는지에 대해서는 명시되지 않았다.

 

참고로, 사용된 데이터의 용량을 살펴보면 약 3GB 정도였다.

 

3.3. Micro Benchmark

Clementini & Di Felice가 제안한 DE-9IM 모델을 이용한 위상적 관계를 계산하도록 질의표를 제작하였다. 이 부분의 표2를 보면 성립 가능한 위상적 관계를 나름대로 분석하여서, 필요한 연산만 할 수 있도록 고민한 흔적이 있다.

 

예: "Line과 Line끼리는 Touches 관계만 성립할 수 있기 때문에, Touches 연산에 대한 성능만 비교하겠다."

 

3.4. Macro Benchmark

실제로 GIS 분석 작업에서 사용되는 시나리오를 반영한 쿼리 표이다. 흥미롭게도, 각 시나리오는 일련의 순서대로 실행되어야 함을 명시하고 있다. 그래서 모든 순서를 수행하기까지 소요된 시간을 측정하도록 하였다.

 

각 시나리오에 대해 간략하게 설명하면 다음과 같다:

• Geocoding : 다른 공간 관련 정보를 가지고 좌표 정보를 추출하는 작업
• Reverse Geocoding : 좌표 정보를 가지고 주변 정보를 추출 → LBS
• Map Search and Browsing : POI 검색 및 지도에 표현하는 작업,
• Flood Risk Analysis : FIRM(Rlood Insurance Rate Map) 이용하여 홍수 발생 위험도 데이터 알아내어 분석하는 작업
• Land Information Management : 토지피복 관련 GIS 작업
• Toxic Spill : 유해물질 유출 분석

 

4. Experimental Setup

사용한 기기의 스펙을 작성하면서, 램에 데이터가 남는 것을 방지하기 위해 일부러 적은 용량의 메모리(512MB)를 할당했다고 언급하였다.

 

실험을 위해 각 데이터베이스(PostgreSQL, MySQL, Informix)에서 공간 인덱싱을 적용했으며, JDBC를 이용하여 실험했다고 한다. 한 번에 하나의 데이터베이스만 실행되도록 설계하였으며, 각 쿼리에 대해 맨 처음으로 실행된 경우를 Warmup 쿼리로 삼았다. 그리고는 3회씩 측정하여 평균적인 쿼리 시간을 측정하였다.

 

5. Benchmark Results

전체적으로 쿼리마다 실행시간의 편차가 큰 편이었다. 주목할 만한 점으로, MySQL은 Refinement 과정을 수행하지 않는다는 특징으로 인해 빠른 쿼리 성능을 보였으나, 안정성이 떨어진다는 관측이 있었다.

 

A. Data Loading

• MySQL: ogr2ogr
• PostgreSQL: shp2pgsql
• Informix: loadshp

데이터 로딩을 위해 각 데이터베이스에서는 위와 같은 도구를 사용하였다. 공통적으로 shp 파일을 Table 형태로 바꾼 후, 비공간 인덱싱 및 공간 인덱싱을 수행하였다.

 

B. Micro Benchmark

 

쿼리마다 유리한 데이터베이스 종류가 각각 달랐다. 극단적인 경우를 예로 보여주자면, AreaDisjointArea 연산을 제외하고는 Informix 성능이 좋았다. 그러나 AreaDisjointArea 연산에서만큼은 Informix가 논에띄게 불리한 결과를 보였다.

 

C. Macro Benchmark

 

MySQL이 뛰어난 결과를 보였다. 그러나 문헌에서는 앞서 언급한 것처럼 Refinement 과정이 생략되었기 때문에 쿼리 시간이 짧게 기록된 것이라고 분석하였다.

 

D. Overall Score

논문에서는 전체적인 쿼리 성능을 비교하기 위해 위와 같은 식을 활용하였다. 이 방식의 한계로는, 모든 데이터베이스(MySQL, PostgreSQL, Informix)에서 모두 동작한 쿼리를 대상으로만 해당 식을 활용하여 비교했다는 점이다.

 

모든 쿼리를 대상으로 정상적으로 동작한 PostgreSQL를 기준으로 했을 때, PostgreSQL의 점수가 1.00이라고 할 때, 다음과 같은 결과가 나왔다.

• Microbenchmark
  • PostgreSQL: 1.00
  • MySQL: 2.21
  • Informix: 5.84
• Macrobenchmark
  • PostgreSQL: 1.00
  • MySQL: 1.06
  • Informix: 0.32

다시 말하지만, 이 수치는 세 데이터베이스에서 모두 동작한 쿼리를 대상으로만 비교한 것임을 명심해야 한다.

 

6. Discussion

Discussion 부분에서는 논문의 주 의의에 대해서 강조하는 느낌이었다. 논문에서 강조한 의의는 다음과 같다:

• 그동안 없었던 공간 데이터베이스를 위한 성능평가 연구를 수행했다.
• 이 방법은 JDBC를 지원하는 모든 데이터베이스에 적용할 수 있을 정도로 유연하다.
• 이 방법은 SEQUOIA 2000에서 제시된 모든 시나리오를 포함할 만큼 풍부하다.

 

개인적 소감

논문에서 제시된 데이터 셋(TIGER data), 데이터 수집 범위(Texas State), 그리고 쿼리 셋(Micro & Macro Benchmark)은 공간 데이터베이스에서 지원하는 공간 연산의 성능을 평가하기에 가치 있는 정보들이었다. 나도 실제로 공간 연산자의 성능을 평가하기 위해 이 방법론을 사용하였다.

 

아쉬운 점은 논문에서 공개했다고 주장한 데이터 셋 및 벤치마킹 툴의 Link가 소멸되었다는 점이다. 때문에 이 논문에서 제시된 방법을 사용하여 성능을 비교하기 위해서는 직접 TIGER 데이터가 있는 홈페이지에 방문하여 다운로드 받고, 필요하다면 직접 Merge, Clip 작업을 해야 한다는 불편함이 있다. 또한, 논문에서 사용한 데이터가 몇 년도의 데이터인지 알 수가 없으며 구체적인 구축 방법에 대해서 묘사하고 있지 않기 때문에 논문과 동일한 실험 환경을 재현하기에 무리가 있다는 한계가 있었다.