재시도 시 삽입 중복 제거

삽입 작업은 타임아웃과 같은 오류로 인해 때때로 실패할 수 있습니다. 삽입이 실패하면 데이터가 실제로 성공적으로 삽입되었을 수도 있고, 그렇지 않을 수도 있습니다. 이 가이드에서는 동일한 데이터가 두 번 이상 삽입되지 않도록 삽입 재시도 시 중복 제거가 작동하는 방식을 설명합니다. 삽입을 재시도하면 ClickHouse는 해당 데이터가 이미 성공적으로 삽입되었는지 확인합니다. 삽입된 데이터가 중복으로 표시되면 ClickHouse는 이를 대상 테이블에 삽입하지 않습니다. 하지만 사용자에게는 데이터가 정상적으로 삽입된 것과 동일하게 작업 성공 상태가 반환됩니다. 중복 제거는 동기 삽입, 비동기 삽입 및 INSERT ... SELECT 쿼리를 지원합니다. deduplicate_insert 설정 하나로 동기 및 비동기 삽입을 제어합니다. INSERT ... SELECT에는 추가 주의가 필요하며 전용 설정이 있습니다. 삽입 중복 제거를 제어하는 설정을 참조하십시오.

제한 사항

불확실한 삽입 상태

삽입 작업이 성공할 때까지 재시도해야 합니다. 모든 재시도가 실패하면 데이터가 삽입되었는지 여부를 판단할 수 없습니다. materialized view가 관련되면 데이터가 어느 테이블에 반영되었을 수 있는지도 불분명합니다. materialized view가 원본 테이블과 동기화되지 않았을 수 있습니다.

중복 제거 윈도우 제한

재시도하는 동안 다른 삽입 작업이 *_deduplication_window를 초과해 발생하면 중복 제거가 의도대로 작동하지 않을 수 있습니다. 이 경우 동일한 데이터가 여러 번 삽입될 수 있습니다.

삽입 중복 제거를 제어하는 설정

ClickHouse는 다음 두 조건이 모두 충족될 때만 삽입 시 중복을 제거합니다.

대상 테이블에서 중복 제거 로그를 유지합니다. 이는 테이블 수준 설정입니다.
쿼리 수준에서 중복 제거가 활성화되어 있습니다. 이는 쿼리 수준 설정입니다.

테이블 수준 설정

삽입 시 중복 제거는 *MergeTree 엔진에서만 지원됩니다. *ReplicatedMergeTree 엔진에서는 중복 제거 로그가 기본적으로 활성화되어 있으며, replicated_deduplication_window 및 replicated_deduplication_window_seconds 설정으로 제어됩니다. 복제되지 않은 *MergeTree 엔진에서는 로그가 non_replicated_deduplication_window 설정으로 제어되며, 기본값은 0입니다. 따라서 일반 MergeTree 테이블은 해당 윈도우를 양수 값으로 설정하기 전까지 아무것도 중복 제거하지 않습니다. 위 설정은 테이블의 중복 제거 로그에 대한 매개변수를 결정합니다. 중복 제거 로그에는 제한된 개수의 block_id가 저장되며, 이 값이 중복 제거 동작 방식을 결정합니다(아래 참조).

replicated_deduplication_window_for_async_inserts 및 replicated_deduplication_window_seconds_for_async_inserts는 레거시 설정입니다. 이제 동기 및 비동기 삽입은 하나의 중복 제거 로그를 공유하므로 replicated_deduplication_window가 둘 다 제어합니다. 레거시 설정은 롤링 업그레이드 중에 중요한 기존 ClickHouse Keeper 디렉터리의 범위만 제한했습니다.

쿼리 수준 설정

설정	적용 대상	기본값	용도
`deduplicate_insert`	동기 또는 비동기 방식의 모든 `INSERT`	`enable`	삽입 중복 제거의 기본 스위치
`deduplicate_insert_select`	`INSERT ... SELECT`	`enable_when_possible`	`SELECT` 결과를 재현할 수 없을 때의 처리 방식을 결정합니다
`insert_deduplication_token`	모든 `INSERT`	`''`	데이터 대신 사용자가 제공한 문자열로 삽입을 식별합니다
`deduplicate_blocks_in_dependent_materialized_views`	materialized view에 종속된 테이블	`1`	종속 materialized view의 대상 테이블까지 중복 제거를 확장합니다

