MySQL과 MongoDB 공간 인덱스의 차이

개요

런세권 프로젝트를 개발하며 MySQL에서 MongoDB로 마이그레이션했고, 그 결과 API 응답 속도를 크게 개선할 수 있었다. 처음에는 단순히 NoSQL인 MongoDB가 더 빠르다고만 생각했는데, 이 글을 쓰며 그 차이가 공간 인덱스가 도형을 근사하는 방식의 차이에서 비롯된다는 것을 이해했다.

 

이 글에서는 공간 데이터의 기본 개념부터 MySQL과 MongoDB가 각각 공간 데이터를 저장하고 인덱싱하는 방식을 비교하며, 그 내부 동작 원리를 정리한다.

 

공간 데이터란 무엇인가?

공간 데이터는 기하학적 개체의 물리적 위치 및 모양에 대한 정보를 나타내며, GIS 서비스에서 핵심적으로 사용되는 데이터이다. 공간 데이터와 관련된 표준은 OGC(Open Geospatial Consortium, 개방형 공간 정보 컨소시엄)이라는 국제 표준화 기구에서 지정한다.

예를 들어 '부산'이라는 개체에 대한 공간 데이터는 다음과 같이 표현할 수 있을 것이다.

네이버 지도

 

현재 공간 데이터는 OGC Simple Features 표준에 따라 정의된 명세를 사용하고 있다. 해당 표준에 따르면 공간 데이터는 대표적으로 3가지의 데이터 형식으로 표현된다.

• Point(점): 단일 좌표
  • 예) 어느 특정 카페의 위치
• LineString(선): 좌표들을 이은 선
  • 예) 러닝 코스, 도로
• Polygon(면): 닫힌 선으로 이루어진 면
  • 예) 지도 속 부산 광역시 행정 경계

공간 데이터는 결국 좌표로 표현된다. 하지만, 같은 좌표라도 어떤 기준 위에서 해석하느냐에 따라 실제 위치가 달라질 수 있다. 이 기준을 좌표 참조 시스템(CRS, Coordinate Reference System) 이라고 하며, SRID(Spatial Reference Identifier)는 특정 CRS를 식별하는 ID이다.

 

공간의 기준이 되는 SRID

지구 상의 위치를 좌표로 변환하는 방법은 크게 두 가지로 나뉜다.

1. GCS(Geographic Coordinate System)
2. PCS(Projected Coordinate System)

 

GCS(Geographic Coordinate System, 지리 좌표계)

지리 좌표계(GCS)는 지구를 회전 타원체로 간주하고, 그 표면의 위의 위치를 위도와 경도로 나타내는 좌표계이다. 그런데 실제 지구는 완벽한 타원의 모양을 하지 않고, 울퉁불퉁한 모양을 갖고있다. 그래서 회전 타원체를 지구의 어느 중심에 위치시키느냐에 따라 같은 위도/경도라도 표현되는 위치는 달라질 수 있다.

그래서 회전 타원체 모양과 그 중심에 대한 정보를 함께 표현해야 한다. 대표적인 GCS로는 WGS84, GRS80, NAD83 등이 있다. 이 중 WGS84가 GPS에서 사용하는 국제 표준에 해당한다.

 

PCS(Projected Coordinate System, 투영 좌표계)

투영 좌표계(PCS)는 3차원의 지구를 2차원인 평면에 투영한 좌표계이다. GCS가 위도/경도로 좌표를 나타내는 반면에 PCS는 미터(m) 단위의 x, y 좌표로 위치를 나타낸다.

지구를 평면으로 펼치면서 필연적으로 왜곡이 발생하기에, 어떤 속성(면적, 형태, 거리 등)을 얼마나 보존할지에 따라 다양한 투영 방식이 존재한다. 대표적으로 UTM이 있으며, 한국은 EPSG 5179를 투영 좌표계를 사용한다.

 

SRID

이처럼 지구 상의 위치를 좌표로 변환하는 방법에 어떤 것들이 존재하는지 살펴보았다. 이러한 방법으로 만들어진 여러 좌표계들을 식별하기 위해서 간단하게 SRID라는 고유 ID를 사용한다.

