Deduplicación de inserciones en reintentos

Las operaciones de inserción a veces pueden fallar por errores como timeouts. Cuando una inserción falla, puede que los datos se hayan insertado correctamente o puede que no. Esta guía explica cómo funciona la deduplicación en los reintentos de inserción para que los mismos datos no se inserten más de una vez. Cuando se reintenta una inserción, ClickHouse intenta determinar si los datos ya se insertaron correctamente. Si los datos insertados se marcan como duplicados, ClickHouse no los inserta en la tabla de destino. Sin embargo, el usuario seguirá recibiendo un estado de operación correcta, como si los datos se hubieran insertado con normalidad. La deduplicación abarca inserciones síncronas, inserciones asíncronas y consultas INSERT ... SELECT. La configuración deduplicate_insert controla las inserciones síncronas y asíncronas. INSERT ... SELECT requiere especial atención y tiene su propia configuración. Consulte Configuraciones que controlan la deduplicación de inserciones.

Limitaciones

Estado incierto de la inserción

El usuario debe reintentar la operación de inserción hasta que tenga éxito. Si todos los reintentos fallan, es imposible determinar si los datos se insertaron o no. Cuando intervienen vistas materializadas, tampoco queda claro en qué tablas pueden haber aparecido los datos. Las vistas materializadas podrían no estar sincronizadas con la tabla de origen.

Límite de la ventana de deduplicación

Si durante la secuencia de reintentos se producen más de *_deduplication_window operaciones de inserción adicionales, es posible que la deduplicación no funcione correctamente. En ese caso, los mismos datos pueden insertarse varias veces.

Configuraciones que controlan la deduplicación de inserciones

ClickHouse deduplica una inserción solo cuando se cumplen las dos condiciones siguientes:

La tabla de destino conserva un registro de deduplicación. Esta es una configuración a nivel de tabla.
La deduplicación está habilitada para la consulta. Esta es una configuración a nivel de consulta.

Ajustes a nivel de tabla

Solo los motores *MergeTree admiten la deduplicación durante la inserción. Para los motores *ReplicatedMergeTree, el registro de deduplicación está habilitado de forma predeterminada y se controla mediante los ajustes replicated_deduplication_window y replicated_deduplication_window_seconds. Para los motores *MergeTree no replicados, el registro se controla mediante el ajuste non_replicated_deduplication_window, cuyo valor predeterminado es 0. Por lo tanto, una tabla MergeTree simple no deduplica nada hasta que configure esa ventana con un valor positivo. Los ajustes anteriores determinan los parámetros del registro de deduplicación de una tabla. El registro de deduplicación almacena un número finito de block_id, que determinan cómo funciona la deduplicación (véase más abajo).

replicated_deduplication_window_for_async_inserts y replicated_deduplication_window_seconds_for_async_inserts son ajustes heredados. Las inserciones síncronas y asíncronas ahora comparten un único registro de deduplicación, por lo que replicated_deduplication_window controla ambas. Los ajustes heredados solo delimitaban el antiguo directorio de ClickHouse Keeper, lo cual es relevante durante una actualización progresiva.

Configuraciones a nivel de consulta

Configuración	Se aplica a	Predeterminado	Propósito
`deduplicate_insert`	Cada `INSERT`, síncrono o asíncrono	`enable`	Interruptor principal de la deduplicación de inserciones
`deduplicate_insert_select`	`INSERT ... SELECT`	`enable_when_possible`	Determina qué hacer cuando el resultado de `SELECT` no es reproducible
`insert_deduplication_token`	Cada `INSERT`	`''`	Identifica la inserción mediante una cadena proporcionada por el usuario, en lugar de los datos
`deduplicate_blocks_in_dependent_materialized_views`	Tablas asociadas a vistas materializadas	`1`	Extiende la deduplicación a los destinos de las vistas materializadas dependientes

deduplicate_insert acepta tres valores:

enable — la deduplicación está habilitada para la consulta INSERT.
disable — la deduplicación está deshabilitada para la consulta INSERT.
backward_compatible_choice — la decisión se delega en las configuraciones heredadas insert_deduplicate (inserciones síncronas) y async_insert_deduplicate (inserciones asíncronas).

