Forum d'entraide PHPFrance

Il faut en déduire que les tables MyISAM ne sont pas adaptés à des sites qui demandent des requettes multiples ( donc une bonne partie des sites ) ?

Ben ... oui. Tout talentueux qu'ils soient, les développeurs de MySQL n'ont pas l'expérience, ni les moyens techniques et financiers de sociétés comme Oracle ou Sybase qui font des bases de données depuis 30 ans. Cela n'enlève rien à la qualité du travail produit par MySQL et au fait qu'il est primordial que ce genre d'outil free existe, mais on ne prend pas une Twingo pour courir un Grand Prix de Formule 1.

Il faut garder MySQL et en particulier les tables au format MyISAM pour ce qu'elles sont. C'est à dire une base de données adaptée au Web et pour des données non sensibles. Le type qui voudrait monter la facturation de sa société sur MySQL serait suicidaire.

Je viens de terminer un projet PHP pour une société dont le fond de commerce est une base de données contenant des informations économiques. Il n'y a eu aucune hésitation : la base a été montée sous Oracle 10, sur un serveur différent du serveur Web et avec des outils et des procédures de sauvegarde adaptées à Oracle. Par contre, tous les services annexes ont été montés sur MySQL : forums, statistiques de consultation, outils de simulation, ...

Tout talentueux qu'ils soient, les développeurs de MySQL n'ont pas l'expérience, ni les moyens techniques et financiers de sociétés comme Oracle ou Sybase qui font des bases de données depuis 30 ans.

Je n'ai que 25 ans mais je suis à peu près certain que les bases de données et l'environnement ont légèrement évolué en 30 ans, donc je ne vois pas comment une société spécialisée dans un domaine depuis 30 ans serait automatiquement meilleure qu'une société spécialisée dans le même domaine depuis 10 ans.

En fait, j'ai l'impression que tu confonds volontiers MySQL et ses moteurs de stockage. La différence entre MySQL et Oracle c'est qu'on choisit le moteur que l'on veut utiliser dans MySQL: MyISAM pour des applications très rapides à forts volumes en lecture ou écriture mais qui n'ont pas besoin d'utiliser de transaction ou d'intégrité référentielle, InnoDB pour ces derniers, et très bientôt Falcon ou PrimeBase XT pour des applications utilisant énormément de transactions. (voire même ARCHIVE, MEMORY ou CSV pour des applications spécifiques)

Donc dire qu'il faut garder MySQL pour des "données non sensibles" est faux. Utiliser MyISAM pour des données sensibles est une mauvaise idée, c'est pour ça qu'InnoDB existe. Et j'imagine que la technologie d'InnoDB est plutôt bonne puisqu'Oracle l'a rachetée.

Désolé pour la réponse un peu longue ...

Je n'ai que 25 ans mais je suis à peu près certain que les bases de données et l'environnement ont légèrement évolué en 30 ans, donc je ne vois pas comment une société spécialisée dans un domaine depuis 30 ans serait automatiquement meilleure qu'une société spécialisée dans le même domaine depuis 10 ans.

Tu serais étonné de constater que non. Il y a eu très peu d'évolution dans le domaine du stockage des fichiers des SGBD et des manières de les traiter. On retrouve essentiellement à la base les technologies ISAM et VSAM dont les spécifs de bases ont été définies par IBM dans les années 70 ou 80 et que l'on retrouve également sur les mainframe Cobol/CICS.
Ne me fais pas dire ce que je n'ai pas dit : bien sûr que ça a évolué en 30 ans et les bases de données ne sont pas du Cobol. Mais les évolutions ont essentiellement sur les algorithmes d'optimisation des requêtes, sur les index, sur l'intégrité des données, sur les bases de données réparties. Et bien sûr sur la sécurité des données. Mais les principes ont assez peu bougé.

D'autre part, l'avantage d'avoir commencé avec 20 ans d'avance, c'est que certains bugs ont été résolus depuis pas mal de temps ou que certaines fonctionnalités ont été mises en place depuis plusieurs années. Encore une fois, je trouve remarquable le travail de MySQL ou d'InnoDB, mais ils sont encore très loin des possibilités d'un SGBDR Oracle, Sybase ou IBM et continuent à debugger des problèmes qui sont de lointains souvenirs pour ces anciens. Par exemple, les vues, triggers, fonctions et procédures stockées viennent à peine de faire leur entrée dans MySQL 5 et il y a un manque de recul quant à leur fiabilité.

Concernant la sécurité : je viens à l'instant de faire un simple essai sur mon serveur de développement. Je suis webmaster et je fais une fausse manip ...
J'efface accidentellement un fichier de données Oracle --> opération refusée.
J'efface accidentellement un fichier de données MySQL (MyISAM ou InnoDB) --> le fichier est effacé.
Rien que ce simple test m'incite à dire qu'il est suicidaire de mettre des données sensibles pour l'entreprise dans une base MySQL.

