Spatial Query Index 최적화(공간 쿼리 최적화)

🤔 문제의식

개발을 하다 보니 좌표를 사용하는 경우가 꽤 있었다.

필자의 경우 대다수의 상황을 프론트가 지도를 연동하는 과정 속에 대부분 String으로 좌표값만 저장 후 전달해 주었던 것 같다.

새로운 프로젝트에서 사용자 위치 기반으로 가게를 거리별로 페이징 해주어야하는 부분이 있었고, 직접 처리해보고자 하였다.

String으로 처리하고자 하니 인덱싱이 되지 않는 문제가 있었다. 사용자의 위치를 기반으로 일정한 거리를 계산하고자 하니 풀 테이블 스캔이 필연적으로 발생하는 문제였다.

→ 프로젝트 규모상 위도 경도를 일정 범위로 제한한 뒤에 다시 원형으로 거리를 측정하는 방식을 도입하는 것만으로도 충분했지만 더 좋은 정보가 없나 찾아보았고 Spatial Query라는 것을 알게 되었다.

---

💡Spatial Query란?

• 정의
  • Spatial Query(공간 쿼리)는 단순히 속성(attribute) 값만을 조건으로 데이터를 조회하는 것이 아니라, 위치, 거리, 면적, 인접 관계 등 지리적 조건을 포함하여 데이터를 조회하는 방법이다.
• 예시
  • 일반 쿼리: “가격이 5만 원 이하인 가게 찾기”
  • 공간 쿼리: “사용자 위치에서 1km 이내에 있고, 가격이 5만 원 이하인 가게 찾기”
• 필요성
  • 문자열 좌표로는 단순 저장/조회만 가능 → 거리 연산, 인접성 판단 불가
  • Spatial Query는 GIS(Geographic Information System) 기능을 DB 레벨에서 지원 → 거리 계산, 포함 여부, 겹침 여부 등을 효율적으로 처리 가능
• DB 지원 기능 (간략하게)
  • MySQL: ST_Distance, ST_Contains, MBRContains 등
  • PostgreSQL(PostGIS): ST_DWithin, ST_Intersects 등
  • 이런 함수들이 Spatial Index와 결합하면 대규모 데이터에서도 빠른 검색 가능

👀 SRID

• SRID (Spatial Reference System Identifier)는 좌표계(Spatial Reference System, SRS)를 구분하기 위한 고유한 식별자다.
  • 간단히 말해, 이 좌표값이 어느 기준 좌표계에서 나온 값인지를 알려주는 ID라고 보면 된다.
• 예를 들어 같은 (127.0, 37.5)이라는 좌표라도,
  • 어떤 시스템은 위도/경도 (도 단위, WGS84)로 해석할 수 있고,
  • 어떤 시스템은 미터 단위 평면 좌표(UTM)로 해석할 수도 있다.
• 동일한 SRID를 가진 공간에 대해서만 질의를 할 수 있다.
  • 대표적으로 사용하는 4326의 경우 구글 등에서 사용하고 있으며,
  • 0을 사용하는 것은 무한한 2차원 좌표평면계를 이용한다는 것과 동일하다.

---

😀 사용법

JPA 엔티티 등록

@Column(columnDefinition = "POINT SRID 4326")를 통해 등록할 수 있다. 인덱스를 사용하기 위해서는 반드시 nullable = false 옵션이 추가되어야 하고, SRID를 설정해주지 않으면 0으로 자동 등록된다.

DB(Mysql) 등록

CREATE TABLE store (
    id BIGINT AUTO_INCREMENT PRIMARY KEY,
    name VARCHAR(100) NOT NULL,
    -- 좌표를 POINT 타입으로 저장 (SRID 4326 : 위도/경도)
    location POINT NOT NULL SRID 4326,
    SPATIAL INDEX (location) -- 공간 인덱스 생성
);

위와 같은 코드로 등록 및 인덱싱 또한 할 수 있다.

사용

상황에 따라 위도와 경도가 다를 수 있는데 위도/경도 순으로 제공하는 것이 일반적이다. DB 혹은 메서드에 따라 기준이 다를 수 있으니 꼭 찾아보고 사용하도록 하자.