> Tech > Améliorations de la base de données

Améliorations de la base de données

Tech - Par iTPro - Publié le 24 juin 2010
email

Les nouvelles technologies et les améliorations progressives des V4R3 et V4R4 permettent à  la base de données de l'AS/400, désormais appelée DB2 Universal Database for AS/400 (UDB/400), de traiter davantage de données en moins de temps. Plus précisément, un nouveau procédé d'indexation et des améliorations du langage SQL ont simplifié

Améliorations de la base de données

la conception des requêtes et amélioré leurs performances. Pour d’autres benchmarks intéressants, voir l’encadré “ Résultats de UDB/400 ”, ci-après.

Index de vecteurs encodés (EVI : Encoded Vector Indexes). UDB/400 est le premier membre de la famille DB2 d’IBM à  bénéficier des EVI. Contrairement aux index arborescents binaires traditionnels, qui améliorent les performances des applications OLTP et de BI, les EVI sont conçus spécifiquement pour rendre plus performantes les requêtes dans des environnements de datawarehousing.

La technologie EVI, brevetée par IBM, exploite la puissance de l’indexation bitmap sans la charge associée. Les EVI sont des objets spéciaux constitués de deux tables : l’une contient des statistiques sur chaque valeur unique dans la colonne de la table sous-jacente, et l’autre associe chaque valeur unique à  un code. L’optimiseur des requêtes de l’AS/400 utilise la première table pour déterminer si un EVI est susceptible d’optimiser les performances et, si oui, il utilise la seconde table pour construire un bitmap dynamique contenant un bit par ligne de la table. On peut ensuite combiner ces bitmaps dynamiques (comme des index bitmap) en utilisant une logique booléenne. Ainsi, si l’on crée plusieurs EVI (il est conseillé d’en créer un par colonne) pour une table, l’optimiseur de requêtes peut créer (et utiliser en tandem) plusieurs bitmaps dynamiques pour rendre les requêtes aussi performantes que possible.

Les EVI présentent des avantages par rapport aux index de base (radix) et bitmap. Lors de tests effectués au Teraplex Center d’IBM, les temps de construction d’EVI ont été généralement de 10 à  30% plus rapides que ceux des index de base (radix). En outre, comme les EVI stockent l’information sur chaque valeur de clé unique (par opposition à  un bitmap complet pour chaque valeur), ils sont bien entendu plus petits que les index bitmap. Le Teraplex Center a également constaté que les EVI étaient jusqu’à  16 fois plus petits que les index de base construits sur les mêmes colonnes. Enfin, en matière de performances, les EVI ont considérablement réduit les temps de requêtes dans des environnements ad hoc.

En V4R3, le surcroît de performances des EVI est limité principalement à  la sélection d’enregistrements. En revanche, en V4R4, les EVI peuvent traiter des jointures— un avantage considérable pour tous ceux qui comptent sur le schéma en étoile pour mettre en oeuvre des magasins et des entrepôts de données. Pour en savoir plus sur les EVI, voir “ Quoi de neuf pour la base de données ? ”, NEWSMAGAZINE, septembre 1998, page 95.

Chargeur de données en parallèle. Lui aussi introduit avec la V4R3, le chargeur de données en parallèle permet d’importer de grands tableaux bidimensionnels (fichiers plats) depuis d’autres systèmes directement dans UDB/400. Compte tenu des environnements informatiques hétérogènes actuels, il est vital de pouvoir transférer des données d’autres systèmes dans des entrepôts de données AS/400. Pourtant, avant cette amélioration, il fallait utiliser de façon créative la commande CPYF (Copy File) ou écrire des programmes de conversion chargés de transférer les données brutes dans les tables DB2/400.

Le chargeur de données propose une nouvelle commande CL (CPYFRMIMPF (Copy from Import File)) permettant de définir les délimiteurs dans le fichier d’importation. (Dans le cas de fichiers à  format fixe, on crée un fichier de définitions de zones référencé par la commande CPYFRMIMPF. Cette méthode est analogue aux fichiers FDF utilisés pour transmettre des données aux AS/400 via Client Access.) CPYFRMIMPF est particulièrement utile lorsque de grands fichiers plats sont régulièrement transférés depuis d’autres systèmes vers un datamart ou un datawarehouse AS/400. Comme son nom l’indique, le chargeur de données en parallèle ne peut bénéficier de multiples processeurs que si la fonction SMP (Symmetric MultiProcessing) de l’AS/400 a été installée.

Maintenance de fichiers logiques en parallèle. Tout responsable de datawarehouse vous le dira : pendant les périodes de chargement, les performances se dégradent. L’une des causes en est la maintenance des fichiers logiques qui, avant la V4R3, s’effectuait fichier par fichier. Grâce aux récentes améliorations de l’OS/400, l’AS/400 peut désormais maintenir plusieurs fichiers logiques en même temps. De quoi combler les utilisateurs d’entrepôts de données parce que la plupart des applications de BI s’appuient sur de nombreux fichiers logiques. Les améliorations de performances sont plus apparentes dans le cas de grandes bases de données fréquemment mises à  jour (comme pour le chargeur de données en parallèle, pour bénéficier de cette fonction, SMP doit être installé sur le système.)

Nouvelles fonctionnalités des zones de date. Ceux d’entre vous qui stockent les dates dans des zones de date (plutôt que des zones numériques) seront heureux d’apprendre qu’en V4R4 les clauses SQL Group By et Order By permettent de récapituler les données par composants de la zone date (par exemple par an) en une seule instruction. Cette fonction simplifie la conception des bases de données parce qu’il n’est plus nécessaire de maintenir des zones mois et années séparées pour améliorer les performances des requêtes.

Support des tables dérivées. La V4R4 permet aussi de simplifier les instructions SQL parce qu’on peut définir une sous-requête sur la clause From. Ce type de sous-requête de table dérivée permet d’effectuer davantage de traitements dans une instruction SQL, éliminant souvent le besoin de créer des vues temporaires pour honorer la requête de données.

Prise en compte des jointures extérieures gauches. La V4R4 permet également d’imbriquer une jointure extérieure gauche dans une autre et de spécifier plus grands que (>), plus grand que ou égal à  (>=), et d’autres opérandes (et non pas simplement des égalités) quand il y a plus d’une jointure extérieure gauche entre des tables.

Amélioration des performances de la fonction Group By. Enfin, la V4R4 présente une fonction de “ hachage ” Group By presque huit fois plus rapide que celle de la V4R3 pour des constructions de grandes tables récapitulatives.

Téléchargez gratuitement cette ressource

IBMi et Cloud : Table ronde Digitale

IBMi et Cloud : Table ronde Digitale

Comment faire évoluer son patrimoine IBMi en le rendant Cloud compatible ? Comment capitaliser sur des bases saines pour un avenir serein ? Faites le point et partagez l'expertise Hardis Group et IBM aux côtés de Florence Devambez, DSI d'Albingia.

Tech - Par iTPro - Publié le 24 juin 2010