Tenga en cuenta que una consulta que se ejecuta con deduplicate_insert = disable no escribe ningún block_id para sus bloques. Esos datos no se pueden deduplicar posteriormente, incluso si vuelve a intentar la inserción con deduplicate_insert = enable. Lo mismo ocurre si la tabla de destino no conserva ningún registro de deduplicación: no se registra nada, por lo que no se puede encontrar ninguna coincidencia al volver a intentarlo.

Precedencia

Para una consulta INSERT ... SELECT, prevalece deduplicate_insert_select. Consulte Deduplicación para INSERT … SELECT.
Para cualquier otro INSERT, prevalece deduplicate_insert.
insert_deduplicate y async_insert_deduplicate solo se leen cuando deduplicate_insert tiene el valor backward_compatible_choice.

Configuraciones heredadas y obsoletas

Configuración	Estado	Usar en su lugar
`insert_deduplicate`	Heredada. Solo se lee cuando `deduplicate_insert = backward_compatible_choice`	`deduplicate_insert`
`async_insert_deduplicate`	Heredada. Solo se lee cuando `deduplicate_insert = backward_compatible_choice`	`deduplicate_insert`
`insert_select_deduplicate`	Obsoleta. No tiene efecto	`deduplicate_insert_select`
`update_insert_deduplication_token_in_dependent_materialized_views`	Obsoleta. No tiene efecto	—

A partir de la versión 26.2, deduplicate_insert tiene como valor predeterminado enable. Por lo tanto, establecer insert_deduplicate = 0 ya no desactiva por sí solo la deduplicación. Para desactivarla, establezca deduplicate_insert = disable.

La versión 26.2 también cambió los valores predeterminados de async_insert y deduplicate_blocks_in_dependent_materialized_views a habilitados. La configuración compatibility controla las tres. Si establece compatibility en una versión anterior a 26.2, estas configuraciones conservan sus valores predeterminados anteriores: deduplicate_insert pasa a ser backward_compatible_choice, que delega la decisión en insert_deduplicate y async_insert_deduplicate. Una configuración establecida explícitamente siempre se respeta y nunca se ve afectada por compatibility.

Cómo funciona la deduplicación de inserciones

Cuando los datos se insertan en ClickHouse, se dividen en bloques en función del número de filas y bytes. En las tablas que usan motores *MergeTree, a cada bloque se le asigna un block_id único, que es un hash de los datos de ese bloque. Este block_id se utiliza como clave única para la operación de inserción. Si se encuentra el mismo block_id en el registro de deduplicación, el bloque se considera duplicado y no se inserta en la tabla. Este enfoque funciona bien cuando las inserciones contienen datos distintos. Sin embargo, si los mismos datos se insertan varias veces de forma intencionada, debes usar la configuración insert_deduplication_token para controlar el proceso de deduplicación. Esta configuración te permite especificar un token único para cada inserción, que ClickHouse utiliza para determinar si los datos están duplicados. insert_deduplication_token tiene mayor prioridad: ClickHouse no utiliza la suma hash de los datos cuando se proporciona el token. Para las consultas INSERT ... VALUES, la división de los datos insertados en bloques es determinista y viene determinada por la configuración. Por lo tanto, debes reintentar las inserciones con los mismos valores de configuración que en la operación inicial.

Deduplicación para `INSERT ... SELECT`

En las consultas INSERT ... SELECT, la parte SELECT debe devolver los mismos datos en el mismo orden en cada intento. De lo contrario, los bloques serán distintos, los block_ids también y el reintento no se reconocerá como duplicado. ClickHouse no puede verificar que los datos de origen no hayan cambiado, pero sí puede comprobar si la consulta produce un resultado reproducible. Un SELECT se considera estable cuando se cumplen las dos condiciones siguientes:

La consulta incluye una cláusula ORDER BY ALL. Solo se reconoce el literal ORDER BY ALL. Un simple ORDER BY <expressions> no se reconoce, y un UNION de dos o más SELECTs nunca es estable.
La canalización de lectura termina en un único flujo.