예를 들어 SRID 4326은 WGS84 좌표계를 의미한다. MongoDB의 2dsphere 인덱스는 WGS84를 기본으로 가정하며, MySQL은 기본값은 0이지만 테이블 생성 시 SRID 4326을 명시적으로 설정해줄 수 있다.

 

MySQL에서의 공간 데이터 처리 방식 파헤치기

앞서 공간 데이터의 형태(Point, Polygon 등)와 그 기준이 되는 도화지(SRID)에 대해 알아보았다. 그렇다면 MySQL은 이 2차원의 도화지 위에 그려진 복잡한 데이터들을 어떻게 저장하고 빠르게 검색할까?

 

MySQL은 공간 데이터들을 효율적으로 저장하기 위해 세 가지 포맷을 활용한다.

• WKT(Well-Known Text)
  공간 데이터를 사람이 읽을 수 있는 텍스트 형태로 표현한 OGC 표준이다. 흔히 쿼리를 작성할때 사용되는 포맷이다.
• WKB(Well-Known Binary)
  해당 포맷은 순수 이진 형태로 네트워크를 통해 데이터를 송수신할때 효율적으로 교환하기 위한 포맷이다. 16진수 바이트 배열로 표현하며 이 또한 OGC 국제 표준이다.
• Internal Geometry Storage
  MySQL이 실제로 디스크에 공간 데이터를 저장할 때 사용하는 포맷이다. WKB 포맷에 4바이트의 SRID 숫자를 조합하여 저장한다.

 

즉, 개발자는 WKT로 쿼리를 작성하고, 애플리케이션과 MySQL 사이의 데이터 전달은 드라이버가 WKB로 처리하며, MySQL은 최종적으로 SRID + WKB 형태의 Internal Geometry Storage로 디스크에 저장한다.

 

이렇게 저장된 데이터를 빠르게 검색하기 위해서는 공간 인덱스를 활용해야 한다. MySQL은 수학적 계산을 기반으로 공간 인덱스를 계산 및 처리한다. 공간 인덱스와 관련해서는 이미 작성해두었던 과거 글을 참고하면 된다.

 

MongoDB에서의 공간 데이터 처리 방식 파헤치기

앞서 MySQL에서는 공간 데이터를 어떻게 저장하고, 인덱스를 만드는지 살펴보았다. 이번에는 런세권 프로젝트에서 사용하고 있는 MongoDB를 기준으로 공간 데이터를 어떻게 저장하고, 인덱스를 만드는지 살펴보자.

 

기본적으로 MongoDB는 BSON이라는 데이터 포맷으로 데이터들을 저장하지만, 공간 데이터의 경우 GeoJSON이라는 형태를 이용하고 있다. 이는 OGC 표준은 아니고 개방형 공개 표준 형식으로 JSON 형태로 공간 데이터를 저장하는 포맷이다.

{
  "type": "Feature",
  "geometry": {
    "type": "LineString",
    "coordinates": [
      [127.0276, 37.4979], // [경도, 위도]
      [127.0280, 37.4985],
      [127.0291, 37.5001]
    ]
  },
  "properties": {
    "courseName": "강남역 1km 왕복 코스",
    "difficulty": "Easy",
    "distance": 1000
  }
}

 

이러한 형태로 저장되는데, 이게 하나의 러닝 코스를 의미한다. type을 통해 Feature, FeatureCollection, 공간 데이터 타입과 같은 것을 나타낼 수 있고 geometry를 통해 실제 저장되는 공간 데이터를 지정할 수 있다. 또한, 공간 데이터에 대한 부가 정보를 properties에 담을 수 있다.

 

하지만 MongoDB에서는 GeoJSON의 Feature 구조 전체를 저장하는 것이 아니라, geometry는 별도 필드로, properties의 내용은 일반 필드로 분리하여 도큐먼트 안에 저장한다. 그래서 실제로는 아래와 같은 형태로 저장된다.

{
  "courseName": "강남역 1km 왕복 코스",
  "difficulty": "Easy",
  "distance": 1000,
  "location": {
    "type": "LineString",
    "coordinates": [
      [127.0276, 37.4979], // [경도, 위도]
      [127.0280, 37.4985],
      [127.0291, 37.5001]
    ]
  }
}

 

S2 Geometry

