PostgreSQL, Materialized View 업데이트 속도 혁신!

by DD
1개월 전
조회수 10

PostgreSQL의 Materialized View는 변경 사항 발생 시 전체 데이터를 갱신하는 문제점을 가지고 있었음

제안된 패치는 `WHERE` 절을 추가하여 O(delta) 업데이트를 가능하게 함으로써 성능을 개선함

Statement-level trigger를 활용한 즉시 갱신(Immediate View Maintenance)과 pg_cron을 이용한 지연 갱신(Deferred View Maintenance) 패턴을 제시함

커뮤니티에서는 패치의 성능 개선 효과에 대한 기대와 긍정적인 반응을 보임

O(delta) 업데이트 구현 기술

제안된 패치는 Materialized View의 갱신 시 `WHERE` 절을 사용하여 변경된 데이터만 처리하도록 최적화한다. 기술적으로, 옵티마이저(Optimizer)가 predicate를 기본 테이블로 푸시(Push)하여 전체 데이터셋 대신 변경된 데이터에 비례하는 갱신을 수행한다. 이는 기존 O(total) 방식의 갱신 문제를 해결하고, 데이터 처리량(Throughput)을 향상시키는 핵심 기술이다. 특히, 대용량 데이터셋에서 갱신 속도를 획기적으로 개선할 수 있다.

즉시 갱신(Immediate) vs 지연 갱신(Deferred) 아키텍처

패치는 두 가지 갱신 패턴을 제시한다. 즉시 갱신(Immediate View Maintenance)은 statement-level trigger를 사용하여 변경 사항을 즉시 반영하며, 데이터 일관성(Data Consistency)을 보장한다. 반면, 지연 갱신(Deferred View Maintenance)은 pg_cron을 사용하여 주기적으로 갱신하며, 쓰기 지연 시간(Write Latency)을 최소화한다. 두 방식 모두 장단점이 존재하며, 시스템 요구 사항에 따라 적절한 아키텍처를 선택해야 한다.

동시성(Concurrency) 문제 해결

저자는 초기 구현에서 발생한 락킹(Locking) 문제를 해결하기 위해, SELECT FOR UPDATE를 사용한 2단계 SPI 실행 전략을 채택했다. 이는 동시적인 부분 갱신(Partial Refresh)을 안전하게 처리하기 위한 핵심 기술이다. 또한, 빈번한 트리거 기반 갱신으로 인한 재컴파일 오버헤드(Recompilation Overhead)를 줄이기 위해 세션 레벨 캐시를 추가했다. 이러한 기술적 개선을 통해 시스템의 안정성을 확보했다.

성능 테스트 및 향후 과제

저자는 테스트를 위해 pgbench 결과를 포함한 테스트 하네스를 제공하여, 패치의 성능을 검증했다. 테스트 결과는 O(delta) 업데이트의 성능 향상(Performance Improvement)을 입증했다. 향후 과제로는 트리거 함수 작성, staging table 생성 등 수동 설정을 엔진 자체에서 지원하는 방향으로의 개선이 제시되었다. 이는 개발자의 편의성을 높이고, Materialized View의 활용성을 더욱 증대시킬 것이다.

I wrote a PostgreSQL patch to make materialized view refreshes O(delta) instead of O(total)