SedonaDB 0.4: GPU 레이트레이싱 코어로 공간 조인을 5.93배 빠르게 만드는 방법 (RayBooster · VLDB 2026)

요약

공간 조인(spatial join)은 지리 데이터 처리에서 가장 비용이 큰 연산이다. "100만 개의 배달 주소 중 어느 것이 어떤 배달 구역 폴리곤 안에 있는가"처럼 기하 형상 두 집합을 교차 검사해야 한다. 기존 CPU 기반 R-tree 인덱스로도 한계가 있다.

2026년 6월 26일에 출시된 SedonaDB 0.4는 게이밍 GPU의 레이트레이싱(RT) 코어를 공간 조인에 최초로 적용한 프로덕션 데이터베이스 릴리스다. VLDB 2026 Industry Track에 채택된 RayBooster 논문(Ohio State University 협업)을 기반으로, 소비자용 RTX GPU 한 장으로 H100보다 빠른 공간 조인을 CPU 대비 5.93배, 비용 59% 절감으로 달성한다.

공간 조인이 왜 어려운가

공간 조인은 두 기하 데이터셋을 쌍으로 검사한다. 순진한 구현은 O(N×M)이다. 실무에서는 R-tree 인덱스나 그리드 기반 가속으로 필터링 단계를 줄이지만, 최종 정밀 검사(refinement phase)는 여전히 CPU에서 기하 연산을 직렬로 수행한다.

CPU 솔루션의 병목은 두 가지다.

1. 분기 집약적 기하 계산: 각 기하 형상 쌍에 대해 조건부 경로가 많다.
2. 캐시 비효율: 형상 데이터가 불규칙한 크기와 구조를 가져 CPU 캐시에 잘 맞지 않는다.

GPU 병렬화로 이를 돌파하려는 시도가 있었지만, 기존 GPU 커널 방식은 기하 형상 타입·조건자 조합마다 별도 커널을 작성해야 해 수백 개의 특수화 커널이 필요했다.

RayBooster: RT 코어를 공간 조인에 쓰는 원리

NVIDIA RTX 시리즈 GPU에는 레이트레이싱(RT) 코어가 있다. 이 코어는 비디오 게임에서 빛의 경로를 시뮬레이션하기 위한 레이-삼각형 교차 검사를 하드웨어로 가속한다. 데이터베이스 쿼리 시에는 이 코어가 완전히 유휴 상태다.

RayBooster는 공간 조인 조건자를 레이트레이싱 씬으로 사상(mapping)한다.

Z-stacking 인덱스 트릭

레이트레이싱 씬은 3D 공간이다. 공간 데이터는 2D(위도·경도)이므로 Z축은 사용되지 않는다. RayBooster는 이 미사용 Z축에 데이터베이스 행 ID를 인코딩한다.

이 단순한 트릭이 큰 이점을 만든다. 기존 GPU 공간 처리는 기하 형상마다 별도의 BVH(Bounding Volume Hierarchy)를 구축해야 했다. Z-stacking을 쓰면 전체 형상 배치에 대해 단일 전역 BVH 하나만 구축하면 된다. BVH 구축 오버헤드가 기하 형상 수에 선형으로 증가하는 것이 아니라, 배치 전체에 대해 상수 횟수로 줄어든다.

SoA(Structure of Arrays) 저장 레이아웃

기하 형상 데이터를 저장할 때 기존 방식(Array of Structures, AoS)은 형상 하나의 모든 속성을 연속 메모리에 저장한다. 이 경우 임의 형상에 접근하려면 가변 길이 데이터를 스캔해야 한다.

RayBooster는 offsets 배열, vertices 배열, geometry types 배열을 분리 저장하는 SoA 레이아웃을 쓴다. 이로써 형상 i의 시작 위치를 offsets[i]에서 O(1)로 조회할 수 있고, GPU의 랜덤 접근 메모리 패턴에 최적화된다.

RelateEngine: DE-9IM을 RT 코어에서 계산

공간 조인 조건자(ST_Contains, ST_Intersects, ST_Touches 등)는 내부적으로 DE-9IM(Dimensionally Extended 9-Intersection Model) 위상 행렬을 평가한다. 이 9칸짜리 이진 행렬이 두 기하 형상의 공간적 관계를 완전히 기술한다.

기존 GPU 구현들은 조건자 종류 × 기하 형상 타입 조합마다 전용 커널을 작성했다(수백 개). RelateEngine은 DE-9IM 행렬을 RT 코어에서 직접 계산함으로써 모든 기하 타입·조건자 조합을 단일 코드 경로로 처리한다. 유지 보수 부담이 드라마틱하게 줄어든다.

왜 H100보다 RTX GPU가 더 빠른가

이 결과는 직관에 반하지만 이유가 분명하다.

RT 코어는 소비자용 게이밍 GPU(RTX 시리즈)에만 탑재되어 있다. H100, A100 같은 데이터센터 컴퓨트 GPU는 ML 연산에 최적화된 Tensor 코어를 갖지만 RT 코어가 없다. RayBooster의 가속은 전적으로 RT 코어에 의존하므로, H100에서 실행하면 RT 코어 없이 소프트웨어 BVH 탐색으로 폴백(fallback)한다.