On peut également citer les problèmes de pertes de données avoués par MySQL en cas de plantage lors de l'écriture d'un fichier (voir également l'expérience citée par gwendal). D'un autre côté, un des mes clients a débranché des dizaines de fois un serveur Oracle pendant des phases d'écritures de données pour tester la robustesse : il n'a jamais perdu une seule donnée.

Cas InnoDB :
MySQL intègre un moteur développé par InnoDB. Mais on ne peut pas dire qu'il s'agit de bases MySQL. La meilleure preuve étant que lorsqu'on parle de base MySQL, on sous-entend MyISAM et qu'on est obligé de préciser quand il s'agit d'une autre technologie. D'ailleurs, il est possible que ce moteur ne soit bientôt plus dispo sous MySQL puisque depuis le rachat par Oracle, des renégociations sont en cours.

Concernant ce rachat d'InnoDB par Oracle et la tentative manquée d'achat de MySQL par Oracle. Oracle a toujours eu un manque sur le marché des SGBD légers et n'arrive pas à imposer sa solution Oracle Lite. La solution passe donc par un rachat, comme l'avait fait Sybase il y a une dizaine d'années en rachetant l'excellent moteur Watcom SQL pour le renommer en SQL Anywhere. De plus, Oracle flirte pas mal de temps avec le monde de l'opensource et c'est là une occasion d'y mettre un bon pied.

MyISAM pour des applications très rapides à forts volumes en lecture ou écriture mais qui n'ont pas besoin d'utiliser de transaction ou d'intégrité référentielle

Je ne comprends pas bien. Toutes les applications qui utilisent des bases de données font des lectures et des écritures. Et quand la volumétrie monte, MyISAM n'est pas un moteur particulièrement réputé pour sa robustesse, ni pour sa rapidité : il n'y a pas besoin d'avoir fait de longues études en informatique pour se rendre compte que le fait que MyISAM stocke chaque table dans trois fichiers différents entraîne des temps d'ouverture/fermeture plus longs qu'un stockage comme Oracle où tout est stocké dans un seul fichier organisé en fonction de la volumétrie de chaque table (voire deux fichiers, un pour les données et l'autre pour les index).

D'autre part, toutes les applications ont besoin d'intégrité référentielle. Ou plutôt devraient en avoir besoin. C'est justement parce que MySQL n'intègrait pas ces mécanismes qu'on a fait semblant de croire qu'on n'en avait pas besoin ou qu'on a développé des programmes complexes pour pallier à leur manque.

Tout cela pour dire que oui, MySQL, MyISAM et InnoDB sont des produits fantastiques. Mais qu'il ne faut pas les utiliser n'importe comment et qu'il faut se poser de sérieuses questions quant à leur fiabilité si des données sensibles pour l'entreprise doivent y être stockées.

voire même ARCHIVE, MEMORY ou CSV pour des applications spécifiques

Avis personnel : il vaut mieux, satisfaire 99% des utilisateurs en améliorant MyISAM plutôt que de faire joujou en intégrant des moteurs utilisés au maximum pour 1% des utilisateurs. Question d'efficacité.

J'efface accidentellement un fichier de données MySQL (MyISAM ou InnoDB) --> le fichier est effacé.

Ça demanderait vérification mais je crois que le cas que tu décris est couvert par les paramètres safe-updates et skip-external-locking. Dans tous les cas, c'est difficile de se protéger contre quelqu'un qui efface des fichiers au hasard

