Il y a deux ans jour pour jour, Baron Schwartz publiait un billet sur les choses à savoir avant de migrer de Oracle vers MySQL.
A présent que Oracle et MySQL ne font plus qu’un, et ça je ne pense pas que Baron l’imaginait en 2009, la formule reste malgré tout d’actualité, plus encore qu’en 2009 à mon avis.

J’ai eu moi même à conseiller de nombreux clients sur la question en 2010 et il me semble que c’est une question d’autant plus légitime depuis qu’Oracle a acquis MySQL et ainsi donné des ailes à toute une communauté déjà lancée à pleine vitesse. Mais je reviendrai la dessus un peu plus tard.

Je vous propose donc dans ce billet, non seulement une traduction française du billet de Baron mais également une mise à niveau des informations données à l’époque par rapport aux dernières évolutions du moteur MySQL, ainsi que  mon modeste sentiment, en orange sur certains points.

Bonne lecture !

1 – Les sous requêtes sont à proscrire
2 – Les requêtes complexes  (nombreuses jointures par exemple) posent problème
3 –  L’optimiser est beaucoup moins évolué que celui d’Oracle
4 – Les compteurs de performance sont moindre. Depuis la version 5.5, la base performance_schema permet d’avoir accès à plus d’informations
5 –  Les audits sont limités et souvent plus difficiles à réaliser du fait du point 4
6 –  La notion de sécurité est extrêmement limitée. Je dirais que sur ce point, on voit à quel point MySQL est fait pour les applis web avec quelques utilisateurs base de données à gérer (le plus souvent, mes clients utilisaient le user root !). La gestion des utilisateurs devient très vite un cauchemar avec MySQL !
Il n’y a pas réellement de solution de cryptage de données dans MySQL. Celle qui existe oblige à modifier le code applicatif.
7 – Depuis la version 5.5, il est désormais possible d’avoir une authentification externe. Ce n’était pas le cas dans les versions précédentes
8 – Le cluster MySQL n’est pas ce que vous pensez ! (il faudrait un article entier pour expliquer ça…)
9 – Les procédure stockées et les triggers sont limités. Je dirais même qu’il ne faut tout simplement pas utiliser les triggers
10 – La flexibilité verticale (vertical scalability) est pauvre. Depuis la version 5.5, ou avec xtradb, ce n’est plus vrai
11 –  Les traitements massivement parallèles ne sont pas gérés. Depuis la version 5.5, ce n’est plus vrai à mon sens
12 –  MySQL ne sait pas gérer plus de 4 ou 8 coeurs. Ce n’est plus vrai en 5.1 (plugin InnoDB) ni en 5.5, mais attention, uniquement avec InnoDB
13 – Il n’y a pas de type spécifique pour les fractions de seconde
14 – Oubliez le PL/SQL, le langage MySQL est beaucoup plus limité
15 – Il n’y a pas de récupération des annulations
16 – Pas de snapshots
17 – Pas de database link mais un moteur de stockage appelé federated qui ne fait pas tout à fait la même chose et apparemment bugué (je n’ai pas eu l’occasion de le voir en prod celui là)
18 –  La vérification de l’intégrité des données est légère et les contraintes ne peuvent pas toujours être appliquées en fonction des moteurs de stockage
19 –  Il y a très peu de hints pour forcer l’optimiser à utiliser un plan d’exécution spécifique
20 – Il n’y a qu’un seul type de plan pour les jointure (nested-loop)
21 – La plupart des requêtes ne peuvent utiliser qu’un index par table
22 – Il n’y a pas d’index bitmap. Chaque moteur de stockage supporte différents type d’index, la plupart supporte les B-tree
23 – Il y a peu d’outils pour l’adminitration
24 – Il n’y a pas réellement d’environnement de développement intégré ni de debuger pour les procédures stockées, c’est à vous de tracer vos procédures
25 – Chaque table d’une base peut avoir un moteur de stockage différent (ce que je ne recommande pas)
26 – Chaque moteur de stockage peut avoir un comportement et des caractéristiques très différents. Par exemple, MyISAM est un moteur non transactionnel
27 – Les clés étrangères ne sont supportées que par le moteur InnoDB
28 – Le moteur par défaut est non transactionnel (MyISAM). Depuis la version 5.5, le moteur par défaut est InnoDB (transactionnel)
29 – InnoDB appartient à Oracle. Désormais, MySQL appartient à Oracle !
30 – Certains type de plan d’exécution sont supportés uniquement sur certains moteurs de stockage. Certain type de COUNT() s’exécutent instantanément sur certains moteurs et plus lentement sur d’autres. Avec MyISAM par exemple, le verrouillage table permet un stockage du nombre de lignes dans le fichier descripteur des tables
31 – Les plans d’exécution ne sont pas mis en cache globalement mais par session
32 – La recherche fulltext et les type de données GIS/Spatial ne sont disponibles que avec MyISAM (moteur non transactionnel)
33 – Il n’y a pas de contôle des ressources. Un simple utilisateur peut surcharger le serveur en mémoire ou en CPU !
34 – Il n’y a pas de fonctionnalité BI intérgée. Des moteurs spécifiques existent néanmoins pour cela, Infobright ou InfiniDB par exemple
35 – Il n’y a rien d’équivalent à Grid control
36 – Il n’y a rien qui ressemble à du RAC. Si vous vous demandez “comment puis-je avoir un RAC avec MySQL”, vous vous posez la mauvaise question
37 – Il n’y a pas de type utilisateur ou de domaines
38 – Le nombre de jointures par requête est limité à 61
39 – MySQL supporte un plus petit ensemble de la syntaxe SQL.
40 – Il n’y a pas de colonnes virtuelles (colonnes dont la valeur est calculée comme une expression)
41 – Vous ne pouvez pas créer un index à partir d’une expression, vous pouvez seulement indéxer des colonnes
42 – Il n’y a pas de vues matérialisés
43 – Les statistiques sur la distribution des données sont limitées (cardinalité et range). Il n’y a pas de réel contrôle de la mise à jour des statistiques
44 – Il n’y a pas de mécanisme intégré pour la promotion d’un esclave ou le failover (réplication)
45 – La réplication est asynchrone et à beaucoup de limitations. Par exemple, elle est mono-thread
46 – Bis : Le cluster MySQL n’est pas ce que vous pensez !
47 – Le dictionnaire de données (INFORMATION_SCHEMA) est limité et très lent (ce sont des vues non indexées). Interroger le dictionnaire peut provoquer, dans certains cas, une déffaillance sur un serveur déjà chargé
48 – Un ALTER TABLE verrouille toute la table (pas de mode online)
49 – Il n’y a pas de séquence mais des colonnes auto incrémentées beaucoup moins évoluées
50 – Les ordres DDL ne sont pas transactionnel et valident (commit) les transactions en cours

Pour ceux qui se demandent ce que sont les moteurs de stockage, vous trouverez ci-après le schéma de l’architecture MySQL :

Source : http://www.xaprb.com/blog/2009/03/13/50-things-to-know-before-migrating-oracle-to-mysql/




Share the love!

Inscrirez vous au flux RSS ou par email pour recevoir automatiquement et en temps réel une notification de publication des nouveaux articles.

Oracle, MySQL, and InnoDB are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners