AnalyticDB:Écritures et requêtes

Aperçu de la FAQ

• Puis-je utiliser JDBC pour interroger des données depuis des tables Hudi ?

• Puis-je lire des données depuis des tables Hudi dans OSS ?

• Un cluster peut-il basculer automatiquement entre un job XIHE MPP et un job XIHE BSP ?

• Comment choisir entre XIHE MPP et XIHE BSP pour exécuter un job ?

• Comment vérifier le statut d'un job XIHE BSP ?

• Comment isoler les ressources pour réduire les interférences entre les jobs SQL ?

• Que faire si une clause IN contient trop d'éléments ?

• Que faire en cas d'erreur « Query exceeded maximum time limit of 1800000.00ms » lors d'une requête ?

• Que faire en cas d'erreur « Out of Memory Pool size pre cal. available 0 require 3 » lors d'une requête ?

• Que faire en cas d'erreur « STORAGE_INDEX_ERROR, msg:Index does not exist » lors d'une requête ?

• Que faire en cas d'erreur « multi-statement found » lors de l'exécution de plusieurs instructions SQL ?

• Comment résoudre la troncature des valeurs temporelles dans les résultats de requête ?

• Comment corriger une erreur liée à la fonction intégrée AES_ENCRYPT ?

• Pourquoi mes résultats de requête changent-ils de manière inattendue ?

• Pourquoi une requête ORDER BY sur une seule table est-elle lente ?

• Pourquoi le nombre total de lignes analysées dans un plan d'exécution diffère-t-il du nombre réel de lignes analysées par la requête ?

• Pourquoi des doublons apparaissent-ils lors de l'utilisation de INSERT OVERWRITE sur une table sans clé primaire ?

• Pourquoi l'erreur « Column 'XXX' not in GROUP BY clause » survient-elle lors d'une requête SELECT * FROM ... GROUP BY ... ?

• Pourquoi les données de la table d'origine ne sont-elles pas écrasées après l'exécution d'une instruction INSERT OVERWRITE SELECT ?

• Existe-t-il une limite au nombre de valeurs dans un opérateur IN lorsque les résultats sont renvoyés au format JSON ?

• Les fichiers CSV compressés GZIP dans OSS peuvent-ils servir de source de données pour une table externe ?

• L'instruction INSERT ON DUPLICATE KEY est-elle prise en charge ?

• Puis-je utiliser une clause JOIN dans une instruction UPDATE ?

• Puis-je définir des variables dans une instruction SQL ?

• Puis-je utiliser le plug-in Logstash pour insérer des données en lot avec une instruction INSERT ON DUPLICATE KEY UPDATE ?

• Quelles sont les conditions préalables au chargement d'un jeu de données intégré ?

• Comment vérifier le chargement réussi d'un jeu de données intégré ?

• Que faire en cas d'échec ou de lenteur du chargement d'un jeu de données intégré ?

• Comment un compte de base de données standard peut-il utiliser un jeu de données intégré ?

• Comment tester un jeu de données intégré après son chargement ?

Les clusters Enterprise Edition, Basic Edition et Data Lakehouse Edition prennent-ils en charge l'interrogation des données des tables Hudi via JDBC ?

Oui. Après avoir créé une table Hudi dans un cluster Enterprise Edition, Basic Edition ou Data Lakehouse Edition, vous pouvez interroger directement la table Hudi via JDBC.

Les clusters Enterprise Edition, Basic Edition et Data Lakehouse Edition prennent-ils en charge la lecture des données de table Hudi depuis OSS ?

Oui. Pour plus d'informations sur la lecture des données depuis les tables Hudi dans OSS à l'aide d'une table externe, consultez Utiliser une table externe pour importer des données dans un cluster Data Lakehouse Edition.

**Les clusters Enterprise Edition, Basic Edition et Data Lakehouse Edition prennent-ils en charge le basculement automatique entre les jobs XIHE MPP et les jobs XIHE BSP ?**

Non. Lors de la soumission d'un job, vous devez spécifier manuellement le groupe de ressources cible (Interactive ou Job). Ce choix détermine si le job s'exécute en tant que job XIHE MPP ou XIHE BSP.

Comment choisir entre XIHE MPP et XIHE BSP pour exécuter des jobs sur les clusters Enterprise Edition, Basic Edition et Data Lakehouse Edition ?

Par défaut, un job XIHE BSP est soumis de manière asynchrone. La différence entre la soumission synchrone et asynchrone réside dans l'attente ou non de la fin de la requête par le client.

La soumission asynchrone présente les limites suivantes :

