Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
Découvrez les dangers de MySQL et MariaDB, par Frédéric BROUARD (SQLpro)
Chers membres du club,
J'ai le plaisir de vous présenter cet article :
Bonne lectureCet article a donc pour but de vous démontrer que MySQL/MariaDB n’est pas compatible avec la sûreté, la qualité et les performances attendues par l’entreprise. Il en est même dangereux ! Lire la suite de l'article...
Retrouvez les meilleurs cours et tutoriels pour apprendre les bases de données MySQL.
Merci pour cet article
C'est... consternant!
Question
Par quoi remplacer MySQL dans ce cas ou que devrait-on utiliser ?
Article intéressant mais à charge
Bonjour,
article intéressant mais très (trop) à charge.
Le principal reproche que je ferais à votre article concerne la forme : le ton employé assez sarcastique donne moins de poids à vos arguments (c'est mon avis).
Je comprends bien que ce ton est en adéquation avec votre fonction (expertise et audit de base de données), mais pour moi, cela ne le fait pas...
Certains chapitres semblent vouloir effrayer le lecteur:
- celui listant les amendes dans les stockages de documents électroniques, alors que les failles relevées n'ont pour moi que très peu de rapport avec des fonctionnalités pures de sgbd. Il est plutôt rare (à ma connaissance) de laisser la gestion des documents électroniques au sgbd, cela est effectué par des systèmes informatiques dédiés possédant de nombreuses autres fonctionnalités dans ce domaine.
- celui sur le chiffrement est hors sujet depuis MariaDB 10.1[.4] (voir ici). Je ne sais pas si cela répond totalement à vos attentes, mais donne néanmoins une autre vision de MariaDB.
Ensuite, n'étant pas expert en base de données, simple utilisateur depuis 20 ans de certains gros systèmes (Oracle, DB2 principalement), vous laissez penser que les solutions propriétaires sont le graal (notamment SQLServer qui revient souvent dans votre article). J'en doute fortement par mon expérience.
En plus d'être (très) coûteuses, ces solutions sont opaques. Vous semblez être expert en SQLServer notamment, sachez que côté Oracle, les opérations de support et maintenance sont très compliquées... sauf à payer le prix fort en abonnement adéquat (et encore, les bugs remontés ne sont jamais remontés dans un hotfix).
MySQL/MariaDB ont en effet de grosses lacunes, sur les points que vous évoquez (même si certains restent anecdotiques de mon point de vue),
mais il s'agit d'un moteur sgbd (ou de 2 ^^) possédant sûrement quelques qualités que vous ne citez pas (je ne le ferai pas moi-même, n'étant pas expert dans le domaine). Et sa gratuité et son aspect open-source sont un plus pour beaucoup, même dans le milieu de l'entreprise.
Je tiens quand même à vous remercier pour cet article, certains points m'étaient méconnus,
et puis, tout est question de nuances ;-)
Bonne journée,
Nicolas
Désolé, mais comme miaou_, je n'adhère pas du tout au discours.
L'exemple IV.A en est la parfaite illustration ... SQLServer n’empêchera absolument pas la suppression d'un fichier si le serveur est arrêté ! Le sujet chiffrement est traité tout autant à charge, cela donne l'idée du reste de l'article ! Enfin, laisser penser que MySQL est réalisé par un suédois dans son garage alors qu'il appartient depuis plus de 10 ans à Sun puis à Oracle ...
N'oublions pas non plus que SQLServer (je ne parle même pas d'Oracle !) coûte plusieurs milliers d'euro par an et par VCPU !
Très bon article recensant de nombreux points.
Certains considère l'article à charge. Le ton peut effectivement laisser penser cela, mais les faits sont pourtant bien là !
Je rajouterai pour ma part le problème d'intégrité des données suite à un arrêt brutal du service (bug, crash serveur, kernel panic, etc...). Perdre une BD à cause de ça, c'est possible avec MySQL, alors qu'un SGBD digne de ce nom encaisse sans broncher ce genre d'interruption.
SQL Server coute cher pour les versions Enterprise et Standard. La version Express est tout à fait abordable (gratuite !) et est même disponible maintenant sur... Linux ! Et avant d'arriver aux limites de la version Express, et bien, il faut y aller ! (4 coeurs, 10G par BD hors fonctionnalité FileStream).Envoyé par Gregslv
PostgreSQL à condition de :
- Ne pas avoir de grosses bases (se limiter à quelques centaines de Go - PostgreSQL ne dispose pas d'espace de stockage administrés)
- Se limiter en nombre d'utilisateurs simultanés (ne pas trop dépasser la centaine)
- Ne pas avoir d'application tournant 24h sur 24, 7 jours sur 7 (la maintenance est bloquante - VACUUM et particulier…)
- Ne pas avoir des requêtes trop complexes (se limiter au plus à une douzaine de table dans la requête à cause de GEQO)
SQL Server ou Oracle (beaucoup plus cher) ou IBM DB2 (encore beaucoup plus cher)
A +
Moi j'utilise sqlite, aucun problème
Merci , c'est bien de connaitre ces limites !
Cette fonctionnalités est présente dans la norme SQL depuis la version 3 datant de 1999, soit 20 ans… IBM DB2 et SQL Server l'implémente correctement. Oracle s'en approche partiellement avec le BFile. L'un des intérêts majeur est de pouvoir synchroniser les sauvegardes des données relationnelles et des fichiers électroniques associés ce qui ni MySQL, ni PostgreSQL sont en mesure de faire, en sus du transationnement des fichiers. Sans cela en cas de restauration on se retrouve immanquablement avec des fichiers manquants ou orphelins...Peut être parce que vous ne connaissez pas les autres SGBDR et sans doute parce que vous n'avez jamais eu affaire à de grosses GED… !Il est plutôt rare (à ma connaissance) de laisser la gestion des documents électroniques au sgbdS'en est encore très loin. J'avais lu tout ceci avant de rédiger mon article.celui sur le chiffrement est hors sujet depuis MariaDB 10.1[.4] (voir ici). Je ne sais pas si cela répond totalement à vos attentes, mais donne néanmoins une autre vision de MariaDB.Quand on analyse un cout il faut analyser tout :Vous laissez penser que les solutions propriétaires sont le graal (notamment SQLServer qui revient souvent dans votre article). J'en doute fortement par mon expérience.
En plus d'être (très) coûteuses, ces solutions sont opaques.
- le cout des machines sous jacente (il faut beaucoup plus de ressources aux SGBD "Libre" pour atteindre les mêmes performances),
- le cout de l'administration qui est généralement très élevé dans le libre car il y a très peu d'outil pour se faire…
- le coût d'une éventuelle panne bloquant la production
- le coût des bugs à corriger
Tout cela s'appelle le TCO. Il est généralement favorable au libre sur de petites config dont la sécurité importe peu. Il est très généralement favorable aux solutions du style SQL Server dès que la volumétrie des données, et des transaction est importante…
Pour votre information, sur de très petites bases, les Oracle et SQL Server ont des solutions gratuites…
Et certaines éditions sont très peu cher. Par exemple l'édition WEB de SQL Server coute quelque dizaines d'euro par mois….
C'est un des points extrêmement négatif d'Oracle. Sa hot line de premier niveau est lamentable et celle de second niveau totalement hors de prix. Ce n'est pas du tout le cas de Microsoft dont la hot line Europe est à Paris et non seulement disponible, mais efficace et rapide !Vous semblez être expert en SQLServer notamment, sachez que côté Oracle, les opérations de support et maintenance sont très compliquées... sauf à payer le prix fort en abonnement adéquat (et encore, les bugs remontés ne sont jamais remontés dans un hotfix).
A +
Pour information, j'utilisait encore il y a peu Mozilla Thunderbird qui utilise du SQL Lite pour y stocker les messages. Du fait du volume accumulé, j'ai eut des nombreuses corruption de données et il est devenu impossible de réparer et récupérer les bases…. J'ai perdu plus de la moitié des mes emails et le volume de données a explosé (de très nombreux messages apparaissent plusieurs dizaines de fois….).Moi j'utilise sqlite, aucun problème
Sans compté que SSQL Lite n'est pas du tout transactionnel ni concurrentiel. C'est fait pour de l'embarqué. C'est comme si vous compariez un vélo à une navette spatiale !
A +
Pour information, il n'y a pas de licence par an pour SQL Server, sauf en ce qui concerne l'édition WEB qui est en mode SPLA et c'est un peu plus de mille euros par an quelque soit le nombre de CPU (et non VCPU, encore une erreur…).
A +
L'article est intéressant mais je rejoins l'avis d'autres sur le ton employé qui dévalorise totalement l'article.
De plus, donner des liens vers des rapports (je parle pas du bug) qui datent de plus de 5 ans... :/
Pour moi, MySQL/MariaDB est/sont l'un des SGBD qui évolue le plus rapidement.
De plus l'affaire du chiffrement et du stockage de document électronique ne peut en aucun cas être imputé uniquement au SGBD, oui il peut fournir des solutions de chiffrement mais pour moi les applicatifs sont principalement responsable de cette tâche.
Oui j'ai déjà eu à faire face à une grosse GED, et ni SQL Server ni Oracle n'ont été retenu pour cette tache, ni MySQL d'ailleurs.
Oui MySQL et MariaDB ont leurs inconvénients comme tout SGBD, mais dans tout les soit disant "méfaits/mensonge" remontés, j'ai jamais eu à faire des choses qui auraient pu me remonter ça. Et pourtant je lui en ai fait voir de toutes les couleurs... (une BDD sous MySQL 5 avec plus de 150 tables et 600+ Millions d'enregistrements)
Bref, j'ai utilisé SQLServer et Oracle pendant plus de 10 ans et sincèrement PLUS JAMAIS !
Je parle même pas de PostgreSQL qui est totalement à la ramasse.
Toutefois cela reste mon avis.
Bizarre, selon ce document Microsoft https://download.microsoft.com/downl..._Datasheet.pdf, il est bien stipulé :
"To license a VM or container with core licenses, purchase a core license for each virtual core (virtual thread)allocated to the VM"
Vous avez le choix de limiter la licence au vCPU d'une VM hébergeant une instance de SQL Server, si ce nombre est inférieur au nombre de cœurs physique, ou bien, de licencier le nombre de cœurs physique quelque soit le nombre de vCPU de l'ensemble des instances de SQL Server hébergées sur l'hôte.
Ce qui revient bien à dire que vous ne payez que pour des cœurs physiques…
A +
Soit vous plaisantez, soit vous n'êtes pas au courant de la concurrence….
Mais pour votre information, voici quelques manques de MySQL que les concurrents ont :
- intégration des schéma SQL
- gestion des transactions imbriquées
- transationnement du DDL, DCL
- gestion des espaces de stockage
- indexation verticale
- indexation XML
- table in memory
- journalisation asynchrone
- DATALINK
- FileTable
- Table temporelles
- Utilisation de HMS pour le stockage des clefs de chiffrement
Voici maintenant quelques un des modules très incomplets ou fortement bogués qui les rendent inexploitable dans MySQL :
- full text
- spatial
- XML
- JSON
A +
Je suis au courant oui, mais avoir ces fonctionnalité ne font pas forcément d'elles des fonctionnalités utiles ou (très) utilisées.
Et quand bien même, j'ai toujours réussi à faire sans et j'en m'en porte pas moins bien pour autant.
Perso, je suis pas trop pour des modules tel que le JSON dans des SGBDR... Laissons ça à des système "conçu" pour. Même si ça peut être pratique dans certain cas et sur un volume de données restreint.
Chez mon client actuel ils l'utilisent ce module JSON, j'ai moi-même fais des benchs sur 17 millions d'enregistrements, même si les concurrents (tel que ElasticSearch & Co) font très certainement mieux, MySQL se défend.
Mais comme je l'ai dis, MySQL a aussi ses défaut et n'est pas forcément complet, d’ailleurs aucun SGBD ne l'ai réellement.
N'oublions pas ancienneté MS SQL Server c'est 30 ans d'âge et Oracle 42 ans, Ils n'ont pas eu les mêmes passif ni les même moyens, pour un produit Open Source...
Je trouve également l'article à charge. Je l'ai quand-même trouvé intéressant, et je sais que tu n'aimes pas du tout MySQL.
Je ne suis pas du tout expert dans le domaine (je vais donc peut-être dire des bêtises), mais voici mes remarques/interrogations.
Intéressant et probablement en adéquation avec les posts réguliers sur ce type de problème dans nos forums. Mais il suffit de changer celle-ci.Beaucoup de développeurs n'ont pas remarqué cela et laissent en production cette collation qui peut s'avérer une bombe à retardement en matière de gestion des données accentuées, car le jeu de caractères accentués de la langue suédoise n'est pas compatible avec les principaux accents du français.
MySQL/MariaDB, un SGBD non relationneDonc qui ment ?InnoDB est un moteur de stockage pour les systèmes de gestion de base de données MySQL et MariaDB. Il est inclus et activé dans toutes les distributions fournies par MySQL AB depuis la version 41 et devient le moteur par défaut à partir de MySQL 5.5.52. Son principal avantage par rapport aux autres moteurs de stockage de MySQL est qu'il permet des transactions ACID (atomiques, cohérentes, isolées et durables), ainsi que la gestion des clés étrangères (avec vérification de la cohérence). Autrement dit, InnoDB est un moteur de bases de données relationnelles et transactionnelles, à l'image de celui utilisé par son concurrent Open Source PostgreSQL.
Je pense que c'est plus compliqué que cela, voir cette discussion sur le sujet.
J'en conclus que MySQL est relationnel au moins en partie. Sur l'exemple présenté, je ne peux pas juger, mais vu l'auteur je pense qu'il a raison et que dans l'exemple fourni, MySQL ne conviendra pas.
Et la table système INFORMATION_SHEMA c'est quoi alors ? un tutoriel sur le sujet.À l’exception de MySQL/MariaDB, tous les SGBD relationnels, PostGreSQL compris, disposent d’un catalogue(5)
J'ai fait un test, j'ai supprimé le fichier de définition de .frm, la base a continué de fonctionner, jusqu'au redémarrage du serveur.Disparition des objets de la base
J'ai essayé de recréer une base après copie du fichier db.opt et recréation de celle-ci avec le même shéma, la recopie du fichier db.opt ne m'as pas permis de récupérer les données. Avec SQL Server tout est dans le fichier .mdf et .ldf, je ne sais pas si il est possible de remonter une base directement depuis une copie de ces fichiers en l'état, mais ce n'est de toute façon pas une bonne méthode. Le fait qu'il n'est pas possible de supprimer les fichiers .mdf depuis l'interface graphique Windows indique uniquement que les services SQL-Server les bloquent. Il suffit de stopper ces services et la même connerie peut être faite. On ne bidouille pas des fichiers de Program files sans risquer de conséquences.
Extrait de la doc :Cette absence de table système constituant le catalogue exigé par Codd, contraint MySQL/MariaDB à valider automatiquement toutes les transactions de tous les utilisateurs sans leur demander leur avis dans certaines circonstances
https://dev.mysql.com/doc/refman/5.7...it-commit.htmlCREATE TABLE and DROP TABLE statements do not commit a transaction if the TEMPORARY keyword is used. (This does not apply to other operations on temporary tables such as ALTER TABLE and CREATE INDEX, which do cause a commit.) However, although no implicit commit occurs, neither can the statement be rolled back, which means that the use of such statements causes transactional atomicity to be violated. For example, if you use CREATE TEMPORARY TABLE and then roll back the transaction, the table remains in existence.
Ça ne semble pas être le cas pour CREATE TABLE ou DROP TABLE. Pour le reste, je ne comprend pas les impacts. Et je ne connais pas les normes.
Pour les "calculs faux", MySQL retourne NULL. Si on teste le retour, on voit bien un problème. Je présume que ceci permet de retourner une valeur sans interrompre la requête tandis qu'une gestion en "strict mode" permet une interruption ?
Pour avoir une sauvegarde consistante, il faut effectivement mettre un verrou sur les tables avant de faire un mysql dump. En utilisant LVM, il suffit de locker les tables, créer le cliché, puis déverrouiller tout de suite les tables. Le SQL Dump depuis le cliché sera cohérent. C'est plus ou moins ce que dois faire SQL Server avec VSS. Il est possible aussi d'utiliser des outils comme Percona Xtrabackup, gratuit, qui permet en plus des sauvegardes incrémentielles. C'est externe à MySQL mais répond au besoin. Dans les deux cas(SQL Server et MySQL) il est possible de monter un cluster,le le problème de sauvegarde se réglant en bloquant temporairement un membre du cluster.Sauvegarde non consistente.
Les condamnations CNIL ne concernent pas des problèmes liées à la base de données mais au site lui-même. Utiliser une base cryptée, et/ou autre que MySQL n'aurait rien changé, les failles se situant au niveau du code du site. Dans tous les cas cités, la modification de l'URL permettait d'interroger la base sur des critères inadéquats.
Il ne sert à rien de crypter une base données si la vulnérabilité se situe au niveau de son point d'entrée comme un site web. Cela revient à mettre une porte blindée quand un voleur peut entrer par la fenêtre.
Je pense que MySQL, même si il n'est pas parfait, est un bon compromis pour des petites bases, notemment pour le web, comme le dit l'auteur de l'article. Dans le cas de grosses bases, ce sera de toute façon SQL Server ou Oracle (postGreSQL est un challenger, mais quel est l'interet par rapport à Oracle par exemple ?). On ne va pas utiliser de camionettes pour transporter plusieurs tonnes, tout comme on ne va pas utiliser un un camion à remorque pour transporter une palette. Sur de grosses bases, la notion de côut est un critère négligeable car en général les acteurs on les ressources derrière.
pour info : Les messages ne sont pas stockées en SQLite dans Thunderbird, mais au format MBOX. Les fichiers d'index .msf de chaque dossier sont effaçable et se reconstituent. Cela peut régler pas mal de problèmes. Les fichiers SQLite utilisés sont global-messages-db permettant la recherche, supprimable également. Lithning et les autres extensions utilisent des bases SQLite.Pour information, j'utilisait encore il y a peu Mozilla Thunderbird qui utilise du SQL Lite pour y stocker les messages. Du fait du volume accumulé, j'ai eut des nombreuses corruption de données et il est devenu impossible de réparer et récupérer les bases…. J'ai perdu plus de la moitié des mes emails et le volume de données a explosé (de très nombreux messages apparaissent plusieurs dizaines de fois….).
Comme je m'y connais la dessus (je suis ces histoires de près !), je me permets d'intervenir. Effectivement, le SGBD n'est pas la source de la faille. Mais la faille est une conséquence du manque de fonctionnalités du SGBD choisi.
Le coup du mot de passe stockée en clair par exemple, il faut vraiment le faire exprès avec un SGBD comme SQL Server pour le faire (car il propose les fonctionnalités qui vont bien). Mais il est difficile de faire autrement en utilisant MySQL.
De même, pour la gestion des "documents électroniques", (plus communément appelés "fichiers"), elle peut se faire très simplement avec SQL Server, sans avoir à besoin de créer un répertoire qui contiendra les données, dont on aura oublié de gérer les droits et qui se retrouvera indexé par Google et accessible à tout le monde.
Je pense que c'était ce que voulait dire Frédéric en mentionnant ces failles : les condamnations CNIL auraient pu être évitées simplement en utilisant de bons outils dès le départ.
Partager