News MYSQL

Ecrire un commentaire
Coup sur coup, les versions de MySQL sont devenues plus compliquées. En fait, les moteurs de tables disponibles pour MySQL ont maintenant leur vie propre indépendante de MySQL (le serveur lui-même).

Reprenons :
- Oracle/InnoDB est livré indépendamment de MySQL depuis Avril
- Falcon est basé sur MySQL 6.0 (pas sur la 5.1)
- Maria est basé sur MySQL 5.1 (pas sur la 6.0)
- MySQL Cluster a une version indépendante (lui-même est en version 6.2)
- Les tables fédérées ont disparu de la 5.1.24 (mais reviendront en 5.1.25)

Je comprend le besoin de pouvoir faire évoluer deux projets comme le serveur MySQL et ses moteurs de tables indépendamment. Mais il faut reconnaître qu'il va être plus difficile de constituer son serveur MySQL maintenant, vu qu'il faut préciser la version de MySQL et celle des tables.

La présence d'un moteur dans la distribution de base est primordiale pour son utilisation maximale : il ne reste que MyISAM et le blackhole, en attendant que Falcon et Maria soient suffisamment mûrs. Et tous les autres moteurs qui sortent ici et là, resteront très discrets.

- MySQL 6.2 is GA, but 5.1 is RC and 6.0 is alpha
- Bravo Oracle: InnoDB Plugin 1.0 released
Ecrire un commentaire
Note de l'auteur :

Récemment, Ghislain (qui gère les serveurs de nexen) m'a rappelé l'existence de SHOW FULL PROCESSLIST, qui est si pratique pour faire afficher la totalité des requêtes SQL en cours, et non pas les premiers caractères. Quand on veut profiler un serveur, et savoir quelles sont les requêtes qui sont si lentes, c'est vraiment essentiel.

Autrement, je recommande souvent 4 étapes pour profiler une requête SQL :

1) L'exécuter manuellement et voir le temps qu'elle prend dans le client MySQL. C'est souvent par cela qu'on commence, vu qu'il faut bien déboguer fonctionnellement la requête avant de la profiler. A ce stade, si le temps de calcul dépasse 0.00s, c'est mauvais. EXPLAIN arrive alors à la rescousse.

2) Après les tests à l'unité, il faut évaluer le comportement avec beaucoup de données. Généralement, un ordre de magnitude de plus que ce qui est attendu est une bonne marque : vous envisagez 1 million de clients ? Créez donc 10 millions de lignes dans la table, et voyez l'impact.

3) Outre les données, il y a bien sûr l'exécution dynamique qui joue aussi : prenez la requête, la bonne quantité de données, et utilisez mysqlslap (livré en standard), mysql super smack ou même votre propre script PHP. Que se passe-t-il quand cette requête est en concurence avec elle-même ?

4) Enfin, il reste à tester au final dans des conditions de concurrence avec d'autres requêtes. Idéalement, un log de requêtes MySQL permet de rejouer des variétés réalistes de requêtes, et de voir comment l'ensemble se comporte.

Cette approche est la plus complète pour vérifier qu'une requête SQL sera viable dans un système en production. Si la 4eme étape est au niveau du luxe, les deux premières devraient être faciles à inclure dans n'importe quel plan de développement : elles identifient 90% des problèmes les plus courants.

- SHOW PROCESSLIST
- mysqlslap
- MySQL SuperSmack
Ecrire un commentaire
Todd Hoff lance un pavé dans la mare : si vous voulez que votre application tienne des charges phénoménales, il faut abandonner les jointures et dénormaliser. Les jointures représentent la sécurité des données : en évitant les doublons, on peut facilement modifier des informations et avoir un système à jour en permanence. C'est rassurant, mais cela se pait au prix des performances.

En dénormalisant, les jointures disparaissent : on peut constituer des tables qui gère les informations directement, sans se préoccuper qu'une autre table ait besoin des mêmes données ailleurs. La cohérence des données passe alors par les règles métier, et toutes les entrées dans la base doit passer par de la programmation pour pouvoir appliquer ces règles.

Lisez l'article de Todd, et n'oubliez pas d'abandonner toutes vos préjugés de normalisateurs. Sinon, vous allez perdre du temps dans cet article. Il faut reconnaître que faire sauter les jointures et tout partitionner est tellement tentant !

- How I Learned to Stop Worrying and Love Using a Lot of Disk Space to Scale
- How Todd Hoff learned to stop worrying and use lots of disk space to scale
Ecrire un commentaire
Une commande 'RENAME DATABASE' a été introduite en MySQL 5.1.7, puis retirée en 5.1.23, pour des raisons de 'danger'. Vadim s'interroge sur les raisons de ces allers et venues : est-ce pour pouvoir publier la 5.1 GA qu'une fonctionnalité utile (et peut être moins dangereuse que DROP DATABASE) a été retirée ?

