Une alternative recommandée au moteur de table Buffer est d’activer les insertions asynchrones.
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
Paramètres facultatifs du moteur
flush_time, flush_rows, and flush_bytes
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
min_rows, max_rows, and flush_rows
min_bytes, max_bytes, and flush_bytes
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 :
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
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 et #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.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.