• L'ensemble de résultats peut contenir au maximum 10 000 lignes.

• Un maximum de 1 000 ensembles de résultats, y compris leurs liens de téléchargement CSV, peuvent être conservés pendant 30 jours maximum.

Nous recommandons la soumission asynchrone pour les requêtes longues et gourmandes en calcul qui renvoient peu de résultats, telles que INSERT INTO SELECT, INSERT OVERWRITE SELECT ou CREATE TABLE AS SELECT.

Clusters Enterprise Edition, Basic Edition et Data Lakehouse Edition : Comment afficher le statut d'un job XIHE BSP ?

• Si vous soumettez un job XIHE BSP via l'éditeur de jobs d'un cluster Data Lakehouse Edition, accédez à la page Job Editor > SQL Development et consultez le statut du job dans l'onglet Execution Records en bas de la page.

• Si vous n'avez pas soumis le job XIHE BSP depuis l'éditeur de jobs, interrogez son statut dans une table système interne. Exécutez l'instruction suivante :

  SELECT status FROM information_schema.kepler_meta_elastic_job_list WHERE process_id='<job_id>';

  Pour obtenir le décompte de tous les jobs XIHE BSP par statut, exécutez l'instruction suivante :

  SELECT status,count(*) FROM information_schema.kepler_meta_elastic_job_list GROUP BY status;

Isolation des ressources pour les jobs SQL

Les clusters Data Warehouse Edition (mode élastique) et Enterprise Edition, Basic Edition et Data Lakehouse Edition prennent en charge les groupes de ressources. Pour plus d'informations sur les types de groupes de ressources, consultez Aperçu des groupes de ressources (Data Warehouse Edition) et Aperçu des groupes de ressources (Data Lakehouse Edition). Créez différents types de groupes de ressources et soumettez-y les jobs SQL afin d'isoler les ressources.

Gestion d'un nombre excessif d'éléments dans une clause IN

AnalyticDB for MySQL limite le nombre d'éléments dans une liste IN. La limite par défaut est de 2 000, mais vous pouvez l'ajuster.

Par exemple, pour définir la limite à 3 000, exécutez l'instruction suivante :

SET ADB_CONFIG max_in_items_count=3000;

Résolution de l'erreur « Query exceeded maximum time limit »

Cette erreur survient lorsque la requête SQL dépasse le délai d'exécution par défaut de 1 800 000 ms (30 minutes) défini dans AnalyticDB for MySQL. Vous pouvez configurer le délai d'attente pour une seule requête ou pour toutes les requêtes du cluster :

• Définissez le délai d'attente pour une seule requête.

  /*+ QUERY_TIMEOUT=xxx */SELECT count(*) FROM t;

• Définissez le délai d'attente pour toutes les requêtes du cluster.

  SET ADB_CONFIG QUERY_TIMEOUT=xxx;

  Pour plus d'informations, consultez Paramètres de configuration courants.

Résolution des erreurs de mémoire insuffisante

Cause : De grandes requêtes SQL de longue durée peuvent s'exécuter dans le cluster AnalyticDB for MySQL. Ces requêtes consomment beaucoup de mémoire, ce qui provoque une erreur de mémoire insuffisante lors de la soumission d'une nouvelle requête SQL.

Solution : Attendez quelques minutes et relancez l'instruction SQL.

Résolution de l'erreur « STORAGE_INDEX_ERROR »

Cause : Cette erreur est due à un défaut connu dans certaines versions antérieures du noyau AnalyticDB for MySQL. Dans des conditions spécifiques, ce défaut peut provoquer des incohérences dans les métadonnées d'index d'une table. Par conséquent, l'index est introuvable lors d'une requête, ce qui déclenche l'exception STORAGE_INDEX_ERROR.

Solution : Mettez à niveau la version du noyau de votre cluster. Ce problème est corrigé dans les versions ultérieures du noyau.

Résolution de l'erreur « multi-statement found »

Seuls les clusters dont la version du noyau est 3.1.9.3 ou ultérieure prennent en charge la fonctionnalité multi-instructions. Vérifiez d'abord que la version du noyau de votre cluster est 3.1.9.3 ou ultérieure. Si la version est antérieure, contactez le support technique pour effectuer une mise à niveau. Si la version est 3.1.9.3 ou ultérieure mais que l'erreur persiste, la fonctionnalité multi-instructions peut être désactivée côté client.

