Contexte

Cet article vise à présenter de manière exhaustive et centralisée les nouveautés des versions récentes de TiDB. Au fil des mises à jour, TiDB continue d'améliorer ses performances, sa facilité d'utilisation et sa sécurité. L'objectif est de permettre aux utilisateurs de comprendre pleinement les avantages et fonctionnalités des nouvelles versions de TiDB, afin de profiter pleinement des améliorations et facilités qu'elles apportent.

Fonctionnalités liées à la fiabilité

Top SQL

Cette fonctionnalité permet d'identifier rapidement les requêtes SQL responsables d'une utilisation élevée du CPU ou de la mémoire sur les nœuds tidb-server ou tikv-server. Lorsque l'utilisation des ressources est élevée sur des nœuds de calcul ou de stockage, il est probable qu'une requête SQL en soit la cause.

Par exemple, si vous constatez que l'utilisation CPU de certains nœuds Tikv est significativement plus élevée que celle des autres nœuds, vous pouvez utiliser cette fonctionnalité pour identifier la requête SQL responsable. Même en l'absence de tels problèmes, vous pouvez l'utiliser pour identifier les requêtes consommant le plus de ressources.

Dans le monitoring Grafana, trouvez le nœud Tikv correspondant (xxx:20180), puis allez dans la page Top SQL et sélectionnez ce nœud pour consulter les requêtes. N'oubliez pas de sélectionner la période de temps appropriée.

Désactivation de la collecte automatique des informations statistiques

Dans certains scénarios simples mais essentiels, certains utilisateurs désactivent la collecte d'informations statistiques et utilisent des indications (hints) SQL pour fixer le plan d'exécution. À partir de la version 6.1, TiDB propose une fonctionnalité pour désactiver la collecte automatique des informations statistiques avec le paramètre : tidb_enable_auto_analyze.

Configuration de la taille de split de région dans TiKV

Pour les environnements avec de grands volumes de données, des disques de moyenne qualité, une volonté d'économiser des coûts ou peu de données chaudes, il est possible d'augmenter la taille par défaut des régions (96MB) vers une valeur plus importante.

Le paramètre associé est : region-split-size pour ajuster la taille des régions.

Récupération automatique des fichiers SST endommagés

C'est une amélioration de la récupération en cas de panne de TiKV. Par exemple, dans des situations extrêmes comme la suppression manuelle de fichiers SST au niveau de TiKV, les régions concernées sont signalées à PD, qui planifie la suppression des copies de ces régions pour auto-réparation. Un fichier endommagé n'empêche pas l'exécution de l'instance TiKV, qui tente une auto-réparation dans les 1 heure par défaut.

Le paramètre associé est : background-error-recovery-window.

Configuration du temps d'exécution maximum pour Auto Analyze

Permet de définir la durée maximale d'exécution des tâches de collecte automatique des informations statistiques, par défaut de 12 heures. Cela évite que la collecte d'informations statistiques pour les grandes tables ne prenne trop de temps et affecte les pefrormances.

Fonctionnalité Online Recover

Le scénario principal d'utilisation est le suivant : lorsque le cluster TiDB perd plus de la moitié des copies de données, le cluster ne fournit plus de service. Cela viole le protocole Raft, et la base de données rejette les lectures et écritures.

Dans ce cas, TiKV doit effectuer une opération de récupération. Dans les versions précédentes, cette opération était relativement complexe. Dans les versions plus récentes, elle est considérablement simplifiée avec une récupération en un seul clic.

Flashback de cluster

Permet de revenir rapidement à un point spécifique dans le temps grâce à la commande FLASHBACK (fonctionnalité expérimentale) :

FLASHBACK CLUSTER TO TSO 445494839813079041;

Cela permet de restaurer les données du cluster à un moment antérieur au cycle de garbage collection (GC). Les données doivent être réécrites, et il faut disposer d'espace suffisant.

Seuil d'utilisation mémoire pour les instances tidb-server

