Materialized Views와 프로젝션 비교
사용자들이 자주 하는 질문 중 하나는 언제 materialized view를 사용하고, 언제 프로젝션을 사용해야 하는지입니다. 이 문서에서는 두 기능의 주요 차이점과 특정 시나리오에서 왜 하나를 다른 것보다 선택해야 하는지를 살펴봅니다.
핵심 차이점 요약
아래 표는 다양한 측면에서 materialized views와 프로젝션 간의 핵심 차이점을 요약합니다.
| Aspect | Materialized views | Projections |
|---|---|---|
| Data storage and location | 결과를 별도의 명시적인 대상 테이블에 저장하며, 소스 테이블에 대해 INSERT가 수행될 때 insert trigger처럼 동작합니다. | 프로젝션은 최적화된 데이터 레이아웃을 생성하며, 물리적으로 메인 테이블 데이터와 함께 저장되고 사용자에게는 보이지 않습니다. |
| Update mechanism | (증분형 materialized views의 경우) 소스 테이블에 대한 INSERT 시 동기적으로 동작합니다. 참고로, refreshable materialized views를 사용하여 주기적으로 실행되도록 스케줄링하는 것도 가능합니다. | 메인 테이블에 대한 INSERT 이후 백그라운드에서 비동기적으로 업데이트됩니다. |
| Query interaction | Materialized views를 사용할 때에는 대상 테이블을 직접 쿼리해야 하므로, 쿼리를 작성할 때 materialized views의 존재를 인지하고 있어야 합니다. | 프로젝션은 ClickHouse 쿼리 옵티마이저에 의해 자동으로 선택되며, 사용자가 프로젝션이 있는 테이블을 활용하기 위해 쿼리를 수정할 필요가 없다는 점에서 투명하게 동작합니다. 또한 버전 25.6부터는 둘 이상의 프로젝션을 기준으로 필터링하는 것도 가능합니다. |
Handling UPDATE / DELETE | materialized views는 소스 테이블에 대해 insert trigger로만 동작하고 소스 테이블의 변경 내역을 인지하지 못하므로, 소스 테이블에서 수행되는 UPDATE 또는 DELETE 작업에 자동으로 반응하지 않습니다. 이로 인해 소스 테이블과 대상 테이블 간 데이터가 오래되거나 불일치할 수 있으며, 이를 보완하기 위해 우회 방법이나 refreshable materialized view를 이용한 주기적인 전체 갱신이 필요합니다. | 기본적으로 (특히 lightweight deletes의 경우) DELETED 행과는 호환되지 않습니다. lightweight_mutation_projection_mode(v24.7+)를 사용하면 호환성을 활성화할 수 있습니다. |
JOIN support | 예. Refreshable materialized views는 복잡한 비정규화(denormalization)에 사용할 수 있습니다. 증분형 materialized views는 가장 왼쪽 테이블에 대한 insert에만 트리거됩니다. | 아니요. 프로젝션 정의 내에서는 materialized된 데이터를 필터링하기 위한 JOIN 연산을 지원하지 않습니다. 그러나 프로젝션이 있는 테이블들을 조인하는 쿼리는 정상적으로 동작하며, 프로젝션은 개별 테이블 접근을 최적화합니다. |
WHERE clause in definition | 예. materialization 전에 데이터를 필터링하기 위해 WHERE 절을 포함할 수 있습니다. | 아니요. 프로젝션 정의 내에서는 materialized된 데이터를 필터링하기 위한 WHERE 절을 지원하지 않습니다. |
| Chaining capabilities | 예. 하나의 materialized view 대상 테이블을 또 다른 materialized view의 소스로 사용할 수 있어, 다단계 파이프라인을 구성할 수 있습니다. | 아니요. 프로젝션은 체이닝할 수 없습니다. |
| Applicable table engines | 다양한 소스 테이블 엔진과 함께 사용할 수 있으나, 대상 테이블은 보통 MergeTree 패밀리입니다. | MergeTree 패밀리 테이블 엔진에서만 사용 가능합니다. |
| Failure handling | 데이터 삽입 중 실패가 발생하면 대상 테이블에서 데이터가 손실될 수 있으며, 이로 인해 불일치가 발생할 수 있습니다. | 실패는 백그라운드에서 조용히 처리됩니다. 쿼리는 materialized 파트와 비-materialized 파트를 문제없이 함께 사용할 수 있습니다. |
| Operational overhead | 명시적인 대상 테이블 생성과, 종종 수동 백필(backfilling)이 필요합니다. 또한 UPDATE/DELETE와의 일관성을 관리해야 하므로 복잡성이 증가합니다. | 프로젝션은 자동으로 유지 및 동기화되며, 일반적으로 운영 부담이 더 낮습니다. |
FINAL query compatibility | 일반적으로 호환되지만, 대상 테이블에 대해 GROUP BY가 필요한 경우가 많습니다. | FINAL 쿼리와는 동작하지 않습니다. |
| Lazy materialization | 예. | materialization 기능을 사용할 때 프로젝션 호환성 문제를 모니터링해야 합니다. 필요한 경우 query_plan_optimize_lazy_materialization = false로 설정해야 할 수 있습니다. |
| Parallel replicas | 예. | 아니요. |
optimize_read_in_order | 예. | 예. |
| Lightweight updates and deletes | 예. | 아니요. |
materialized view와 프로젝션 비교
materialized view를 선택해야 할 때
다음과 같은 경우 materialized view 사용을 고려할 수 있습니다:
- 실시간 ETL 및 다단계 데이터 파이프라인을 다루는 경우: 데이터가 도착하는 즉시 복잡한 변환과 집계를 수행하거나, 여러 단계를 거치도록 뷰를 체이닝하여 데이터를 라우팅해야 합니다.
- 복잡한 비정규화가 필요한 경우: 여러 소스(테이블, 서브쿼리, 딕셔너리)의 데이터를 하나의 쿼리 최적화 테이블로 미리 조인해야 하며, 특히 갱신 가능 구체화 뷰를 사용한 주기적인 전체 갱신이 허용되는 경우에 적합합니다.
- 명시적인 스키마 제어가 필요한 경우: 사전 계산된 결과를 위한 별도의 대상 테이블이 필요하며, 이 테이블은 고유한 스키마와 엔진을 가져야 하고, 이를 통해 데이터 모델링에 더 높은 유연성을 확보하려는 경우입니다.
- 수집 시점에서 필터링하고 싶은 경우: 데이터가 materialized view에 저장되기 이전 에 필터링하여 대상 테이블에 기록되는 데이터의 양을 줄여야 합니다.
materialized view를 피해야 하는 경우
다음과 같은 상황에서는 materialized view 사용을 피하는 것이 좋습니다:
- 소스 데이터가 자주 업데이트되거나 삭제되는 경우: 소스 테이블과 타깃 테이블 간의 일관성을 유지하기 위한 추가 전략이 없다면, 증분형 materialized view가 오래되거나 일관성이 없게 될 수 있습니다.
- 단순성과 자동 최적화를 선호하는 경우: 별도의 타깃 테이블을 직접 관리하고 싶지 않은 경우입니다.
프로젝션을 선택해야 할 때
다음과 같은 경우 프로젝션 사용을 고려합니다:
- 단일 테이블의 쿼리를 최적화할 때: 기본 목표가 단일 기본 테이블에 대한 쿼리 속도를 높이는 것일 때, 대체 정렬 순서를 제공하거나, 기본 키에 포함되지 않은 컬럼에 대한 필터를 최적화하거나, 단일 테이블에 대한 집계를 미리 계산하여 쿼리를 가속화하려는 경우에 적합합니다.
- **쿼리 투명성(query transparency)**을 원하는 경우: 쿼리를 수정하지 않고 항상 원본 테이블을 대상으로 실행하면서, 각 쿼리에 대해 ClickHouse가 최적의 데이터 레이아웃을 자동으로 선택하도록 하고자 할 때 사용합니다.
프로젝션을 피해야 하는 경우
다음과 같은 경우 프로젝션 사용을 피하는 것이 좋습니다:
- 복잡한 데이터 변환이나 다단계 ETL이 필요한 경우: 프로젝션 정의에서는
JOIN연산을 지원하지 않으며, 여러 단계를 연결해 파이프라인을 구성할 수 없고, 윈도 함수나 복잡한CASESQL 문과 같은 일부 SQL 기능을 처리하지 못합니다. 프로젝션이 있는 테이블에 대한 쿼리는 자유롭게 조인할 수 있지만, 프로젝션 자체는 복잡한 데이터 변환에는 적합하지 않습니다. - 구체화된 데이터에 대한 명시적 필터링이 필요한 경우: 프로젝션 정의에서는 프로젝션 자체에 구체화되는 데이터를 필터링하기 위한
WHERE절을 지원하지 않습니다. - MergeTree가 아닌 테이블 엔진을 사용하는 경우: 프로젝션은
MergeTree계열 엔진을 사용하는 테이블에서만 사용할 수 있습니다. FINAL쿼리가 필수적인 경우: 프로젝션은 중복 제거를 위해 가끔 사용되는FINAL쿼리와 함께 동작하지 않습니다.- 병렬 레플리카(parallel replicas)가 필요한 경우: 프로젝션은 이를 지원하지 않습니다.
요약
materialized view와 프로젝션은 쿼리 최적화와 데이터 변환을 위한 모두 강력한 도구이며, 일반적으로 둘 중 하나만 선택해야 하는 상호 배타적인 선택지로 보지 않는 것을 권장합니다. 대신 서로를 보완하는 방식으로 함께 사용하여 쿼리 성능을 최대한 끌어올릴 수 있습니다. 따라서 ClickHouse에서 materialized view와 프로젝션 중 어떤 것을 사용할지는 구체적인 사용 사례와 접근 패턴에 따라 달라집니다.
일반적인 기준으로, 하나 이상의 소스 테이블에서 타깃 테이블로 데이터를 집계해야 하거나, 대규모의 복잡한 변환을 수행해야 하는 경우 materialized view 사용을 고려할 수 있습니다. materialized view는 비용이 많이 드는 집계 작업을 쿼리 시점이 아니라 INSERT 시점으로 이전하는 데 매우 효과적입니다. 일별 또는 월별 롤업, 실시간 대시보드, 데이터 요약 등에 훌륭한 선택입니다.
반면, 프로젝션은 테이블의 디스크 상 물리적 정렬을 결정하는 기본 키에 사용되는 컬럼이 아닌 다른 컬럼으로 필터링하는 쿼리를 최적화해야 할 때 사용하면 좋습니다. 특히 테이블의 기본 키를 더 이상 변경할 수 없게 되었거나, 기본 키가 수용할 수 있는 범위보다 접근 패턴이 더 다양할 때 유용합니다.
