> ## Documentation Index
> Fetch the complete documentation index at: https://private-7c7dfe99-trino-dialect.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

> Les mises à jour légères simplifient la mise à jour des données dans la base de données à l’aide de patch parts.

# L’instruction Lightweight UPDATE

export const BetaBadge = ({link, galaxyTrack, galaxyEvent}) => {
  if (link) {
    return <a href={link} target="_blank" rel="noopener noreferrer" className="betaBadge" onClick={galaxyTrack && galaxyEvent ? galaxyOnClick(galaxyEvent) : undefined}>
                <span>Beta</span>
            </a>;
  }
  return <a href="https://clickhouse.com/docs/reference/settings/beta-and-experimental-features#beta-features" className="betaBadge">
            <span>Fonctionnalité en bêta</span>
        </a>;
};

<BetaBadge />

<Note>
  Les mises à jour légères sont actuellement en bêa.
  Si vous rencontrez des problèmes, veuillez ouvrir une issue dans le dépôt [ClickHouse repository](https://github.com/clickhouse/clickhouse/issues).
</Note>

L’instruction `UPDATE` légère met à jour les lignes d’une table `[db.]table` qui correspondent à l’expression `filter_expr`.
On l’appelle "mise à jour légère" pour la distinguer de la requête [`ALTER TABLE ... UPDATE`](/fr/reference/statements/alter/update), qui est un processus lourd réécrivant des colonnes entières dans les parties de données.
Elle n’est disponible que pour la famille de moteurs de table [`MergeTree`](/fr/reference/engines/table-engines/mergetree-family/mergetree).

```sql theme={null}
UPDATE [db.]table [ON CLUSTER cluster] SET column1 = expr1 [, ...] [IN PARTITION partition_expr] WHERE filter_expr;
```

Le `filter_expr` doit être de type `UInt8`. Cette requête met à jour les valeurs des colonnes spécifiées en leur attribuant les valeurs des expressions correspondantes, pour les lignes dans lesquelles `filter_expr` prend une valeur non nulle.
Les valeurs sont converties en type de colonne à l'aide de l'opérateur `CAST`. La mise à jour des colonnes utilisées dans le calcul des clés primaire ou de partition n'est pas prise en charge.

<div id="examples">
  ## Exemples
</div>

```sql theme={null}
UPDATE hits SET Title = 'Updated Title' WHERE EventDate = today();

UPDATE wikistat SET hits = hits + 1, time = now() WHERE path = 'ClickHouse';
```

<div id="lightweight-update-does-not-update-data-immediately">
  ## Les mises à jour légères ne mettent pas les données à jour immédiatement
</div>

L’`UPDATE` léger repose sur des **patch parts** — un type spécial de partie de données qui contient uniquement les colonnes et les lignes mises à jour.
Un `UPDATE` léger crée des patch parts, mais ne modifie pas immédiatement et physiquement les données d’origine en stockage.
Le processus de mise à jour est similaire à une requête `INSERT ... SELECT ...`, mais la requête `UPDATE` attend que la création de la patch part soit terminée avant de renvoyer la réponse.

Les valeurs mises à jour sont :

* **Immédiatement visibles** dans les requêtes `SELECT` grâce à l’application des patchs
* **Physiquement matérialisées** uniquement lors des fusions et mutations ultérieures
* **Supprimées automatiquement** une fois les patchs matérialisés dans toutes les parties actives

<div id="lightweight-update-requirements">
  ## Exigences pour les mises à jour légères
</div>

Les mises à jour légères sont prises en charge par les moteurs [`MergeTree`](/fr/reference/engines/table-engines/mergetree-family/mergetree), [`ReplacingMergeTree`](/fr/reference/engines/table-engines/mergetree-family/replacingmergetree), [`CollapsingMergeTree`](/fr/reference/engines/table-engines/mergetree-family/collapsingmergetree), [`VersionedCollapsingMergeTree`](/fr/reference/engines/table-engines/mergetree-family/versionedcollapsingmergetree), ainsi que par leurs versions [`Replicated`](/fr/reference/engines/table-engines/mergetree-family/replication) et [`Shared`](/fr/products/cloud/features/infrastructure/shared-merge-tree).

Pour utiliser les mises à jour légères, la matérialisation des colonnes `_block_number` et `_block_offset` doit être activée à l’aide des paramètres de table [`enable_block_number_column`](/fr/reference/settings/merge-tree-settings/enable-block#enable_block_number_column) et [`enable_block_offset_column`](/fr/reference/settings/merge-tree-settings/enable-block#enable_block_offset_column).

<div id="lightweight-delete">
  ## Suppressions légères
</div>

Une requête [lightweight `DELETE`](/fr/reference/statements/delete) peut être exécutée sous forme de `UPDATE` léger plutôt que comme une mutation `ALTER UPDATE`. L'implémentation de lightweight `DELETE` est contrôlée par le paramètre [`lightweight_delete_mode`](/fr/reference/settings/session-settings/lightweight#lightweight_delete_mode).

<div id="performance-considerations">
  ## Considérations relatives aux performances
</div>

**Avantages des mises à jour légères :**

* La latence de la mise à jour est comparable à celle de la requête `INSERT ... SELECT ...`
* Seules les colonnes et les valeurs mises à jour sont écrites, et non des colonnes entières dans les parties de données
* Il n’est pas nécessaire d’attendre la fin des fusions/mutations en cours, la latence d’une mise à jour est donc prévisible
* L’exécution parallèle des mises à jour légères est possible

**Impacts potentiels sur les performances :**

* Ajoute un surcoût aux requêtes `SELECT` qui doivent appliquer des patchs
* Les [index de saut de données](/fr/reference/engines/table-engines/mergetree-family/mergetree#table_engine-mergetree-data_skipping-indexes) ne seront pas utilisés pour les colonnes des parties de données auxquelles des patchs doivent être appliqués. Les [projections](/fr/reference/engines/table-engines/mergetree-family/mergetree#projections) ne seront pas utilisées s’il existe des patch parts pour la table, y compris pour les parties de données auxquelles aucun patch ne doit être appliqué.
* De petites mises à jour trop fréquentes peuvent entraîner une erreur « too many parts ». Il est recommandé de regrouper plusieurs mises à jour dans une seule requête, par exemple en plaçant les ID à mettre à jour dans une seule clause `IN` de la clause `WHERE`
* Les mises à jour légères sont conçues pour mettre à jour de petites quantités de lignes (jusqu’à environ 10 % de la table). Si vous devez en mettre à jour une plus grande quantité, il est recommandé d’utiliser la mutation [`ALTER TABLE ... UPDATE`](/fr/reference/statements/alter/update)

<div id="concurrent-operations">
  ## Opérations concurrentes
</div>

Contrairement aux mutations lourdes, les mises à jour légères n'attendent pas la fin des fusions/mutations en cours.
La cohérence des mises à jour légères concurrentes est contrôlée par les paramètres [`update_sequential_consistency`](/fr/reference/settings/session-settings/update#update_sequential_consistency) et [`update_parallel_mode`](/fr/reference/settings/session-settings/update#update_parallel_mode).

<div id="update-permissions">
  ## Autorisations de mise à jour
</div>

`UPDATE` nécessite le privilège `ALTER UPDATE`. Pour permettre à un utilisateur donné d’exécuter des instructions `UPDATE` sur une table spécifique, exécutez :

```sql theme={null}
GRANT ALTER UPDATE ON db.table TO username;
```

<div id="details-of-the-implementation">
  ## Détails de l’implémentation
</div>

Les patch parts sont identiques aux parts ordinaires, mais ne contiennent que les colonnes mises à jour, les colonnes de la clé de tri de la table et les colonnes système suivantes :

* `_part` - le nom de la part d’origine
* `_block_number` - le numéro du block de la ligne dans la part d’origine
* `_block_offset` - le décalage du block de la ligne dans la part d’origine
* `_data_version` - la version des données mises à jour (numéro de block alloué à la requête `UPDATE`)

Les colonnes système aident à trouver les lignes de la part d’origine qui doivent être mises à jour.
Elles sont liées aux [colonnes virtuelles](/fr/reference/engines/table-engines/mergetree-family/mergetree#virtual-columns) de la part d’origine, qui sont ajoutées à la lecture lorsque des patch parts doivent être appliquées.
Les patch parts sont triées selon la clé de tri de la table, à laquelle sont ajoutées les colonnes `_block_number` et `_block_offset`.
Le surcoût de stockage par ligne mise à jour dépend de la taille des valeurs des colonnes de la clé de tri.

Les patch parts appartiennent à des partitions différentes de celle de la part d’origine.
L’identifiant de partition de la patch part est `patch-<hash of the patch part structure>-<original_partition_id>`.
Par conséquent, les patch parts avec des colonnes différentes sont stockées dans des partitions différentes.
Par exemple, trois mises à jour `SET x = 1 WHERE <cond>`, `SET y = 1 WHERE <cond>` et `SET x = 1, y = 1 WHERE <cond>` créeront trois patch parts dans trois partitions différentes.

Les patch parts peuvent être fusionnées entre elles afin de réduire le nombre de patchs appliqués aux requêtes `SELECT` et de limiter le surcoût. La fusion des patch parts utilise l’algorithme de fusion [replacing](/fr/reference/engines/table-engines/mergetree-family/replacingmergetree) avec `_data_version` comme colonne de version.
Par conséquent, les patch parts stockent toujours la version la plus récente de chaque ligne mise à jour dans la part.

Une patch part est appliquée en la fusionnant avec la partie de données selon la clé de tri de la table : une ligne est mise à jour si les valeurs des colonnes de la clé de tri ainsi que des colonnes `_block_number` et `_block_offset` sont égales dans la partie de données et dans la patch part.
L’application des patch parts nécessite de lire les colonnes de la clé de tri de la partie de données, même si la requête ne les sélectionne pas.
L’utilisation de mémoire liée à l’application d’une patch part est limitée par la plus grande plage de lignes ayant des valeurs de clé de tri égales.

<div id="patch-parts-format-in-mixed-version-clusters">
  ### Format des patch parts dans les clusters à versions mixtes
</div>

Le format des nouveaux patch parts est contrôlé par le paramètre de table [`patch_parts_version`](/fr/reference/settings/merge-tree-settings).
Les versions de ClickHouse antérieures à la version 26.8 ne prennent en charge que le format legacy `v1` et ne peuvent pas lire les patch parts au format actuel `v2` décrit ci-dessus.
Lors d’une rolling upgrade depuis une telle version, continuez à écrire au format `v1` jusqu’à ce que toutes les répliques soient mises à niveau : définissez `patch_parts_version = 'v1'` pour les tables utilisant des mises à jour légères, ou définissez le paramètre [`compatibility`](/fr/reference/settings/session-settings/compatibility#compatibility) sur la version depuis laquelle vous effectuez la mise à niveau.
Une fois la mise à niveau terminée, supprimez l’override afin de commencer à écrire les patch parts au format `v2`.
Les patch parts des deux formats restent lisibles et applicables, quelle que soit la valeur du paramètre.

<div id="related-content">
  ## Contenu connexe
</div>

* [`ALTER UPDATE`](/fr/reference/statements/alter/update) - Opérations `UPDATE` lourdes
* [Lightweight `DELETE`](/fr/reference/statements/delete) - Opérations de `DELETE` légères
* [`APPLY PATCHES`](/fr/reference/statements/alter/apply-patches) - Forcer la matérialisation physique des patchs sur les parties de données (opération de mutation)