Blogs des dveloppeurs

< Le blog de SQLpro/>

Article complet: Base de donnes et performances... petites tables et tables obses !

19/06/2011
20:20:16, Catgories: Rcapitulatif Web, Langage SQL (norme), MySQL, Rcapitulatif SGBD, Langage SQL, Oracle, SQL Server, PostgreSQL, Firebird, Interbase, 1717 mots , sqlpro

[Firebird][Interbase][MySQL][Oracle][PostgreSQL][SGBD][SQL][SQL Server][Web] Base de donnes et performances... petites tables et tables obses !

La plupart des dveloppeurs sont persuads que mettre toutes les informations dans une mme table rendra leur base de donnes plus rapide... Et l'on voit apparatre dans la base de nombreuses tables de plusieurs dizaines de colonnes. C'est une vue court terme, car ds que la base de donnes commence croitre ou que le nombre d'utilisateur augmente, les performances deviennent vite catastrophique... Cet article explique pourquoi... [Suite:] chaque audit que je fais, et cela depuis maintenant plus de 15 ans, on trouve rgulirement la mme erreur : des tables avec un nombre effrayant de colonnes. Par exemple une table des personnes, dans laquelle on trouve des adresses, des tlphones, des mails, ... bref tout un tas d'information relatif une personne, mais qui ne constitue aucunement des attributs directs de la personne. Et chaque fois que l'on fait remarquer cela aux dveloppeurs, la rponse est la mme : "on m'a dit que les jointures c'tait mal" "les jointures c'est pas performants, c'est connu" "Je mets tout dans la mme table, a ira plus vite" ... Bien videmment, c'est tout le contraire, mais pour le comprendre il faut revenir ce qu'est une base de donnes relationnelle, comment fonctionne les SGBDR client/serveur et ce qu'est la normalisation d'un modle de donnes, c'est dire son dcoupage en de multiples tables, chacune tant bien spcialis et concentr sur l'objet qu'elle modlise. Types de donnes et forme normale Le choix des types de donnes, la matrise de la qualit des donnes et le respect des formes normales reprsente, lorsqu'on ne les met pas en uvre, plus de 70% des problmes de performance. Mais l o c'est pervers, c'est que le dveloppeur ne s'en rendra compte que trop tard, lorsque aprs plusieurs mois, voire plusieurs annes de production, le volume de la base de donnes dpassant largement celui de