Un insert_deduplication_token no vacío es un sustituto equivalente de la estabilidad, ya que el token, y no los datos, identifica la inserción. La configuración deduplicate_insert_select determina qué hacer:

Valor	Comportamiento
`enable_when_possible` (predeterminado)	Deduplica cuando el `SELECT` es estable o se ha establecido un token. De lo contrario, omite la deduplicación y escribe un mensaje en el registro del servidor.
`force_enable`	Siempre deduplica. Si el `SELECT` no es estable y no se ha establecido ningún token, lanza la excepción `DEDUPLICATION_IS_NOT_POSSIBLE`.
`enable_even_for_bad_queries`	Deduplica independientemente de la estabilidad. Se mantiene por compatibilidad con versiones anteriores. Con un `SELECT` inestable, el reintento normalmente no se reconoce como duplicado, por lo que se recomienda usar otro valor.
`disable`	Nunca deduplica `INSERT ... SELECT`.

enable_when_possible y enable_even_for_bad_queries también respetan deduplicate_insert: si es disable, la consulta no se deduplica. force_enable sobrescribe deduplicate_insert. Tenga en cuenta que la tabla seleccionada puede actualizarse entre reintentos. En ese caso, las dos opciones se comportan de forma opuesta:

Sin insert_deduplication_token, los block_ids se calculan a partir de los datos. El resultado modificado genera block_ids distintos, no se produce la deduplicación y el reintento inserta los nuevos datos además de los que ya hubiera escrito el primer intento.
Con insert_deduplication_token, el token por sí solo identifica la inserción. El reintento se reconoce como duplicado y se descarta, aunque hubiera insertado datos diferentes.

Elija la opción que se ajuste al significado que desea dar a un reintento. Además, al insertar grandes cantidades de datos, el número de bloques puede desbordar la ventana del registro de deduplicación, por lo que ClickHouse no podrá deduplicarlos.

Deduplicación de inserciones asíncronas

Las inserciones asíncronas (async_insert, habilitadas de forma predeterminada desde la versión 26.2) se deduplican en los reintentos del mismo modo que las inserciones síncronas. deduplicate_insert controla ambas, por lo que no se requiere una opción independiente. Ambos tipos de inserción también comparten un registro de deduplicación y calculan los block_id del mismo modo. Por lo tanto, puede alternar un client entre inserciones síncronas y asíncronas sin afectar a la deduplicación, y un reintento enviado en un modo seguirá reconociéndose como duplicado de un intento enviado en el otro. Migrar una carga de trabajo de inserciones síncronas a asíncronas sigue siendo seguro en una tabla que depende de la deduplicación.

Antes de la versión 26.2, la deduplicación de inserciones asíncronas estaba deshabilitada de forma predeterminada y se controlaba mediante async_insert_deduplicate. Esta configuración ahora solo se consulta cuando deduplicate_insert es backward_compatible_choice.

Granularidad de la deduplicación

El servidor agrupa varias inserciones asíncronas en un lote y escribe ese lote como una o más partes, al menos una por cada valor distinto de la clave de partición. La deduplicación funciona por consulta de usuario, no por lote:

Cada consulta en cola aporta un token de deduplicación al lote.
Un token es el valor de insert_deduplication_token, cuando la consulta proporciona uno, o un hash de las filas aportadas por esa consulta.
La agrupación en lotes no influye en los tokens, y insert_deduplication_token no influye en cómo se agrupan las consultas en lotes.

Esto tiene dos consecuencias:

Cuando una consulta de un lote es un duplicado, ClickHouse elimina solo las filas de esa consulta. El resto del lote se inserta normalmente. Una parte se omite por completo únicamente cuando se eliminan todas sus filas.
Cuando dos consultas del mismo lote tienen el mismo token, la segunda se descarta antes de escribir la parte. Esto se aplica por partición: si las dos consultas escriben filas en particiones diferentes, ambas se conservan.

Los eventos DuplicatedAsyncInserts y SelfDuplicatedAsyncInserts de system.events contabilizan estos dos casos.

Inserciones asíncronas y vistas materializadas

