L'index Panda d'Alibaba offre aux clés uniques d'InnoDB un historique de versions qu'elles n'avaient jamais eu

Les clés uniques sont le goulot d'étranglement silencieux des bases de données en ligne. Les identifiants de commande, les numéros de téléphone et les numéros de série de transactions s'appuient sur les index à clé unique (UK) pour rester non dupliqués, et sous forte concurrence, l'application de cette contrainte commence à coûter cher. Dans InnoDB, le moteur qui sous-tend MySQL et PolarDB-X, la base compatible MySQL d'Alibaba, le problème est structurel : les index secondaires ne portent aucune information de version, si bien que le moteur compense avec des verrous d'écart et des consultations de table.

L'équipe PolarDB-X d'Alibaba a publié un correctif. Panda Index, un index UK de nouvelle génération pour les nœuds de données du moteur, confère aux clés uniques une capacité multi-version native grâce à des colonnes de transaction et à une chaîne d'annulation indépendante sur chaque enregistrement. Le post technique de l'équipe ApsaraDB décrit un chemin d'insertion simplifié et de véritables analyses index-only.

Le goulot d'étranglement des clés uniques dans InnoDB

PolarDB-X est une base de données distribuée reposant sur une architecture unifiée centralisée et distribuée, entièrement compatible MySQL, avec un stockage en lignes gérant l'OLTP par nœud de données. L'index clusterisé d'InnoDB gère l'historique de manière standard : chaque enregistrement porte un TRX_ID et un ROLL_PTR vers une chaîne d'annulation, les mises à jour se font en place, et l'arbre B+ ne conserve que la dernière version. Les index secondaires n'ont droit à rien de tout cela. Les enregistrements UK ne portent ni TRX_ID, ni ROLL_PTR, ni information de version.

Une mise à jour de clé unique passe donc par un marquage de suppression suivi d'une insertion : le moteur marque l'ancien enregistrement comme supprimé, puis en insère un nouveau. Jusqu'à l'exécution du thread de purge, plusieurs enregistrements physiques portant la même clé coexistent sur l'index. Cela compromet l'application de l'unicité de deux manières.

Le premier problème est le verrouillage. La détection de conflit à l'insertion ne peut pas déterminer lequel de plusieurs enregistrements partageant une clé est actif ; elle les scanne donc tous et place des verrous d'écart sur l'intervalle. Des transactions logiquement non conflictuelles finissent par s'attendre mutuellement, parfois dans un interblocage. Le problème est particulièrement aigu dans les systèmes de trading, les déductions de solde et les ventes flash, notent les ingénieurs d'ApsaraDB.

Le second est la visibilité. Sans information de version sur les enregistrements UK, une lecture MVCC ne peut pas juger de la visibilité à elle seule, même lorsque l'index couvre toutes les colonnes de la requête. Elle doit revenir à l'index clusterisé et parcourir la chaîne d'annulation, tout comme la détection implicite de verrous et la purge. Les charges de travail à forte écriture ajoutent une troisième pénalité : la purge prend du retard sur les suppressions, et les enregistrements résiduels marqués comme supprimés élargissent la plage d'analyse du prochain contrôle de conflit.

À l'intérieur de Panda Index : quatre colonnes système et une chaîne d'annulation indépendante

Panda Index fait descendre le versionnement de l'index clusterisé dans l'index UK. Chaque enregistrement gagne quatre colonnes système : TRX_ID, l'identifiant de transaction de la modification la plus récente ; ROLL_PTR, un pointeur vers un enregistrement d'annulation indépendant ; SCN, un numéro de séquence de validation provenant du système transactionnel Lizard ; et UBA, une adresse de bloc d'annulation. Leur sémantique correspond à celle des enregistrements de l'index clusterisé, si bien que le moteur réutilise le framework de visibilité existant de Lizard, Vision.

ROLL_PTR pointe vers une chaîne d'annulation appartenant exclusivement à l'index UK. Les mises à jour se font en place : pas de marquage de suppression suivi d'une insertion, un enregistrement physique par clé unique, et les versions historiques sont stockées dans un tablespace d'annulation séparé, accessibles via ROLL_PTR sans consultation de table. Les DML directs, l'annulation (rollback) et la purge suivent chacun une logique dédiée, ce qui découple le cycle de vie des versions de l'index UK de celui de l'index clusterisé.

Un verrou d'enregistrement au lieu d'une rangée de verrous d'écart

Les mises à jour en place produisent un effet secondaire utile : au plus un enregistrement physique existe par clé unique. La détection de conflit à l'insertion se réduit à un simple contrôle. Si aucun enregistrement n'existe, l'insertion réussit immédiatement. S'il en existe un, le moteur place un verrou d'enregistrement unique sur celui-ci et vérifie s'il est marqué comme supprimé. Pas de verrous d'écart, et une empreinte de verrouillage bien plus réduite.

Le post inclut un exemple détaillé. Une transaction supprime une ligne où c1 = 1 et insère une nouvelle ligne avec la même valeur ; une seconde transaction insère ensuite c1 = 2, ce qui ne crée pas de conflit. Avec le comportement InnoDB standard, la seconde insertion expire, avec quatre verrous sur l'index, dont trois verrous d'écart. Avec Panda Index, elle réussit immédiatement avec un seul verrou d'enregistrement X,REC_NOT_GAP.

La visibilité bénéficie de la même simplification : les lectures cohérentes s'achèvent dans l'arbre B+ de l'index, les requêtes sur index couvrant obtiennent de véritables analyses index-only, et la détection implicite de verrous n'atteint plus l'index clusterisé.

Le bénéfice en haute concurrence, et ce qui manque encore

Ce changement aligne la gestion des versions UK sur celle de l'index clusterisé, qu'InnoDB gère déjà bien. Alibaba a publié des résultats pour des travaux d'index de base de données connexes : la compression de préfixe secondaire de PolarDB-X a réduit l'espace d'index de 30 à 70 pour cent, avec des gains de débit sysbench allant jusqu'à 47 pour cent sous pression d'E/S, et les travaux séparés sur l'index vectoriel de PolarDB ont rapporté des constructions et des requêtes 1,5 à 2 fois plus rapides, avec une contention d'E/S en baisse de 90 pour cent.

Panda Index lui-même n'a pas encore de chiffres publiés. Le post ne contient aucun benchmark, et les preuves relatives aux verrous couvrent un unique scénario construit à la main. Quatre colonnes système supplémentaires et une seconde chaîne d'annulation ajoutent leur propre surcoût de stockage et de purge, et seule une mesure peut dire si ces coûts restent stables sous des écritures intensives en clés UK. Le résumé honnête : le mécanisme semble juste, et la base de preuves est celle d'Alibaba elle-même.