On peut également citer les problèmes de pertes de données avoués par MySQL en cas de plantage lors de l'écriture d'un fichier (voir également l'expérience citée par gwendal)

Je ne vois pas de quel "problème avoué par MySQL" tu veux parler, est-ce que tu pourrais m'envoyer un lien stp? Préférablement un serveur utilisant InnoDB et le binlog, sinon ça compte pour du beurre.
L'"expérience citée par gwendal" c'est celle où il a perdu l'intégrité référentielle d'une base de données qui ne la supporte pas ? ah, en effet c'est un problème. Heureusement, maintenant qu'il sait comment changer ses tables en InnoDB ça ne devrait plus se reproduire.

[...] on parle de base MySQL, on sous-entend MyISAM

Les gens sous-entendent trop de choses.

Je ne comprends pas bien. Toutes les applications qui utilisent des bases de données font des lectures et des écritures.

Mais le ratio entre les deux peut pencher d'un côté ou de l'autre. MyISAM peut faire une grande quantité de SELECT à grande vitesse parce qu'il ne s'embête pas avec du MVCC. Il peut aussi faire des tonnes d'INSERT sans avoir à vérouiller la table donc si l'application en question fait essentiellement du logging et reporting (autrement dit, très peu d'UPDATEs) alors MyISAM sera le plus rapide.

MyISAM stocke chaque table dans trois fichiers différents entraîne des temps d'ouverture/fermeture plus longs [...]

...ou plus court si tu as besoin de faire un table scan ou si tu n'as besoin d'accéder qu'aux indices. Là encore ça dépend de l'usage que l'on en fait.

D'autre part, toutes les applications ont besoin d'intégrité référentielle. Ou plutôt devraient en avoir besoin.

Dans un monde parfait tout le monde utiliserait du RAID5 ou du solid storage qui ne flanche jamais. Mais dans le monde réel, beaucoup d'applications sont prêtes à échanger un petit peu d'intégrité pour beaucoup de performance (meilleure rentabilité). Dans un monde parfait il y aurait une caserne de pompiers au pied de chaque immeuble.

MySQL, MyISAM et InnoDB sont des produits fantastiques. Mais qu'il ne faut pas les utiliser n'importe comment et qu'il faut se poser de sérieuses questions quant à leur fiabilité si des données sensibles pour l'entreprise doivent y être stockées.

Je crois qu'on ne peut pas tomber plus d'accord. Les gens qui ont besoin de 99.9% d'uptime et sont prêt à perdre quelques heures de données en cas de crash du serveur mais n'ont pas beaucoup de ressources devraient utiliser MyISAM, peut-être en mitigeant les risques en utilisant la réplications. Ceux qui ont besoin de 99.999% d'uptime et 100% d'intégrité des données devront s'intéresser à d'autres technologies (InnoDB, MySQL Cluster, Oracle ou autre).

Ensuite à chacun de faire sa sauce, j'ai entendu parler de configurations qui utilisaient Oracle en backend avec une réplication vers du MySQL (MyISAM si mes souvenirs sont bons) pour du frontend. Et c'est là aussi la grande force de l'architecture de MySQL, on a le choix entre réplication, partionnement, intégrité référentielle, clustering, archivage en temps réel ou stockage en mémoire, voire même accéder à des données en provenance de serveurs étranger via FEDERATED (qui à ma connaissance est à peu près aussi lent que son équivalent chez Oracle). Derrière, c'est au DBA de faire les bons choix.

Bon, je viens mettre mon grain de sel dans la discussion car il y a plusieurs points sur lesquels je ne suis pas d'accord.

Avant toute chose, il y a un point sur lequel je souhaite revenir. Le couple MySQL-MyISAM ne convient certainement pas a une application critique. Neanmoins, il est incontestable que pour un serveur web style forum ou blog ou... c'est de tres loin un couple bien plus performant qu'Oracle. Montez deux PC avec 1 Go de RAM et le meme CPU, l'un avec Oracle, l'autre avec MySQL, quels que soient les defauts de MyISAM, l'un supportera peut-etre 10 utilisateurs simultanés et l'autre plusieurs centaines.

il n'y a pas besoin d'avoir fait de longues études en informatique pour se rendre compte que le fait que MyISAM stocke chaque table dans trois fichiers différents entraîne des temps d'ouverture/fermeture plus longs qu'un stockage comme Oracle où tout est stocké dans un seul fichier organisé en fonction de la volumétrie de chaque table (voire deux fichiers, un pour les données et l'autre pour les index).

Sur ce point en particulier, je ne suis pas d'accord. Cette affirmation est en effet extremement dependant du Filesystem sur lequel sont stockees les donnees.
Typiquement dans le cas d'un systeme RAID, je peux te certifier qu'il est tout a fait possible de rendre l'acces a 3 fichiers bien plus rapide que l'acces a un seul
Dans le cas d'un disque simple sous Windows ou Linux, c'est plus difficile a affirmer car cela depend de la taille des fichiers en question et de leur degre de fragmentation.

Maintenant je souhaite insister sur ce dernier point :

Rien que ce simple test m'incite à dire qu'il est suicidaire de mettre des données sensibles pour l'entreprise dans une base MySQL.

Il se trouve que tout le monde ne semble pas avoir les memes a priori concernant MySQL - InnoDB. J'en veux pour preuve les tres nombreux systemes critiques bases sur ce couple magique, ne serait-ce que le dernier né d'Airbus, l'A380, ou le Dreamliner de chez Boeing. Et je peux t'assurer que pour faire voler un tel systeme, il est necessaire de le faire certifier... entre autres par les autorités aériennes.
Donc si ca n'etait pas fiable, ca ne serait pas le cas.


Pour finir, il faut bien le faire un jour, je pense qu'il est un peu trop facile de considérer MySQL comme une application non-fiable ou plus exactement non-professionnelle :
- MySQL - MyISAM remplit tout a fait son role dans le cadre d'appli non-critiques
- MySQL - InnoDB est tout a fait satisfaisant pour des applications critiques sans avoir besoin de l'usine a gaz d'Oracle.

Maintenant il est vrai que l'avenir du couple MySQL - InnoDB sera vraisemblablement une license payante pour un usage professionnel.