PolarDB:Index columnaires (IMCI)

Contexte

PolarDB for MySQL cible les scénarios de traitement transactionnel en ligne (OLTP) liés à des activités générant de grands volumes de données. Toutefois, l'architecture orientée lignes de PolarDB for MySQL ne satisfait pas toujours aux exigences de performance des requêtes dans tous les cas d'usage. L'exécution de requêtes analytiques complexes impose généralement d'exporter les données depuis PolarDB for MySQL pour les importer ensuite dans un système de traitement analytique en ligne (OLAP). Cette approche nécessite deux systèmes de bases de données distincts, ce qui accroît les coûts, la complexité architecturale et la charge d'exploitation et de maintenance.

Pour répondre aux besoins OLAP impliquant des requêtes complexes sur de grands volumes de données, PolarDB for MySQL propose la fonctionnalité IMCI. Grâce à celle-ci, PolarDB for MySQL offre une solution hybride de traitement transactionnel et analytique (HTAP) tout-en-un, combinant traitement transactionnel et analyse de données en temps réel. Ainsi, un seul système de base de données suffit pour couvrir les besoins OLTP et OLAP.

Principes techniques

Le diagramme ci-dessous illustre l'architecture fonctionnelle de la fonctionnalité d'index colonnaire dans PolarDB for MySQL :

Comme le montre ce schéma, l'architecture de l'index colonnaire de PolarDB for MySQL s'articule autour de trois couches : le moteur de stockage, l'opérateur d'exécution et l'optimiseur.

• Moteur de stockage : prend en charge le stockage hybride en lignes et en colonnes avec une cohérence transactionnelle en temps réel.

• Opérateur d'exécution : fournit un opérateur parallèle vectorisé pour le stockage en colonnes, permettant des requêtes extrêmement rapides sur une ou plusieurs tables.

• Analyseur/Optimiseur SQL : intègre un optimiseur basé sur les coûts (CBO) adapté au stockage hybride. Il sélectionne automatiquement le stockage en lignes ou en colonnes pour exécuter les requêtes selon une évaluation des coûts.

Grâce à cette architecture, PolarDB for MySQL assure une compatibilité totale avec le protocole MySQL tout en offrant une accélération des requêtes de plusieurs ordres de grandeur.

Mise en œuvre

Afin d'isoler les ressources de calcul OLAP et OLTP, créez les IMCI exclusivement sur des nœuds en lecture seule. Toutes les requêtes OLAP s'exécutent uniquement sur ces nœuds. Configurez des règles de distribution des requêtes pour diriger le trafic OLAP vers les nœuds en lecture seule utilisant le stockage en lignes ou en colonnes. Présentation de la distribution des requêtes HTAP entre les nœuds de stockage en lignes et en colonnes.

Avantages clés

La fonctionnalité d'index colonnaire apporte à PolarDB for MySQL les atouts suivants :

• Compatibilité MySQL totale : le système de types de données du stockage en colonnes est identique à celui de MySQL. Il prend en charge des conversions de types flexibles et respecte intégralement le protocole MySQL.

• Performances HTAP exceptionnelles : PolarDB offre nativement d'excellentes performances OLTP. L'index colonnaire hisse ses capacités OLAP au niveau des systèmes de bases de données analytiques dédiés.

• Réduction des coûts grâce au stockage hybride : la prise en charge simultanée des formats de stockage en lignes et en colonnes garantit une cohérence transactionnelle en temps réel entre les deux modèles, tout en tirant parti des coûts réduits inhérents au stockage en colonnes.

Cas d'usage

L'index colonnaire de PolarDB for MySQL délivre une expérience produit HTAP intégrée, adaptée à divers contextes métier :

• Analyse en temps réel des données opérationnelles, notamment pour la génération de rapports instantanés.

• Entrepôt de données dédié : exploitez les capacités de stockage massif de PolarDB pour agréger plusieurs sources de données et constituer un entrepôt centralisé.

• Accélération des traitements ETL : tirez parti de la puissance et de la flexibilité de calcul de PolarDB, offertes par l'index colonnaire, pour exécuter des opérations ETL directement en SQL au sein de PolarDB.

Tarification

