ApsaraDB for ClickHouse:Notes de version de l'édition compatible communautaire 26.3

CTE matérialisée

La version 26.3 LTS introduit la syntaxe CTE matérialisée. En utilisant le mot-clé MATERIALIZED, ClickHouse stocke les résultats CTE dans une table temporaire en mémoire pour éviter les calculs redondants et améliorer l'efficacité d'exécution des requêtes SQL complexes de reporting et d'analyse multidimensionnelle.

Exemple :

SET enable_materialized_cte = 1;

WITH top_users AS MATERIALIZED (
    SELECT user_id, count() AS cnt
    FROM events
    GROUP BY user_id
    ORDER BY cnt DESC
    LIMIT 1000
)
SELECT *
FROM top_users
INNER JOIN (SELECT user_id FROM top_users WHERE ...) ON ...;

Réordonnancement intelligent des JOIN pour tous les types de JOIN

L'optimiseur basé sur les coûts (CBO) de la version 26.3 LTS prend désormais en charge l'inversion automatique des côtés Build/Probe pour LEFT ANTI JOIN, SEMI JOIN et FULL JOIN, en plus des INNER JOIN et LEFT/RIGHT JOIN standards. L'optimiseur construit automatiquement la table de hachage à partir du côté le plus petit en fonction des statistiques de la table, empêchant ainsi les erreurs de dépassement de mémoire (OOM) causées par un ordre SQL manuel inapproprié.

Map partitionnée

Pour les scénarios où le type Map stocke des tags de profil utilisateur et des fonctionnalités dynamiques, la version 26.3 LTS introduit une disposition de sérialisation physique compartimentée. Les recherches par clé unique s'améliorent de 2 à 49 fois car les données au sein de la Map sont compartimentées par hachage selon la clé.

Exemple :

CREATE TABLE user_profiles (
    id UInt64,
    attributes Map(String, UInt64)
) ENGINE = MergeTree
ORDER BY id
SETTINGS map_serialization_version = 'with_buckets', max_buckets_in_map = 32;

Nettoyage TTL des tables larges : Fusion verticale

La version 26.3 LTS introduit un algorithme de fusion verticale pour les opérations TTL DELETE. La fusion privilégie le filtrage des clés primaires et des colonnes TTL sans lire les colonnes larges non pertinentes, ce qui réduit considérablement les frais généraux d'E/S et de mémoire lors du nettoyage des données en arrière-plan.

Codec de compression flottante sans perte adaptatif (ALP)

Un nouveau codec de compression flottante sans perte CODEC(ALP, ZSTD) est disponible. ALP (Adaptive Lossless floating-Point) est optimisé pour les données Float32 et Float64 dans les scénarios de surveillance industrielle et de métriques de séries temporelles, offrant de meilleurs taux de compression et une vitesse de décompression que l'encodage Gorilla classique.

SET dialect = 'polyglot', polyglot_dialect = 'snowflake';

Exécution des requêtes et optimiseur

• Le cache des conditions de requête, la compilation JIT des expressions et les filtres d'exécution JOIN sont activés par défaut pour réduire les analyses répétées et la surcharge des JOIN de grandes tables.

• RIGHT JOIN et FULL JOIN utilisent ConcurrentHashJoin, avec une amélioration des performances allant jusqu'à 2 fois dans certains scénarios. Une nouvelle optimisation de l'ordre des JOIN réorganise automatiquement les JOIN multi-tables en fonction des statistiques.

• L'élagage des index de clés primaires et de clés de partition est étendu : les clés primaires prennent en charge des expressions déterministes arbitraires pour ignorer les données, et les clés de partition enveloppées dans des chaînes de fonctions déterministes peuvent toujours être élaguées.

• Les requêtes ORDER BY ... LIMIT N peuvent réduire considérablement le nombre de lignes analysées grâce aux index skip et aux filtres de seuil dynamique.

Moteur de stockage et saut de données

• Le lecteur Parquet v3 est activé par défaut avec la poussée de filtre au niveau de la page et la prise en charge de PREWHERE. Les lectures de data lake ajustent automatiquement les pipelines en fonction des threads de traitement, atteignant une amélioration d'environ 40 fois sur les machines multicœurs.

• Le filtrage par index skip en flux pendant les lectures est activé par défaut. Les index de texte prennent en charge davantage de formes de prédicats et peuvent être utilisés dans PREWHERE.

• Dans les scénarios d'élagage de partitions intensif, les requêtes SELECT sur des tables comportant plus de 10 000 parties sont jusqu'à 8 fois plus rapides. Les tables Iceberg prennent en charge l'optimisation PREWHERE et le préchargement asynchrone des métadonnées.

Exécution distribuée et parallèle

• INSERT SELECT distribué parallèle est activé par défaut et exécuté indépendamment sur chaque shard. Les sous-requêtes IN distribuées ajoutent automatiquement DISTINCT pour réduire le transfert de données temporaires entre shards.

• L'analyse d'index distribuée prend en charge SharedMergeTree et les scénarios de stockage partagé. Les réplicas parallèles prennent en charge la matérialisation paresseuse avec une meilleure répartition de la charge pour réduire la latence de longue traîne.

Fonctions et index

• LIKE et les expressions régulières sont automatiquement réécrits vers des implémentations plus efficaces et activés par défaut. StringZilla accélère la recherche de chaînes sensible à la casse, et la distribution dynamique SIMD accélère les fonctions logiques et la conversion des colonnes booléennes.

Mémoire, observabilité et réseau

• Les caches de marques, non compressés et de pages utilisent des arènes jemalloc indépendantes pour réduire la fragmentation. Les pages sales de jemalloc sont nettoyées dans des threads indépendants. Les tables de journaux système ajoutent des index minmax et bloom_filter pour accélérer le dépannage.

• La sérialisation et la compression des blocs dans les requêtes distribuées peuvent être déléguées aux threads de pipeline pour améliorer l'efficacité du transfert de données volumineuses.

Préparation avant la mise à niveau

1. Clonage ou vérification de l'environnement de test : Déployez d'abord la nouvelle version dans un environnement cloné ou de test pour évaluer l'impact des changements de version sur les configurations et les requêtes existantes.

2. Vérifiez la compatibilité des dépendances : Confirmez la compatibilité des pilotes clients et des outils tiers avec la nouvelle version.

Remarques importantes

• Validation des fonctionnalités expérimentales : Les CTE matérialisées et les dialectes Polyglot sont marqués comme expérimentaux dans cette version. Nous vous recommandons de valider ces fonctionnalités dans un cluster de test avant de les utiliser en production.

• Tests de régression des performances : Après la mise à niveau, comparez le temps d'exécution des requêtes clés pour vous assurer que les optimisations telles que le cache Parquet, l'index inversé et le réordonnancement des JOIN prennent effet.

• Ajustement de la surveillance et des alertes : Ajustez les seuils de surveillance en fonction des nouvelles métriques et des modifications.