5.1 Vue d'ensemble de l'optimisation
5 Optimisation de MySQL
Manuel de Référence MySQL 4.1 : Version Française
. Limitations et inconvénients des choix conceptuels de MySQL
->Portabilité
. Pour quoi avons nous utilisé MySQL ?
. La suite de tests MySQL
. Utiliser vos propres tests de performance
|
5.1.2 Portabilité
Comme tous les serveurs SQL implémentent différemment le langage
SQL, cela prend de solides connaissances pour écrire des applications
SQL portables. Pour les insertions et sélections simples, c'est très
simple, mais plus vos besoins se complexifient, plus c'est abscons. Si
vous voulez une application qui fonctionne rapidement sur de nombreuses
bases de données, c'est même encore plus difficile.
Pour rendre une application complexe portable, vous pouvez commencer
par choisir une panoplie de serveurs SQL avec lesquels travailler.
Vous pouvez utiliser le programme/page web de MySQL appelé
crash-me
http://www.mysql.com/information/crash-me.php pour trouver
les fonctions, types et limites que vous pouvez utiliser avec
un panel de serveurs de bases de données. Les tests de
crash-me
ne vérifient pas tout, mais il est déjà
très exhaustif avec plus de 450 points de tests.
Par exemple, vous ne devriez pas avoir de nom de colonne supérieur à
18 caractères, si vous voulez pouvoir utiliser Informix ou DB2.
Les programmes de tests
crash-me
et de performances de MySQL
sont très indépendants du serveur. En regardant comment nous avons
géré ces situations, vous pouvez comprendre comment rendre votre propre
code indépendant du serveur. Les tests de performances sont situés
dans le dossier
sql-bench
de la distribution source de MySQL.
Ils sont écrits en Perl avec l'interface DBI, ce qui résout les problèmes
de connexion.
Voyez http://www.mysql.com/information/benchmarks.php pour
connaître les résultats de ces benchmarks.
Comme vous pouvez le voir avec ces résultats, toutes les bases de données
ont leur point faible. En réalité, elles ont toutes une approche différente
du même problème, et cela conduit à des comportements spécifiques.
Si vous avez besoin de l'indépendance au serveurs de bases de données,
vous devez bien connaître les faiblesses de chaque serveur. MySQL est très
rapide pour lire et modifier les données, mais peine lorsque les lectures
et écritures sont lentes sur la même table. Oracle, d'un autre coté,
a de gros problèmes lorsque vous essayez d'accéder aux données que vous
avez modifié récemment (jusqu'à ce qu'elles soient écrites sur le disque).
Les bases de données transactionnelles en général ne sont pas très douées
pour générer des tables résumés à partir des tables de log, car dans ce
cas, le verrouillage de ligne est inutile.
Pour rendre votre application
reellement
indépendante de la base de données,
vous devez définir un classe très souple à travers laquelle vous allez vous
interfacer pour manipuler vos données. Comme le langage
C++ est disponible sur la plupart des systèmes, cela rend les classes C++
très pratiques pour cette tâche.
Si vous utilisez une fonctionnalité spécifique d'une base de données
(comme la commande
REPLACE
de MySQL), il vous faut aussi coder
la même commande pour les autres serveurs (qui sera alors plus lente).
Avec MySQL, vous pouvez aussi utiliser la syntaxe
/*! */
pour utiliser des mots clés spécifiques de MySQL dans une requête.
Le code entre
/* */
sera alors traité comme un commentaire et
ignoré par la plupart des autres serveurs SQL.
Si les hautes performances sont plus importantes que l'exactitude, comme
pour les applications web, il est possible de créer une
couche application qui met en cache les résultats et vous donne de
meilleures performances. En laissant les anciens résultats se périmer,
vous pouvez garder un cache à jour. Cela vous donne une méthode pour
gérer les grandes charges, durant lesquelles vous pouvez augmenter
la taille du cache, et augmenter la durée de vie.
Dans ce cas, les informations de création de tables doivent contenir les
informations de taille initiale du cache, et la fréquence de rafraîchissement
des tables.
|
