News MYSQL

Lorsque certaines requêtes SQL ont de trop gros résultats, dépassant la taille de tmp_table_size, MySQL ouvre automatiquement une table temporaire sur le disque pour y stocker les données. C'est transparent pour l'utilisateur, hormis pour les performances : une table sur le disque est beaucoup plus lente qu'en mémoire.

Peter Zaitsev compare alors une table temporaire sur le disque et en mémoire : la différence est un gain de l'ordre de 100 fois.

Pour tirer partie des tables temporaires en mémoire, il faut régler deux variables : max_heap_table_size, qui indique la quantité de mémoire réservée aux opérations en mémoire pour MySQL, et tmp_table_size, qui mesure la taille maximale d'une table temporaire en mémoire avant de la passer sur le disque.

Au passage, deux trucs intéressants à noter :

SELECT * FROM table GROUP BY col ORDER BY NULL;

Group by a la facheuse habitude de trier les résultats : avec order by NULL, on peut forcer GROUP BY a ne pas trier, ce qui fait gagner beaucoup de temps selon Peter.

Quand on modifie une variable globale, la connexion courante n'est pas affectée. Seule les nouvelles connexions sont affectées...

- How much overhead is caused by on disk temporary tables
Le sharding est une pièce d'architecture à la mode pour MySQL. Le concept est de base est un couple de serveurs MySQL en réplication réciproque (chacun est le maître et l'esclave de l'autre). Cette simple configuration permet d'atteindre plusieurs buts :

Haute disponibilité : chaque machine peut servir de backup immédiat à l'autre
Plus de performances : les deux machines travaillent, au lieu d'en avoir une qui attend que l'autre tombe pour prendre le relais.
Plus d'écriture : les écritures sont réparties sur deux maîtres

Flickr a porté le concept plus loin en appliquant un système de partitionnement : les données sont découpées en plusieurs partitions, et chaque partition va sur un shard. Un dernier shard sert alors à diriger les requêtes vers les bons shards.

- An Unorthodox Approach to Database Design : The Coming of the Shard
- Scaling PHP/MySQL...Presentation from Flickr
le 15/08/2007 à 23:46
Truc de réplication MySQL
La partie difficile dans une réplication est l'initialisation des données sur l'esclave. La récupération des données, qu'elle se fasse via le système ou bien directment en commande MySQL, impose un lourd travail d'exportation au maître.

Keith Murphy vous propose une astuce, pour ajouter un second esclave à un maître : utilisez le second esclave pour prendre les données ET le point de réplication. Une fois les données lues sur cet esclave, reportez le nouvel esclave sur le maître, avec le point de réplication obtenu de l'autre esclave.

Lisez le billet pour connaître toutes les commandes.

- Replication Trick
Parfois, il manque vraiment une structure de boucle en SQL. On aimerait bien pouvoir exécuter plusieurs fois la même requête, avec des changements incrémentaux sans avoir à passer par un éditeur ou un script PHP.

C'est maintenant possible avec le proxy MySQL : le proxy dispose d'un langage de programmation, qui permet d'exécuter des scripts. Guiseppe Maxia a trouvé comment utiliser ces boucles pour des boucles numériques et même des boucles associatives.

- Boost your SQL with Proxy loops
- MySQL Proxy forge
le 14/08/2007 à 00:15
La vie va changer avec MySQL 5.1
MySQL 5.1 devrait bientôt remplacer la version 5.0 comme version stable.
Qu'est-ce que cette nouvelle version va apporter aux utilisateurs ? Guiseppe Maxia nous rappelle les points forts :
- Partitions
- Réplication à la ligne
- Tables de log à la demande
- Programmeur d'événements
- Fonctions XML

- How MySQL 5.1 is going to change your life
- Download MySQL 5.1
- Improving Database Performance with Partitioning
- Chapter 17. Partitioning
Kaj Arnö annonce par le biais de son blogue, un changement important dans la politique de publication du code source 'Entreprise' de MySQL.

Les nouvelles fonctionnalités sont désormais envoyées directement dans les nouvelles versions. MySQL s'engage à faire au moins 2 mises à jour de la version de production (dite GA) par an, en fonction des alertes de sécurité qui seront identifiées.

Les versions MySQL seront mises à jour tous les mois jusqu'à ce que la compagnie décide que cette version est mature : dans ce cas, le rythme de mise à jour baissera considérablement.

Les sources de la version Entreprise ne sont plus publiées.

Dans l'ensemble, le processus de publication se clarifie, ce qui est bon : les versions très stables n'ont plus que des corrections de bogues et sécurité. Les nouvelles fonctionnalités sont repoussées à la version de développement, et les versions de productions initiales, qui auront la plus forte charge de tests, seront mises à jour mensuellement.

Deux points plus sensibles sont à relever. Les sources de la version Entreprise sont retirées. Cela ne fait qu'ajouter un obstacle sur la rue, puisque la GPL permet à n'importe quel client de publier ce code librement. Le code était déjà bien caché dans le ftp de MySQL, mais il est encore plus loin maintenant.

