Lors de l’utilisation du moteur de table Memory sur ClickHouse Cloud, les données ne sont pas répliquées sur tous les nœuds (c’est intentionnel). Pour garantir que toutes les requêtes sont acheminées vers le même nœud et que le moteur de table Memory fonctionne comme prévu, vous pouvez procéder de l’une des manières suivantes :
- Exécuter toutes les opérations dans la même session
- Utiliser un client qui passe par TCP ou l’interface native (ce qui active la prise en charge des connexions persistantes), comme clickhouse-client
PREWHERE, y compris le déplacement automatique des conditions WHERE contrôlé par le paramètre optimize_move_to_prewhere : seules les colonnes des conditions sont lues dans un premier temps, et les colonnes restantes ne sont lues que pour les blocs dans lesquels certaines lignes satisfont les conditions, et uniquement pour ces lignes. Une conjonction de conditions est évaluée par étapes, comme dans MergeTree avec le paramètre enable_multiple_prewhere_read_steps : les colonnes de chaque condition suivante ne sont lues que pour les lignes ayant satisfait les conditions précédentes. C’est particulièrement avantageux en combinaison avec compress = true, car pour une condition sélective, la plupart des colonnes ne sont jamais décompressées. SELECT count() FROM table sans filtre est servi à partir des métadonnées, sans lire les données.
Les performances maximales (plus de 10 Go/s) sont atteintes sur des requêtes simples, car il n’y a ni lecture depuis le disque, ni décompression, ni désérialisation des données. (Notons que, dans bien des cas, les performances du moteur MergeTree sont presque aussi élevées.)
Lors du redémarrage d’un serveur, les données disparaissent de la table et celle-ci devient vide.
En règle générale, l’utilisation de ce moteur de table ne se justifie pas. Il peut toutefois être utilisé pour des tests, ainsi que pour des tâches nécessitant une vitesse maximale sur un nombre relativement faible de lignes (jusqu’à environ 100 000 000).
Le moteur Memory est utilisé par le système pour les tables temporaires contenant des données externes de requête (voir la section “External data for processing a query”), ainsi que pour l’implémentation de GLOBAL IN (voir la section “IN operators”).
Des limites haute et basse peuvent être spécifiées pour limiter la taille des tables du moteur Memory, ce qui lui permet de fonctionner comme un tampon circulaire (voir Paramètres du moteur).
Paramètres du moteur
min_bytes_to_keep— Nombre minimal d’octets à conserver lorsque la taille de la table en mémoire est plafonnée.- Valeur par défaut :
0 - Nécessite
max_bytes_to_keep
- Valeur par défaut :
max_bytes_to_keep— Nombre maximal d’octets à conserver dans la table en mémoire, où les lignes les plus anciennes sont supprimées à chaque insertion (c.-à-d. tampon circulaire). Ce maximum peut dépasser la limite indiquée si, lors de l’ajout d’un grand bloc, la suppression du plus ancien lot de lignes ferait passer le total sous la limitemin_bytes_to_keep.- Valeur par défaut :
0
- Valeur par défaut :
min_rows_to_keep— Nombre minimal de lignes à conserver lorsque la taille de la table en mémoire est plafonnée.- Valeur par défaut :
0 - Nécessite
max_rows_to_keep
- Valeur par défaut :
max_rows_to_keep— Nombre maximal de lignes à conserver dans la table en mémoire, où les lignes les plus anciennes sont supprimées à chaque insertion (c.-à-d. tampon circulaire). Ce maximum peut dépasser la limite indiquée si, lors de l’ajout d’un grand bloc, la suppression du plus ancien lot de lignes ferait passer le total sous la limitemin_rows_to_keep.- Valeur par défaut :
0
- Valeur par défaut :
compress- Indique s’il faut compresser les données en mémoire.- Valeur par défaut :
false
- Valeur par défaut :
Utilisation
Initialiser les paramètresbytes et rows peuvent être définis simultanément ; toutefois, les bornes inférieures de max et min seront appliquées.