Pourquoi mes données ne sont-elles pas visibles dans un dictionnaire dans ClickHouse Cloud ?

Il peut arriver que les données d’un dictionnaire ne soient pas visibles immédiatement après sa création.

​

Dictionaries dans ClickHouse

Les dictionnaires créés dans ClickHouse Cloud peuvent présenter des incohérences pendant la phase de création initiale. Cela signifie qu’il se peut qu’aucune donnée ne soit visible dans le dictionnaire juste après sa création. Cependant, après plusieurs tentatives, la requête de création peut être envoyée à différentes répliques, et les données deviennent alors visibles.

Cela se produit parfois parce que le dictionnaire a été créé avant que la part n’atteigne le serveur. Par exemple :

2024-01-25 13:38:25.615837 - CREATE DICTIONARY received
2024-01-25 13:38:25.626468 - CREATE DICTIONARY finished
2024-01-25 13:38:25.733008 - Part all_0_0_0 downloaded

Comme vous pouvez le voir, la part n’est arrivée qu’après la création du dictionnaire. Cela peut devenir un problème plus sérieux si vous utilisez LIFETIME(MIN 0 MAX 0), car cela signifie que le dictionnaire ne sera jamais actualisé automatiquement. Par conséquent, le dictionnaire restera vide jusqu’à l’exécution de la commande RELOAD DICTIONARIES.

Pour résoudre ce problème, utilisez une requête SELECT au lieu de spécifier une table source lors de la création du dictionnaire, et activez le paramètre select_sequential_consistency=1.

Au lieu de spécifier une table source :

SOURCE(CLICKHOUSE(
    table 'test.temp_title_table_1706189903924'
    user default password 'PASSWORD'))

Utilisez une requête SELECT avec select_sequential_consistency=1 :

SOURCE(CLICKHOUSE(QUERY
    'SELECT songTitle, mappedTitle
    FROM test.temp_title_table_1706189903924
    SETTINGS select_sequential_consistency=1' USER default PASSWORD ''))

​

Pourquoi ce problème se produit-il ?

Lorsque vous insérez des données, puis créez ou rechargez un dictionnaire, le DDL peut parvenir à une réplique avant les données (ou les nouvelles données). Les dictionnaires deviennent alors incohérents d’une réplique à l’autre. Ensuite, selon la réplique qui reçoit la requête, vous pouvez obtenir des résultats différents.

Notez que le même phénomène se produit lorsque vous insérez des données puis lisez immédiatement une table. Si vous lisez depuis une réplique qui n’a pas encore répliqué les données, vous ne verrez pas les données nouvellement insérées. Si vous avez besoin d’une cohérence séquentielle, au prix d’une baisse de performances (ce qui explique pourquoi son utilisation n’est généralement pas recommandée), vous pouvez activer select_sequential_consistency.

Le cas des dictionnaires est un peu plus délicat, car les dictionnaires n’utilisent pas les paramètres de la requête, mais ceux du serveur. Par conséquent, lors du chargement des données dans le dictionnaire, même si vous utilisez SET select_sequential_consistency=1, les données peuvent être chargées de manière incohérente entre les répliques. Spécifier select_sequential_consistency=1 dans la requête de la source du dictionnaire permet à celui-ci de respecter ce paramètre, même s’il n’est pas activé globalement comme paramètre du serveur.