la RAM du serveur, les performances deviennent catastrophiques... J'ai vu plusieurs diteurs en situation de quasi faillite aprs avoir vendu leur logiciel avec une base mal modlise leur premier gros client. Le scnario est gnralement le suivant : aprs plusieurs semaines d'exploitation, les temps de rponses tant dj mauvais, le client intime l'diteur de trouver une solution. Comme il n'y a pas de silver boulette (comme disent nos amis amricains) et que tout redvelopper est gnralement inenvisageable, on patch quelques petits lments droite gauche pour gagner du temps... Au bout de quelques mois, le client s'impatiente et menace de ne pas payer... Et finalement c'est ce qu'il fait car rien ne vient ! Normaliser une base de donnes La normalisation d'une base de donnes (c'est--dire le respecte des rgles de modlisation) n'est pas une figure de style. C'est, avant tout, une question de performance ! Par exemple le viol de la notion d'atomicit (premire forme normale), c'est dire mettre plusieurs informations dans une mme colonne est une erreur aux consquences lourdes. Elle conduira tt ou tard des tables obsdes et des acrobaties pour crire des requtes qui ne pourront jamais tre optimises. Je donne souvent les exemples suivants : "modlisez moi une adresse IP, modlisez moi un n de scurit sociale" (bien entendu ces demandes sont "noyes" dans un exercice plus gnral de modlisation).... La plupart du temps les dveloppeurs modlisent une adresse IP sous la forme d'une chaine de caractres de longueur maximale 15. L je leur demande de saisir quelques adresses IP et je leur demande d'crire la requte suivante : "Trouvez-moi les ordinateurs affrent au masque de sous rseau de classe C" Et l c'est la panique... Lorsque la requte est crite (ce qui est rarement arrive...) elle est catastrophiquement lente du fait de multiples fonctions. C'est ce moment que le dveloppeur me dit que cela aurait t mieux s'il avait modlis cette adresse IP avec 4 entiers. Parfait lui dis-je... ce moment-l, je lui demande de me dire comment traiter les adresses IP V6 ! Pour le numro de scurit sociale, c'est le mme tabac. La plupart du temps les dveloppeurs me mettent deux zones de saisie : une de 13 caractres et l'autre de 2 pour la clef. Maintenant je leur demande de me dire comment ils vont contrler la saisie sachant que le premier caractres doit tre un 1 ou 2 , les 2 second de 00 99, les 2 d'aprs de 01 12, etc. Puis je leur demande de m'crire une requte pour trouver toutes les personnes du sexe masculin ne dans les annes 60 en rgion parisienne... Bien entendu je leur montre la solution finale qui consiste dcouper le n de scurit sociale en au moins 5 groupes : sexe, mois, anne, commune et rang. De la mme faon je leur donne une table contenant des informations de personnes ou l'on trouve outre le nom et le prnom une adresse un mail et 3 zone de saisie de tlphones (fixe, fax et GSM), et l je leur demande de me retrouver le nom d'une personne dont le n est 06 11 44 78 95... videmment la table contient ce genre de choses :

TEL ---------------01 47 58 42 23 0645145874 01-22-44-25-36 0645184953 +33 6 52418552 06 11 22 55 87

FAX GSM ------------------ -----------------+33 5 21 56 89 45 06 11 49 56 12 04-87-56-23-21 06 12457825 01.22.44.12.52 09 48 41 25 14 06 78 41 56 23

Alors qu'il est si simple de crer une table des tlphones avec une seule colonne pour tous les numros en les typant et en maitrisant la saisie. Le non respect des formes normales, conduit systmatiquement dcrochage des performances ds que le volume des donnes de la base dpasse la quantit de RAM. L'application du processus de normalisation, conduit un grand nombre de tables avec trs peu de colonnes (en moyenne moins d'une dizaine) et de nombreuses jointures doivent tre ralises pour retrouver les donnes. Les jointures, tout particulirement lorsqu'elles portent sur des "petites" clefs (comme un entier avec un auto incrment de type SEQUENCE ou IDENTITY) sont des processus d'une extrme rapidit (c'est l'opration la plus courante dans un SGBDR, donc la plus optimise). Par exemple, avec deux tables de 100 millions de lignes, une jointure qui au final renvoie une ligne ne coutera que la lecture de 6 pages, ce qui est trs peu. Et joindre 30 tables de 100 millions de lignes de ce type ne coute que 180 lectures, ce qui n'est rien pour un SGBDR qui gnralement lit 8 pages d'un seul coup ! Diffrences entre des petites tables et une grosse table pour les oprations de mises jour (criture) : Dans une grosse table contenant un grand nombre de colonnes, chaque criture (INSERT, UPDATE or DELETE) pose un verrou exclusif tant est si bien que personne d'autre ne peut l'utiliser. Dans un jeu de plusieurs petites tables reprsentant une seule et mme grosse table, les oprations d'criture se succderons squentiellement et tandis que l'un est mis a jour avec un verrou exclusive, les autres peuvent tre utiliss en lecture comme en criture. Finalement plus d'utilisateurs peuvent travailler simultanment sans tre victimes de temps d'attente importants dans une base constitue de nombreuses petites tables. Diffrences entre des petites tables et une grosse table pour les oprations de lecture : Dans une table, qu'elle soit petite ou grande, une seule mthode doit tre choisie pour accder aux donnes : - balayage de toutes les lignes de la table; - balayage de toutes les lignes d'un index; - recherche dans un index; Une fois qu'une grande table a t morcele en plusieurs petites tables, l'optimiseur peut choisir la meilleure mthode d'accs entre balayage et recherche en prfrant la recherche aussi souvent que possible. S'il existe plusieurs prdicats de recherches ou plusieurs conditions dans le prdicat, la seule manire d'oprer dans une grande table est de balayer toute la table.

Bien entendu les recherches sont incommensurablement plus rapides que les balayages parce que leur cot est logarithmique. Finalement et malgr le cot des jointures, une requte avec plusieurs prdicats ou conditions s'excutera beaucoup plus rapidement ds que le volume de donnes commence peser d'un poids important. Et plus les requtes "roulent" vite, plus un grand nombre d'utilisateurs peuvent utiliser simultanment le systme Toutes les oprations relationnelles dans une base de donnes sont faites exclusivement en mmoire. Aussi quelque soit la mthode d'accs aux donnes, toutes les donnes ncessaires la requte doivent tre places en RAM avant d'tre lues. Avec un balayage, toutes les lignes de la table doivent tre places en mmoire Avec une recherche, trs peu de pages doivent tre places en mmoire, parce qu'un index est un arbre et qu'il suffit d'y placer la page racine, les pages de navigation et la page feuille contenant les donnes finales. Bien entendu un balayage place un grand nombre de page en mmoire, tandis qu'une recherch en place trs peu. Conclusion : Dans une base mal modlise, le rsultat est une consommation anormale de RAM du fait de nombreux balayage. Dans un tels cas, la solution consiste avoir une RAM sur le serveur gal la taille de la base ou bien de restructurer la base ! Le problme est que restructurer la base ncessite une refonte complte du dveloppement, si les dveloppeurs n'ont pas prvu au dpart d'utiliser des vues Bref, pour ne pas avoir respecter l'art de la modlisation des donnes, les performances deviendront tt ou tard un cauchemar !
-------Frdric Brouard, SQLpro - ARCHITECTE DE DONNES, http://sqlpro.developpez.com/ Expert bases de donnes relationnelles et langage SQL. MVP Microsoft SQL Server www.sqlspot.com : modlisation, conseil, audit, optimisation, tuning, formation * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

Commentaires, Pingbacks: Commentaire de: zinzineti [Membre]

Voil un condens de best pratices pour tous ceux qui travaillent directement ou indirectement avec les bases de donnes. 132 ! 132 c'est le nombre de colonnes d'une table que j'ai identifi lors d'une opration "pompier" sur une application qui met genou le serveur de base de donnes et renvoie les tlconseillers d'un centre d'appel en congs forcs... Ce qui est navrant c'est quand ces erreurs de conception proviennent de "grand" diteur de logiciel. Comment en arrive-t-on l ? Pourquoi ces erreurs ne sont pas identifies lors des tests de monte de charge ? Pourquoi ces erreurs de conception ne sont pas identifes avant la sortie officelle du logiciel ? Le dveloppeur est-il le seul responsable dans cette affaire ? Pour ma petite esprience je pense que le mot dveloppeur est un fourre-tout ! un fourre-tout parce que Monsieur le dveloppeur doit avoir des comptences larges et vares. Qu'attend les managers d'quipe ou chefs de projet d'un dveloppeur ? Pour eux le dveloppeur doit : pisser des lignes de code : du bon code (.NET ou Java ou ...) savoir dployer ces applications quelque soit l'environnement du client final ... tre bon en systme et rseaux (pour ne pas tout le temps dranger les ingnieurs systmes,...) avoir l'aptitude de travailler non seulement sur WINDOWS mais aussi sur Linux pour crire de temps en temps des scripts shell avoir de bonne aptitude produire des documents de tests, de recette, d'exploitation,... Et les base de donnes ? Le dveloppeur doit : matriser la modlisation/conception des bases de donnes (SQL SERVER ET ORACLE ET SYBASE ET ...) matriser les principaux tches de maintenance des serveurs de base de donnes (SQL SERVER ET ORACLE ET SYBASE ET ...) matriser l'criture de requtes SQL : pas des SELECT * Non ! mais des requtes optimes bref il doit tre expert en TUNING de requtes SQL

 matriser la conception, la cration et dploiement des rapports (reporting) sur SSAS ET sur BO ET sur COGNOS ET sur .... Honntement, est ce possible qu'un dveloppeur ait toutes ces comptences ? Les bases de donnes sont complexes, et il faut du temps et du travail pour avoir un niveau de matrise acceptable sur UN SGBD ! Mais est ce que les managers d'puipe, les chefs de projet sont-ils sensibiliss sur l'importance d'une bonne conception des bases de donnes ? Pas sr ... Et cal complique tout ! sur les analyses, sur les dcisions et les actions mener : Notamment la formation ! La formation, car l'ignorance tue !

20/06/2011 @ 22:57

Commentaire de: sqlpro [Membre] http://sqlpro.developpez.com Zinzineti : La formation, car l'ignorance tue ! Hlas tu prche un convertis... J'enseigne dans diffrentes coles d'ing. 32 h de cours sur 5 ans pour faire : 1) la modlisation des donnes 2) le SQL et les transactions 3) le dcisionnel 4) l'admin de SGBDR ! Inutile de te dire que lorsque l'on arrive peu prs faire 1 et 2 je suis content ! A+
21/06/2011 @ 10:30

Vous devez tre identifi pour poster un commentaire.

Responsable bnvole de la rubrique Blogs : - Contacter par email