deduplicate_insert는 세 가지 값을 허용합니다.

enable — INSERT 쿼리에 대해 중복 제거가 활성화됩니다.
disable — INSERT 쿼리에 대해 중복 제거가 비활성화됩니다.
backward_compatible_choice — 레거시 설정인 insert_deduplicate(동기 삽입) 및 async_insert_deduplicate(비동기 삽입)가 이 결정을 내립니다.

deduplicate_insert = disable로 실행되는 쿼리는 해당 블록의 block_id를 기록하지 않습니다. 따라서 나중에 deduplicate_insert = enable로 삽입을 재시도하더라도 이러한 데이터는 중복 제거할 수 없습니다. 대상 테이블에 중복 제거 로그가 없는 경우에도 마찬가지입니다. 아무것도 기록되지 않으므로 재시도 시 대조할 항목도 없습니다.

precedence

INSERT ... SELECT 쿼리에서는 deduplicate_insert_select이 적용됩니다. INSERT … SELECT의 중복 제거를 참조하십시오.
그 밖의 모든 INSERT에서는 deduplicate_insert이 적용됩니다.
deduplicate_insert이 backward_compatible_choice인 경우에만 insert_deduplicate 및 async_insert_deduplicate를 읽습니다.

레거시 및 더 이상 사용되지 않는 설정

설정	상태	대신 사용할 항목
`insert_deduplicate`	레거시. `deduplicate_insert = backward_compatible_choice`일 때만 읽습니다	`deduplicate_insert`
`async_insert_deduplicate`	레거시. `deduplicate_insert = backward_compatible_choice`일 때만 읽습니다	`deduplicate_insert`
`insert_select_deduplicate`	더 이상 사용되지 않음. 효과 없음	`deduplicate_insert_select`
`update_insert_deduplication_token_in_dependent_materialized_views`	더 이상 사용되지 않음. 효과 없음	—

버전 26.2부터 deduplicate_insert의 기본값은 enable입니다. 따라서 insert_deduplicate = 0만 설정해서는 더 이상 중복 제거를 비활성화할 수 없습니다. 중복 제거를 비활성화하려면 deduplicate_insert = disable로 설정하십시오.

버전 26.2에서는 async_insert 및 deduplicate_blocks_in_dependent_materialized_views의 기본값도 활성화됨으로 변경되었습니다. compatibility 설정은 이 3개 설정을 모두 제어합니다. compatibility를 26.2 이전 버전으로 설정하면 이 설정들은 이전 기본값을 유지합니다. 즉, deduplicate_insert는 backward_compatible_choice가 되며, 이 경우 insert_deduplicate 및 async_insert_deduplicate가 결정합니다. 명시적으로 지정한 설정은 항상 적용되며 compatibility의 영향을 받지 않습니다.

삽입 중복 제거의 작동 방식

ClickHouse에 데이터를 삽입하면 행 수와 바이트 수를 기준으로 데이터를 블록으로 나눕니다. *MergeTree 엔진을 사용하는 테이블에서는 각 블록에 해당 블록 데이터의 해시값인 고유한 block_id가 할당됩니다. 이 block_id는 삽입 작업의 고유 키로 사용됩니다. 중복 제거 로그에서 동일한 block_id가 발견되면 해당 블록은 중복으로 간주되며 테이블에 삽입되지 않습니다. 이 방식은 삽입마다 서로 다른 데이터가 포함되는 경우에 효과적입니다. 하지만 동일한 데이터를 의도적으로 여러 번 삽입해야 하는 경우에는 중복 제거 과정을 제어하기 위해 insert_deduplication_token 설정을 사용해야 합니다. 이 설정을 사용하면 각 삽입에 대해 고유한 토큰을 지정할 수 있으며, ClickHouse는 이를 기준으로 데이터가 중복인지 판단합니다. insert_deduplication_token의 우선순위가 더 높습니다. 토큰이 제공되면 ClickHouse는 데이터의 해시 합을 사용하지 않습니다. INSERT ... VALUES 쿼리의 경우, 삽입된 데이터를 블록으로 나누는 방식은 결정적이며 설정값에 따라 정해집니다. 따라서 삽입을 재시도할 때는 최초 작업과 동일한 설정값을 사용해야 합니다.