Nouveau paramètre tidb_server_memory_limit qui définit la limite d'utilisation mémoire pour une instance tidb-server. Lorsque cette limite est atteinte, la requête SQL consommant le plus de mémoire est terminée pour permettre à l'instance de se rétablir.

Les opérations SQL suivantes ne sont pas terminées par la limite tidb_server_memory_limit :

• Opérations DDL
• Opérations SQL contenant des fonctions de fenêtre et des expressions de table communes (CTE)

Création de liaisons basées sur les plans d'exécution historiques

Prend en charge la liaison des plans d'exécution historiques (fonctionnalité expérimentale, disponible en GA à partir de la version 7.1), permettant de lier un plan d'exécution historique à une requête SQL à l'aide de son plan_digest.

Cette méthode est destinée aux requêtes complexes dont le plan d'exécution change fréquemment, où il est difficile d'utiliser correctement les indications manuelles pour influencer le plan d'exécution. On trouve le plan d'exécution historique correct et on l'utilise pour créer une liaison via son code d'empreinte.

Actuellement, la création de liaisons basées sur les plans d'exécution historiques présente certaines limitations :

• Cette fonctionnalité génère des indications à partir de plans d'exécution historiques pour créer des liaisons. Les plans d'exécution historiques proviennent des tables de résumé des instructions (Statement Summary Tables), donc le système variable tidb_enable_stmt_summary doit être activé avant d'utiliser cette fonctionnalité.
• Les requêtes avec sous-requêtes, les requêtes accédant à TiFlash, et les requêtes joignant trois tables ou plus ne sont pas actuellement prises en charge pour la liaison via les plans d'exécution historiques.

Nouveau modèle de coût : Cost Model Version 2

L'optimiseur introduit un modèle de coût plus précis, le Cost Model Version 2 (GA). La nouvelle version recommande l'utilisation de ce nouveau modèle. Lors de la mise à niveau, il est conseillé de prêter attention aux changements du paramètre tidb_cost_model_version. Les tests internes ont montré que ce modèle est plus précis que la version 1.

Fonctionnalités liées aux performances

Tables en cache

Cette fonctionnalité est spécifique à TiDB. Il est possible de créer une table dont les données sont stockées dans TiKV, mais que tidb-server charge entièrement en mémoire. Lorsqu'une requête SQL accède à cette table, elle n'interagit pas avec TiKV, mais lit directement depuis la mémoire de tidb-server.

Dans ce design :

1. Les mises à jour fréquentes ne sont pas recommandées pour les tables en cache
2. Les tables en cache ont une durée de location (lease limit), ce qui signifie que tidb-server périodiquement récupère les nouvelles données depuis TiKV. Les mises à jour de la table sont affectées par cette durée de location.
3. Les tables de grande taille ne sont pas recommandées, car cela entraînerait une utilisation mémoire importante et permanente sur tidb-server.

Verrouillage pessimiste en mémoire

TiDB a d'abord utilisé un verrouillage optimiste, avant d'introduire le verrouillage pessimiste. Dans les premiers temps du verrouillage pessimiste, TiDB effectuait toutes les opérations de verrouillage et de vérification de verrouillage sur disque, ce qui présentait des problèmes de performance.

Cet optimise consiste à déplacer ces opérations de disque vers la mémoire. Les performances sont ainsi améliorées. Cette configuraton ne nécessite pas de modification manuelle et est activée par défaut dans les nouvelles versions.

Optimisation de l'obtention TSO pour le niveau d'isolation RC

Le niveau d'isolation "Read Committed" (lecture validée) est utilisé dans les scénarios avec peu de conflits lecture-écriture pour réduire les obtentions TSO inutiles. Il tente d'utiliser l'horodateur valide précédent pour la lecture des données.

Dans le niveau RC, une transaction peut voir les modifications déjà validées par d'autres transactions. Si une transaction contient 300 instructions SQL, avec 290 lectures, chaque exécution de lecture nécessite d'obtenir un TSO, ce qui génère beaucoup d'interactions entre tidb-server et PD.

Cette optimisation cible les scénarios avec peu de conflits lecture-écriture. Le paramètre associé est tidb_rc_write_check_ts.

