cached stocke le dictionnaire dans un cache comportant un nombre fixe de cellules.
Ces cellules contiennent des éléments fréquemment utilisés.
La clé du dictionnaire est de type UInt64.
Lors d’une recherche dans un dictionnaire, le cache est consulté en premier. Pour chaque bloc de données, toutes les clés qui ne sont pas trouvées dans le cache ou qui sont obsolètes sont demandées à la source à l’aide de SELECT attrs... FROM db.table WHERE id IN (k1, k2, ...). Les données reçues sont ensuite écrites dans le cache.
Cela s’applique à la recherche d’une clé — dictGet et les autres fonctions de dictionnaire. Lire le dictionnaire en tant que table avec SELECT ... FROM <dictionary> est différent : comme un cache ne conserve aucune trace des clés existantes, la lecture énumère uniquement les cellules qui se trouvent présentes dans le cache à cet instant et qui contiennent une valeur, et un WHERE sur la clé est un filtre ordinaire appliqué à ces cellules, et non une liste de clés à récupérer. Une clé absente du cache ne peut pas être découverte de cette manière, quel que soit le contenu du WHERE. Une clé qui a été recherchée mais qui n’a pas été trouvée à la source n’est pas visible non plus : le cache mémorise l’échec sous la forme d’une cellule par défaut, et une lecture sous forme de table ignore les cellules par défaut. Les cellules présentes ne sont pas non plus exemptes de sollicitation de la source : une cellule expirée est lue via le même chemin que dictGet, elle est donc redemandée à la source — de manière synchrone, ou asynchrone si allow_read_expired_keys est activé.
dictGet avec le layout direct, qui interroge la source à chaque recherche et ne met rien en cache. Notez qu’une lecture sous forme de table d’un dictionnaire direct n’est pas non plus une récupération par clé : SELECT ... FROM <dictionary> WHERE key IN (...) charge l’intégralité de la source puis applique le filtre, car ClickHouse ne pousse pas le filtre sur la clé dans le dictionnaire. Pour lire un dictionnaire sous forme de table, utilisez un layout qui le contient entièrement, tel que flat ou hashed.
Si des clés ne sont pas trouvées dans le dictionnaire, une tâche de mise à jour du cache est créée et ajoutée à la file d’attente de mise à jour. Les propriétés de cette file d’attente peuvent être contrôlées avec les paramètres max_update_queue_size, update_queue_push_timeout_milliseconds, query_wait_timeout_milliseconds, max_threads_for_updates.
Pour les dictionnaires cache, la durée de vie des données dans le cache peut être définie. Si un délai supérieur à lifetime s’est écoulé depuis le chargement des données dans une cellule, la valeur de la cellule n’est pas utilisée et la clé expire. La clé est redemandée la prochaine fois qu’elle doit être utilisée. Ce comportement peut être configuré avec le paramètre allow_read_expired_keys.
C’est la méthode la moins efficace de toutes pour stocker des dictionnaires. La vitesse du cache dépend fortement du bon réglage des paramètres et du scénario d’utilisation. Un dictionnaire de type cache n’est performant que lorsque le taux de réussite est suffisamment élevé (99 % ou plus recommandé). Vous pouvez consulter le taux de réussite moyen dans la table system.dictionaries.
Si le paramètre allow_read_expired_keys est défini sur 1 (0 par défaut), le dictionnaire peut alors prendre en charge des mises à jour asynchrones. Si un client demande des clés et qu’elles sont toutes dans le cache, mais que certaines ont expiré, le dictionnaire renverra au client les clés expirées et les redemandera de manière asynchrone à la source.
Pour améliorer les performances du cache, utilisez une sous-requête avec LIMIT et appelez la fonction avec le dictionnaire à l’extérieur.
Tous les types de sources sont pris en charge.
Exemple de paramètres :
- DDL
- Fichier de configuration
Définissez une taille de cache suffisamment grande. Vous devrez faire des essais pour choisir le nombre de cellules :
- Définissez une valeur.
- Exécutez des requêtes jusqu’à ce que le cache soit complètement rempli.
- Évaluez la consommation de mémoire à l’aide de la table
system.dictionaries. - Augmentez ou diminuez le nombre de cellules jusqu’à atteindre la consommation mémoire souhaitée.
ClickHouse n’est pas recommandé comme source pour ce layout. Les recherches dans le dictionnaire nécessitent des lectures ponctuelles aléatoires, ce qui ne correspond pas au modèle d’accès pour lequel ClickHouse est optimisé.