`INSERT ... SELECT`의 중복 제거

INSERT ... SELECT 쿼리에서는 매 시도마다 SELECT 부분이 동일한 데이터를 동일한 순서로 반환해야 합니다. 그렇지 않으면 블록과 block_id가 달라져 재시도가 중복으로 인식되지 않습니다. ClickHouse는 원본 데이터가 변경되지 않았는지 확인할 수 없지만, 쿼리 자체가 재현 가능한 결과를 생성하는지는 확인할 수 있습니다. 다음 두 조건을 모두 충족하면 SELECT는 안정적인 것으로 처리됩니다.

쿼리에 ORDER BY ALL 절이 포함되어 있습니다. 리터럴 ORDER BY ALL만 인식됩니다. 일반적인 ORDER BY <expressions>는 인식되지 않으며, 2개 이상의 SELECT를 UNION한 쿼리는 안정적인 것으로 처리되지 않습니다.
읽기 파이프라인이 단일 스트림으로 끝납니다.

비어 있지 않은 insert_deduplication_token은 안정성을 대체할 수 있는 동등한 수단입니다. 이 경우 데이터가 아니라 토큰으로 삽입을 식별하기 때문입니다. deduplicate_insert_select 설정으로 수행할 작업을 선택합니다.

값	동작
`enable_when_possible` (기본값)	`SELECT`가 안정적이거나 토큰이 설정된 경우 중복을 제거합니다. 그렇지 않으면 중복 제거를 건너뛰고 서버 로그에 메시지를 기록합니다.
`force_enable`	항상 중복을 제거합니다. `SELECT`가 안정적이지 않고 토큰도 설정되지 않은 경우 `DEDUPLICATION_IS_NOT_POSSIBLE` 예외를 발생시킵니다.
`enable_even_for_bad_queries`	안정성과 관계없이 중복을 제거합니다. 이전 버전과의 호환성을 위해 유지됩니다. 불안정한 `SELECT`에서는 재시도가 대개 중복으로 인식되지 않으므로 다른 값을 사용하는 것이 좋습니다.
`disable`	`INSERT ... SELECT`에 대해 중복 제거를 수행하지 않습니다.

enable_when_possible 및 enable_even_for_bad_queries는 deduplicate_insert 설정도 따릅니다. 이 값이 disable이면 쿼리에 중복 제거가 적용되지 않습니다. force_enable은 deduplicate_insert를 재정의합니다. 선택한 테이블은 재시도 사이에 업데이트될 수 있다는 점에 유의하십시오. 이 경우 두 방식은 서로 반대로 동작합니다.

insert_deduplication_token이 없으면 block_id는 데이터에서 계산됩니다. 변경된 결과로 인해 다른 block_id가 생성되므로 중복 제거가 수행되지 않으며, 재시도 시 첫 번째 시도에서 이미 기록한 데이터에 새 데이터가 추가로 삽입됩니다.
insert_deduplication_token이 있으면 토큰만으로 삽입을 식별합니다. 재시도 시 다른 데이터가 삽입되었을 수 있더라도 중복으로 인식되어 삭제됩니다.

재시도가 어떤 의미를 가져야 하는지에 맞는 방식을 선택하십시오. 또한 대량의 데이터를 삽입하면 블록 수가 중복 제거 로그 윈도우를 오버플로우할 수 있으며, 이 경우 ClickHouse는 블록을 중복 제거해야 하는지 알 수 없습니다.

비동기 삽입의 중복 제거

