Mar/093
Les tables temporaires
J’oublie parfois à quel point les tables temporaires peuvent être pratiques. On tente de sortir des rapports avec des tables qui ne sont pas prévues pour ça. On écrit des requêtes inimaginables et souvent très lentes. Résultat: on perd notre temps.
La solution: les tables temporaires ! Ce n’est pas très coûteux et drôlement pratique. Au lieu de prendre 25 minutes à écrire “une” requête qui prend un temps énorme à s’exécuter, prenez 10 minutes pour écrire 2-3 requêtes simples qui utilisent des tables temporaires et sortez le même résultat en quelques secondes!
Et si c’est efficace, performant (surtout performant) et récurrent, pourquoi ne pas transformer ces tables temporaires en view ?
Dec/083
Ça fait quoi un DBA ?!
Parfois, et surtout durant les fêtes, on me demande ce que je fais dans la vie. Je suis DBA, ou Administrateur de Base de Données. 95% des gens à qui je réponds ne savent pas ce que je fais. Alors, j’explique qu’est-ce qu’une base de données et le type d’application propice à en utiliser, et j’opte pour les exemples:
- Je m’assure que la BD est performance
- Je m’assure de l’intégrité des données
- Je m’assure qu’il n’y aura pas de downtime
- Je m’assure des backups
Beaucoup de gens ne comprennent toujours pas ce que je fais, mais bon, tant pis je vais pas leur donner un cours.
Tout ça me fait réfléchir sur ce que font concrètement les gens qui ont un emploi comme moi. Les 4 points que je donne en exemple ne sont souvent pas suffisants pour occuper un employé à temps plein, à 40h par semaine.
Pour ma part, mon background de développeur me permet de participer activement à l’analyse de nouveaux projets qui utiliseront une base de données. De plus, je m’occupe de la performance de notre application, car même avec un serveur MySQL dédié ultra performant, les performances peuvent être décevantes si l’application ne communique pas adéquatement avec la BD.
Au-delà du boulot quotidien, j’essaye de me tenir à jour sur tous les nouveaux features de MySQL et les nouvelles technologies en lien avec les bases de données. J’anticipe l’utilisation des features de 5.1 et 6.0 sans négliger la possibilité d’utiliser autre chose que MySQL, comme Drizzle ou PostgreSQL ou encore utiliser les nouveaux storage engines comme XtraDB de Percona.
Je vous pose donc la question: quelles sont vos tâches quotidiennes en tant qu’expert en technologie de l’information ?
Nov/088
64bit VS 32bit
Je croyais jusqu’à tout récemment que la majorité des serveurs étaient tous en 64bit. La presque totalité des nouveaux hardware supportent le 64bit alors pourquoi installer un OS 32bit sur une machine 64bit ? Pour moi la question ne se posait même pas tellement la réponse me semblait évidente. Hé bien j’étais loin de la réalité.
En 5 mois, j’ai été témoin de 4 personnes (amis et connaissance d’IRC) ayant installé un OS 32 bit sur des machines 64bit. On pourrait croire que ce n’est pas tellement grave, puisque de toute façon il y a peu d’application développée spécifiquement pour les 64bit, et s’ils le sont, le gain de performance est à peu près imperceptible. C’est faux, complètement faux.
Il faut être très vigilant dans le choix de l’OS qu’on installe, surtout sur une machine qui sera dédiée à MySQL. Je vais vous expliquer pourquoi avec 2 exemples.
Cas #1.
MySQL roule sur un OS 32 bits depuis déjà longtemps. Tout fonctionne à merveille, mais la charge de travail a augmenté considérablement depuis la mise en ligne, à un point où il devient nécessaire d’augmenter la RAM pour conserver une performance acceptable. C’est une décision importante, car cette modification demandera un downtime de quelques minutes, et forcement il y a quelqu’un qui perd de l’argent lorsque le serveur ne fonctionne plus. La mémoire vive est très abordable maintenant et l’équipe décide d’upgrader à 8Go de RAM.
Plusieurs d’entre vous ont probablement déjà identifié le problème. Les OS 32bit ne supportent pas plus de 4Go de RAM, théoriquement. En pratique, on plafonne souvent à 3.5Go et comme l’OS utilise de la mémoire, MySQL lui sera capable d’utiliser au mieux ~2.5Go de RAM. Les performances sont loin des résultats escomptés. De plus, pour corriger le problème, il faudra installer un OS 64bit, ce qui entraînera un second downtime plus long que le premier.
Cas #2.
Un Master roule sur un OS 32 bits, mais la machine (qui supporte le 64bit) se fait vieille et de moins en moins performante. Nous avons aussi un Slave utilisé pour les backups dans les mêmes conditions. L’équipe décide donc d’acheter une nouvelle machine très performante, avec plusieurs CPU, plusieurs Go de RAM et des disques très rapides. Évidemment on installe un OS 64bit sur la bête, car nous avons beaucoup plus que 4Go de RAM. Le plan de match est de mettre la nouvelle machine Slave de l’actuel Master, et d’inverser les rôles au moment opportun. C’est une opération qui se fait très rapidement pour minimiser le downtime. Tout se passe à merveille, le changement de serveur est un succès.
Il y a cependant un détail qui a été négligé dans cette opération. Le Master est une machine 64bit alors que les 2 slaves sont demeurés 32bit. Il n’y a rien d’incorrect dans ce procédé, mais là où ça bug, c’est qu’on fait des copies binaires des données sur un des Slave en guise de backup. S’il s’avère nécessairement d’utiliser ces backups sur le Master, il y a de fortes chances que des données soient perdues à cause des floating points.
Je n’ai pas l’infrastructure et le temps nécessaire pour effectuer mes propres tests de performance pour mesurer le réel impact d’un 32bit vs 64bit. Plusieurs personnes de renom affirment qu’il y a un avantage non-négligeable pour les applications demandant beaucoup de CPU et mémoire, comme MySQL. C’est une opinion que j’ai tendance à croire étant donné la multitude d’articles qui l’appuie. La principale raison pour utiliser un os 64 demeure la possibilité d’avoir plus de 4Go de RAM, mais s’il n’y a pas de désavantage à utiliser un 64bit, pourquoi s’en priver ?
Sep/082
Performance avec les procédures stockées
Les procédures stockées ont fait leur apparition avec MySQL 5.0. Une procédure stockée est un ensemble de plusieurs requêtes basées sur le standard sql:2003, regroupées ensemble et stockées dans la base de données. On leur attribut plusieurs avantages, notamment:
- Elles réduisent le trafic réseau: on peut exécuter plusieurs requêtes avec un seul échange entre le client et le serveur.
- Elles offrent un contrôle de sécurité: un user peut exécuter une procédure qui fait des requêtes sur une ou des tables auxquelles il n’a pas accès. Ces requêtes peuvent être en lecture ou en écriture.
- Elles assurent le respect de logiques particulières ou d’intégrité.
J’avais un cas où une application devait faire très régulièrement (jusqu’à plusieurs fois par secondes) les 4 mêmes requêtes: SELECT.. UPDATE.. SELECT.. UPDATE. En déplaçant ces 4 requêtes dans une procédure stockée, j’ai sauvé 3 échanges entre le client et le serveur, quelques boucles dans le code et l’instanciation de quelques objets PHP. Au total, le même processus est devenu 46% plus rapide.
L’utilisation de procédure n’est pas sans risque. En effet, la souplesse de MySQL peut rendre la création et l’exécution d’une procédure valide, alors qu’elle ne le devrait pas. C’est pourquoi il est recommandé de créer la procédure en strict mode. Ainsi, vous serez averti si une de vos opérations repose sur un comportement variable.
Il y a plusieurs niveaux de sécurité reliés aux procédures. Tout d’abord, MySQL 5.0 possède de nouveaux privilèges permettant à un utilisateur de:
- Créer des routines*
- Modifier des routines
- Exécuter des routines
*Les procédures stockées, les fonctions et les “triggers” sont inclus dans la définition d’une routine.
Il est généralement déconseillé de permettre aux utilisateurs de créer ou modifier des routines. Puisqu’elles sont exécutées sur le serveur, il est possible de faire planter tout le système si un utilisateur crée accidentellement une boucle infinie. Ces privilèges devraient être réservés à un DBA ou à un utilisateur expérimenté en qui vous avez confiance.
De plus, l’exécution d’une procédure doit obéir aux privilèges du definer ou de l’invoker. Lors de sa création, il est possible d’indiquer si l’exécution de chaque statement doit respecter les privilèges du créateur ou de l’exécuteur. Le défaut est definer, ce qui peut être potentiellement dangereux si la procédure est créée en étant root. À l’inverse, ça peut être très pratique pour permettre de lire ou écrire de manière restreinte dans une table dans laquelle un utilisateur n’a pas forcement accès.
Les procédures possèdent un tas d’avantages: rapidité, sécurité et consistance. On peut même les utiliser pour réduire des erreurs liées aux transactions (locktimeout, deadlock, etc..) et prévenir les injections SQL. Elles possèdent cependant des désavantages: les requêtes exécutées ne peuvent être cachées. Puisqu’elle sont préalablement parsées et stockées sur le serveur, il n’est pas possible de faire appel au mécanisme de caching lors de leur exécution. C’est un aspect à considérer lors d’optimisation d’un processus.
En conclusion, lorsqu’elles sont correctement utilisées, les procédures stockées peuvent ajouter beaucoup de rapidité à un processus. Plusieurs programmeurs qui n’ont jamais utilisé d’autre SGBD que MySQL ne sont peut-être pas familliers avec les procédures. Je recommande à tous de prendre un instant pour y jeter un coup d’oeil !