Comparaison des fonctionnalit´es de MySQL

Sur la page crash-me (http://www.mysql.com/information/crash-me.php) vous pouvez trouver une liste des avantages et limitations que l’on peut d´etecter avec un programme. Notez bien que de nombreuses ´evaluations num´eriques peuvent ˆetre modifi´ees avec les op- tions de d´emarrage des diff´erentes bases de donn´ees. Cette page web est extrˆemement pra- tique si vous voulez vous assurer que votre application fonctionnera sur diff´erents serveurs SQL, ou si vous voulez convertir votre application d’un serveur `a l’autre.

MySQL offre les avantages suivants sur PostgreSQL:

• MySQL est g´en´eralement plus rapide que PostgreSQL. MySQL 4.0.1 a aussi un cache de

requˆetes qui peut acc´el´erer les requˆetes pour les lectures de tables les plus fr´equentes.

• MySQL a une base d’utilisateurs bien plus grande que PostgreSQL. Par cons´equent, le

code est test´e dans de meilleures conditions, et il a ´et´e historiquement plus stable que PostgreSQL. MySQL est utilis´e plus souvent en environnement de production que Post- greSQL, notamment grˆace au fait que MySQL AB, ex TCX DataKonsult AB, a fourni un support commercial de haute qualit´e pour le serveur MySQL depuis la premi`ere publication, tandis que, jusqu’`a r´ecemment, PostgreSQL n’avait pas de support.

• MySQL fonctionne bien mieux sur Windows que PostgreSQL. MySQL fonctionne

comme une application Windows native (un service sur NT/2000/XP), tandis que PostgreSQL fonctionne en mode ´emulation de Cygwin. Nous avons entendu dire que PostgreSQL n’est pas encore stable sous Windows mais non n’avons pas ´et´e capable de le v´erifier nous-mˆemes.

• MySQL a plus d’API avec d’autres langages, et est support´e par un plus grand nombre

de programmes que PostgreSQL. Voir Annexe B [Contrib], page 711.

• MySQL fonctionne avec les syst`emes critiques, `a forte charge, 24h/24 et 7j/7. Dans la

plupart des cas, nous n’avons jamais `a effectuer d’entretien de MySQL. PostgreSQL ne supporte par encore les syst`emes 24h/24 et 7j/7, car il faut ex´ecuter VACUUM une fois de temps en temps pour r´ecup´erer l’espace vide issu des commandes UPDATE et DELETE, et pour faire des analyses statistiques qui sont primordiales pour obtenir de bonnes performances avec PostgreSQL. VACUUM est aussi n´ecessaire apr`es avoir ajout´e un grand nombre de lignes dans une table. Sur un syst`eme tr`es occup´e avec de nombreuses modifications, VACUUM doit ˆetre ex´ecut´e tr`es fr´equemment, et parfois, plusieurs fois dans la journ´ee. Durant l’ex´ecution de VACUUM, qui peut prendre plusieurs heures si la base de donn´ees est importante, le serveur est, d’un point de vue production, quasiment mort. Notez qu’avec PostgreSQL version 7.2, l’entretien simple des tables ne n´ecessite plus le verrouillage des tables, et le niveau d’utilisation est alors `a peu pr`es normal. Une

nouvelle commande VACUUM FULL effectue les entretiens traditionnels en verrouillant la table, et en r´eduisant sa taille sur le disque.

• Le syst`eme de r´eplication de MySQL a ´et´e test´e soigneusement, et il est utilis´e sur des

sites comme :

− Yahoo Finance (http://finance.yahoo.com/) − Mobile.de (http://www.mobile.de/)

− Slashdot (http://www.slashdot.org/)

• Dans les deux distributions de MySQL, vous trouverez des suites de tests,

‘mysql-test-run’ et crash-me (http://www.mysql.com/information/crash-me.php), ainsi que la suite de performances. Le syst`eme de tests est souvent modifi´e avec des nouveaux tests pour les nouvelles fonctionnalit´es, ainsi que les bogues qui nous sont rapport´es. Nous testons chacune de nos versions sur un grand nombre de plate-formes. Ces tests sont plus sophistiqu´es que tout ce que nous avons pu voir chez PostgreSQL, et il nous assurent que le serveur MySQL reste de bonne qualit´e.

• Il y a bien plus de livres concernant MySQL que PostgreSQL. O’Reilly, SAMS, Que et-

New Riders sont des ´editeurs importants, avec des livres traitant de MySQL. Toutes les fonctionnalit´es de MySQL sont aussi document´ees sur le manuel en ligne, car lorsqu’une nouvelle fonctionnalit´e est impl´ement´ee, les d´eveloppeurs MySQL doivent la docu- menter avant qu’elle soit inclue dans le source.

• MySQL support plus de fonctions ODBC que PostgreSQL. • MySQL a une commande ALTER TABLE beaucoup plus puissante.

• MySQL supporte les tables sans transaction pour les applications qui ont besoin de

plus de vitesse. Les tables peuvent ˆetre plac´ees en m´emoire, comme les tables HEAP, ou bien sur le disque, comme les tables MyISAM. Voir Chapitre 7 [Table types], page 531.

• MySQL supporte deux types de gestionnaires de tables, qui supportent les transactions :

InnoDB et BerkeleyDB. Comme chaque moteur de transactions travaille dans diff´erentes conditions, cela donne plus de possibilit´es aux auteurs d’applications pour choisir leur solution optimale pour la configuration du serveur, au besoin table par table. Voir Chapitre 7 [Table types], page 531.

• Les tables group´ees MERGE vous donnent un moyen d’acc´eder instantan´ement a plusieurs

tables de mˆeme structure, et de les utiliser ensemble, comme une seule. C’est le moyen parfait lorsque vous avez des tables de logs trop grosses, et que vous les s´eparez par mois. Voir Section 7.2 [MERGE], page 539.

• La possibilit´e de compresser les tables en lecture seule, mais tout en ayant un acc`es

direct aux lignes de la table, vous donnent plus de performance en lecture, en r´eduisant la taille des donn´ees lues sur le disque. C’est tr`es pratique pour les archives. Voir Section 4.7.4 [myisampack], page 297.

• MySQL poss`ede le support d’outils de recherche en texte plein. Voir Section 6.8 [Full-

text Search], page 522.

• Vous pouvez acc´eder `a de nombreuses bases de donn´ees avec la mˆeme connexion, du

moment que vous avez les droits pour le faire.

• MySQL est cod´e depuis le d´ebut pour ˆetre multi-thread´e, tandis que PostgreSQL utilise

les processus. Le temps de changement de contexte et d’acc`es aux zones de stockage est bien plus court avec des threads qu’entre des processus s´epar´es. Cela donne un

avantage de vitesse `a MySQL dans les applications multi-utilisateurs, et aussi avec les syst`emes `a plusieurs processeurs sym´etriques.

• MySQL a un syst`eme de droits bien plus avanc´e que PostgreSQL. Alors que PostgreSQL

ne supporte que des droits pour les commandes INSERT, SELECT et UPDATE/DELETE au niveau de l’utilisateur pour une base ou une table, MySQL vous permet de d´efinir un jeu de droits complet pour une base, une table ou une colonne. MySQL vous permet aussi de sp´ecifier des droits par hˆote ou utilisateur. Voir Section 4.3.1 [GRANT], page 226.

• MySQL supporte un protocole client/serveur compress´e qui am´eliore grandement les

performances sur les connexions lentes.

• MySQL applique le concept des “gestionnaires de table”, et est la seule base de donn´ees

relationnelle que nous connaissons qui utilise ce concept. Cela permet diff´erents types de tables depuis le moteur SQL, et chaque table peut ˆetre optimis´ee pour diff´erentes performances.

• Tous les types de tables MySQL (except´e InnoDB) sont impl´ement´es avec des fichiers

(une table par fichier), ce qui rend tr`es souple les sauvegardes, les d´eplacements et les effacements, ou mˆeme l’utilisation des liens symboliques pour les tables et les bases, mˆeme lorsque le serveur est ´eteint.

• Les outils pour r´eparer et optimiser les tables MyISAM (le type de tables MySQL le plus

courant). Un outil de r´eparation n’est n´ecessaire que pour les corruptions physiques dans un fichier de donn´ees, et g´en´eralement, pour corriger une d´efaillance du mat´eriel. Elle permet `a la majorit´e des donn´ees d’ˆetre r´ecup´er´ees.

• Changer de version de MySQL est tr`es simple. Lorsque vous changer de version de

MySQL, vous n’avez pas `a exporter et r´eimporter vos donn´ees, comme vous devez le faire avec PostgreSQL.

Les inconv´enients de MySQL face `a PostgreSQL:

• Le support des transactions de MySQL n’est pas aussi bien test´e que celui de Post-

greSQL.

• Comme le serveur MySQL utilise les threads, qui ne sont pas encore parfaitement

rod´es sur tous les syst`emes d’exploitation, il faut alors utiliser les ex´ecutables binaires de http://www.mysql.com/downloads/, ou bien lire avec beaucoup de soin les instruc- tions dans la section Section 2.3 [Installing source], page 84 pour obtenir un ex´ecutable qui fonctionne de mani`ere optimale.

• Le verrouillage de table, tel qu’utilis´e par les tables non transactionnelles MyISAM, est

dans de nombreux cas plus rapide que les verrous de page, de ligne ou le versionnage. L’inconv´enient est que si l’on ne prend pas garde au fonctionnement du verrouillage de table, une requˆete seule, `a longue dur´ee d’ex´ecution peut bloquer la table en ´ecriture pour un long moment. Cela peut ˆetre ´evit´e en concevant correctement l’application. Sinon, on peut toujours changer le gestionnaire de la table pour un mod`ele transac- tionnel. Voir Section 5.3.2 [Table locking], page 381.

• Avec UDF (user-defined functions, fonction d´efinies par les utilisateurs), il est possible

de faire ´evoluer les fonctions du serveur MySQL aussi bien pour les fonctions SQL normales que pour les fonctions d’agr´egation, mais ce syst`eme n’est pas aussi pratique que pour PostgreSQL. Voir Section 9.2 [Adding functions], page 672.

• Les modifications qui s’effectuent sur plusieurs tables sont bien plus difficiles `a faire

multi-tables, et en MySQL version 4.1, avec les sous-s´elections. En MySQL version 4.0, on peut utiliser les effacements multi-tables pour effacer plusieurs lignes dans diff´erentes tables simultan´ement. Voir Section 6.4.6 [DELETE], page 494.

PostgreSQL offre actuellement les avantages suivants sur MySQL :

Notez que comme nous connaissons le plan de d´eveloppement de MySQL, nous avons in- clus la table suivante, avec les version du serveur MySQL o`u les fonctionnalit´es seront support´ees. Malheureusement, nous ne pouvions pas faire les mˆemes comparaisons avec les fonctionnalit´es `a venir de PostgreSQL, car nous ne connaissons pas le plan de d´eveloppement de PostgreSQL.

Fonctionnalit´e version de MySQL

Sous-s´elections 4.1

Cl´e ´etrang`eres 5.0 (3.23 avec InnoDB)

Vues 5.0 Proc´edures stock´ees 5.0 Triggers 5.0 Unions 4.0 Jointures totales 4.1 Contraintes 4.1 ou 5.0 Curseurs 4.1 ou 5.0

R-trees 4.1 (pour les tables

MyISAM) Tables h´erit´ees Non pr´evu Type de donn´ees extensible Non pr´evu Autres raisons de consid´erer PostgreSQL :

• L’utilisation standard de PostgreSQL est parfois plus proche de la norme ANSI SQL. • Il est possible d’acc´el´erer les traitements de PostgreSQL en codant des proc´edures

stock´ees.

• Pour les donn´ees g´eographiques, les R-trees font de PostgreSQL un meilleur choix que

MySQL. (note : MySQL version 4.1 dispose des R-trees pour les tables MyISAM).

• L’optimiseur PostgreSQL fait des optimisations que l’optimiseur de MySQL ne peut

faire. La plus importante est lors de jointures, lorsqu’il n’y a pas les cl´es n´ecessaires, ou lorsque les jointures se font avec des cl´es combin´ees par un OR. La suite de tests de MySQL http://www.mysql.com/information/benchmarks.html montre quels types de constructions vous devriez ´eviter lorsque vous utilisez diff´erentes bases de donn´ees.

• PostgreSQL a une plus grande ´equipe de d´eveloppement qui contribue au serveur.

Les inconv´enients de PostgreSQL face `a MySQL :

• L’utilitaire VACUUM rend PostgreSQL difficile `a utiliser en environnement de production

24h/24 et 7j/7.

• Les tables sont obligatoirement transactionnelles.

• Les commandes INSERT, DELETE et UPDATE sont plus lentes.