Par exemple, lors de l'utilisation d'un client MySQL JDBC pour se connecter à un cluster, vous devez non seulement exécuter la commande SET ADB_CONFIG ALLOW_MULTI_QUERIES=true; pour activer manuellement la fonctionnalité Multi-Statement, mais aussi définir la propriété de connexion JDBC allowMultiQueries sur true.

Dépannage des valeurs temporelles tronquées dans les résultats de requête

Vérifiez d'abord le résultat à l'aide d'un client MySQL. Si la valeur temporelle s'affiche correctement dans le client MySQL, le problème peut provenir d'un autre outil client traitant l'ensemble de résultats.

Correction des erreurs avec la fonction AES_ENCRYPT

L'instruction suivante génère une erreur.

 SELECT CONVERT(AES_DECRYPT(AES_ENCRYPT('ABC123','key_string'),'key_string'),char(10));

Cause : L'erreur survient car le type de données du premier argument x dans la fonction AES_ENCRYPT(varbinary x, varchar y) doit être varbinary. L'exemple suivant montre une instruction valide :

SELECT CONVERT(AES_DECRYPT(AES_ENCRYPT(CAST('ABC123' AS VARBINARY), 'key_string'), 'key_string'),char(10)); 

Modifications inattendues des résultats de requête

Si vous confirmez que les données n'ont pas été mises à jour, les résultats de la requête peuvent changer de manière inattendue pour les raisons suivantes :

• Une clause LIMIT est utilisée sans clause ORDER BY. AnalyticDB for MySQL est une base de données distribuée qui exécute des requêtes sur plusieurs nœuds via plusieurs threads. Si certains threads renvoient suffisamment de lignes pour satisfaire la clause LIMIT, la requête se termine. Par conséquent, sans clause ORDER BY, l'ordre des résultats n'est pas garanti car le système ne peut pas assurer un ordre de réponse fixe des threads.

• Dans une requête d'agrégation groupée, si un champ de la liste SELECT ne figure ni dans une fonction d'agrégation ni dans la clause GROUP BY, une valeur aléatoire du groupe est renvoyée pour ce champ.

Si le problème persiste, contactez le support technique.

Lenteur des requêtes ORDER BY sur une seule table

Cause : Les données ne sont pas triées au niveau de la couche de stockage et sont dispersées. Cela peut déclencher un grand nombre de lectures de données inutiles, augmentant ainsi le temps de requête.

Solution : Créez un index clusterisé sur le champ spécifié dans la clause ORDER BY. Avec un index clusterisé, les données sont partiellement triées au niveau de la couche de stockage. Les requêtes ORDER BY lisent alors moins de données, ce qui améliore les performances. Pour plus d'informations sur la création d'un index clusterisé, consultez Ajouter un index clusterisé.

Écart dans les comptes de lignes analysées

Ce problème est généralement causé par des tables répliquées. Dans AnalyticDB for MySQL, une copie d'une table répliquée est stockée sur chaque shard. Lorsque vous interrogez une table répliquée, le nombre de lignes analysées est compté plusieurs fois, une fois pour chaque copie.

Duplication des données avec INSERT OVERWRITE

La déduplication automatique n'est pas prise en charge pour les tables AnalyticDB for MySQL qui ne possèdent pas de clé primaire.

Résolution de l'erreur « Column not in GROUP BY clause »

Dans une requête groupée, vous ne pouvez pas utiliser l'instruction SELECT * FROM table GROUP BY key pour récupérer tous les champs. Vous devez lister explicitement tous les champs. Voici un exemple SQL.

SELECT nation.name FROM nation GROUP BY nation.nationkey

Pourquoi INSERT OVERWRITE SELECT n'écrase-t-il pas les données de la table d'origine ?

Cause : L'instruction INSERT OVERWRITE écrase les données partition par partition. Les nouvelles partitions remplacent les anciennes partitions partageant les mêmes valeurs de partition. Si le résultat SELECT est vide, aucune nouvelle partition n'est créée, donc les données existantes dans la table d'origine ne sont pas écrasées.

Solution : Modifiez l'instruction INSERT OVERWRITE SELECT pour vous assurer que le résultat SELECT n'est pas vide avant d'écraser les données de la table d'origine.

Limite sur les valeurs de l'opérateur IN dans les résultats JSON

Pour les clusters AnalyticDB for MySQL dont la version du noyau est 3.1.4 ou antérieure, le nombre de valeurs spécifiées dans un opérateur IN ne peut pas dépasser 16. Pour les clusters dont la version du noyau est ultérieure à 3.1.4, aucune limite n'est imposée. Pour savoir comment vérifier la version du noyau de votre cluster, consultez Afficher la version du noyau d'un cluster.