Optimisation des points chauds d'index

Paramètre associé : TIDB_SHARD

Dans les points chauds couramment mentionnés, la plupart sont des points chauds en lecture/écriture. Les points chauds en écriture, en particulier les points chauds de données, ont l'impact le plus important et sont souvent rencontrés comme goulot d'étranglement, car les données sont généralement plus larges.

Les index sont encodés sous la forme tableId_indeValue:handle_Id, globalement ordonnés. Par exemple, lors de la création d'un index sur un champ commençant tous par "1" (comme les numéros de téléphone).

Les points chauds causés par les index sont difficiles à gérer. La fonction tidb_shard encapsule les données d'index avec une fonction de fragmentation (shard). Cette fonctionnalité a des limites et est utilisée dans des scénarios spécifiques.

Moteur de stockage Raft Engine (GA)

Réduit jusqu'à 40% du trafic d'écriture I/O de TiKV et 10% de l'utilisation du CPU. Auparavant, chaque instance TiKV utilisait deux instances RocksDB pour la persistance : data et log.

Le nouveau moteur Raft Engine utilise une nouvelle méthode d'écriture des journaux, plus rapide mais qui exerce une pression plus importante sur les disques. Pour les clusters avec des disques de qualité moyenne, les journaux Raft peuvent être isolés.

Indication MERGE

Introduit une indication d'optimiseur MERGE, permettant de développer l'incorporation (inlining) des CTE. Dans les requêtes contenant des expressions de table communes (CTE), l'utilisation de l'indication MERGE() peut désactiver le processus de matérialisation pour la sous-requête actuelle et développer l'incorporation de la requête interne dans la requête externe. Cette indication s'applique aux requêtes CTE non récursives et, dans certains scénarios, peut être plus efficace que l'exécution par défaut qui alloue un espace temporaire.

Stockage Fast Scan dans TiFlash

TiFlash prend en charge un nouveau format de stockage (v6.2 est la version par défaut, v6.2+ ne prend pas en charge la rétrogradation vers les versions antérieures). Les utilisateurs de TiFlash doivent mettre à niveau rapidement pour bénéficier d'une expérience TiFlash plus rapide.

Fonctionnalité Fast DDL : tidb_ddl_enable_fast_reorg

Les performances d'ajout d'index dans TiDB sont améliorées d'environ 10 fois (GA) (Ingest SST directement). L'index est lu sur le nœud DDL owner de tidb-server, les fichiers SST sont générés sur le disque, puis directement importés dans TiKV, similaire au mode local de lightning. Auparavant, les données étaient lues logiquement, encodées en données d'index, puis écrites logiquement dans TiKV.

Dans l'utilisation pratique, il est recommandé de déployer séparément un tidb-server avec de bons disques, puis de configurer tidb_enable_ddl pour contrôler quels nœuds tidb-server peuvent être élus comme nœud DDL owner. Cela économise des ressources et exploite mieux cette fonctionnalité.

Matérialisation des résultats de requête TiFlash

Prend en charge la matérialisation des résultats de requête TiFlash via l'instruction INSERT INTO SELECT (fonctionnalité expérimentale, maintenant en GA). En bref, dans l'instruction insert into select, la partie select peut utiliser le moteur TiFlash pour accélérer l'analyse, et les résultats analysés sont écrits directement dans TiKV via insert.

Dans les anciennes versions, ce type d'instruction devait être manuellement divisé en deux instructions (insert + select) pour bénéficier de l'accélération de lecture de TiFlash et de MPP.

Lecture Follower

Peut être considérée comme la séparation lecture-écriture de MySQL (les lectures sont envoyées aux esclaves, les écritures au maître). Cela réduit l'impact des points chauds et est très adapté aux scénarios de lecture multi-sites actifs.

Lorsque des régions de lecture热点 (hotspots) existent dans le système, ce qui entraîne une tension sur les ressources des leaders et devient un goulot d'étranglement pour l'ensemble du système, l'activation de la fonctionnalité Follower Read peut réduire considérablement la charge des leaders. En équilibrant la charge entre plusieurs followers, elle améliore significativement le débit global du système.