C'est un choix à faire pour chaque version : soit on souhaite des fonctionnalités finalisées, en sacrifiant le calendrier, ou bien des versions à l'heure, sans être finies. J'ai la sensation que cela n'arrive pas qu'à MySQL...

- Dangerous command
Ecrire un commentaire
le 19/05/2008 à 23:36
MySQL Replication Manager
MySQL Replication Manager est une interface Web pour surveiller une architecture maître esclave. Elle permet simplement de lancer le maître et l'esclave, de gérer les logs et de surveiller l'état de fonctionnement. Il vous faut bien sûr les droits d'administration.

Ce n'est pas la première tentative pour avoir une interface graphique qui permet de gérer en un coup d'oeil l'état de fonctionnement d'une réplication. Et cela sera certainement utile à beaucoup d'entre nous, à défaut d'être complet ou de permettre la resynchronisation des tables en un clic.

- MySQL Replication Manager screenshot and screencast
- MySQL Replication Manager
- MySQL Replication Manager.pl
Ecrire un commentaire
Choisir l'implémentation de ses index : B-TREE ou HASH, quelles différences ?

Préambule technique à une série de futurs articles, je ne vous en dis pas plus, l'épisode du jour a pour point de départ un moteur de stockage MySQL avec à la clé la possibilité, ou pas, de définir l'implémentation de ses index : B-TREE ou HASH.

Ce choix nest en effet pas toujours disponible, cest même plutôt rare puisque seul le moteur de stockage MEMORY vous permet depuis la version 4.1 de MySQL, deffectuer ce choix. Nous ne parlerons pas ici du MySQL Cluster et de son moteur NDB qui sera abordé spécifiquement dans un autre épisode.

Pourquoi alors se soucier de ce type d'implémentation si seul le moteur MEMORY offre la possibilité de choisir ?

- MyISAM et InnoDB pourraient à l'avenir proposer ce choix.
- Afin de comprendre plus finement comment fonctionnent les index que vous utilisez tous les jours, se pencher sur la façon dont ils sont implémentés permet de mieux appréhender certains résultats.

- Choisir l'implémentation de ses index : B-TREE ou HASH, quelles différences ?
Ecrire un commentaire
le 18/05/2008 à 23:35
Où est passé la communauté MySQL ?
Sheeri Cabral a passé en revue le site Web de MySQL pour y rechercher la documentation : en partant de mysql.com, comment faire pour y arriver? Il faut déjà arriver à faire le tri dans les différentes offres commerciales de MySQL, qui ne citent jamais la base de données. Ensuite, quand on a trouvé la partie développeur, on peut y accéder.

Ce qui est si surprenant, c'est la place que finit par prendre les offres commerciales, qui finit par reléguer la communauté au fond du site. Ce n'est pas la première fois que l'on voit ça sur un site qui a des objectifs professionnels ambitieux : les offres prennent la première place. Cela m'est toujours apparu correct, tant que la communauté conserve sa place. C'est quand on commence à la cacher, que je suis plus inquiet.

- MySQL Website a Reflection of Values
- MySQL
Ecrire un commentaire
le 16/05/2008 à 23:30
Utilisations pratiques des vues
Les vues, qui permettent de déguiser une requête SELECT en une table, n'ont pas besoin d'être complexes pour être utiles : en fait, elles permettent simplement de configurer en permanence une extraction particulière des données dans une table. Par exemple, on peut s'en servir pour :
- Ajouter ou retirer des colonnes
- Formater des colonnes
- Combiner des colonnes
- Limiter les lignes affichées

- Useful ways of using Views
Ecrire un commentaire
Baron Schwartz déclare que MySQL est un logiciel libre, mais pas Open Source. La base de données est libre grâce à sa licence GNU GPL, sans ambiguïté. Pour l'Open Source, c'est un constat : il n'est pas possible de contribuer à MySQL facilement, et le modèle de développement est fermé. Pas moyen d'envoyer un patch sans signer une lettre de Contributor Licence Agreement, qui donne la propriété du code à MySQL/SUN, et même quand c'est le cas, les patchs sont très longs à être acceptés.

La taille de l'entreprise et les enjeux exigent des protections supplémentaires du code source : il n'est certainement pas possible de gérer un projet de 15 ans comme un qui vient de démarrer. Mais il est dommage de constater que les contributions deviennent effectivement de plus en plus difficiles.

- MySQL: Free Software but not Open Source
- MySQL Contributor License Agreement v0.3
Ecrire un commentaire
le 14/05/2008 à 22:05
Effacement avec jointure et limite
MySQL permet de faire des effacements multi-tables : un effacement à jointure, si vous voulez. Mais cette fonctionnalité si pratique ne supporte pas la clause LIMIT, que JOIN et DELETE supportent séparément.
Justin Swanhart vous propose alors une solution de remplacement, basée sur des variables de session.

- Using a DELETE w/ a JOIN and LIMITing the number of rows deleted.
LoadingChargement en cours