결과적으로 $1,500 수준의 RTX 4090 소비자 GPU가 $30,000 H100보다 RayBooster 벤치마크에서 더 빠르다.

지원 GPU: 컴퓨트 캐파빌리티 7.5 · 8.6 · 8.9 (RTX Turing · Ampere · Ada Lovelace 세대).

SedonaDB 0.4의 나머지 변경사항

RayBooster가 0.4의 핵심 기술 기여지만, 이번 릴리스는 그 외에도 상당한 범위의 업데이트를 포함한다.

API 확장

• Python DataFrame API: Ibis·DuckDB의 relational Python API에서 영감을 받은 공간 특화 DataFrame 인터페이스. SQL 없이 Python에서 공간 연산을 체이닝할 수 있다.
• R dplyr 바인딩: R 사용자는 익숙한 dplyr 문법으로 SedonaDB에서 공간 쿼리를 실행할 수 있다.

공간 타입·함수

• Geography 타입: Google s2geometry 라이브러리 기반. 구면(spherical) 거리 계산을 정확하게 처리한다 (기존 Geometry 타입은 평면 좌표 전제).
• 26개 새 공간 SQL 함수 추가. 해결된 이슈 총 187건.

패키징

• GeoParquet 개선: 공간 메타데이터를 Parquet 파일에 표준화된 방식으로 저장.
• conda-forge 패키지 등록: conda install -c conda-forge sedonadb로 설치 가능.
• 공식 Docker 이미지: GPU 기능 사용 시 권장 방법. 표준 Python 패키지에는 GPU 기능이 포함되지 않는다.

SedonaDB vs 분산 Apache Sedona: SedonaDB는 Spark·Flink 위의 분산 Apache Sedona와 별개의 단일 노드 분석 데이터베이스 엔진이다(DuckDB와 유사한 설계 철학). 분산 워크로드가 아닌 단일 머신 공간 OLAP을 위한 제품이다.

운영 체크리스트

• [ ] GPU 계열 확인: RT 코어는 RTX Turing(컴퓨트 7.5)·Ampere(8.6)·Ada Lovelace(8.9)에만 있음 — H100/A100은 RT 코어 없음
• [ ] GPU 기능은 opt-in: 표준 Python 패키지(pip install sedonadb)에 포함되지 않으므로 공식 Docker 이미지 사용 권장
• [ ] 공간 조인 규모 확인: 소규모(<10만 형상)에서는 CPU R-tree가 충분할 수 있음; GPU 초기화 오버헤드 고려
• [ ] Geography vs Geometry 선택: 전국 단위 거리 계산은 GEOGRAPHY 타입(s2geometry 구면 계산) 사용; 소지역 평면 좌표는 기존 GEOMETRY로 충분
• [ ] 분산 Apache Sedona(Spark/Flink)와 혼동 주의: SedonaDB는 단일 노드 엔진
• [ ] Python DataFrame API vs SQL: 새로운 Python API는 SQL보다 공간 연산 체이닝이 편리하지만 현재 지원 함수 목록 확인 필요
• [ ] R 사용자: dplyr 바인딩 사용 시 최소 R 버전과 패키지 의존성 확인
• [ ] GeoParquet 파이프라인: 외부 도구(GDAL, GeoPandas)와의 파일 호환성 검증

요점 정리

• 공간 조인은 기하 형상 두 집합의 쌍별 교차 검사가 필요한 연산이다. CPU R-tree로도 규모가 커지면 벽에 부딪힌다.
• RayBooster (VLDB 2026 Industry Track): 게이밍 GPU의 RT 코어를 공간 조인에 사상해 단일 코드 경로로 모든 기하 타입·조건자를 처리.
• Z-stacking: 미사용 Z축에 행 ID를 인코딩해 배치 전체에 단일 BVH 하나만 구축.
• SoA 레이아웃: 형상 데이터를 배열 분리 저장해 GPU O(1) 랜덤 접근 최적화.
• RelateEngine: DE-9IM 위상 행렬을 RT 코어에서 직접 계산 — 수백 개의 전용 커널 불필요.
• 성능: CPU 대비 5.93×, 비용 59% 절감. RTX 소비자 GPU가 H100을 능가 (RT 코어 유무 차이).
• SedonaDB 0.4는 Python DataFrame API, R dplyr 바인딩, Geography 타입(s2geometry), 26개 신규 공간 함수, GeoParquet 개선도 함께 출시했다.

References

• SedonaDB 0.4 릴리스 블로그 (2026-06-26): https://sedona.apache.org/latest/blog/2026/06/26/sedonadb-04-gpu-accelerated-spatial-joins/
• SedonaDB GitHub 릴리스: https://github.com/apache/sedona-db/releases
• SedonaDB 소개 (2025-09): https://sedona.apache.org/latest/blog/2025/09/24/introducing-sedonadb-a-single-node-analytical-database-engine-with-geospatial-as-a-first-class-citizen/