비동기 삽입(async_insert, 버전 26.2부터 기본 활성화)은 동기 삽입과 마찬가지로 재시도 시 중복 제거됩니다. deduplicate_insert는 두 방식 모두를 제어하므로 별도의 설정은 필요하지 않습니다. 두 삽입 방식은 하나의 중복 제거 로그를 공유하고 동일한 방식으로 block_id를 계산합니다. 따라서 중복 제거에 영향을 주지 않고 클라이언트를 동기 삽입과 비동기 삽입 간에 전환할 수 있습니다. 한 모드에서 전송한 재시도도 다른 모드에서 전송한 시도의 중복으로 인식됩니다. 중복 제거에 의존하는 테이블에서도 워크로드를 동기 삽입에서 비동기 삽입으로 안전하게 전환할 수 있습니다.

버전 26.2 이전에는 비동기 삽입의 중복 제거가 기본적으로 비활성화되어 있었으며, async_insert_deduplicate로 제어되었습니다. 이제 이 설정은 deduplicate_insert가 backward_compatible_choice인 경우에만 읽습니다.

중복 제거 세분화 수준

서버는 여러 비동기 삽입을 하나의 배치로 묶어, 서로 다른 파티션 키 값마다 최소 하나씩 하나 이상의 파트에 기록합니다. 중복 제거는 배치 단위가 아니라 사용자 쿼리 단위로 수행됩니다.

큐에 있는 각 쿼리는 배치에 하나의 중복 제거 토큰을 추가합니다.
토큰은 쿼리에서 제공된 경우 insert_deduplication_token의 값이고, 그렇지 않은 경우 해당 쿼리가 추가한 행의 해시입니다.
배칭은 토큰에 영향을 주지 않으며, insert_deduplication_token은 쿼리가 배치로 묶이는 방식에 영향을 주지 않습니다.

이로 인해 다음과 같은 두 가지 결과가 발생합니다.

배치 내 한 쿼리가 중복인 경우 ClickHouse는 해당 쿼리의 행만 제거합니다. 배치의 나머지 행은 정상적으로 삽입됩니다. 모든 행이 제거된 경우에만 파트 전체를 건너뜁니다.
동일한 배치에 있는 두 쿼리가 같은 토큰을 가지면, 두 번째 쿼리는 파트가 기록되기 전에 삭제됩니다. 이는 파티션별로 적용됩니다. 두 쿼리가 서로 다른 파티션에 행을 기록하면 둘 다 유지됩니다.

system.events의 DuplicatedAsyncInserts 및 SelfDuplicatedAsyncInserts 이벤트는 이 두 가지 사례를 집계합니다.

비동기 삽입 및 materialized view

비동기 삽입의 중복 제거는 종속 materialized view와 연동됩니다. 규칙은 간단합니다. 블록 하나가 들어오면 블록 하나가 나옵니다. 뷰의 내부 쿼리가 입력 블록 하나를 출력 블록 하나로 변환하면 중복 제거가 작동합니다. 뷰가 두 번째 블록을 내보내면 ClickHouse에서 NOT_IMPLEMENTED 예외가 발생합니다. 뷰의 출력이 하나의 블록에 담기지 않으면 두 번째 블록을 내보냅니다. max_block_size는 하나의 블록에 담을 수 있는 행 수를 설정합니다. 컬럼 변환, 필터링, 집계는 행을 추가하지 않으므로 항상 하나의 블록으로 유지됩니다. JOIN은 행을 추가할 수 있습니다. 결과가 max_block_size 이하이면 작동하지만, 이를 초과하면 실패합니다. 둘 이상의 블록을 내보내는 뷰를 통해 삽입하려면 deduplicate_blocks_in_dependent_materialized_views = 0을 설정하거나 동기 삽입을 사용하십시오.

materialized view에서의 삽입 중복 제거

