layout de dictionnaire cache

Stocke un dictionnaire dans un cache en mémoire de taille fixe.

Le type de layout de dictionnaire 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.

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

LAYOUT(CACHE(SIZE_IN_CELLS 1000000000))

Fichier de configuration

<layout>
    <cache>
        <!-- La taille du cache, en nombre de cellules. Arrondie à une puissance de deux. -->
        <size_in_cells>1000000000</size_in_cells>
        <!-- Permet de lire les clés expirées. -->
        <allow_read_expired_keys>0</allow_read_expired_keys>
        <!-- Taille maximale de la file d'attente de mise à jour. -->
        <max_update_queue_size>100000</max_update_queue_size>
        <!-- Délai d'attente maximal, en millisecondes, pour ajouter une tâche de mise à jour à la file d'attente. -->
        <update_queue_push_timeout_milliseconds>10</update_queue_push_timeout_milliseconds>
        <!-- Délai d'attente maximal, en millisecondes, pour que la tâche de mise à jour se termine. -->
        <query_wait_timeout_milliseconds>60000</query_wait_timeout_milliseconds>
        <!-- Nombre maximal de threads pour la mise à jour du dictionnaire cache. -->
        <max_threads_for_updates>4</max_threads_for_updates>
    </cache>
</layout>

Définissez une taille de cache suffisamment grande. Vous devrez faire des essais pour choisir le nombre de cellules :

1. Définissez une valeur.
2. Exécutez des requêtes jusqu’à ce que le cache soit complètement rempli.
3. Évaluez la consommation de mémoire à l’aide de la table system.dictionaries.
4. 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é.