L'utilisation de closest-adaptive économise intelligemment le trafic inter-zone dans les cas réels, réduisant de plus de 30% le trafic inter-AZ.

Fusion d'index (Index Merge)

La fusion d'index (Index Merge) combine automatiquement les index de différentes colonnes pour satisfaire les conditions de filtre AND ou OR, atteignant des performances similaires à celles d'un index composite (prise en charge新增 des conditions AND).

Fonctionnalités liées au cadre distribué

Prise en charge du mode de découpage dynamique pour les tables partitionnées dans le moteur MPP TiFlash

Le découpage dynamique (Dynamic Pruning) est une technique d'optimisation des performances, particulièrement lors du traitement des tables partitionnées. Lorsqu'une requête implique une table partitionnée, le mode de découpage dynamique peut, à l'exécution, sélectionenr dynamiquement uniquement les partitions pertinentes en fonction des conditions de la requête, évitant ainsi le balayage complet de la table, réduisant les opérations d'E/S et améliorant l'efficacité des requêtes.

Notez que après avoir modifié les paramètres liés au découpage dynamique, il est nécessaire de collecter manuellement les informations statistiques de la table.

Prise en charge du kill global des requêtes ou des connexions

Nouvelle configuration enable-global-kill. Dans les versions antérieures à 6.1.0, il fallait se connecter au nœud tidb-server correspondant pour tuer une requête SQL. Dans les nouvelles versions, cette fonctionnalité est activée par défaut, permettant de tuer des requêtes ou des connexions globalement, améliorant ainsi la facilité de maintenance.

Fonctionnalités SQL

Prise en charge de la syntaxe d'indication d'ordre de jointure

Deux nouvelles méthodes d'indication : LEADING hint et STRAIGHT_JOIN hint.

