피드로 돌아가기
Dev.toDatabase
원문 읽기
Bloom Filter 도입 통한 candidate 파일 658개에서 1개로 최적화
How Hard Is It to Add an Index to an Open Format? Lessons from the Apache Iceberg Community
AI 요약
Context
Partition Pruning 및 File-level Statistics 기반의 데이터 필터링 구조를 보유했으나, 비파티션 컬럼 기반의 point query 시 과도한 파일 스캔이 발생하는 Needle in a Haystack 문제 직면. 또한 Vector Search 수요 증가 및 MOR 모드의 Delete File 누적으로 인한 Read Amplification 심화로 새로운 접근 경로 확보가 시급한 상황.
Technical Solution
- Open Format 특성상 다양한 Write Engine 간의 호환성 확보를 위해 Index Lifecycle 및 Snapshot Binding 관계를 표준화한 Universal Foundation 설계
- Write Path의 복잡도 증가 및 엔진별 구현 차이 방지를 위해 Synchronous 업데이트 대신 Background Job을 통한 Asynchronous Maintenance 전략 검토
- 초기 단계에서 정합성 보장이 명확하고 쓰기 경로 변경이 필요 없는 Puffin 기반 Bloom Filter Skipping Index 우선 채택
- B-Tree 및 Vector Index 등 고성능 구조는 Materialized View나 전용 Native Structure를 활용하여 확장 가능한 플러그인 형태로 설계
- Catalog API 표준화를 통해 특정 쿼리 엔진에 종속되지 않는 Engine-agnostic한 인덱스 관리 체계 구축
실천 포인트
- 다수 엔진이 공유하는 데이터 포맷 설계 시, 쓰기 경로에 제약을 주는 동기식 업데이트보다 비동기식 메타데이터 갱신 구조 검토 - 인덱스 도입 전 기존의 통계 기반 Pruning 한계점을 정량적으로 분석하여 적합한 인덱스 타입(Bloom, B-Tree 등) 선정 - 특정 구현체에 종속되지 않도록 인터페이스(API)와 실제 저장소(Storage Medium)를 분리하는 추상화 계층 설계