서버 재시작 시 갱신 가능 구체화 뷰는 어떻게 되나요?

ClickHouse Keeper를 통해 갱신을 조정하지 않는 갱신 가능 구체화 뷰(Refreshable Materialized View)는 마지막 갱신 시점을 기억하지 못하므로, 서버가 준비되자마자 다시 갱신될 수 있습니다. 이러한 뷰가 많거나 대규모 데이터셋을 대상으로 하는 뷰가 있는 서버에서는 부하를 감당하기 가장 어려운 시점에 전체 데이터셋 갱신이 동시에 여러 건 실행될 수 있습니다.

어떤 뷰가 스케줄을 유지합니까?

Replicated 데이터베이스에 있는 뷰의 갱신(refresh)은 ClickHouse Keeper를 통해 조정됩니다. ClickHouse Cloud에서는 Shared 데이터베이스도 마찬가지입니다. 두 Cloud 데이터베이스 모두에서 APPEND 계열 뷰는 SETTINGS all_replicas = 1을 지정하여 조정 대상에서 제외할 수 있습니다. 오픈 소스 ClickHouse 서버에서는 Replicated 데이터베이스에서만 이러한 조정이 이루어집니다. 조정되지 않는 뷰는 마지막 갱신 시각을 메모리에만 보관하므로, 일반 스케줄을 사용하는 경우 재시작 후에는 항상 갱신 시점이 이미 지난 상태가 됩니다. RANDOMIZE FOR를 사용해도 이러한 갱신은 분산되지 않습니다.

추가로 발생하는 갱신은 데이터 중복을 일으킬 수도 있습니다

APPEND 뷰는 전체 결과를 한 번 더 추가합니다. 조정되지 않은 APPEND INCREMENTAL 뷰는 트랜잭션을 지원하는 대상 테이블이 커서를 커밋하지 않았다면 재시작 시 인메모리 커서를 잃습니다. 그 결과 이미 추가했던 행을 다시 처리하게 됩니다. 아래 설명처럼 시작 시점을 단계적으로 분산하면 동시에 실행되는 갱신 수를 제한할 수 있지만, 갱신 자체는 여전히 실행됩니다. APPEND 뷰는 어차피 다음 갱신 시점이 되었을 때에만 시작하면 불필요한 추가 작업을 피할 수 있습니다. 반면 커서를 잃은 APPEND INCREMENTAL 뷰는 시점을 조정해도 얻는 이점이 없습니다. 언제 다시 실행되든 원본 테이블 전체를 다시 처리하고 그 결과를 추가하기 때문입니다. 따라서 중복된 행을 감당하거나 제거할 수 있을 때까지 중지된 상태로 두십시오.

서버 시작 시 모든 뷰를 중지된 상태로 유지하기

서버 자체의 설정 프로필(settings profile)에 stop_refreshable_materialized_views_on_startup을 설정하십시오. 서버의 설정 프로필은 system_profile에 지정된 프로필이며, 지정되지 않은 경우 default_profile, 그다음 default 순으로 폴백합니다. 이 설정은 실험적 기능입니다:

/etc/clickhouse-server/users.d/refreshable_materialized_views.xml

<clickhouse>
    <profiles>
        <default>
            <stop_refreshable_materialized_views_on_startup>1</stop_refreshable_materialized_views_on_startup>
        </default>
    </profiles>
</clickhouse>

이 예시에서는 기본 default 프로필을 사용합니다. 사용자 정의 system_profile을 사용한다면 이를 해당 프로필로 바꾸십시오. SYSTEM STOP VIEWS는 대안이 될 수 없습니다. 이 SQL 문으로 설정한 중지 상태는 재시작하면 유지되지 않기 때문입니다.

뷰를 하나씩 시작하기

SYSTEM START VIEWS는 모든 뷰를 한꺼번에 시작하므로 동일한 부하 급증이 발생합니다. 따라서 각 뷰를 이름으로 지정해 하나씩 시작하고, 해당 뷰의 갱신이 끝난 뒤 다음 뷰를 시작하십시오. 뷰 목록은 system.view_refreshes에서 확인할 수 있습니다. ClickHouse Cloud에서는 이 시스템 테이블이 노드 로컬이므로 노드별로 각각 확인하십시오:

SYSTEM START VIEW my_database.my_view;
SYSTEM WAIT VIEW my_database.my_view;

뷰를 시작하면 해당 뷰의 스케줄만 재개될 뿐이며, SYSTEM REFRESH VIEW와 달리 별도의 갱신을 추가로 수행하지 않습니다. 중지된 동안 갱신 시점이 지난 뷰는 이미 스케줄상 기한을 넘긴 상태이므로 시작하는 즉시 갱신되며, SYSTEM WAIT VIEW는 해당 갱신이 실행되는 동안 블로킹됩니다. REFRESH ... DEPENDS ON으로 지정된 선행 뷰를 기다리는 뷰는 아직 갱신되지 않으므로, 이러한 뷰는 의존 대상 뷰를 먼저 시작한 뒤에 시작하십시오. 순환 의존성에는 이러한 순서가 없으며, 뷰들이 서로 조정되지 않은 상태에서 재시작하면 사이클이 끊어집니다. 이 경우 모든 멤버 뷰를 시작한 다음, 사이클을 처음 생성할 때 사이클을 시작하기 위해 실행했던 것과 동일한 SYSTEM REFRESH VIEW를 실행하고 해당 갱신이 완료될 때까지 기다리십시오. 처음 시작할 때 이러한 갱신이 두 번 이상 필요했던 그래프라면 같은 갱신들을 다시 실행해야 합니다. 다른 멤버를 트리거하면 사이클이 유휴 상태로 남을 수 있는데, 뷰는 모든 선행 뷰가 갱신된 후에야 재개되기 때문입니다. 일단 트리거되면 사이클은 자체적으로 갱신되므로, 뷰를 하나씩 시작하는 절차는 트리거 시점에서 끝납니다.

자동화에 미치는 영향

이 설정이 적용된 동안 예기치 않은 재시작이 발생하면 모든 갱신 가능 구체화 뷰(refreshable materialized view)가 중지된 상태로 남으며, 새로 생성한 뷰도 시작하기 전까지는 갱신되지 않습니다. 단, 갱신이 조정(coordinated)되지 않는 뷰에는 RESTORE가 예외로 적용됩니다. RESTORE는 복원 대상에 포함된 이러한 뷰를 모두 시작하며, 이때 해당 뷰는 곧바로 예정 시각을 넘긴 상태가 되어 소스 데이터를 다시 처리할 수 있습니다. 조정되는 뷰는 복원 시 시작되지 않으므로 직접 시작하기 전까지 중지된 상태로 유지됩니다. 서버를 재시작하고 뷰를 생성하는 자동화가 뷰 시작까지 담당하도록 구성하십시오.

​어떤 뷰가 스케줄을 유지합니까?

​추가로 발생하는 갱신은 데이터 중복을 일으킬 수도 있습니다

​서버 시작 시 모든 뷰를 중지된 상태로 유지하기

​뷰를 하나씩 시작하기

​자동화에 미치는 영향

어떤 뷰가 스케줄을 유지합니까?

추가로 발생하는 갱신은 데이터 중복을 일으킬 수도 있습니다

서버 시작 시 모든 뷰를 중지된 상태로 유지하기

뷰를 하나씩 시작하기

자동화에 미치는 영향