Utilisation de fichiers CSV compressés GZIP depuis OSS comme source de données

AnalyticDB for MySQL prend en charge l'utilisation de fichiers CSV compressés GZIP depuis OSS comme source de données pour une table externe. Pour ce faire, ajoutez compress_type=gzip à la définition de la table externe. Pour plus d'informations sur la syntaxe des tables externes OSS, consultez Tables externes OSS non partitionnées.

INSERT ON DUPLICATE KEY est-il pris en charge ?

AnalyticDB for MySQL prend uniquement en charge les mises à jour par égalité de valeur, et non les expressions arithmétiques.

Utilisation d'une clause JOIN dans les instructions UPDATE

Cette fonctionnalité est disponible uniquement pour les clusters AnalyticDB for MySQL dont la version du noyau est 3.1.6.4 ou ultérieure. Pour plus d'informations, consultez UPDATE.

Puis-je définir des variables dans une instruction SQL ?

AnalyticDB for MySQL ne prend pas en charge la définition de variables dans les instructions SQL.

Pouvez-vous utiliser l'instruction INSERT ON DUPLICATE KEY UPDATE pour insérer des données en lot avec le plug-in Logstash ?

Oui. Lorsque vous utilisez l'instruction INSERT ON DUPLICATE KEY UPDATE pour insérer des données par lots, vous n'avez pas besoin d'ajouter ON DUPLICATE KEY UPDATE après chaque instruction VALUES(). Ajoutez-la uniquement après la dernière instruction VALUES().

Par exemple, pour insérer par lots 3 enregistrements dans la table student_course, exécutez l'instruction suivante :

INSERT INTO student_course(`id`, `user_id`, `nc_id`, `nc_user_id`, `nc_commodity_id`, `course_no`, `course_name`, `business_id`)
VALUES(277943, 11056941, '1001EE1000000043G2T5', '1001EE1000000043G2TO', '1001A5100000003YABO2', 'kckm303', 'Industrial Accounting Practice V9.0--77', 'kuaiji'),
(277944, 11056943, '1001EE1000000043G2T5', '1001EE1000000043G2TO', '1001A5100000003YABO2', 'kckm303', 'Industrial Accounting Practice V9.0--88', 'kuaiji'),
(277945, 11056944, '1001EE1000000043G2T5', '1001EE1000000043G2TO', '1001A5100000003YABO2', 'kckm303', 'Industrial Accounting Practice V9.0--99', 'kuaiji')
ON DUPLICATE KEY UPDATE
course_name = 'Industrial Accounting Practice V9.0--77',
business_id = 'kuaiji';

Conditions préalables au chargement d'un jeu de données intégré

Le cluster doit disposer d'au moins 24 ACU de ressources de stockage réservées, et le groupe de ressources user_default doit disposer d'au moins 16 ACU de ressources de calcul réservées.

Vérification du chargement d'un jeu de données intégré

Vous pouvez afficher la progression du chargement sur la page Job Development > SQL Development. Le jeu de données est chargé avec succès si l'icône sur le bouton Load Built-in Dataset est grisée, et si la base de données ADB_SampleData_TPCH et ses tables sont visibles dans l'onglet Databases and Tables.

Gestion des échecs lors du chargement d'un jeu de données intégré

Exécutez d'abord l'instruction SQL DROP TABLE table_name; pour supprimer toutes les tables de la base de données. Ensuite, exécutez l'instruction SQL DROP DATABASE ADB_SampleData_TPCH; pour supprimer la base de données du jeu de données intégré. Une fois la base de données ADB_SampleData_TPCH supprimée, rechargez le jeu de données.

Utilisation d'un jeu de données intégré avec un compte standard

La fonctionnalité de jeu de données intégré suit les règles de gestion des autorisations de AnalyticDB for MySQL. Même si un jeu de données intégré est chargé dans le cluster, un compte de base de données standard ne peut pas l'utiliser sans autorisations sur la base de données ADB_SampleData_TPCH. Un compte privilégié doit accorder les autorisations requises au compte standard en exécutant l'instruction suivante :

GRANT select ON ADB_SampleData_TPCH.* TO <user_name>;

Test d'un jeu de données intégré

Une fois le jeu de données chargé avec succès, AnalyticDB for MySQL fournit un ensemble de scripts de requête correspondants. Sur la page SQL Development, ouvrez l'onglet Scripts et exécutez les exemples d'instructions de requête. Pour plus d'informations sur les requêtes, consultez Requêtes de test TPC-H.