Les nouvelles fonctionnalités et contributions de la communauté sont repoussées à la versions de développement actuelle. Nous sommes rendus à la version 5.0 en GA, et la version 5.1 (qui arrive sous peu), est en béta : en fait, les nouvelles contributions sont repoussées à la version 5.2/6.0, et n'apparaîtront pas avant ... longtemps. Très longtemps.

La communauté des contributeurs au code réagit fortement à ces annonces. Peter Zaitsev indique qu'il a un patch de micro-secondes pour les slow query qui attend encore, alors que Jeremy Cole a recu un traitement de faveur pour son SHOW profile. Tous ces contributeurs ayant pignon sur rue, montent au créneau pour défendre leur travail.

En regardant de plus loin, il semble que la communauté soit incitée à travailler sur les versions récentes uniquement. Plus la version du serveur est stable (beta, GA, mature GA), plus les versions sont rares. Les versions payantes sont ainsi réservées à ceux qui ne connaissent pas bien MySQL : ce sont eux qui iront chercher les mature GA ou les versions entreprise, pour se prémunir d'un bug possible.

La communauté ne paie pas cher, mais court les risques. Les clients paient peu cher, mais s'assure contre les bogues. Est-ce un modèle viable pour votre entreprise ?

Avec un rythme de mise à jour annuel des serveurs (qui donc utilise encore une version 4 ?), cette nouvelle politique devrait avoir un faible impact sur une installation en production. Les nouvelles fonctionnalités seront reportées à l'année d'après, et il ne reste que le cas des bogues teigneux à corriger : avoir besoin d'une correction spécifique va devenir compliqué, ou cher, ou les deux.

Enfin, la disparition des codes sources entreprise sont surtout des sujets politiques : tant qu'on est pas impacté par un bogue, on va facilement en sauter quelques versions. Mais c'est dommage de voir ce point mis tout à la fin, et publié en pleines vacances : on dirait une vieille manipulation politique ou commerciale, alors que ça n'en est pas.

- Communication Challenges for the MySQL Community Team
- Refining MySQL Community Server
- MySQL Takes Another Step (Away from Open Source)
- On MySQLs Commitment to Open Source
- Refining MySQL Community Server
- Refining MySQL Community Server (2)
- DorsalSource
- MySQL Community split officially a failure
- New MySQL Community Release Policies published
- The Importance of Being Earnest
- Tension Grows Between MySQL AB and the Open Source Community
le 08/08/2007 à 21:07
Webinar Cluster MySQL
Note de l'auteur :

Durant ce webinar, nous apprendrons les concepts fondamentaux pour concevoir et sélectionner les bons composants pour réussir un Cluster MySQL et son évaluation.
Nous allons analyser le matériel, le réseau et les pré-requis logiciels.
Nous travaillerons à partir d'une installation de base, pour réaliser des tests fonctionnels.
Finalement, nous terminerons les récents résultats de tests de performances réalisés avec Intel et Dolphin Interconnect Solutions.

Il y a deux sessions : la première le 8 Aout, à 19h00, heure de Paris, et la seconde le 15 Aout, à 15h00, heure de Paris.

- MySQL Cluster Webinar & Evaluation Guide
- Designing, Evaluating and Benchmarking MySQL Cluster
le 07/08/2007 à 23:24
XML dans MySQL : exports
MySQL disposent de fonctions destinées à manipuler du contenu XML directement dans la base, comme les fonctions ExtractValue et UpdateXML, pour rechercher et modifier une structure XML.

Pour la production de code XML, il n'y a rien de prévu, mais un coup de procédure stockée vous donnera quelques outils bien pratiques. Erik Wetterberg vous en parle plus.

- XML output from MySql
- More on XML output from MySql
- XML Functions
David Axmark a fondé MySQL AB avec Michael "Monty" Widenius et Allan Larsson en 1995.

Aujourd'hui, c'est un membre de l'équipe de relations avec la communauté, et il a un rôle de conseil dans l'équipe de direction de MySQL.
Il voyage à travers tout le monde pour faire la promotion de MySQL et des logiciels Open Source en général. Il a récemment déménagé de Uppsala, Suède vers Ascot, Royaume-Uni, où il vit avec sa femme et ses deux enfants.

- From Visions to Reality - an interview with David Axmark, Co-Founder of MySQL AB
Peter Zaitsev publie sa présentation OSCON 2007 sur l'état actuel et les performances des moteurs transactionnels de MySQL : Innodb, Falcon, PBXT et SolidDB.

On y trouve une comparaison des avantages et inconvénients de chaque moteur : InnoDB gagne haut la main, avec la meilleure maturité (les autres ont tous un an ou presque), même est développé à un rythme assez lent. Il y aussi des graphiques de performances.

Au bout du compte, même si tous les 4 moteurs sont annoncés, 3 sont quasiment inutilisés en production.

- Landscape of Transactional Storage Engines
- Landscape of Transactional Storage Engines for MySQL
LoadingChargement en cours