La deduplicación de inserciones asíncronas funciona junto con las vistas materializadas dependientes. La regla es sencilla: un bloque de entrada produce un bloque de salida. Si la consulta interna de una vista transforma un bloque de entrada en un bloque de salida, la deduplicación funciona. Si la vista genera un segundo bloque, ClickHouse lanza una excepción NOT_IMPLEMENTED. Una vista genera un segundo bloque cuando su salida ya no cabe en un único bloque. max_block_size determina cuántas filas caben. Las transformaciones de columnas, el filtrado y la agregación nunca añaden filas, por lo que siempre permanecen en un único bloque. Un JOIN puede añadir filas. Funciona mientras el resultado se mantenga por debajo de max_block_size, pero falla si lo supera. Para insertar mediante una vista que genera más de un bloque, establezca deduplicate_blocks_in_dependent_materialized_views = 0 o use inserciones síncronas.

Deduplicación de inserciones con vistas materializadas

Cuando una tabla tiene una o más vistas materializadas, los datos insertados también se insertan en el destino de esas vistas con las transformaciones definidas. Los datos transformados también se deduplican en los reintentos. ClickHouse realiza la deduplicación en las vistas materializadas del mismo modo que deduplica los datos insertados en la tabla de destino. Puede controlar este proceso con los siguientes ajustes de la tabla de origen:

La deduplicación en las tablas asociadas a vistas materializadas también se rige por el ajuste del perfil de usuario deduplicate_blocks_in_dependent_materialized_views, que está habilitado de forma predeterminada desde la versión 26.2. Ambos ajustes deben permitirla: deduplicate_insert deduplica los datos insertados en la tabla de origen y deduplicate_blocks_in_dependent_materialized_views además deduplica los datos en las tablas dependientes. Habilite ambos si desea una deduplicación completa. Al insertar bloques en tablas asociadas a vistas materializadas, ClickHouse calcula el block_id aplicando un hash a una cadena que combina los block_id de la tabla de origen con identificadores adicionales. Esto garantiza una deduplicación precisa dentro de las vistas materializadas, lo que permite distinguir los datos según su inserción original, independientemente de cualquier transformación aplicada antes de llegar a la tabla de destino de la vista materializada.

Ejemplos

Bloques idénticos tras las transformaciones de una vista materializada

Los bloques idénticos generados durante la transformación dentro de una vista materializada no se deduplican porque se basan en datos insertados distintos. Aquí tiene un ejemplo:

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;

La configuración anterior nos permite seleccionar desde una tabla con una serie de bloques que contienen solo una fila. Estos bloques pequeños no se compactan y permanecen iguales hasta que se insertan en una tabla. Hacemos explícita la deduplicación en la vista materializada, aunque está habilitada de forma predeterminada:

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 │
└─────┴───────┴───────────┘

Aquí vemos que se han insertado dos partes en la tabla dst. 2 bloques del select — 2 partes al insertar. Las partes contienen datos diferentes.

SELECT
    *,
    _part
FROM mv_dst
ORDER BY all;

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

Aquí vemos que se han insertado 2 partes en la tabla mv_dst. Esas partes contienen los mismos datos; sin embargo, no se han deduplicado.

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 │
└─────┴───────┴───────────┘

Aquí vemos que, al reintentar las inserciones, todos los datos se deduplican. La deduplicación funciona tanto para las tablas dst como mv_dst.

Bloques idénticos al insertar

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;

Inserción:

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 │
└────────────┴─────┴───────┴───────────┘

Con la configuración anterior, se obtienen dos bloques de select–; por lo tanto, debería haber dos bloques para insertar en la tabla dst. Sin embargo, vemos que solo se ha insertado un bloque en la tabla dst. Esto ocurrió porque el segundo bloque se ha deduplicado. Tiene los mismos datos y la clave de deduplicación block_id, que se calcula como un hash a partir de los datos insertados. Este comportamiento no era el esperado. Estos casos son poco frecuentes, pero teóricamente son posibles. Para manejar estos casos correctamente, el usuario tiene que proporcionar un insert_deduplication_token. Corrijámoslo con los siguientes ejemplos:

