머티리얼라이즈드 뷰 사용하기
머티리얼라이즈드 뷰 사용하기
머티리얼라이즈드 뷰는 미리 계산해 저장한 결과로 쿼리를 가속화합니다. ClickHouse에는 증분(incremental)형과 갱신(refreshable)형 두 종류가 있으며, 이 문서에서는 각각을 언제 써야 하는지 알려드릴게요.
출처: 문서
본문
ClickHouse는 두 가지 유형의 머티리얼라이즈드 뷰를 지원합니다: 증분형(incremental)과 갱신형(refreshable)입니다. 둘 다 결과를 미리 계산하고 저장하여 쿼리를 가속화하도록 설계되었지만, 기본 쿼리가 언제 어떻게 실행되는지, 어떤 워크로드에 적합한지, 데이터 신선도(freshness)를 어떻게 처리하는지에서 크게 다릅니다. 가속화해야 할 특정 쿼리 패턴에 대해 머티리얼라이즈드 뷰를 고려하세요. 단, 타입과 프라이머리 키 최적화에 관한 이전 모범 사례를 먼저 수행했다고 가정합니다. 증분 머티리얼라이즈드 뷰는 실시간으로 갱신됩니다. 소스 테이블에 새 데이터가 삽입되면 ClickHouse가 자동으로 머티리얼라이즈드 뷰의 쿼리를 새 데이터 블록에 적용하고 그 결과를 별도의 대상 테이블에 기록합니다. 시간이 지나면 ClickHouse는 이 부분적인 결과들을 병합하여 완전하고 최신의 뷰를 만들어 냅니다. 이 접근 방식은 계산 비용을 삽입 시점으로 옮기고 새 데이터만 처리하기 때문에 매우 효율적입니다. 그 결과 대상 테이블에 대한 SELECT 쿼리는 빠르고 가볍습니다. 증분 뷰는 모든 집계 함수를 지원하며 각 쿼리가 삽입 중인 데이터셋의 작고 최근의 일부만 처리하기 때문에 페타바이트 규모의 데이터까지 잘 확장됩니다. 반면 갱신형 머티리얼라이즈드 뷰는 스케줄에 따라 갱신됩니다. 이 뷰는 주기적으로 전체 쿼리를 다시 실행하고 그 결과를 대상 테이블에 덮어씁니다. 이는 Postgres 같은 전통적인 OLTP 데이터베이스의 머티리얼라이즈드 뷰와 유사합니다. 증분형과 갱신형 중 어느 것을 선택할지는 쿼리의 성격, 데이터가 얼마나 자주 바뀌는지, 그리고 뷰의 갱신이 삽입되는 모든 행을 반영해야 하는지 아니면 주기적인 갱신이 허용 가능한지에 크게 달려 있습니다.
증분 머티리얼라이즈드 뷰를 사용해야 하는 경우
증분 머티리얼라이즈드 뷰가 일반적으로 선호됩니다. 소스 테이블이 새 데이터를 받을 때마다 실시간으로 자동 갱신되기 때문입니다. 모든 집계 함수를 지원하며 단일 테이블에 대한 집계에 특히 효과적입니다. 삽입 시점에 결과를 증분 계산하므로 쿼리는 훨씬 더 작은 데이터 하위 집합에 대해 실행되며, 덕분에 이 뷰들은 페타바이트 규모까지 쉽게 확장됩니다. 대부분의 경우 전체 클러스터 성능에 눈에 띄는 영향을 주지 않습니다. 다음과 같은 경우 증분 머티리얼라이즈드 뷰를 사용하세요:
- 모든 삽입마다 갱신되는 실시간 쿼리 결과가 필요할 때.
- 대량의 데이터를 자주 집계하거나 필터링할 때.
- 쿼리가 단일 테이블에 대한 간단한 변환이나 집계를 포함할 때.
증분 머티리얼라이즈드 뷰의 예시는 여기를 참고하세요.
갱신형 머티리얼라이즈드 뷰를 사용해야 하는 경우
갱신형 머티리얼라이즈드 뷰는 증분 방식이 아닌 주기적으로 쿼리를 실행하며, 빠른 검색을 위해 쿼리 결과 집합을 저장합니다. 쿼리 성능이 중요하고(예: 서브 밀리초 지연) 약간 오래된 결과가 허용될 때 가장 유용합니다. 쿼리가 전체로 다시 실행되므로, 갱신형 뷰는 계산이 상대적으로 빠르거나 드문 간격으로 계산할 수 있는(예: 시간별) 쿼리, 예를 들어 "top N" 결과나 룩업 테이블 캐싱에 가장 적합합니다. 시스템에 과도한 부하를 주지 않도록 실행 빈도를 신중하게 조정해야 합니다. 상당한 리소스를 소비하는 매우 복잡한 쿼리는 신중하게 스케줄링해야 합니다. 이는 캐시에 영향을 주고 CPU와 메모리를 소비하여 전체 클러스터 성능을 저하시킬 수 있습니다. 쿼리는 클러스터에 과부하를 주지 않도록 갱신 간격에 비해 상대적으로 빠르게 실행되어야 합니다. 예를 들어 쿼리 자체를 계산하는 데 최소 10초가 걸린다면 뷰를 10초마다 갱신하도록 스케줄링하지 마세요.
요약
요약하면, 다음과 같은 경우 갱신형 머티리얼라이즈드 뷰를 사용하세요:
- 즉시 사용할 수 있는 캐시된 쿼리 결과가 필요하고, 신선도의 약간의 지연이 허용될 때.
- 쿼리 결과 집합의 top N이 필요할 때.
- 결과 집합의 크기가 시간이 지나도 무한정 커지지 않을 때. 커지면 대상 뷰의 성능이 저하됩니다.
- 여러 테이블을 포함하는 복잡한 조인이나 역정규화를 수행하며, 소스 테이블이 변경될 때마다 갱신이 필요할 때.
- 배치 워크플로우, 역정규화 작업을 구축하거나 DBT DAG와 유사한 뷰 의존성을 만들 때.
갱신형 머티리얼라이즈드 뷰의 예시는 여기를 참고하세요.
APPEND vs REPLACE 모드
갱신형 머티리얼라이즈드 뷰는 대상 테이블에 데이터를 쓰는 두 가지 모드를 지원합니다: APPEND와 REPLACE. 이 모드들은 뷰가 갱신될 때 뷰 쿼리의 결과가 어떻게 기록되는지 정의합니다. REPLACE가 기본 동작입니다. 뷰가 갱신될 때마다 대상 테이블의 이전 내용이 최신 쿼리 결과로 완전히 덮어써집니다. 이는 뷰가 항상 최신 상태를 반영해야 하는 경우, 예를 들어 결과 집합을 캐싱하는 경우에 적합합니다. 반면 APPEND는 대상 테이블의 내용을 대체하는 대신 끝에 새 행을 추가할 수 있게 합니다. 이는 주기적인 스냅샷을 캡처하는 것 같은 추가적인 사용 사례를 가능하게 합니다. APPEND는 각 갱신이 고유한 특정 시점을 나타내거나 결과의 역사적 누적이 바람직할 때 특히 유용합니다. 다음과 같은 경우 APPEND 모드를 선택하세요:
- 과거 갱신의 히스토리를 유지하고 싶을 때.
- 주기적인 스냅샷이나 리포트를 만들 때.
- 시간이 지남에 따라 갱신 결과를 증분 수집해야 할 때.
다음과 같은 경우 REPLACE 모드를 선택하세요:
- 가장 최근 결과만 필요할 때.
- 오래된 데이터를 완전히 버려야 할 때.
- 뷰가 현재 상태나 룩업을 나타낼 때.
Medallion 아키텍처를 구축한다면 APPEND 기능의 응용 예를 찾아볼 수 있습니다.