테이블에 하나 이상의 materialized view가 있으면, 삽입된 데이터는 정의된 변환을 거쳐 해당 뷰의 대상에도 삽입됩니다. 변환된 데이터도 재시도 시 중복 제거됩니다. ClickHouse는 대상 테이블에 삽입된 데이터를 중복 제거하는 것과 동일한 방식으로 materialized view에 대해서도 중복 제거를 수행합니다. 다음 원본 테이블 설정으로 이 과정을 제어할 수 있습니다.

materialized view의 대상 테이블에서 중복 제거는 사용자 프로필 설정 deduplicate_blocks_in_dependent_materialized_views의 추가 제어를 받으며, 이 설정은 버전 26.2부터 기본적으로 활성화되어 있습니다. 두 설정 모두 중복 제거를 허용해야 합니다. deduplicate_insert는 원본 테이블에 삽입된 데이터를 중복 제거하고, deduplicate_blocks_in_dependent_materialized_views는 종속 테이블의 데이터도 추가로 중복 제거합니다. 전체 중복 제거가 필요하면 두 설정을 모두 활성화하십시오. materialized view의 대상 테이블에 블록을 삽입할 때 ClickHouse는 원본 테이블의 block_id와 추가 식별자를 결합한 문자열을 해시하여 block_id를 계산합니다. 이를 통해 materialized view 내에서 정확한 중복 제거가 보장되며, materialized view의 대상 테이블에 도달하기 전에 어떤 변환이 적용되었는지와 관계없이 원래 삽입된 기준에 따라 데이터를 구분할 수 있습니다.

예시

materialized view 변환 후 동일한 블록

materialized view 내부의 변환 과정에서 생성된 동일한 블록은 서로 다른 데이터가 삽입된 결과이므로 중복 제거되지 않습니다. 다음은 예시입니다:

CREATE TABLE dst
(
    `key` Int64,
    `value` String
)
ENGINE = MergeTree
ORDER BY tuple()
SETTINGS non_replicated_deduplication_window=1000;

CREATE MATERIALIZED VIEW mv_dst
(
    `key` Int64,
    `value` String
)
ENGINE = MergeTree
ORDER BY tuple()
SETTINGS non_replicated_deduplication_window=1000
AS SELECT
    0 AS key,
    value AS value
FROM dst;

SET max_block_size=1;
SET min_insert_block_size_rows=0;
SET min_insert_block_size_bytes=0;

위 설정을 사용하면 행(row)이 1개만 포함된 일련의 블록으로 이루어진 테이블(table)에서 데이터를 선택할 수 있습니다. 이러한 작은 블록은 더 큰 블록으로 합쳐지지 않으며, 테이블에 삽입될 때까지 그대로 유지됩니다. 기본적으로 활성화되어 있지만, materialized view에서 중복 제거를 명시적으로 설정합니다:

SET deduplicate_blocks_in_dependent_materialized_views=1;

INSERT INTO dst SELECT
    number + 1 AS key,
    IF(key = 0, 'A', 'B') AS value
FROM numbers(2);

SELECT
    *,
    _part
FROM dst
ORDER BY all;

┌─key─┬─value─┬─_part─────┐
│   1 │ B     │ all_0_0_0 │
│   2 │ B     │ all_1_1_0 │
└─────┴───────┴───────────┘

여기서는 dst 테이블에 2개의 파트가 삽입된 것을 확인할 수 있습니다. select에서 가져온 2개의 블록 — 삽입 시 2개의 파트입니다. 이 파트들은 서로 다른 데이터를 포함하고 있습니다.

SELECT
    *,
    _part
FROM mv_dst
ORDER BY all;

┌─key─┬─value─┬─_part─────┐
│   0 │ B     │ all_0_0_0 │
│   0 │ B     │ all_1_1_0 │
└─────┴───────┴───────────┘

여기서는 mv_dst 테이블에 2개의 파트가 삽입된 것을 확인할 수 있습니다. 이 파트들은 동일한 데이터를 포함하지만, 중복 제거되지는 않습니다.

INSERT INTO dst SELECT
    number + 1 AS key,
    IF(key = 0, 'A', 'B') AS value
FROM numbers(2);

SELECT
    *,
    _part
FROM dst
ORDER BY all;

