> ## Documentation Index
> Fetch the complete documentation index at: https://private-7c7dfe99-postgresql-tls-support.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# materialized views와 프로젝션 비교
> ClickHouse의 materialized views와 프로젝션을 비교하는 문서로, 사용 사례, 성능, 제한 사항을 다룹니다.
> 사용자가 자주 묻는 질문 중 하나는 materialized views와
> 프로젝션을 각각 언제 사용해야 하는지입니다. 이 문서에서는 두 기능의 주요 차이점과
> 특정 시나리오에서 어느 쪽을 선택하는 것이 적절한지 살펴보겠습니다.
## 주요 차이점 요약
아래 표는 여러 측면에서 materialized view와 프로젝션의 주요 차이점을 요약한 것입니다.
| Aspect | Materialized views | 프로젝션 |
| ------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- |
| 데이터 저장 및 위치 | 소스 테이블에 `INSERT`할 때 삽입 트리거처럼 동작하며, 결과를 **별도의 명시적인 대상 테이블**에 저장합니다. | 프로젝션은 최적화된 데이터 레이아웃을 생성하며, 이는 물리적으로 **기본 테이블 데이터와 함께 저장**되고 사용자에게는 보이지 않습니다. |
| 업데이트 메커니즘 | 소스 테이블에 대한 `INSERT` 시 **동기식으로** 동작합니다(증분형 materialized view의 경우). 참고: 갱신 가능 구체화 뷰를 사용하면 **예약 실행**할 수도 있습니다. | 기본 테이블에 `INSERT`된 후 백그라운드에서 **비동기식으로** 업데이트됩니다. |
| 쿼리 상호작용 | materialized view를 사용하려면 **대상 테이블을 직접 쿼리**해야 하므로, 쿼리를 작성할 때 materialized view의 존재를 알고 있어야 합니다. | 프로젝션은 ClickHouse의 쿼리 옵티마이저가 **자동으로 선택**하며, 사용자가 이를 활용하기 위해 프로젝션이 있는 테이블에 대한 쿼리를 수정할 필요가 없다는 점에서 투명합니다. 25.6 버전부터는 둘 이상의 프로젝션으로 필터링하는 것도 가능합니다. |
| `UPDATE` / `DELETE` 처리 | materialized view는 소스 테이블에 대한 삽입 트리거로만 *동작할 뿐* 소스 테이블 자체를 인식하지 못하므로, 소스 테이블의 `UPDATE` 또는 `DELETE` 작업에 **자동으로 반응하지 않습니다**. 이로 인해 소스 테이블과 대상 테이블 사이에 데이터가 오래될 수 있으며, 우회 방법이나 주기적인 전체 갱신이 필요합니다. (갱신 가능 구체화 뷰를 통해). | 기본적으로 **`DELETED` 행과 호환되지 않습니다**(특히 경량한 삭제). `lightweight_mutation_projection_mode` (v24.7+)를 사용하면 호환성을 활성화할 수 있습니다. |
| `JOIN` 지원 | 예. 갱신 가능 구체화 뷰는 복잡한 비정규화에 사용할 수 있습니다. 증분형 materialized view는 가장 왼쪽 테이블에 대한 삽입에서만 트리거됩니다. | 아니요. 프로젝션 정의 내에서는 구체화된 데이터를 필터링하기 위한 `JOIN` 작업을 지원하지 않습니다. 그러나 프로젝션이 있는 테이블을 조인하는 쿼리는 정상적으로 동작하며, 프로젝션은 개별 테이블 접근을 최적화합니다. |
| 정의에서의 `WHERE` 절 | 예. 구체화 전에 데이터를 필터링하기 위해 `WHERE` 절을 포함할 수 있습니다. | 아니요. 프로젝션 정의 내에서는 구체화된 데이터를 필터링하기 위한 `WHERE` 절을 지원하지 않습니다. |
| 체이닝 기능 | 예. 하나의 materialized view 대상 테이블을 다른 materialized view의 소스로 사용할 수 있으므로 다단계 파이프라인을 구성할 수 있습니다. | 아니요. 프로젝션은 체이닝할 수 없습니다. |
| 적용 가능한 테이블 엔진 | 다양한 소스 테이블 엔진과 함께 사용할 수 있지만, 대상 테이블은 일반적으로 `MergeTree` 계열입니다. | `MergeTree` 계열 테이블 엔진에서만 **사용할 수 있습니다**. |
| 장애 처리 | 데이터 삽입 중 장애가 발생하면 대상 테이블의 데이터가 유실되어 잠재적인 불일치가 발생할 수 있습니다. | 장애는 백그라운드에서 **조용히** 처리됩니다. 쿼리는 구체화된 파트와 구체화되지 않은 파트를 자연스럽게 함께 사용할 수 있습니다. |
| 운영 오버헤드 | 명시적인 대상 테이블 생성이 필요하며, 종종 수동 백필도 필요합니다. `UPDATE`/`DELETE`와의 일관성을 관리하면 복잡성이 증가합니다. | 프로젝션은 자동으로 유지되고 동기화 상태도 자동으로 유지되므로 일반적으로 운영 부담이 더 낮습니다. |
| `FINAL` 쿼리 호환성 | 일반적으로 호환되지만, 대상 테이블에서 `GROUP BY`가 필요한 경우가 많습니다. | `FINAL` 쿼리와는 **작동하지 않습니다**. |
| Lazy materialization | 예. | materialization 기능을 사용할 때는 프로젝션 호환성 문제를 확인해야 합니다. `query_plan_optimize_lazy_materialization = false`를 설정해야 할 수 있습니다. |
| 병렬 레플리카 | 예. | 아니요. |
| [`optimize_read_in_order`](/ko/reference/settings/session-settings#optimize_read_in_order) | 예. | 예. |
| 경량 업데이트 및 삭제 | 예. | 아니요. |
## materialized view와 프로젝션 비교
### materialized view를 선택할 때
다음과 같은 경우 materialized view 사용을 고려해야 합니다:
* **실시간 ETL 및 다단계 데이터 파이프라인**을 다루는 경우: 데이터가 들어오는 즉시 복잡한 변환이나 집계를 수행하거나 데이터를 라우팅해야 하며, 경우에 따라 뷰를 연결해 여러 단계로 처리해야 합니다.
* **복잡한 비정규화**가 필요한 경우: 여러 소스(테이블, 서브쿼리 또는 딕셔너리)의 데이터를 쿼리에 최적화된 단일 테이블로 미리 조인해야 하며, 특히 갱신 가능 구체화 뷰를 사용한 주기적인 전체 갱신을 허용할 수 있다면 적합합니다.
* **명시적인 스키마 제어**가 필요한 경우: 사전 계산된 결과를 저장하기 위해 자체 스키마와 engine을 갖는 별도의 대상 테이블이 필요하며, 이를 통해 데이터 모델링의 유연성을 더 높일 수 있습니다.
* **수집 시점에 필터링**하려는 경우: 데이터가 구체화되기 *전* 에 필터링해야 하며, 이렇게 하면 대상 테이블에 기록되는 데이터 양을 줄일 수 있습니다.
### materialized view 사용을 피해야 하는 경우
다음과 같은 경우에는 materialized view를 사용하지 않는 편이 좋습니다.
* **원본 데이터가 자주 업데이트되거나 삭제되는 경우**: 원본 테이블과 대상 테이블 간의 일관성을 유지하기 위한 추가 전략이 없으면 증분형 materialized view가 오래되어 일관성이 깨질 수 있습니다.
* **단순성과 자동 최적화를 우선하는 경우**: 별도의 대상 테이블을 관리하지 않으려는 경우입니다.
### 프로젝션을 선택해야 하는 경우
다음과 같은 경우 프로젝션 사용을 고려해야 합니다.
* **단일 테이블에 대한 쿼리 최적화**: 주된 목표가 대체 정렬 순서를 제공하거나, 프라이머리 키에 포함되지 않은 컬럼의 필터를 최적화하거나, 단일 기본 테이블의 집계를 미리 계산해 해당 테이블의 쿼리 성능을 높이는 것인 경우입니다.
* **쿼리 투명성**이 필요합니다. 즉, 쿼리를 수정하지 않고 원본 테이블을 그대로 대상으로 하면서, 주어진 쿼리에 가장 적합한 데이터 레이아웃을 ClickHouse가 선택하도록 하려는 경우입니다.
### 프로젝션 사용을 피해야 하는 경우
다음과 같은 경우에는 프로젝션 사용을 피하는 것이 좋습니다.
* **복잡한 데이터 변환 또는 다단계 ETL이 필요한 경우**: 프로젝션 정의에서는 `JOIN` 작업을 지원하지 않으며, 여러 단계의 파이프라인으로 연결할 수도 없고, 윈도우 함수나 복잡한 `CASE` 구문 같은 일부 SQL 기능도 처리할 수 없습니다. 프로젝션이 있는 테이블에 대한 쿼리에서는 자유롭게 조인을 사용할 수 있지만, 프로젝션 자체는 복잡한 데이터 변환에 적합하지 않습니다.
* **구체화된 데이터를 명시적으로 필터링해야 하는 경우**: 프로젝션 정의에서는 `WHERE` 절을 지원하지 않으므로, 프로젝션 자체에 구체화될 데이터를 필터링할 수 없습니다.
* **MergeTree가 아닌 테이블 엔진을 사용하는 경우**: 프로젝션은 `MergeTree` 계열 엔진을 사용하는 테이블에서만 사용할 수 있습니다.
* `FINAL` 쿼리가 필수인 경우: 프로젝션은 `FINAL` 쿼리와 함께 사용할 수 없으며, `FINAL` 쿼리는 경우에 따라 중복 제거에 사용됩니다.
* [병렬 레플리카](/ko/products/cloud/features/infrastructure/parallel-replicas)가 필요한 경우: 프로젝션에서는 이를 지원하지 않습니다.
## 요약
materialized view(Materialized View)와 프로젝션은 모두 쿼리 최적화와 데이터 변환에 유용한 강력한 도구이며,
일반적으로는 둘 중 하나만 선택해야 하는 것으로 보지 않는 것이 좋습니다. 대신 두 기능을 상호 보완적으로
활용하면 쿼리를 최대한 효율적으로 사용할 수 있습니다. 따라서 ClickHouse에서 materialized view와 프로젝션 중 무엇을 선택할지는 궁극적으로 구체적인 사용 사례와
액세스 패턴에 따라 달라집니다.
일반적인 경험칙으로, 하나 이상의 소스 테이블에서 데이터를 집계해 대상 테이블에 반영해야 하거나
대규모의 복잡한 변환을 수행해야 한다면 materialized view 사용을
고려해야 합니다. materialized view는 비용이 큰
집계 작업을 쿼리 시점에서 삽입 시점으로 옮기는 데 매우 효과적입니다. 일별 또는 월별 롤업,
실시간 대시보드, 데이터 요약에 특히 적합합니다.
반면, 디스크에 저장된 데이터의 물리적 정렬을 결정하는 테이블의 프라이머리
키에 사용된 컬럼이 아닌 다른 컬럼으로 필터링하는 쿼리를 최적화해야 한다면 프로젝션을 사용하는 것이 좋습니다. 특히
테이블의 프라이머리 키를 더 이상 변경할 수 없거나,
프라이머리 키만으로는 감당하기 어려울 정도로 액세스 패턴이 다양할 때
유용합니다.