LLM WikiAccess-protected knowledge portal

WIKI

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

요약 공간 조인 spatial join 은 지리 데이터 처리에서 가장 비용이 큰 연산이다. "100만 개의 배달 주소 중 어느 것이 어떤 배달 구역 폴리곤 안에 있는가"처럼 기하 형상 두 집합을 교차 검사해야 한다. 기존 CPU 기반 R tree 인덱스로도 한계가 있다. 2026년 6월 26일에 출시된 SedonaDB 0.4 는 게이밍 GPU의 레이트레이싱 RT 코어 를 공간 조인에 최초로 적용한 프로덕션 데이터베이스 릴리스다

경로human/study/content/database-frontier/88-sedonadb-0-4-rt-cores-spatial-joins-raybooster.md
카테고리Study
태그#cores #joins #mysql #raybooster #sedonadb #spatial #study

요약

공간 조인(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)한다.

입력
기하 형상 집합 A
폴리곤·라인·포인트
기하 형상 집합 B
포인트·영역
↓
RayBooster 사상 계층
Z-stacking
row ID → Z축 인코딩
전체 배치 단일 BVH
SoA 레이아웃
offsets·vertices·types 분리
O(1) 랜덤 접근
↓
RT 코어
레이-삼각형 교차 검사
하드웨어 BVH 탐색
RelateEngine
DE-9IM 위상 행렬
단일 코드 경로
↓
출력
조인 결과
ST_Contains / ST_Intersects / ...
RayBooster: 공간 조인 → RT 코어 사상 구조

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 벤치마크에서 더 빠르다.

설정처리 시간H100 대비비용 대비
CPU (R-tree)기준 (1.0×)—기준
H100 (RT 코어 없음)0.7× 빠름1.0× (H100 기준)고비용
RTX GPU (RT 코어)5.93× 빠름RTX가 H100보다 빠름59% 절감

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

SedonaDB 0.4의 나머지 변경사항

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

API 확장

공간 타입·함수

패키징

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

운영 체크리스트

요점 정리

References