MongoDB에서는 공간 인덱스를 위해서 구글에서 만든 S2 Geometry를 이용한다. 구를 6개의 면으로 나누어 각 면을 재귀적으로 4등분하여 작은 셀(Cell) 단위로 지구를 구성한다. 단계별로 알아보자.

 

1. 지구를 정육면체로 감싸기

Gemini 생성 이미지

 

MySQL의 공간 인덱스의 MBR처럼 지구를 커다란 직육면체 모양의 MBR로 감싼다. 그리고 각 면으로 지구를 나눈다. 각 면은 평면이기에 구면을 투영하게 되면 왜곡이 생기기 때문에 S2는 내부적으로 보정 함수를 통해 셀 크기 편차가 최대 5.2배 이내로 유지되도록 한다.

 

2. 계층적 셀 분할

정육면체로 감싸인 6개의 면은 다시 4개의 사각형 셀(Cell)로 쪼개진다. 이 과정은 재귀적으로 반복되며, MongoDB가 사용하는 S2 Geometry는 최대 30단계까지 분할할 수 있다.

 

30 레벨에 다다르면 약 0.48cm^2 만큼 작은 크기의 셀이 만들어진다.

 

3. 힐베르트 곡선

2차원 평면(정육면체의 면) 위에 쪼개진 수많은 셀 조각들을 어떻게 컴퓨터가 이해하기 쉬운 순서로 정렬할까? 여기서 힐베르트 곡선이라는 공간 채움 곡선이 사용된다.

 

힐베르트 곡선은 레벨 30에 해당하는 셀들에 대해서 힐베르트 곡선을 만든다. 상위의 레벨의 셀은 해당 곡선의 범위로 표현할 수 있기 때문이다.

 

곡선 경로는 프랙탈 구조로 생성한다. 이 과정에서 각 셀은 고유한 64비트 Cell ID를 부여받으며, 이 ID를 통해 셀의 위치와 레벨을 모두 식별할 수 있다. 셀 ID는 다음처럼 64비트 정수 하나로 표현된다.

 

[ 3비트: 면(0-5) ][ 나머지: 위치 ][ 1: 레벨 표시 ][ 0으로 패딩 ]

• 상위 3비트는 정육면체의 어느 면인지 표현한다.
• 중간 비트는 아래 설명할 힐베르트 곡선 상의 위치이다.
• 1비트로 현재 셀의 레벨 경계를 표시한다. -> 1의 위치로 레벨을 알 수 있다.

 

힐베르트 곡선의 핵심 특성은 공간적으로 가까운 셀일수록 Cell ID도 가깝다는 것이다. 덕분에 특정 영역을 검색할 때 해당 영역을 커버하는 셀들의 Cell ID가 B-Tree 상에서 연속된 범위에 몰려있어, 범위 탐색 한 번으로 효율적으로 찾을 수 있다. 즉, R-Tree를 사용하지 않아도 된다.

 

그래서 MongoDB의 2dsphere 인덱스는 도형을 셀 ID 집합으로 변환하고 B-Tree에 저장한다. 탐색 시에는 검색 영역의 셀 ID 범위와 매칭되는 도큐먼트를 찾는다.

 

요약하면, 지구를 정육면체로 감싸고(1단계), 이를 작은 정육면체로 계속 쪼개어(2단계), 꼬불꼬불한 선으로 순서를 매겨(3단계) 각 위치에 번호표(Cell ID)를 붙여 관리하는 방식이다.

 

정리하면

MySQL의 R-Tree는 MBR이라는 직사각형으로 도형을 근사하기 때문에, 인덱스 탐색 후 실제 도형에 해당하지 않는 가짜 데이터를 걸러내는 2차 필터링이 필요하다. 반면 MongoDB의 S2 Geometry는 여러 셀의 조합으로 도형을 보다 정밀하게 근사하기 때문에 가짜 데이터가 줄고, Cell ID 기반 B-Tree 범위 탐색으로 효율적인 조회가 가능하다.

 

런세권 프로젝트에서 MySQL의 공간 쿼리 성능 문제를 겪은 후 MongoDB로 마이그레이션했는데, 이 글을 정리하며 그 성능 차이가 단순한 DB 선택의 문제가 아니라 인덱스의 도형 근사 방식 차이에서 비롯된 것임을 이해할 수 있었다.