┌─key─┬─value─┬─_part─────┐
│   1 │ B     │ all_0_0_0 │
│   2 │ B     │ all_1_1_0 │
└─────┴───────┴───────────┘

SELECT
    *,
    _part
FROM mv_dst
ORDER by all;

┌─key─┬─value─┬─_part─────┐
│   0 │ B     │ all_0_0_0 │
│   0 │ B     │ all_1_1_0 │
└─────┴───────┴───────────┘

여기서는 삽입을 재시도하면 모든 데이터가 중복 제거되는 것을 확인할 수 있습니다. 중복 제거는 dst 테이블과 mv_dst 테이블 모두에 적용됩니다.

삽입 시 동일 블록

CREATE TABLE dst
(
    `key` Int64,
    `value` String
)
ENGINE = MergeTree
ORDER BY tuple()
SETTINGS non_replicated_deduplication_window=1000;

SET max_block_size=1;
SET min_insert_block_size_rows=0;
SET min_insert_block_size_bytes=0;

삽입:

INSERT INTO dst SELECT
    0 AS key,
    'A' AS value
FROM numbers(2);

SELECT
    'from dst',
    *,
    _part
FROM dst
ORDER BY all;

┌─'from dst'─┬─key─┬─value─┬─_part─────┐
│ from dst   │   0 │ A     │ all_0_0_0 │
└────────────┴─────┴───────┴───────────┘

위 설정에서는 select–의 결과로 두 개의 블록이 생성되므로, table dst에 삽입할 블록도 두 개여야 합니다. 그러나 실제로는 table dst에 하나의 블록만 삽입된 것을 확인할 수 있습니다. 이는 두 번째 블록이 중복 제거되었기 때문입니다. 이 블록은 데이터가 동일하고, 삽입된 데이터에서 해시로 계산되는 중복 제거 키 block_id도 같습니다. 이러한 동작은 예상한 결과가 아닙니다. 이런 경우는 드물지만 이론적으로는 발생할 수 있습니다. 이러한 경우를 올바르게 처리하려면 사용자가 insert_deduplication_token을 제공해야 합니다. 다음 예시에서 이를 수정해 보겠습니다:

`insert_deduplication_token`을 사용한 삽입 중 동일한 블록

CREATE TABLE dst
(
    `key` Int64,
    `value` String
)
ENGINE = MergeTree
ORDER BY tuple()
SETTINGS non_replicated_deduplication_window=1000;

SET max_block_size=1;
SET min_insert_block_size_rows=0;
SET min_insert_block_size_bytes=0;

삽입:

INSERT INTO dst SELECT
    0 AS key,
    'A' AS value
FROM numbers(2)
SETTINGS insert_deduplication_token='some_user_token';

SELECT
    'from dst',
    *,
    _part
FROM dst
ORDER BY all;

┌─'from dst'─┬─key─┬─value─┬─_part─────┐
│ from dst   │   0 │ A     │ all_2_2_0 │
│ from dst   │   0 │ A     │ all_3_3_0 │
└────────────┴─────┴───────┴───────────┘

예상대로 동일한 2개의 블록이 삽입되었습니다.

SELECT 'second attempt';

INSERT INTO dst SELECT
    0 AS key,
    'A' AS value
FROM numbers(2)
SETTINGS insert_deduplication_token='some_user_token';

SELECT
    'from dst',
    *,
    _part
FROM dst
ORDER BY all;

┌─'from dst'─┬─key─┬─value─┬─_part─────┐
│ from dst   │   0 │ A     │ all_2_2_0 │
│ from dst   │   0 │ A     │ all_3_3_0 │
└────────────┴─────┴───────┴───────────┘

삽입을 재시도하면 예상대로 중복이 제거됩니다.

SELECT 'third attempt';

INSERT INTO dst SELECT
    1 AS key,
    'b' AS value
FROM numbers(2)
SETTINGS insert_deduplication_token='some_user_token';

SELECT
    'from dst',
    *,
    _part
FROM dst
ORDER BY all;

