Conseils de dépannage pour Actian Vector dans Hadoop

Actian Vector et Vector in Hadoop sont des outils puissants qui permettent d'exécuter des requêtes de manière efficace. Cependant, la plupart des utilisateurs de plateformes analyse de données cherchent à optimiser les performances afin d'améliorer progressivement les requête .

L'équipe de service et de Support d'Actian travaille avec nos clients pour identifier les domaines communs qui devraient être examinés lorsqu'on essaie d'améliorer la performance des requête . La plupart de nos recommandations s'appliquent aussi bien à Actian Vector (un seul nœud) qu'à Actian Vector in Hadoop (VectorH, un cluster multi-nœuds sur Hadoop).

Actian a récemment publié un aperçu approfondi des connaissances techniques et des meilleures pratiques qui aideront tous les utilisateurs de Vector et de VectorH à optimiser leur performance, avec un accent particulier sur VectorH.

Contrairement aux moteurs de requête SQL sur Hadoop (Hive, Impala, Spark SQL, etc.), VectorH est un véritable moteur de requête en colonnes, MPP, SGBDR avec toutes les capacités de SQL, l'transactions acid (c'est-à-dire le support des mises à jour et des suppressions en place), des options de sécurité robustes intégrées, etc. Cette flexibilité permet à VectorH d'être optimisé pour des charges de travail et des environnements complexes.

Notez que Vector et VectorH sont tout à fait capables d'exécuter des requêtes efficacement sans utiliser aucune des techniques examinées. Cependant, ces techniques seront utiles pour les charges de travail exigeantes et les environnements Hadoop chargés et vous permettront d'obtenir les meilleurs résultats de votre plateforme.

En travaillant avec nos clients, nous avons constaté que les domaines suivants devraient être étudiés pour obtenir des performances maximales.

Lire le rapport complet

Partitionner vos tables

Une considération très importante dans la conception des schémas pour tout système de traitement massivement parallèle (MPP) comme VectorH est la façon de répartir les données dans un cluster afin d'équilibrer l'exécution des requête façon égale sur toutes les ressources disponibles. Si vous ne partitionnez pas explicitement vos tables lors de leur création, VectorH créera par défaut des tables non partitionnées - mais pour de meilleures performances, vous devriez toujours partitionner les plus grandes tables de votre base de données.

Éviter l'asymétrie des données

Les données déséquilibrées, où un petit nombre de machines ont beaucoup plus de données que la plupart des autres, sont connues sous le nom de "data skew" (asymétrie des données). L'asymétrie des données peut entraîner de graves problèmes de performance pour les requêtes, car la machine disposant d'une quantité disproportionnée de données régit la vitesse globale de la requête et peut devenir un goulot d'étranglement.

Statistiques manquantes

distribution des données Les statistiques sont essentielles à la création d'un bon plan de requête . En l'absence de statistiques, l'optimiseur de requête VectorH émet certaines hypothèses par défaut sur des éléments tels que le nombre de lignes qui correspondront lorsque deux tables seront jointes. Lorsqu'il s'agit d'ensembles de données plus importants, il est préférable de disposer de données réelles sur la distribution effective des données, plutôt que de s'appuyer sur ces estimations.

Tri des données

Le modèle relationnel de traitement n'exige pas que les données soient triées sur le disque - au lieu de cela, une clause ORDER BY est utilisée sur une requête qui nécessite que les données soient restituées dans un ordre particulier.

Cependant, en utilisant ce que l'on appelle les index MinMax (maintenus automatiquement dans la structure d'une table sans intervention de utilisateur ), VectorH est capable d'utiliser des données ordonnées pour éliminer plus efficacement les blocs de données inutiles du traitement et donc d'accélérer l'exécution des requête , lorsque les requêtes ont une clause WHERE ou une restriction de jointure sur une colonne sur laquelle la table est triée.

Utiliser les types de données les plus appropriés

Comme pour toute base de données, choisir le bon type de données pour votre schéma et vos requêtes peut faire une grande différence dans les performances de VectorH, donc ne prenez pas l'habitude d'utiliser la taille maximale des colonnes par commodité. Au lieu de cela, considérez les plus grandes valeurs que vous êtes susceptible de stocker dans une colonne VARCHAR, par exemple, et dimensionnez vos colonnes en conséquence.