En bref, dans les anciennes versions, lorsque le plan d'exécution SQL n'était pas optimal (par exemple, des problèmes dans l'ordre des jointures), on pouvait utiliser ces deux nouvelles indications pour influencer manuellement l'ordre des jointures.

Prise en charge de la plupart des fonctions de verrouillage utilisateur de MySQL 5.7 dans TiDB

Prend en charge la gestion des verrous utilisateur compatible avec MySQL, avec les fonctions GET_LOCK, RELEASE_LOCK, RELEASE_ALL_LOCKS.

Prise en charge de l'ajout, de la suppression et de la modification de plusieurs colonnes ou index

TiDB permet d'utiliser une seule instruction ALTER TABLE pour ajouter, supprimer ou modifier plusieurs colonnes ou index.

Prise en charge de SAVEPOINT dans les transactions

Fonctionnalité prise en charge à partir de la version 6.2.0, dont l'utilisation est similaire à celle de MySQL.

Il est à noter que la fonctionnalité SAVEPOINT n'est pas compatible avec TiDB Binlog, ni avec les transactions pessimistes lorsque tidb_constraint_check_in_place_pessimistic est désactivé.

Optimisation de colonne à incrémentation monotone

Prend en charge l'attribut de colonne AUTO_INCREMENT haute performance et globalement monotone.

Dans les premières versions de TiDB, pour augmenter le débit de la base de données, chaque tidb-server mettait en cache une partie des valeurs et les attribuait localement. Cela garantissait l'unicité des valeurs AUTO_INCREMENT, mais permettait à des données écrites plus tard d'avoir une valeur inférieure à des données écrites plus tôt.

À partir de la version 6.4.0, l'introduction d'un service d'allocation centralisé signifie que la modification des valeurs AUTO_INCREMENT est une opération en mémoire dans le processus du service TiDB, plus rapide que dans les versions précédentes.

Il est à noter que dans la plupart des cas, l'unicité et la monotonie des ID sont garanties, et le comportement est presque identique à celui de MySQL. Même en accédant à travers plusieurs instances TiDB, les ID ne régressent pas. Seule la panne de l'instance "maître" du service centralisé peut entraîner une petite discontinuité dans les ID. Lors du basculement maître-esclave, l'instance "esclave" doit rejeter certaines ID potentiellement déjà attribuées par l'ancien "maître" pour garantir l'unicité des ID.

Facilité d'utilisation

Règles de placement en SQL

Utilisation de SQL pour configurer les règles de stockage des tables, par exemple : toutes les données de la table A sont placées dans le centre de données 1, toutes les données de la table B sont placées dans le centre de données 2, etc.

Il convient de noter qu'il est nécessaire d'utiliser une version plus récente prenant en charge SURVIVAL_PREFERENCE. Cet attribut affecte la priorité de placement du niveau de tolérance aux pannes des données sous les règles. Sans cet attribut, il pourrait y avoir des problèmes au niveau de la tolérance aux pannes.

Modification en ligne des configurations de cluster

Les paramètres TiDB/TiKV/TiFlash peuvent être modifiés en ligne sans redémarrage pour prendre effet. Il est à noter qu'après avoir modifié un paramètre TiKV en ligne, le fichier de configuration TiKV est également automatiquement modifié. Cependant, il est toujours nécessaire d'utiliser la commande tiup edit-config pour modifier le paramètre correspondant, sinon les opérations de maintenance comme upgrade et reload écraseront les modifications en ligne.

Après avoir modifié les informations du nœud de contrôle, vous pouvez rafraîchir la configuration (sans redémarrer les processus) :

tiup cluster reload <cluster-name> --skip-restart</cluster-name>

Page de monitoring TiDB Dashboard

Le TiDB Dashboard dispose d'une nouvelle page Monitoring, affichant les indicateurs clés nécessaires pour l'optimisation des performances applicatives.

Dans la maintenance quotidienne, dans la plupart des cas, il n'est plus nécessaire d'ouvrir Grafana pour consulter des indicateurs de monitoring plus détaillés. Ici, vous pouvez voir les indicateurs de monitoring courants pour analyser l'état actuel du cluster, réduisant la nécessité de sauter d'une interface à l'autre comme avant.

Plan d'exécution graphique

Le TiDB Dashboard prend en charge les plans d'exécution graphiques, permettant de comprendre plus rapidement les requêtes complexes et volumineuses.

Vue de tableau DATA_LOCK_WAITS

La vue de verrous prend en charge les informations sur les transactions optimistes bloquées, montrant les relations de conflit de verrous. Le tableau DATA_LOCK_WAITS affiche toutes les situations d'attente de verrou actuellement en cours sur tous les nœuds TiKV du cluster, y compris les situations d'attente de verrous pessimistes et les informations sur les transactions optimistes bloquées.

Utilisation de TTL (Time to Live) pour la suppression périodique de données expirées

Il est possible d'utiliser TTL (Time to Live) pour supprimer périodiquement les données expirées. Exemple d'utilisation :

• Utiliser DEFAULT CURRENT_TIMESTAMP pour spécifier que la valeur par défaut d'une colonne est l'heure de création de la ligne, et utiliser cette colonne comme colonne temporelle pour TTL. Les données créées il y a plus de 3 mois seront marquées comme expirées :

CREATE TABLE t1 (
    id int PRIMARY KEY,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
) TTL = created_at + INTERVAL 3 MONTH;

Pour les tables ayant besoin d'un nettoyage périodique des données, il n'est plus nécessaire d'utiliser des scripts de suppression externes ou de créer des tables partitionnées pour le nettoyage. Utilisez directement la fonctionnalité TTL, configurez les propriétés de la table, et la base de supprimera automatiquement les données correspondantes en arrière-plan.

Cette fonctionnalité est maintenant en GA et peut être utilisée directement. Le monitoring inclut les indicateurs de performance correspondants. Les paramètres tidb_ttl_scan_worker_count et tidb_ttl_delete_worker_count contrôlent le parallélisme de suppression et de lecture. Les variables globales tidb_ttl_job_schedule_window_start_time et tidb_ttl_job_schedule_window_end_time peuvent être configurées pour spécifier la fenêtre de temps pour le recyclage des données.