┌─'from dst'─┬─key─┬─value─┬─_part─────┐
│ from dst   │   0 │ A     │ all_2_2_0 │
│ from dst   │   0 │ A     │ all_3_3_0 │
└────────────┴─────┴───────┴───────────┘

해당 삽입도 실제로 삽입된 데이터가 다르더라도 중복 제거됩니다. insert_deduplication_token의 우선순위가 더 높다는 점에 유의하십시오. insert_deduplication_token이 제공되면 ClickHouse는 데이터의 해시값을 사용하지 않습니다.

materialized view의 기반 테이블에서 변환 후 동일한 데이터를 생성하는 여러 삽입 작업

CREATE TABLE dst
(
    `key` Int64,
    `value` String
)
ENGINE = MergeTree
ORDER BY tuple()
SETTINGS non_replicated_deduplication_window=1000;

CREATE MATERIALIZED VIEW mv_dst
(
    `key` Int64,
    `value` String
)
ENGINE = MergeTree
ORDER BY tuple()
SETTINGS non_replicated_deduplication_window=1000
AS SELECT
    0 AS key,
    value AS value
FROM dst;

SET deduplicate_blocks_in_dependent_materialized_views=1;

select 'first attempt';

INSERT INTO dst VALUES (1, 'A');

SELECT
    'from dst',
    *,
    _part
FROM dst
ORDER by all;

┌─'from dst'─┬─key─┬─value─┬─_part─────┐
│ from dst   │   1 │ A     │ all_0_0_0 │
└────────────┴─────┴───────┴───────────┘

SELECT
    'from mv_dst',
    *,
    _part
FROM mv_dst
ORDER by all;

┌─'from mv_dst'─┬─key─┬─value─┬─_part─────┐
│ from mv_dst   │   0 │ A     │ all_0_0_0 │
└───────────────┴─────┴───────┴───────────┘

select 'second attempt';

INSERT INTO dst VALUES (2, 'A');

SELECT
    'from dst',
    *,
    _part
FROM dst
ORDER by all;

┌─'from dst'─┬─key─┬─value─┬─_part─────┐
│ from dst   │   1 │ A     │ all_0_0_0 │
│ from dst   │   2 │ A     │ all_1_1_0 │
└────────────┴─────┴───────┴───────────┘

SELECT
    'from mv_dst',
    *,
    _part
FROM mv_dst
ORDER by all;

┌─'from mv_dst'─┬─key─┬─value─┬─_part─────┐
│ from mv_dst   │   0 │ A     │ all_0_0_0 │
│ from mv_dst   │   0 │ A     │ all_1_1_0 │
└───────────────┴─────┴───────┴───────────┘

매번 서로 다른 데이터를 삽입합니다. 그러나 mv_dst 테이블(table)에는 동일한 데이터가 삽입됩니다. 소스 데이터가 서로 달랐기 때문에 데이터는 중복 제거되지 않습니다.

동등한 데이터를 하나의 기반 테이블에 삽입하는 여러 materialized view

CREATE TABLE dst
(
    `key` Int64,
    `value` String
)
ENGINE = MergeTree
ORDER BY tuple()
SETTINGS non_replicated_deduplication_window=1000;

CREATE TABLE mv_dst
(
    `key` Int64,
    `value` String
)
ENGINE = MergeTree
ORDER BY tuple()
SETTINGS non_replicated_deduplication_window=1000;

CREATE MATERIALIZED VIEW mv_first
TO mv_dst
AS SELECT
    0 AS key,
    value AS value
FROM dst;

CREATE MATERIALIZED VIEW mv_second
TO mv_dst
AS SELECT
    0 AS key,
    value AS value
FROM dst;

SET deduplicate_blocks_in_dependent_materialized_views=1;

select 'first attempt';

INSERT INTO dst VALUES (1, 'A');

SELECT
    'from dst',
    *,
    _part
FROM dst
ORDER by all;

┌─'from dst'─┬─key─┬─value─┬─_part─────┐
│ from dst   │   1 │ A     │ all_0_0_0 │
└────────────┴─────┴───────┴───────────┘