Comme VectorH compresse très efficacement les données des colonnes, la création de colonnes beaucoup plus grandes que nécessaire n'a qu'un impact minime sur la taille des tables de données. Comme les colonnes VARCHAR sont stockées en interne sous forme de chaînes à terminaison nulle, la taille du VARCHAR n'a en fait aucun effet sur les temps de traitement des requête . Cependant, elle influe sur les temps de communication du frontend, car les données sont stockées à la longueur maximale définie après avoir quitté le moteur. Notez cependant que le fait de stocker des données qui sont intrinsèquement numériques (identifiants, horodatages, etc.) en tant que données VARCHAR est très préjudiciable au système, car VectorH peut traiter les données numériques de manière beaucoup plus efficace que les données de caractères.

Gestion de la mémoire pour les petites modifications

VectorH dispose d'un mécanisme en instance de brevet pour traiter efficacement de nombreuses petites modifications de données, appelé Positional Delta Trees (PDT). Ces arbres permettent également d'utiliser des instructions de mise à jour et de suppression sur des données stockées dans un système de fichiers en annexe comme HDFS.

Toutefois, si un grand nombre d'instructions de mise à jour, d'insertion ou de suppression sont exécutées, l'utilisation de la mémoire pour les structures PDT peut augmenter rapidement. Si de grandes quantités de mémoire sont utilisées, le système peut devenir plus lent à traiter les modifications futures, et finalement la mémoire sera épuisée. La gestion de cette mémoire est assurée automatiquement, mais l'utilisateur peut également lancer directement une instruction "combine", qui fusionnera les modifications du PDT dans la table principale dans le cadre d'un processus appelé "propagation de la mise à jour". Il existe un certain nombre de déclencheurs qui permettent au système d'effectuer cette maintenance automatiquement en arrière-plan (tels que des seuils pour la mémoire totale utilisée pour les PDT ou le pourcentage de lignes mises à jour), de sorte que cette opération est généralement transparente pour l'utilisateur.

Optimisation de la simultanéité

VectorH est conçu pour permettre à une requête unique d'être exécutée en utilisant autant de fils d'exécution parallèles que possible afin d'atteindre des performances maximales. Cependant, ce qui est peut-être atypique pour un système MPP, il est également conçu pour permettre une grande simultanéité avec une allocation démocratique des ressources lorsqu'il y a un grand nombre de requêtes présentes dans le système. VectorH gère ces deux situations avec des paramètres "prêts à l'emploi", mais peut être adapté aux besoins de l'application (par exemple, si l'on souhaite répondre à un débit plus élevé de requêtes lourdes en limitant les ressources maximales qu'une requête peut acquérir).

Le nombre de connexions simultanées (64 par défaut) qu'une instance VectorH donnée acceptera est régi par le paramètre connect_limit, stocké dans config.dat et géré par l'utilitaire CBF. Mais il y a généralement plus de connexions que de requêtes exécutées, alors comment les ressources sont-elles allouées entre les requêtes concurrentes ?

Par défaut, VectorH tente d'équilibrer les charges de travail à requête requête et à requêtes requête . Les paramètres clés de cet équilibre sont les suivants :

• Le nombre de cœurs de processeur dans le cluster VectorH.
• Le nombre de threads qu'une requête peut utiliser.
• Le nombre de threads qu'une requête est accordée par le système.
• Nombre de requêtes en cours d'exécution dans le système.

Résumé

Vector et VectorH sont tout à fait capables d'exécuter des requêtes efficacement sans utiliser aucune des techniques et astuces décrites ici. Mais plus votre charge de travail est exigeante, en termes de volumes de données, de complexité des requête ou desimultanéité utilisateur , plus l'application de certains des conseils définis dans le rapport complet vous permettra d'obtenir les meilleurs résultats de votre plate-forme.

Lire le rapport complet

À propos d'Actian Corporation

Actian facilite l'accès aux données. Notre plateforme de données simplifie la façon dont les gens connectent, gèrent et analysent les données dans les environnements cloud, hybrides et sur site . Avec des décennies d'expérience dans la gestion des données et l'analyse, Actian fournit des solutions de de haute performance qui permettent aux entreprises de prendre des décisions basées sur les données. Actian est reconnu par les principaux analystes et a reçu des prix de l'industrie pour sa performance et son innovation. Nos équipes partagent des cas d'utilisation éprouvés lors de conférences (par exemple, Strata Data) et contribuent à des projets à code source ouvert. Sur le blog d'Actian, nous abordons des sujets tels que l'ingestion de données en temps réel, l'analyse de données, la gouvernance données, la gestion des données, la qualité des données, l'intelligence des données et l'analyse pilotée par l'IA.