Vous chargez du Big Data ? Pour plus de rapidité, pré-tri et chargement en masse
Trouver plus de vitesse lors du chargement de données volumineuses est un défi dans l'ETL, la réorganisation et l'index de très grande base de données (VLDB) peupler les opérations. Une façon de charger plus rapidement le Big Data consiste à le pré-trier, afin que la base de données n'ait pas à trier. IBM et d'autres fournisseurs de bases de données mainframe ont donné ce conseil pendant des décennies, et c'est toujours vrai dans les bases de données relationnelles utilisées sur Unix et d'autres "systèmes ouverts" aujourd'hui, y compris Oracle, DB2, Sybase et SQL Server.
Les références dans ce domaine montrent des améliorations par rapport aux charges non triées en fonction du volume, mais les fournisseurs de tri comme IRI affirment que les performances de charge se sont améliorées entre deux et dix fois. Dans le rapport de TUSC Consulting "Benchmarking Index Impact on OLTP Load Rates and Online Database Block Size Rebuild in Oracle", un test d'insertion d'index unique de 100 000 lignes a montré à lui seul que les données pré-triées se chargeaient 58 % plus rapidement et nécessitaient 49 % d'espace en moins :
- Le chargement dans l'ordre trié avait un taux de chargement soutenu de 42 % moins élevé de lignes/seconde
- Les insertions non triées dans les index obligent à effectuer davantage de travail de base de données interne (gestion des blocs et réorganisation de l'espace)
- Dans les index triés par chargement, le facteur de regroupement sera proche du nombre de blocs feuilles
- L'ordre des données chargées est essentiel pour les performances de chargement.
De nombreuses années plus tard, dans le chapitre 13 de son guide "Expert Oracle Database 11g Administration", Sam R. Alapati (Miro Consulting) a recommandé le pré-tri en conjonction avec les chargements de chemin direct comme le moyen le plus rapide de charger en masse Oracle (par rapport aux insertions) :
"Le chargement par chemin direct l'option n'utilise pas l'instruction SQL INSERT pour placer des données dans des tables ; il formate plutôt les blocs de données Oracle et les écrit directement dans les fichiers de la base de données. Ce processus d'écriture directe élimine une grande partie de la surcharge impliquée dans l'exécution des instructions SQL pour charger les tables. Étant donné que la méthode de chargement par chemin direct ne se dispute pas les ressources de la base de données, elle chargera les données beaucoup plus rapidement qu'un chargement de données conventionnel. Pour les charges de données plus importantes, la méthode de chargement par chemin direct est la meilleure, et il peut s'agir de la seule méthode viable de chargement de données dans des tables pour la simple raison qu'une charge conventionnelle peut nécessiter plus de temps que ce qui est disponible. »
Pour les administrateurs de VLDB d'aujourd'hui, c'est là qu'intervient CoSort, puisque :
"Outre les avantages évidents d'un temps de chargement plus court, le chargement direct vous aide également à reconstruire les index et à pré-trier les données des tables."
CoSort est traditionnellement utilisé dans le pré-tri externe d'un fichier plat qui sera l'import vers un chargement en spécifiant "direct=true" et cette option :
"INDICES SORTÉS :Le paramètre SORTED_INDEXES signale à SQL*Loader que les données sont triées sur un index spécifié, ce qui améliore les performances de chargement."
De même, la documentation de Microsoft SQL Server spécifie le tri préalable des fichiers comme l'une des "Méthodes d'optimisation de l'importation en masse" :
Par défaut, une opération d'importation en bloc suppose qu'un fichier de données n'est pas ordonné. Si la table a un index clusterisé, le bcp L'utilitaire, l'instruction BULK INSERT et la fonction OPENROWSET(BULK...) (Transact-SQL) vous permettent de spécifier la manière dont les données du fichier de données sont triées lors d'une opération d'importation en bloc. Il est facultatif que les données du fichier de données soient triées dans le même ordre que la table. Cependant, vous pouvez améliorer les performances de l'opération d'importation en bloc si vous spécifiez le même ordre pour le fichier de données que pour le tableau.
Le champ /KEY dans un script CoSort SortCL serait généralement la clé d'index (primaire) la plus longue de la table, mais ce n'est pas obligatoire. Selon TUSC, pour des colonnes similaires :
- Plusieurs index longs sont préférables à des index plus courts
- La première colonne détermine le coût de chargement de l'index
Notez également que :
- Par Vertica et d'autres amorces RDBMS, le maintien des colonnes dans des ordres triés optimise les performances des requêtes. Même le vieux conseil du Guide Rdb/VMS de DEC sur la maintenance et les performances de la base de données est toujours vrai :
« Pré-triez les enregistrements que vous prévoyez de stocker dans une table par valeur de clé primaire avant de les charger dans la base de données. Lorsque les enregistrements sont chargés, ils seront physiquement adjacents les uns aux autres, ou regroupés, jusqu'à ce que des enregistrements supplémentaires soient stockés dans la base de données. Le maintien de cette disposition profite aux requêtes qui sélectionnent des lignes en fonction d'une plage de valeurs ou qui joignent plusieurs lignes d'une table avec des lignes dans la même table. »
- Le pré-tri des données dans les tableaux peut également faire gagner du temps dans les vues. D'après "Oracle Database 10g :The Complete Reference" de Kevin Loney :
« Le fait de trier les données dans la vue peut simplifier le développement de votre application. Par exemple, si votre code parcourt un ensemble d'enregistrements, le tri préalable de ces enregistrements peut simplifier votre traitement et la vérification des erreurs. Lors du développement de votre application, vous saurez que les données vous seront toujours renvoyées de manière ordonnée. »
- M. Alapati avertit les DBA d'une limitation des chargements de chemin direct :
"Remarque :dans un chargement direct, vous ne pouvez utiliser aucune fonction SQL. Si vous devez effectuer un chargement de données volumineux et également transformer les données pendant le chargement, vous avez un problème. Le chargement de données conventionnel vous permettra d'utiliser des fonctions SQL pour transformer des données, mais la méthode est très lente par rapport au chargement direct. Ainsi, pour les charges de données volumineuses, vous pouvez envisager d'utiliser l'une des techniques de chargement/transformation les plus récentes, telles que les tables externes ou les fonctions de table. »
Cependant, le programme SortCL de CoSort peut transformer les données de chargement lors du pré-tri; c'est-à-dire en combinant le même type de fonctions SQL dans le même script de travail et la même passe d'E/S, y compris :les jointures, les agrégations, les calculs croisés, les recherches, les fonctions de sélection/filtre, de sous-chaîne et d'instring, et de nombreuses cibles de reformatage et de rapport personnalisé — dans cette même opération de pré-tri.
- Le nouvel utilitaire de réorganisation hors ligne dans IRI Workbench (Eclipse GUI) utilise IRI FACT (Fast Extract) pour décharger rapidement les données de table via OCI, utilise CoSort pour pré-trier sur la clé primaire, et écrit et exécute directement SQL*Loader charges de chemin pour optimiser et combiner chacune de ces étapes.