SELECT
    'from mv_dst',
    *,
    _part
FROM mv_dst
ORDER by all;

┌─'from mv_dst'─┬─key─┬─value─┬─_part─────┐
│ from mv_dst   │   0 │ A     │ all_0_0_0 │
│ from mv_dst   │   0 │ A     │ all_1_1_0 │
└───────────────┴─────┴───────┴───────────┘

동일한 2개의 블록이 예상대로 테이블 mv_dst에 삽입되었습니다.

SELECT 'second attempt';

INSERT INTO dst VALUES (1, 'A');

SELECT
    'from dst',
    *,
    _part
FROM dst
ORDER BY all;

┌─'from dst'─┬─key─┬─value─┬─_part─────┐
│ from dst   │   1 │ A     │ all_0_0_0 │
└────────────┴─────┴───────┴───────────┘

SELECT
    'from mv_dst',
    *,
    _part
FROM mv_dst
ORDER by all;

┌─'from mv_dst'─┬─key─┬─value─┬─_part─────┐
│ from mv_dst   │   0 │ A     │ all_0_0_0 │
│ from mv_dst   │   0 │ A     │ all_1_1_0 │
└───────────────┴─────┴───────┴───────────┘

해당 재시도 작업은 dst와 mv_dst 두 테이블(table) 모두에서 중복 제거 처리됩니다.

Fundamentals

ClickHouse concepts

Best practices

제한 사항

불확실한 삽입 상태

중복 제거 윈도우 제한

삽입 중복 제거를 제어하는 설정

테이블 수준 설정

쿼리 수준 설정

precedence

레거시 및 더 이상 사용되지 않는 설정

삽입 중복 제거의 작동 방식

`INSERT ... SELECT`의 중복 제거

비동기 삽입의 중복 제거

중복 제거 세분화 수준

비동기 삽입 및 materialized view

materialized view에서의 삽입 중복 제거

예시

materialized view 변환 후 동일한 블록

삽입 시 동일 블록

`insert_deduplication_token`을 사용한 삽입 중 동일한 블록

materialized view의 기반 테이블에서 변환 후 동일한 데이터를 생성하는 여러 삽입 작업

동등한 데이터를 하나의 기반 테이블에 삽입하는 여러 materialized view

​제한 사항

​불확실한 삽입 상태

​중복 제거 윈도우 제한

​삽입 중복 제거를 제어하는 설정

​테이블 수준 설정

​쿼리 수준 설정

​precedence

​레거시 및 더 이상 사용되지 않는 설정

​삽입 중복 제거의 작동 방식

​INSERT ... SELECT의 중복 제거

​비동기 삽입의 중복 제거

​중복 제거 세분화 수준

​비동기 삽입 및 materialized view

​materialized view에서의 삽입 중복 제거

​예시

​materialized view 변환 후 동일한 블록

​삽입 시 동일 블록

​insert_deduplication_token을 사용한 삽입 중 동일한 블록

​materialized view의 기반 테이블에서 변환 후 동일한 데이터를 생성하는 여러 삽입 작업

​동등한 데이터를 하나의 기반 테이블에 삽입하는 여러 materialized view

제한 사항

불확실한 삽입 상태

중복 제거 윈도우 제한

삽입 중복 제거를 제어하는 설정

테이블 수준 설정

쿼리 수준 설정

precedence

레거시 및 더 이상 사용되지 않는 설정

삽입 중복 제거의 작동 방식

`INSERT ... SELECT`의 중복 제거

비동기 삽입의 중복 제거

중복 제거 세분화 수준

비동기 삽입 및 materialized view

materialized view에서의 삽입 중복 제거

예시

materialized view 변환 후 동일한 블록

삽입 시 동일 블록

`insert_deduplication_token`을 사용한 삽입 중 동일한 블록

materialized view의 기반 테이블에서 변환 후 동일한 데이터를 생성하는 여러 삽입 작업

동등한 데이터를 하나의 기반 테이블에 삽입하는 여러 materialized view