Comment effectuer une opération BUILD - AnalyticDB - Centre de documentation Alibaba Cloud

Les tâches BUILD reconstruisent les partitions après l'écriture des données. Elles créent des index et suppriment les données redondantes afin d'améliorer les performances en lecture. Lors d'une tâche BUILD, le système fusionne les données écrites en temps réel avec les partitions historiques, crée les index et exécute de manière asynchrone toutes les instructions DDL en attente.

Fonctionnement

Les tâches BUILD s'exécutent à deux niveaux :

Niveau table : Différentes tables exécutent des tâches BUILD en parallèle.
Niveau shard : Une fois la tâche BUILD d'une table lancée, elle se divise en tâches réparties sur les shards. Les trois réplicas de chaque shard exécutent leurs tâches indépendamment. La tâche BUILD est considérée comme terminée lorsque toutes les tâches au niveau des shards sont achevées.

Les tâches BUILD ne traitent que les partitions présentant des modifications de données ; les partitions sans nouvelles opérations INSERT, UPDATE ou DELETE sont ignorées.

AnalyticDB for MySQL utilise un moteur de stockage Log-Structured Merge (LSM). Lorsque vous exécutez DELETE ou REPLACE, les lignes concernées sont uniquement marquées pour suppression au niveau physique et sont effacées de manière asynchrone par une tâche BUILD en arrière-plan. Après un grand nombre d'opérations DELETE ou REPLACE, si la tâche BUILD n'est pas terminée, le nombre de lignes de la table affiché dans Space Overview est supérieur à la valeur renvoyée par SELECT COUNT(*). Le nombre de lignes indiqué dans Space Overview provient de la colonne row_count de information_schema.kepler_partitions et signale les lignes physiques, y compris celles marquées pour suppression mais pas encore effacées. L'instruction SELECT COUNT(*) renvoie le nombre de lignes logiquement valides et exclut les lignes marquées pour suppression. Pour faire converger ces deux valeurs, exécutez manuellement BUILD TABLE afin d'effacer les lignes marquées pour suppression.

Notes d'utilisation

Pendant une tâche BUILD, l'instruction INSERT OVERWRITE SELECT est bloquée. Utilisez plutôt INSERT INTO.
Il est impossible d'annuler une tâche BUILD après sa soumission.
Le nombre de tâches BUILD simultanées est égal à ceil(number of cores / 3) et ne peut pas être modifié. Pour un cluster de 32 cœurs, cela représente 11 tâches simultanées.
Les tâches BUILD consomment des ressources CPU, mémoire et E/S. L'utilisation du processeur et les E/S disque peuvent augmenter fortement pendant l'exécution des tâches et revenir à la normale une fois celles-ci terminées. Exécutez les tâches BUILD pendant les heures creuses.

Déclenchement automatique des tâches BUILD

Une tâche BUILD se déclenche automatiquement lorsque l'une des conditions suivantes est remplie :

Condition 1 : Accumulation suffisante de nouvelles données

Le temps écoulé depuis la dernière tâche BUILD atteint l'intervalle minimal et au moins 50 000 lignes ont été ajoutées à un shard.

Édition	Intervalle minimal
Enterprise Edition	1,5 heure
Basic Edition	1,5 heure
Data Lakehouse Edition	1,5 heure
Data Warehouse Edition (mode élastique)	1,5 heure
Data Warehouse Edition (mode réservé)	0,5 heure

Condition 2 : Mécanisme de secours basé sur le temps

24 heures se sont écoulées depuis la dernière tâche BUILD et au moins une ligne a été modifiée.

Déclenchement manuel des tâches BUILD

Reconstruction des partitions modifiées uniquement

Il s'agit du comportement par défaut : seules les partitions présentant des modifications de données sont reconstruites.

Tables XUANWU
```
BUILD TABLE <table_name>;
```
Tables XUANWU_V2

Remarque
Pour savoir comment déterminer et spécifier un moteur de table, consultez la section « Specify a table engine » de la rubrique Moteur XUANWU_V2.
```
BUILD TABLE <table_name> [BUILD_OPTION];
```
L'option BUILD_OPTION accepte uniquement ttl (facultatif). Lorsqu'elle est spécifiée, les partitions expirées sont supprimées immédiatement après la fin de la tâche BUILD. Lorsqu'elle est omise, seules les partitions modifiées sont reconstruites.

Reconstruction de partitions spécifiques

Disponible pour les clusters AnalyticDB for MySQL exécutant la version V3.1.6.0 ou ultérieure.

BUILD TABLE test force partitions='partition1,partition2';

Utilisez cette approche lorsqu'une table contient de grands volumes de données et qu'une opération BUILD sur l'ensemble de la table serait gourmande en ressources. Le ciblage de partitions spécifiques réduit l'utilisation des ressources et accélère l'exécution de la tâche.

Important

Pour afficher la version mineure de votre cluster, consultez la rubrique Comment afficher la version mineure d'un cluster ?. Pour mettre à jour la version mineure, contactez le support technique.

Reconstruction d'une table entière

Important

Cette opération recrée les index pour toutes les données existantes et peut prendre beaucoup de temps. Évaluez l'impact et les risques avant de procéder. Cette fonctionnalité est désactivée par défaut ; soumettez un ticket pour l'activer. Utilisez autant que possible l'approche par partition spécifique décrite ci-dessus.