Bloques idénticos durante la inserción con `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;

Inserción:

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 │
└────────────┴─────┴───────┴───────────┘

Se han insertado dos bloques idénticos, como se esperaba.

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 │
└────────────┴─────┴───────┴───────────┘

La inserción reintentada se deduplica según lo esperado.

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 │
└────────────┴─────┴───────┴───────────┘

Esa inserción también se deduplica, aunque contenga datos insertados distintos. Ten en cuenta que insert_deduplication_token tiene prioridad: ClickHouse no usa la suma hash de los datos cuando se proporciona insert_deduplication_token.

Diferentes operaciones de inserción generan los mismos datos tras la transformación en la tabla subyacente de la vista materializada

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 │
└───────────────┴─────┴───────┴───────────┘

Insertamos datos distintos cada vez. Sin embargo, en la tabla mv_dst se insertan los mismos datos. Los datos no se deduplican porque los datos de entrada eran distintos.

Diferentes inserciones de vistas materializadas en una misma tabla subyacente con datos equivalentes

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 │
└───────────────┴─────┴───────┴───────────┘

Se insertaron dos bloques iguales en la tabla mv_dst (como se esperaba).

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 │
└───────────────┴─────┴───────┴───────────┘

Esa operación de reintento se deduplica en ambas tablas, dst y mv_dst.

Fundamentals

ClickHouse concepts

Best practices

Deduplicación de inserciones en reintentos

Limitaciones

Estado incierto de la inserción

Límite de la ventana de deduplicación

Configuraciones que controlan la deduplicación de inserciones

Ajustes a nivel de tabla

Configuraciones a nivel de consulta

Precedencia

Configuraciones heredadas y obsoletas

Cómo funciona la deduplicación de inserciones

Deduplicación para `INSERT ... SELECT`

Deduplicación de inserciones asíncronas

Granularidad de la deduplicación

Inserciones asíncronas y vistas materializadas

Deduplicación de inserciones con vistas materializadas

Ejemplos

Bloques idénticos tras las transformaciones de una vista materializada

Bloques idénticos al insertar

Bloques idénticos durante la inserción con `insert_deduplication_token`

Diferentes operaciones de inserción generan los mismos datos tras la transformación en la tabla subyacente de la vista materializada

Diferentes inserciones de vistas materializadas en una misma tabla subyacente con datos equivalentes

​Limitaciones

​Estado incierto de la inserción

​Límite de la ventana de deduplicación

​Configuraciones que controlan la deduplicación de inserciones

​Ajustes a nivel de tabla

​Configuraciones a nivel de consulta

​Precedencia

​Configuraciones heredadas y obsoletas

​Cómo funciona la deduplicación de inserciones

​Deduplicación para INSERT ... SELECT

​Deduplicación de inserciones asíncronas

​Granularidad de la deduplicación

​Inserciones asíncronas y vistas materializadas

​Deduplicación de inserciones con vistas materializadas

​Ejemplos

​Bloques idénticos tras las transformaciones de una vista materializada

​Bloques idénticos al insertar

​Bloques idénticos durante la inserción con insert_deduplication_token

​Diferentes operaciones de inserción generan los mismos datos tras la transformación en la tabla subyacente de la vista materializada

​Diferentes inserciones de vistas materializadas en una misma tabla subyacente con datos equivalentes

Limitaciones

Estado incierto de la inserción

Límite de la ventana de deduplicación

Configuraciones que controlan la deduplicación de inserciones

Ajustes a nivel de tabla

Configuraciones a nivel de consulta

Precedencia

Configuraciones heredadas y obsoletas

Cómo funciona la deduplicación de inserciones

Deduplicación para `INSERT ... SELECT`

Deduplicación de inserciones asíncronas

Granularidad de la deduplicación

Inserciones asíncronas y vistas materializadas

Deduplicación de inserciones con vistas materializadas

Ejemplos

Bloques idénticos tras las transformaciones de una vista materializada

Bloques idénticos al insertar

Bloques idénticos durante la inserción con `insert_deduplication_token`

Diferentes operaciones de inserción generan los mismos datos tras la transformación en la tabla subyacente de la vista materializada

Diferentes inserciones de vistas materializadas en una misma tabla subyacente con datos equivalentes