> ## Documentation Index
> Fetch the complete documentation index at: https://private-7c7dfe99-mintlify-8c05c8a2.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
> Place temporairement les données en mémoire tampon dans la RAM, puis les vide périodiquement dans une autre table. Lors de la lecture, les données sont lues simultanément depuis le tampon et l'autre table.
# Moteur de table Buffer
Place temporairement les données en mémoire tampon dans la RAM, puis les vide périodiquement dans une autre table. Lors de la lecture, les données sont lues simultanément depuis le tampon et l'autre table.
Une alternative recommandée au moteur de table Buffer est d'activer les [insertions asynchrones](/fr/concepts/features/operations/insert/asyncinserts).
```sql theme={null}
Buffer(database, table, num_layers, min_time, max_time, min_rows, max_rows, min_bytes, max_bytes [,flush_time [,flush_rows [,flush_bytes]]])
```
### Paramètres du moteur
#### `database`
`database` – Nom de la base de données. Vous pouvez utiliser `currentDatabase()` ou toute autre expression constante qui renvoie une chaîne de caractères.
#### `table`
`table` – Table de destination pour le vidage des données.
#### `num_layers`
`num_layers` – Niveau de parallélisme. Physiquement, la table est représentée par `num_layers` tampons indépendants.
#### `min_time`, `max_time`, `min_rows`, `max_rows`, `min_bytes`, and `max_bytes`
Conditions de vidage du tampon.
### Paramètres facultatifs du moteur
#### `flush_time`, `flush_rows`, and `flush_bytes`
Conditions de vidage en arrière-plan des données du tampon (s’ils sont omis ou égaux à zéro, cela signifie qu’il n’y a pas de paramètres `flush*`).
Les données sont vidées du tampon et écrites dans la table de destination si toutes les conditions `min*` sont remplies ou si au moins une condition `max*` l’est.
De plus, si au moins une condition `flush*` est remplie, un vidage est déclenché en arrière-plan. Cela diffère de `max*`, car `flush*` permet de configurer séparément les vidages en arrière-plan afin d’éviter d’ajouter de la latence aux requêtes `INSERT` sur les tables Buffer.
#### `min_time`, `max_time` et `flush_time`
Condition relative au délai, en secondes, à compter de la première écriture dans le tampon.
#### `min_rows`, `max_rows`, and `flush_rows`
Condition sur le nombre de lignes dans le tampon.
#### `min_bytes`, `max_bytes`, and `flush_bytes`
Condition relative au nombre d’octets dans le tampon.
Pendant l’écriture, les données sont insérées dans un ou plusieurs tampons aléatoires (configurés avec `num_layers`). Sinon, si la partie de données à insérer est suffisamment volumineuse (supérieure à `max_rows` ou `max_bytes`), elle est écrite directement dans la table de destination, sans passer par le tampon.
Les conditions de vidage des données sont calculées séparément pour chacun des `num_layers` tampons. Par exemple, si `num_layers = 16` et `max_bytes = 100000000`, la consommation maximale de RAM est de 1,6 Go.
Exemple :
```sql theme={null}
CREATE TABLE merge.hits_buffer AS merge.hits ENGINE = Buffer(merge, hits, 1, 10, 100, 10000, 1000000, 10000000, 100000000)
```
Création d’une table `merge.hits_buffer` ayant la même structure que `merge.hits` et utilisant le moteur Buffer. Lors de l’écriture dans cette table, les données sont mises en mémoire tampon dans la RAM, puis écrites ultérieurement dans la table 'merge.hits'. Un seul tampon est créé et les données sont vidées si l’une des conditions suivantes est remplie :
* 100 secondes se sont écoulées depuis la dernière vidange (`max_time`) ou
* 1 million de lignes ont été écrites (`max_rows`) ou
* 100 Mo de données ont été écrits (`max_bytes`) ou
* 10 secondes se sont écoulées (`min_time`) et 10 000 lignes (`min_rows`) et 10 Mo (`min_bytes`) de données ont été écrits
Par exemple, si une seule ligne a été écrite, elle sera vidée après 100 secondes, quoi qu’il arrive. En revanche, si de nombreuses lignes ont été écrites, les données seront vidées plus tôt.
Lorsque le serveur est arrêté, avec `DROP TABLE` ou `DETACH TABLE`, les données mises en mémoire tampon sont également vidées dans la table de destination.
Vous pouvez définir des chaînes vides entre apostrophes pour le nom de la base de données et le nom de la table. Cela indique l’absence de table de destination. Dans ce cas, lorsque les conditions de vidange des données sont remplies, le tampon est simplement effacé. Cela peut être utile pour conserver une fenêtre de données en mémoire.
Lors de la lecture depuis une table Buffer, les données sont traitées à la fois depuis le tampon et depuis la table de destination (s’il y en a une).
Notez que la table Buffer ne prend pas en charge les index. En d’autres termes, les données du tampon sont entièrement parcourues, ce qui peut être lent pour de grands tampons. (Pour les données d’une table subordonnée, l’index qu’elle prend en charge sera utilisé.)
Si l’ensemble des colonnes de la table Buffer ne correspond pas à celui d’une table subordonnée, un sous-ensemble des colonnes présentes dans les deux tables est inséré.
Si les types ne correspondent pas pour l’une des colonnes de la table Buffer et d’une table subordonnée, un message d’erreur est consigné dans le journal du serveur, et le tampon est effacé.
La même chose se produit si la table subordonnée n’existe pas au moment où le tampon est vidé.
L’exécution de ALTER sur la table Buffer dans les versions publiées avant le 26 oct. 2021 provoquera une erreur `Block structure mismatch` (voir [#15117](https://github.com/ClickHouse/ClickHouse/issues/15117) et [#30565](https://github.com/ClickHouse/ClickHouse/pull/30565)) ; supprimer la table Buffer puis la recréer est donc la seule option. Vérifiez que cette erreur est corrigée dans votre version avant d’essayer d’exécuter ALTER sur la table Buffer.
Si le serveur redémarre de manière anormale, les données du tampon sont perdues.
`FINAL` et `SAMPLE` ne fonctionnent pas correctement pour les tables Buffer. Ces conditions sont transmises à la table de destination, mais ne sont pas utilisées pour traiter les données du tampon. Si ces fonctionnalités sont nécessaires, nous recommandons d’utiliser la table Buffer uniquement pour l’écriture, et de lire depuis la table de destination.
Lors de l’ajout de données à une table Buffer, l’un des tampons est verrouillé. Cela entraîne des délais si une opération de lecture est effectuée simultanément sur la table.
Les données insérées dans une table Buffer peuvent se retrouver dans la table subordonnée dans un ordre différent et dans des blocs différents. Pour cette raison, une table Buffer est difficile à utiliser pour écrire correctement dans une CollapsingMergeTree. Pour éviter les problèmes, vous pouvez définir `num_layers` sur 1.
Si la table de destination est répliquée, certaines caractéristiques attendues des tables répliquées sont perdues lors de l’écriture dans une table Buffer. Les changements aléatoires de l’ordre des lignes et de la taille des data parts empêchent la déduplication des données de fonctionner, ce qui signifie qu’il n’est pas possible d’obtenir une écriture fiable 'exactly once' dans des tables répliquées.
En raison de ces inconvénients, nous ne pouvons recommander l’utilisation d’une table Buffer que dans de rares cas.
Une table Buffer est utilisée lorsqu’un trop grand nombre d’INSERT est reçu depuis un grand nombre de serveurs sur une période donnée, et que les données ne peuvent pas être mises en mémoire tampon avant l’insertion, ce qui signifie que les INSERT ne peuvent pas s’exécuter assez rapidement.
Notez qu’il n’est pas pertinent d’insérer des données ligne par ligne, même pour les tables Buffer. Cela ne permet d’atteindre que quelques milliers de lignes par seconde, tandis que l’insertion de blocs de données plus volumineux peut dépasser le million de lignes par seconde.