La fonctionnalité IMCI est fournie gratuitement. Cependant, les nœuds en lecture seule avec stockage en colonnes sont facturés selon la tarification standard des nœuds de calcul. Pour plus d'informations, consultez Tarifs paiement à l'utilisation des nœuds de calcul et Tarifs abonnement des nœuds de calcul. Les index IMCI consomment également de l'espace de stockage facturable. Reportez-vous à la section Tarification du stockage pour plus de détails.

Versions prises en charge

• Un cluster Enterprise Edition répondant à l'une des conditions suivantes :

  • PolarDB for MySQL 8.0.1 dont la version de révision est 8.0.1.1.22 ou ultérieure.

  • PolarDB for MySQL 8.0.2 dont la version de révision est 8.0.2.2.12 ou ultérieure.

• Un cluster Standard Edition utilisant l'architecture CPU X86 et remplissant l'une des conditions suivantes :

  • PolarDB for MySQL 8.0.1 dont la version de révision est 8.0.1.1.38 ou ultérieure.

  • PolarDB for MySQL 8.0.2 dont la version de révision est 8.0.2.2.19 ou ultérieure.

Précautions

• La fonctionnalité d'index colonnaire en mémoire (IMCI) n'est pas compatible avec le Global Database Network (GDN).

• L'utilisation conjointe de l'IMCI et du module Voting Disk Service (VDS) de la fonctionnalité de basculement avec réplica chaud est soumise aux conditions suivantes :

  • Pour un cluster dont la version de révision est 8.0.1.1.42 ou ultérieure ou 8.0.2.2.23 ou ultérieure :

    • Si le cluster contient un nœud en lecture seule sur lequel le basculement avec réplica chaud est activé, ajoutez des nœuds en lecture seule avec stockage en colonnes.

    • Si un nœud en lecture seule avec stockage en colonnes existe déjà dans le cluster, vous ne pouvez pas activer la fonctionnalité de standby chaud sur un autre nœud en lecture seule du même cluster.

  • Pour un cluster dont la version de révision est antérieure à 8.0.1.1.42 ou antérieure à 8.0.2.2.23, l'IMCI et le basculement avec réplica chaud sont incompatibles.

    • Si le cluster contient un nœud en lecture seule sur lequel le basculement avec réplica chaud est activé, l'ajout de nœuds en lecture seule avec stockage en colonnes est impossible.

      Remarque

      Pour ajouter un nœud en lecture seule avec stockage en colonnes au cluster, contactez le support technique afin de désactiver VDS. La désactivation de VDS entraîne le redémarrage automatique de tous les nœuds du cluster.

    • Si un nœud en lecture seule avec stockage en colonnes existe déjà dans le cluster, vous ne pouvez pas activer le standby chaud sur n'importe quel nœud en lecture seule du cluster.

Amélioration des performances

L'index colonnaire accélère considérablement les requêtes SQL, multipliant les performances par plusieurs centaines. Les tests suivants utilisent les tables de données et les requêtes SQL standard TPC-H pour illustrer l'impact de cette accélération.

• Méthodologie de test : TPC-H est un benchmark industriel de référence, développé et publié par le comité TPC pour évaluer les capacités d'analyse des bases de données. Il comprend 8 tables de données et 22 requêtes SQL complexes, impliquant majoritairement des jointures multiples, des sous-requêtes et des agrégations GROUP BY.

• Volume de données : 100 Go.

• Résultats des tests :

  • Comparaison des performances avant et après l'activation de l'index colonnaire

    Le graphique suivant compare les temps de réponse des 22 requêtes TPC-H avant et après l'activation de l'index colonnaire.

  • Comparaison avec ClickHouse après activation de l'index colonnaire

    Le graphique ci-dessous présente les temps de réponse de 21 requêtes TPC-H (hors Q21, non prise en charge par ClickHouse) après activation de l'index colonnaire, mis en regard d'une base ClickHouse de volume et de structure identiques.

• Conclusion :

  • L'index colonnaire accélère la majorité des requêtes complexes, améliorant les performances de manière significative, jusqu'à un facteur cent.

  • Face à ClickHouse, base OLAP traditionnelle : une fois l'index colonnaire activé, PolarDB for MySQL affiche des performances contrastées par rapport à ClickHouse. Il excelle particulièrement dans les scans et agrégations (AGG) sur table unique ainsi que dans les jointures. De futures optimisations de l'index colonnaire devraient apporter des améliorations notables, notamment sur l'accélération des agrégations et les fonctions de fenêtrage.