BUILD TABLE <table_name> force = true;

Cela recrée les index pour toutes les partitions de la table, y compris celles sans modification de données.

Planification des tâches BUILD

Par défaut, les tâches BUILD s'exécutent au fur et à mesure que les données s'accumulent. Pour les restreindre à des fenêtres horaires spécifiques, par exemple pour éviter les heures de pointe métier, configurez une planification.

Définition d'une fenêtre horaire

SET ADB_CONFIG RC_CSTORE_BUILD_SCHEDULE_PERIOD=`<start>,<end>`;

Paramètre	Description	Plage valide
`start`	Début de la fenêtre de planification (heure)	0–24
`end`	Fin de la fenêtre de planification (heure)	0–24

Séparez plusieurs fenêtres horaires par des points-virgules. Encadrez toutes les valeurs par des accents graves (backticks).

Important

La fenêtre horaire contrôle le moment où les tâches sont planifiées, et non celui où elles se terminent. Une tâche planifiée avant la fermeture de la fenêtre peut continuer à s'exécuter après la fin de celle-ci.

Exemple : Planifiez les tâches BUILD entre 00:00–06:59 et 18:00–22:59.

SET ADB_CONFIG RC_CSTORE_BUILD_SCHEDULE_PERIOD=`0,6;18,22`;

Définition des priorités de planification

Disponible pour les clusters AnalyticDB for MySQL exécutant la version V3.1.5.0 ou ultérieure.

Par défaut, les tâches BUILD sont prioritaires en fonction du volume de données ajouté à chaque shard depuis la dernière tâche BUILD : les shards ayant reçu le plus de nouvelles données sont planifiés en premier. Pour remplacer ce comportement, définissez des priorités personnalisées à l'aide d'un indice (hint) ou de SET ADB_CONFIG.

Le paramètre task_priority est un entier (valeur par défaut : 0). Une valeur plus élevée indique une priorité plus grande. La définition d'une valeur négative désactive la planification automatique pour cette table.

Remarque

Pour afficher ou mettre à jour la version mineure de votre cluster, connectez-vous à la console AnalyticDB for MySQL et accédez à la section Configuration Information sur la page Cluster Information.

Utilisation d'un indice (s'applique à une seule table, pour la tâche actuelle uniquement)

/*build_task_priority = <task_priority> */ BUILD TABLE <db_name>.<table_name>;

Exemple : Définissez la priorité à 30 pour la table test dans la base de données adb_demo.

/*build_task_priority = 30 */ Build TABLE adb_demo.test;

Utilisation de SET ADB_CONFIG (persistant, prend en charge plusieurs tables)

Définissez les priorités pour plusieurs tables dans différentes bases de données :

SET ADB_CONFIG RC_BUILD_TASK_PRIORITY_LIST = `<db1_name>.<table1_name>.<task_priority>;<db2_name>.<table2_name>.<task_priority>`;

Exemple : Priorité 30 pour adb_demo1.test1, priorité 10 pour adb_demo2.test2.

SET ADB_CONFIG RC_BUILD_TASK_PRIORITY_LIST = `adb_demo1.test1.30;adb_demo2.test2.10`;

Définissez la même priorité pour toutes les tables d'une base de données :

SET ADB_CONFIG RC_BUILD_TASK_PRIORITY_LIST = `<db1_name>.*.<task_priority>`;

Exemple : Priorité 30 pour toutes les tables de adb_demo1.

SET ADB_CONFIG RC_BUILD_TASK_PRIORITY_LIST = `adb_demo1.*.30`;

Définissez des priorités différentes entre une table spécifique et le reste des tables d'une base de données :
```
SET ADB_CONFIG RC_BUILD_TASK_PRIORITY_LIST = `<db1_name>.*.<task_priority>;<db1_name>.<table_name>.<task_priority>`;
```
Exemple : Priorité 30 pour adb_demo1.test1, priorité 10 pour toutes les autres tables de adb_demo1.
```
SET ADB_CONFIG RC_BUILD_TASK_PRIORITY_LIST = `adb_demo1.*.10;adb_demo1.test1.30`;
```

Lorsqu'un indice et SET ADB_CONFIG sont tous deux configurés pour la même table, l'indice est prioritaire pour la tâche actuelle.

Pour vérifier la configuration actuelle des priorités, exécutez SHOW ADB_CONFIG.

Surveillance de l'état des tâches BUILD

Interrogez l'état des tâches BUILD des trois derniers jours :

SELECT table_name, schema_name, status
FROM INFORMATION_SCHEMA.KEPLER_META_BUILD_TASK
ORDER BY create_time DESC
LIMIT 10;

État	Description
`INIT`	La tâche est en cours d'initialisation.
`RUNNING`	La tâche est en cours d'exécution.
`FINISH`	La tâche est terminée.

FAQ

La planification automatique ne prend pas effet

Les paramètres de temps dans SET ADB_CONFIG RC_CSTORE_BUILD_SCHEDULE_PERIOD doivent être encadrés par des accents graves (backticks). Sans ceux-ci, les valeurs ne sont pas analysées correctement et la planification est ignorée.

Syntaxe correcte :

SET ADB_CONFIG RC_CSTORE_BUILD_SCHEDULE_PERIOD=`0,6`;

Cela planifie les tâches BUILD entre 00:00 et 06:59.