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.3 Pour quoi avons nous utilisé MySQL ?
Pendant le développement initial de MySQL, les fonctions de MySQL ont
été créées pour convenir à un maximum de clients. Celles ci supporte
des entrepôts de données pour deux des plus gros revendeurs suédois.
Nous recevons chaque semaine le résumé de toutes les transactions par
carte de toutes les boutiques, et nous sommes chargés de fournir des
informations utiles aux gérants des boutiques pour les aider à
comprendre comment leurs propres campagnes publicitaires touchent leurs
clients.
Les données sont assez énormes (près de 7 millions de résumés de transactions
par mois), et nous avec les données de 4-10 ans que nous présentons aux
utilisateurs. Nous avons chaque semaine des requêtes des clients qui
veulent un accès 'instantané' aux nouveaux rapports sur ces données.
Nous avons réussi en stockant toutes les informations dans des tables de
'transactions' compressées. Nous avons une série de macros (scripts) qui
génère des tables de résumés groupés par différents critères (groupe de
produits, identifiant de client, boutique ...). ces rapports sont des pages
web générées dynamiquement par un petit script Perl qui parcours une page
web, exécute les requêtes SQL, et insère les résultats. Nous aurions bien
utilisé PHP ou mod_perl à la place, mais ils n'étaient pas disponibles à
cette époque.
Nous avons écrit un outil en
C
pour la représentation graphique des
données qui génère des GIFs à partir du résultat de requêtes SQL (avec
quelques traitements sur le résultat). Ceci est également effectué
dynamiquement par le script Perl qui parcourt les fichiers
HTML
.
Pour la plupart des cas, un nouveau rapport peut simplement être fait en
copiant un script existant, et en modifiant la requête SQL qu'il exécute.
Dans certains cas, nous aurons besoin d'ajouter des champs à une table de
résumé existante ou d'en générer une nouvelle, mais c'est tout de même
toujours assez simple, car nous gardons toutes les tables de transactions
sur disque. (Actuellement, nous avons au moins 50 Go de tables de transactions
et 200 Go d'autres données sur les clients.)
Nous donnons également accès aux tables de résumés à nos clients directement
avec ODBC, de sorte que les utilisateurs avancés puissent traiter les données
eux-mêmes .
Nous n'avons eu aucun problème à supporter tout cela avec une relativement
modeste Sun Ultra SPARCStation (2x200 MHz). Nous avons récemment amélioré l'un
de nos serveurs en un bi-CPU 400 MHz UltraSPARC, et nous projetons actuellement
de supporter les transactions au niveau du produit, ce qui signifie un décuplement
des données. Nous pensons pouvoir y arriver uniquement en ajoutant des disques
supplémentaires à nos systèmes.
Nous expérimentons aussi Intel-Linux, pour pouvoir avoir plus de puissance CPU
pour moins cher. Comme nous utilisons désormais le format binaire portable pour
les bases de données (nouveauté de la version 3.23), nous utiliserons cela pour
quelques parties de l'application.
Nous avons au départ le sentiment que Linux s'acquitera mieux des faibles et
moyennes charges tandis que Solaris fonctionnera mieux sur les grosses charges
à cause des I/O disques extrêmes, mais nous n'avons actuellement aucune conclusion
à ce propos. Après quelques discussion avec un développeur du noyau Linux,
un effet de bord de Linux pourrait tant de ressources aux travaux de traitement
que les performances de l'interface interactive peut devenir vraiment lente.
Cela fait apparaître la machine très lente et sans réponse lorsque de gros
traitements sont en cours. Heureusement, cela sera mieux géré dans les futurs
noyaux de Linux.
|