|
|
Article complet: MySQL ? Un SGBDR poudre aux yeux !
21/07/2010
11:46:51, Catégories: Récapitulatif Web, Langage SQL (norme), MySQL, Récapitulatif SGBD, 2596 mots 
, sqlpro [MySQL][SGBD][Web] MySQL ? Un SGBDR poudre aux yeux !
Une critique objective mais sans pitié pour MySQL...Voici une liste non exhaustive des points pour lesquels je considère que MySQL est un ersatz de SGBDR C/S et qui peuvent poser problème, tant au niveau des performances des applications que de la qualité des données (certains résultats de requête sont mathématiquement faux). En fait, dès sa conception reposant directement sur l'OS, MySQL a été mal conçu. Parmi les principaux défauts de mySQL notons : la pauvreté de la gestion de la concurrence (en pratique les performances de MySQL chutent à plus de 5 utilisateurs en concurrence, alors que tous les autres SGBDR acceptent des centaines d'utilisateurs en parallèle sans broncher), la gestion plus que pauvre des transactions, des sauvegardes impossible à chaud, le manque de fonctionnalité des contraintes SQL, un SQL hors norme et très incomplet (près de 20 ans de retard - certaines requêtes étant infaisables avec MySQL), et pour couronner le tout, la destruction de certaines de vos données ! ... bref un ensemble de problèmes édifiants pour un SGBDR qui se vante d'être le meilleur sans qu'aucun benchmark n'ai jamais étayé cette affirmation !
Voici quelques un des griefs objectifs sur lequel je me base pour affirmer mes dires :
Gestion des threads très pauvre :
- pas de possibilité de donner la priorité à certains threads
- en principe : une connexion = un thread, mais cela ne fonctionne pas dans tous les cas
- aucun moyen d'être sûr qu'il y a X threads en activité
- trop de changement de contexte des threads
- sous utilisation du multi processeur, en particulier lorsque le serveur est chargé et à partir de 4 à 8 CPU
- les requêtes en sont pas multithreadées (processus unique)
- impossibilité d'utiliser les architecture NUMA
- impossibilité d'utiliser AWE sous Windows 32 bits
Gestion mémoire peu souple :
- pas de process unique d'allocation mémoire : chaque moteur à le sien !
- taille du buffer de tri non flexible (comme certains autres tampon mémoire)
- arrive à cours de mémoire lorsque le nombre de threads devient important
- utilise rarement toute la mémoire lorsque seulement quelques threads sont actif et qu'ils le pourraient
Gestion peu fiable des méta données voire inexistantes :
- MySQL n'a pas de méta données statiques (tables systèmes)
- les informations sont générées à la demande depuis les fichiers .frm
- rare sont les fonctions de méta données permettant d'obtenir des informations sur une session (nom d'hôte, adresse IP ou MAC, nom d'application...)
- les opérations de lecture des méta données ne sont pas transactionnelle (on peut donc obtenir un résultat faux).
Indexation restreinte :
- les techniques d'indexation sont très limitées comme le sont les paramètres de création d'un index
- des index sur des colonnes calculées ou des expressions sont impossibles
- des index partiaux ou filtrés ne sont pas pris en charge
- les vues matérialisées ou indexées n'existent pas sous MySQL
- pas d'indexation possible des données XML ni SIG (spatial)
- pas d'index couvrant (clause INCLUDE).
Moteur de requête très limité :
- exécution de certaines opérations strictement dépendante de l'écriture
- exécution parallèle des requêtes très limitée
- gestion du cache des procédures peu évolué (la paramétrisation semble inexistante)
- parseur gourmand en ressources, spécialement pour des petites requêtes
- pas de réécriture pour l'optimiseur (algébrisation plus que faible - test de la requête de Chris Date infaisable, voir : http://blog.developpez.com/sqlpro/p5919/langage-sql-norme/votre-base-de-donnees-est-elle-intellige/ )
- utilisation outrancière de tables temporaires pour la résolution des requêtes
- incapacité de l'optimiseur à synthétiser les opérations dans les vues (simplification des jointures par exemple)
- pas d'optimisation sémantique (sachant tirer partit des contraintes)
Exécution des procédures exécrable :
- mauvaise gestion du cache des procédure à travers les différentes connexions
- pré verrouillage des tables (sauf moteur InnoD
- gestion des curseurs plus que limitée :
-- aucun curseur scrollable (ils sont systématiquement matérialisés, impossible d'avancer autrement qu'en avant et d'une ligne)
-- pas de possibilité de faire du READ ONLY pour éviter de verrouiller les tables
-- impossibilité d'imbriquer la lecture des curseurs
-- pas de possibilité de mettre à jour la ligne courante du curseur
-- aucun curseur dynamique
- le code des déclencheurs n'est pas partagé entre les différentes tables ouvertes
- aucune possibilité d'utiliser un langage externe (sauf pour coder les UDF)
- déclencheurs poudre aux yeux : on ne peut pratiquement rien faire dans un trigger DML !
Réplication peu fiable :
- la réplication ne peut être utilisé dans des contextes de haute sécurité car elle ne garantie pas l'intégrité de la base
- pas de réplication synchrone
- pas d'outil pour vérifier la consistance des données répliquées
- pas de mécanisme intégré de gestion de la haute disponibilité (genre log shipping ou database mirroring)
Convention de nommage très dépendante des moteurs :
- du fait que les tables sont stockées chacune dans un fichier différent, leurs noms peut être sensible ou non à la casse
- le portage d'un environnement à l'autre est difficile (Unix étant Case Sensitive, alors que ce n'est pas le cas de Windows ou MAC OS).
- du fait que les contraintes sont dépendantes du moteur, la portabilité en souffre aussi
SQL pauvre (MySQL ne respecte même pas la norme de 1992 !) :
- pas de domaines
- pas de schémas SQL
- pas de collation insensible aux accents
- pas de requêtes récursives
- des NULLs pas vraiement NULL !!! (voir ci après)
- pas d'opérateur ensemblistes comme INTERSECT ou EXCEPT
- pas d'expression de tables (CTE)
- pas de fonctions de fenêtrage
- pas de relationnel objet (CREATE TYPE ... )
- mélange de calcul agrégés et non agrégés sans clause GROUP BY avec résultat imprévisible !
- groupage OLAP anormatif et incomplet (syntaxe incorrecte de CUBE et ROLLUP, pas de fonction GROUPINGS, pas de GROUPING SET, NULL LAST, NULL FIRST...)
- sous requêtes très limitées dans les ordres de mise à jour
- contraintes dépendantes du moteur
- contraintes CHECK plus que limitées
- contraintes FOREIGN KEY farfelues et non normatives (voir ci après)
- impossible de créer des fonctions (UDF) table.
- pas de type xml et méthodes XQuery/XPath pour la manipulation des documents XML plus que limitées
- type TIME farfelu donnant des résultats incorrect dans les calculs (en sus du mélange physique logique avec UNIX_TIMESTAMP()...)
- type ENUM avec conversions implicites farfelues, donnant des résultats fantaisistes
- certaines requêtes classiques de mise à jour sont infaisable en SQL (viol de la règle de CODD n°7), en effet MySQL ne fonctionne pas de manière ensembliste mais itérative !
- syntaxe SQL très perverse... Certaines commandes passent, ne font aucune erreur de syntaxe, mais ne font rien... Exemple FOREIGN KEY ... SET DEFAULT...
- insertion de données fausses par conversions silencieuses (par exemple une date inexistante comme le 31/02/2000... ou un nombre incompatible avec le format du type et qui va être tronqué : 99999999 dans un NUMERIC(5,2) donne 999.99 !)
- ordre spécifique totalement farfelus en lieu et place des ordres SQL normatif... Exemple REPLACE ... INTO (alors que MERGE est la norme !)
et pour couronner le tout la fameuse date 0000-00-00 qui constitue un bug irréfragable
NOTA : tout ceci à des conséquences dramatiques sur les performances. A lire sur le sujet : http://blog.developpez.com/sqlpro/p9821/langage-sql-norme/agregation-d-intervalles-en-sql-1/
Gestion des transactions plus que minimale :
- seul le moteur innodb accepte les transactions
- le niveau d'isolation par défaut (REPEATABLE READ) est trop élevé pour un usage courant. Il s'ensuit des blocages intempestifs
- le niveau d'isolation snapshot n'est pas implémenté
- pas de gestion automatique de résolution des conflits de verrous mortels dans tous les cas
- point de sauvegarde (SAVEPOINT) limités
- il n'est pas possible de faire un COMMIT ou un ROLLBACK dans un trigger
- pas de déclencheur INSTEAD OFF
- pas de déclencheur DDL
- pas de déférabilité des contraintes
Fonctionnalités poudre aux yeux :
- indexation full texte (recherches textuelle) plus que limitée
- SIG très pauvre et inexploitable comparativement à PostGreSQL par exemple, et bien entendu Oracle ou MS SQL Server
- outils de haute disponibilités très limités à inexistant (pas de log shipping, pas de mirroring...)
- partitionnement profondément anti performant
Gestion du stockage des données inexistantes :
- pas de possibilité de définir la stratégie de gestion des espaces de stockage (par exemple impossible de faire de la pré réservation des espaces de stockage, ni de gérer la stratégie de croissance...)
- partitionnement des données plus cosmétique que technique (et générant de nombreux problèmes de performances)
- pas de stockage compressé des données
- pas de stockage cryptées des données
Gestion des privilèges et sécurité minimaliste :
- sécurité des connexions et des utilisateurs très limitée
- pas de gestion des rôles
- pas de privilèges possible au niveau schéma SQL
- pas de privilèges possible au niveau bases de données SQL
- pas de privilèges possible au niveau serveur
- impersonnalisation impossible
- pas de cryptage des données intégrée
- pas d'authentification possible par certificats
- pas d'outil d'audit de sécurité...
Sauvegardes irréalistes :
- il n'est pas possible de réaliser une sauvegarde à chaud en s'assurant que la base reste intègre
- aucun parallélisme possible pour la sauvegarde (sur plusieurs fichiers, à plusieurs destination, par plusieurs threads...)
- pas de sauvegarde compressées (permettant de réduire le temps de génération de la sauvegarde)
- la durée des sauvegardes et plus encore la durée de la restauration sont des opérations prohibitives pour de grosses bases.
Pas vraiment un logiciel libre :
- il n'est pas open source (http://www.xaprb.com/blog/2008/05/14/mysql-free-software-but-not-open-source/)
il convient de payer la licence :
- soit paiement sous forme de code : vous ne payez pas la licence, mais mettez le code de votre appli à la disposition de tous
- soit paiement sous forme de licence
Car en choisissant l'option GPL, soit disant gratuite, cela contamine le code de votre application. Lire la discussion suivante : http://www.developpez.net/forums/d1133986/bases-donnees/decisions-sgbd/choix-sgbd/#post6264561
aucune garantie :
Voici ce que donne certaines sorties de message d'outils MySQL :
Copyright (c) 2000, 2010, Oracle and/or its affiliates. All rights reserved.
This software comes with ABSOLUTELY NO WARRANTY. This is free software,
and you are welcome to modify and redistribute it under the GPL v2 license
S'agissant de logiciels libre, de manière générale, la dissolution des responsabilité pose de grave problème aux éditeurs qui l'oublient trop souvent. En effet, si un logiciel est mis en cause dans un accident par exemple (comme ce fut le cas du surdosage mortel de l'appareil de radio thérapie d'Épinal) l'éditeur ne peut se retourner contre le fabriquant de MySQL puisque sa licence exclu d'emblée toute responsabilité. Il ne reste plus à l'éditeur qu'a tester toutes les possibilité ce qui peut s'avérer long fastidieux et horriblement couteux !
Correction des bugs :
Du fait de l'absence des responsabilités, l'éditeur n'est pas tenu de corriger ses principaux bugs, et c'est ce qu'il semble faire dans la pratique, privilégiant la sortie de "nouveautés" peu abouties au détriment de la corrections des défauts existants...
D'autant que certains bugs font froid dans le dos en matière de sécurité ! Par exemple celui de la troncature des chaînes de caractères... A lire : http://www.mcherifi.org/hacking/la-faille-mysql-column-truncation.html
Vous avez dit performances ? On plaisante !
Enfin, certains affirment haute et fort que MySQL est le plus rapide des SGBDR... C'est peut être vrai, à condition de n'avoir jamais qu'un seul utilisateur... En effet, dans tous les benchmarks comparatifs et ce depuis plus d'une décennie, MySQL devient un escargot dès que la concurrence fait rage, face à des SGBDR bien conçus comme PostGreSQL, Oracle, IBM Db2, Sybase ou SQL Server... En particulier après 5 utilisateur, MySQL commence à plonger !
Quelques exemples parmi d'autres :
http://www.randombugs.com/linux/mysql-postgresql-benchmarks.html
http://tweakers.net/reviews/657/1/database-test-dual-intel-xeon-5160-introduction.html
http://jayant7k.blogspot.com/2008/06/mysql-versus-postgresql.html
Un petit benchmark comparant MySQL, PostGreSQL et MS SQL Server sur une requête un peu compliquée mais avec une seule table en lecture....
On y relève que MySQL est 1000 fois moins rapide que PostGreSQL et 6000 fois moins que SQL Server.. une paille !
Un large choix de moteur ?... de qui se moque t-on !!!
On nous assène à longueur de temps que la joie dans MySQL c'est qu'il dispose de plusieurs moteurs... Et l'on présente cet argument comme très intéressant. Mais c'est prendre les gens pour des imbéciles :
- chaque moteur ayant des limites et spécificité différentes je ne peut pas avoir SIMULTANÉMENT certaines fonctionnalités. Par exemple il est impossible d'avoir à la fois l'indexation textuelle et les transactions !
- la syntaxe des commandes dépend du moteur. Si vous êtes éditeur et que votre client n'utilise que tel moteur, alors il vous faut récrire une grande partie de l'application...
- les développeurs doivent apprendre plusieurs syntaxes en fonction des commandes spécifiques de MySQL et comme ils ne le retiennent pas, il doivent sans arrêt corriger leur code, d'où une perte de temps de développement.
En fait ce choix de moteurs cache l'incapacité de faire un outil homogène du fait des problèmes techniques interne à MySQL... Bref, l'oin d'être un avantage, cela constitue l'un des inconvénients majeurs de MySQL...
Ce qui est dommage c'est qu'il existe un SGBDR réellement libre et parfaitement bien conçu : PostGreSQL...
Ce qui explique le succès de MySQL est le lobbying qu'a fait la société MySQLAB en fourguant son SGBD à de nombreux hébergeurs gratuitement afin de noyer la concurrence. Opération brillamment réussie, mais quand on voit les dégâts que cela fait en production... En effet, nombreux sont les sites web marchand, qui, par exemple lorsque la montée en charge se fait sentir sont incapable d'absorber la charge...
Il n'est qu'a voir les nombreuses critiques et les problèmes sans noms, les crash et autres arrêt intempestifs qui émaillent les forums consacrés à ce pseudo SGBDR...
Forums MySQL de DVP
Forums MySQL de MySQL AB / SUN / Oracle
Pour poursuivre votre lecture sur les erreurs incroyables de MySQL :
http://sql-info.de/mysql/gotchas.html
http://www.productcriticblog.com/2007/03/who-else-wants-to-use-postgressql.html
http://casey.shobe.info/documents/mysql_limitations/
Bref, j'ai l'impression que MySQL n'est qu'un gigantesque brouillon !
--------
Frédéric Brouard, SQLpro - ARCHITECTE DE DONNÉES, http://sqlpro.developpez.com/
Expert bases de données relationnelles et langage SQL. MVP Microsoft SQL Server
www.sqlspot.com : modélisation, conseil, audit, optimisation, tuning, formation
* * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *
Social Bookmarking:
Commentaires, Pingbacks:
Commentaire de:
Zabriskir [Membre]
J'ai des problèmes de performances sur une application propriétaire qui tourne avec Firebird. Je ne sais pas si cela vient du SGBD lui-même ou des développeurs de l'appli...
Très bon billet.
21/07/2010 @ 13:42
Commentaire de:
tulipebleu [Membre]
Oui c'est vrai, MySQL n'a pas toutes les fonctionnalités des concurrents, mais de la a dire que MySQL n'est pas un SGBD.
Si vous ne l'aimez pas, parfait, ne l'utilisez pas. Mais ne faites pas croire qu'il est tellement null qu'aucun projet ne l'utilise.
Google l'utilise pour son moteur de recherche.
A titre presonnel, je trouve MySQL beaucoup plus rapide pour faire des select, update, delete qu'Oracle. Mes tests automatisé mette 3h30 en MySQL et 4h en Oracle.
Et en parlant d'Oracle, il y a quelques années, j'ai installé Oracle Express sous windows sur un PC. A la fin de l'installation du PC, l'alimentation a commencé à faire des étincelles, et elle a grillé. Je l'ai donc installé sur un autre PC, et la c'est la carte graphique qui est morte. Comme quoi le SGBD d'Oracle est un très bon surconsommateur de ressource. Si on arrive a l'installé sur un PC, alors on peu dire qu'il a au moins plusieurs mois à vivre.
21/07/2010 @ 13:56
Commentaire de:
tulipebleu [Membre]
http://www.mysql.fr/customers/
21/07/2010 @ 13:58
Commentaire de:
daredare [Membre]
....
Si Google utilise MySQL, ce n'est certainement pas pour leur moteur de recherche !
Quant à Oracle Express, je l'ai installé "il y a quelques années" sur un PC modeste (HP Pavilion P4 2 GHZ, 2Go de RAM, Windows 2000 serveur), et je n'ai pas rencontré de souci. Par contre, un jour, en mangeant des cacahuètes, mon PC a pris feu ! Faut-il y voir une relation de cause à effet ?
Ceci étant, je ne suis pas un expert BDD, mais je trouve ce billet tout bonnement excellent (sans compter la poilade liée aux commentaires ;-).
21/07/2010 @ 14:14
Commentaire de:
sqlpro [Membre]
· http://sqlpro.developpez.com
tulipebleu : Google utilise sans doute MySQL mais pour quelle fonctionnalité ? En général c'est pour du stockage de données sans aucune concurrence de mise à jour. Pas vraiment l'usage standard d'un SGBDR, mais plus du COBOL amélioré ! Quand aux listes, cela ne veut rien dire, surtout lorsqu'elles viennent de l'éditeur lui même. En revanche MySQL n'est présent dans aucun site de records de volume comme www.wintercorp.com ni de benchmark officiel comme tpc.org...
En comparaison PostGreSQL possède quelques records non négligeables... http://www.computerworld.com/s/article/9087918/Size_matters_Yahoo_claims_2_petabyte_database_is_world_s_biggest_busiest
daredare : je crois effectivement qu'en matière de commentaires, il va y avoir du sport !!!
21/07/2010 @ 18:44
Commentaire de:
cinephil [Membre]
Ce SGBD n'est certes pas le meilleur mais leur est suffisant... jusqu'au jour où le petit site qu'il ont plus ou moins bien développé rencontre le succès et qu'ils sont obligés de faire appel à des spécialistes comme toi pour leur expliquer pourquoi leur bébé est devenu un escargot.
A titre perso, ce qui m'a décidé à passer à Postgresql pour ma BDD perso, c'est l'absence de contrainte CHECK dans MySQL.
21/07/2010 @ 23:46
Commentaire de:
sqlpro [Membre]
· http://sqlpro.developpez.com
22/07/2010 @ 08:47
Commentaire de:
cinephil [Membre]
22/07/2010 @ 09:21
Commentaire de:
tempoxav [Membre]
- perfs démultipliées sur les multi-coeurs (un séminaire de 4 heures à Paris a détaillé cela devant 140 participants assidus)
- online backup
- performance schema
Un peu de prétention en moins ça aurait fait mieux : allez tous voir les pres et retour d'expérience de Mark Callaghan sur la perf MySQL : il est resp BD de Facebook, après l'avoir été chez Google, avoir été à la R&D Oracle et R&D Informix.
Je rajouterais des paiements CB, des transactions de bourse qui sont gérées par des bases MySQL pour des millions de transactions par jour. transactionnel MySQL ?
Bcp comme vous voudrait reproduire la même architecture avec MySQL que celle utilisée avec MS SQL : c'est une erreur car le design n'est pas le même.
PostGreSQL et les autres bases sont bonnes et vont dans la course à la fonctionnalité. MySQL a suivi une autre approche :
MySQL a été conçue pour la légéreté, la performance, la scalabilité (parler nous de la réplication PostGreSQL,... dans la vraie vie) et la fiabilité.
MySQL ne fait pas la course à la fonctionnalité, car cela amène de la lourdeur et des problèmes de fiabilité!
MySQL c'est juste différent et ça répond à un besoin. Au moins il y a du vrai choix en terme d'architecture pour les utilisateurs!
Rappel : 100 Millions d'installations actives
ce n'est plus un hasard!
22/07/2010 @ 11:26
Commentaire de:
sqlpro [Membre]
· http://sqlpro.developpez.com
Encore une fois facebook est un très mauvais exemple sur le plan des performances transactionnelles, car il n'y a aucune concurrence de mise à jour dans le site... En effet, chaque abonné ne peut modifié que sa propre page, il n'y a donc jamais qu'un seul processus concurrent en écriture ! Or faire des transactions sur une non concurrence revient à ne pas faire de transaction du tout !
En sus, les paiements CB sont généralement externe (solutions propres aux banques) et sont là, fait sur du Oracle ou du IBM DB2....
Quand à parler de fiabilité pour MySQL, je crois que c'est une plaisanterie vu le nombre de posts dans lequel le serveur plante. Personnellement, je n'ai jamais vu un serveur MS SQL, ou Oracle ou IBM DB2 planté, sauf en cas de panne matérielle grave (CPU par exemple).
Enfin, les nombres que vous annoncez en terme d'installations, sont basés sur aucune étude sérieuses et les études sérieuses de Gartner par exemple ne peuvent même pas mesurer les PDM de MySQL tellement elles sont infimes (Gartner a établi de son côté qu'ils [les SGBDR open source] représentent moins de 1% du marché). Il est vrai que si c'est 100 millions d'installation chez des particuliers, cela ne rime à rien !
Un petit exemple de ce que le moteur SQL ne sait pas optimiser (alors que les autres le font) est donné par Peter Gulutzan dans cette vidéo.
22/07/2010 @ 12:42
Commentaire de:
Smashou [Membre]
· http://www.vincentgache.com
* Il est suffisant pour de petites applications qui n'auront pas forcément propension à grossir (exemple de nombreux développements interne dans les sociétés pour faire du partage de planning, de la petite CRM, de l'édition de facture simple, ...)
* On peut dire ce que l'on veut sur le coût, mais cela ne revient pas au coût de SQL server ou Oracle et loin de là.
* Enfin pour les petites structures, installer un SQL server ou un Oracle à un coût bien trop important et demande malgré tout des connaissances supérieures qui coûtent encore une fois très chère! N'oublions pas que, malheureusement, c'est l'argent qui fait tourner les entreprises!
Et bien heureusement qu'il a été offert aux hébergeurs, vous imaginez les coûts liés aux hébergements mutualisés sinon?!
On est tous d'accord que Mysql est loin d'être le SGBD parfait, mais il est tout de même amplement suffisant pour un nombre gigantesque de cas! (Personnellement je trouve cela parfaitement idiot d'installer, par exemple, un Oracle pour une petite application qui possède 5 utilisateurs..., allez justifier les coûts auprès du client après...).
N'oublions pas SVP qu'il y a beaucoup plus de petites structures dans le monde que de grosses!
Enfin je suis tout à fait d'accord sur les qualités de PostGreSQL qui n'a malheureusement pas connu la même publicité que Mysql.
Je m'excuse d'avance, votre argumentaire n'était pas basé sur ces points et était plutôt orienté sur la technique. Mais mon commentaire à plus une vocation à complémenter le votre qu'a le démonter.
22/07/2010 @ 17:50
Commentaire de:
sqlpro [Membre]
· http://sqlpro.developpez.com
En définitive, il n'y a pas de temps gagné en choisissant MySQL (je dirais même qu'il y a beaucoup de temps perdu pour contourner les nombreuses fonctionnalités manquante sans parler des bugs...) et qu'au final le choix de ce SGBDR peut couter très cher à un moment critique ! (celui du passage à un vrai SGBDR).
23/07/2010 @ 11:14
Commentaire de:
Chtulus [Membre]
Salut Fred,
Tu pourrais juste me donner des explications rapide là dessus s'il te plait ?
- les opérations de lecture des méta données ne sont pas transactionnelle (on peut donc obtenir un résultat faux).
- du fait que les tables sont stockées chacune dans un fichier différent, leurs noms peut être sensible ou non à la casse
Ça par contre c'est énorme !
- des index sur des colonnes calculées ou des expressions sont impossibles
;-)
25/07/2010 @ 17:44
Commentaire de:
sqlpro [Membre]
· http://sqlpro.developpez.com
les opérations de lecture des méta données ne sont pas transactionnelle (on peut donc obtenir un résultat faux) :
En effet, MySQL ne stocke pas les méta données des bases dans des tables systèmes, mais parcoure les différents objets pour les présenter sous forme tabulaire. Pendant qu'il effectue ce travail, la structure des objets peut changer ! Dans les SGBDR bien fait, cela est fait à l'aide de table système qui sont verrouillées (par exemple sous SQL server, verrous de type Sch-M et Sch-S pour verrou de schéma Modif et Shared) le temps de lire ou de modifier la structure de l'objet, garantissant ainsi l'aspect transactionnel !
du fait que les tables sont stockées chacune dans un fichier différent, leurs noms peut être sensible ou non à la casse :
En effet suivant le système d'exploitation retenu (Distribution Linux, Editions Windows, Novell, Solaris, UX, AIX...) les noms des tables seront plus ou moins limités car ils sont très dépendant de l'OS (au départ dans MySQL : une table = un fichier...)
des index sur des colonnes calculées ou des expressions sont impossibles :
MySQL ne supporte pas les colonnes calculées, donc pas d'indexation non plus dessus. MySQL ne supporte pas non plus la création d'index sur fonction, sauf dans un cas particulier : une fonction limitant le nombre de caractère dans le cas d'une colonne littérale.
26/07/2010 @ 14:33
Commentaire de:
Chtulus [Membre]
Merci pour ces explications !
Énorme ^^
@ Bientôt
26/07/2010 @ 23:19
Commentaire de:
dbaffaleuf [Membre]
Et on dira ce qu'on veut, mais ni Larry Ellison, ni Dave Campbell ni Bob Epstein n'ont écrit leur SGBD sans une équipe solide avec eux. Monty, lui, était tout seul avec son vi et son gcc.
David B.
17/08/2010 @ 17:10
Commentaire de:
-kiki- [Membre]
Par avance, excusez moi si je suis à côté de la plaque mais je suis développeur php (pour vous donner une idée du niveau en sql :p) et je ne connais que Mysql (je n'ai donc aucun point de comparaison)
1- Vous dites qu'il n'y a pas de mécanisme "haute disponibilité". Que faites-vous du Cluser Mysql?
2- L'exécution parallèle des requêtes serait limitée? Pourtant je pense qu'il n'y a que Mysql qui permette à 2 threads de lire et écrire en même temps sur la même table. niveau parallélisation c'est plutôt pas mal!
3- l'utilisation outrancière des tables temporaires... il ne tiens qu'à nous d'écrire des requêtes qui ne necessitent pas de tables temporaires! (pas toujours possible j'avoue.)
4- l'index full text "poudre aux yeux" ? je dirais plutôt outil moyennement performant mais très pratique pour les boulets du sql comme moi car très simple.
5- Mysql deviendrait problématique lorsque le site deviens trop gros? Alors là vous ne jouez pas dans la même catégorie que la pluspart des entreprises! Et ce commentaire concerne finalement peu de monde (je pense). En ce moment par exemple je bosse pour un site relativement gros, il y a un seul serveur mysql qui se prend 600 connexions secondes avec des requêtes pas toutes optimisées, et ça tourne plutôt pas mal...
Pour vous, un site "qui deviens gros" c'est quoi? 10K connexions secondes? C'est quoi vos sites? Youtube?
En suite, y'a un ptit truc que je trouve magique dans Mysql, et je ne sais pas si des moteurs de tables d'autres sgbdr savent le faire...
roulements de tembours... :)
mettre des champs à taille dynamique en RAM! (comme Varchar ou Text)
Si seul Mysql sais le faire, c'est quand même la honte pour tous les autres!
(je dis ça car innoDB de mysql ne sais pas le faire, j'imagine donc que innoDB des autres sgbdr ne savent pas non plus)
@tempoxav : Mysql 5.5?? la dernière version stable c'est pas 5.1 par hasard?...
14/09/2010 @ 17:25
Commentaire de:
-kiki- [Membre]
Peut-on mettre les tables InnoDB en RAM?
Je vais me renseigner, mais je pose la question au cas où... et pour montrer qu'en fait j'en sais rien.
(c'est la fin de journée, faut être indulgents :p en fait je pensais aux tables HEAP quand je disais qu'on ne pouvait mettre des champs à taille dynamique en RAM)
14/09/2010 @ 17:38
Commentaire de:
-kiki- [Membre]
j'ai encore une remarque :
6- pas de collation insensible aux accents?? pour ne prendre qu'un exemple : utf8_unicode_ci est insensible à la casse et aux accents (comme prévu)
et j'ai une autre remarque pour tempoxav :
Mysql fiable?? je ne connais pas d'autres sgbdr, mais à partir du moment où il y a des bugs je ne considère pas mysql comme fiable! Et j'ai vu plusieurs fois Mysql sortir de jolis bugs sur des requêtes bien faites (lourdes, mais bien faites).
A mes yeux, Mysql est un bon sgbdr, mais seulement si on est peu regardant sur la fiabilité (cohérence des données ou bugs), ce qui est tout de même le cas pour la majorité des sites de contenu, qui eux même représentent une grosse partie des sites web.
Du coup je rejoins finalement tempoxav sur un point : Mysql or not Mysql, ça dépend de nos besoins. Enfin, je crois... :)
15/09/2010 @ 14:01
Commentaire de:
sqlpro [Membre]
· http://sqlpro.developpez.com
kiki
1- Vous dites qu'il n'y a pas de mécanisme "haute disponibilité". Que faites-vous du Cluser Mysql?
Il s'agit avant tout d'une solution système et non au niveau du SGBDR. Par exemple sous PostGreSQL et SQL Server vous avez le log shipping, sous SQL Server vous avez le mirroring, la réplication et Service Broker, sous Oracle, le système RAC....
Bien entendu, tous les OS modernes proposent des solutions de gestion de cluster depuis des années. Pas exemple la solution Microsoft Windows Cluster existe depuis la version 2000 de Windows... Il suffit que le logiciel soit conçu pour être "cluster aware" !
2- L'exécution parallèle des requêtes serait limitée? Pourtant je pense qu'il n'y a que Mysql qui permette à 2 threads de lire et écrire en même temps sur la même table. niveau parallélisation c'est plutôt pas mal!
Tous les SGBDR sauf MySQL savent paralléliser les écritures et lectures, et même les calculs d'agrégats sur TOUS les CPU simultanément. Actuellement SQL Server a été testé avec 96 CPU en //. MySQL est donc très loin du compte !
3- l'utilisation outrancière des tables temporaires... il ne tiens qu'à nous d'écrire des requêtes qui ne nécessitent pas de tables temporaires! (pas toujours possible j'avoue.)
D'autant moins possible que comme MySQL n'implémente ni les requêtes récursives (voir : SQL récursif ), ni les fonctions OLAP, de ranking ou les fonctions analytiques (voir : fonctions fenêtréess ), la plupart du temps il faudra y recourir, alors que sous PostGreSQL, Oracle ou SQL Server cela existe depuis des années (norme SQL 1999) !
4- l'index full text "poudre aux yeux" ? je dirais plutôt outil moyennement performant mais très pratique pour les boulets du sql comme moi car très simple.
Lisez le chapitre 8 de la dernière édition de mon livre sur SQL. Il est consacré à l'indexation textuelle selon la norme SQL. Il compare MySQL et SQL Server. Bref, sur 13 types de recherches textuelle, MySQL n'en supporte que 5 et encore avec beaucoup de manques comme une gestion multilangue des mots noirs. En comparaison, SQL Server en supporte 11 avec une gestion multilangue des mots noirs.
5- Mysql deviendrait problématique lorsque le site deviens trop gros? Alors là vous ne jouez pas dans la même catégorie que la pluspart des entreprises! Et ce commentaire concerne finalement peu de monde (je pense). En ce moment par exemple je bosse pour un site relativement gros, il y a un seul serveur mysql qui se prend 600 connexions secondes avec des requêtes pas toutes optimisées, et ça tourne plutôt pas mal...
Pour vous, un site "qui deviens gros" c'est quoi? 10K connexions secondes? C'est quoi vos sites? Youtube?
fnac.com, Amadeus, United Airlines, Musiwave, Euridile.... des bases de données de plusieurs TO avec SQL Server et quelques milliers d'utilisateurs simultanés.
france telecom, TGV .... des bases de données de plusieurs TO avec Oracle et quelques milliers d'utilisateurs simultanés.
En suite, y'a un ptit truc que je trouve magique dans Mysql, et je ne sais pas si des moteurs de tables d'autres sgbdr savent le faire...
roulements de tembours... :)
mettre des champs à taille dynamique en RAM! (comme Varchar ou Text)
Si seul Mysql sais le faire, c'est quand même la honte pour tous les autres!
(je dis ça car innoDB de mysql ne sais pas le faire, j'imagine donc que innoDB des autres sgbdr ne savent pas non plus)
Preuve que vous ne connaissez pas grand chose aux SGBDR. Tous les SGBDR fonctionnent exclusivement en RAM et le stockage sur disque est un épiphénomène lié à la persistance et aux limites des tailles des RAM ! Dans l'absolu on devrait pouvoir se passer des disques, ce qui n'est pas le cas de MySQL du fait de son architecture simplifié intimement liée à l'OS système... Tous les autres SGBDR intègrent un OS interne pour obtenir des performances nettement supérieures (notamment en terme de concurrence)...
6- pas de collation insensible aux accents?? pour ne prendre qu'un exemple : utf8_unicode_ci est insensible à la casse et aux accents (comme prévu)
Nous avons eu cette discussion sur le fil suivant : Critique MySQL
Il en ressort que piloter l'insensibilité aux accents est impossible. En effet, dans MySQL soit les collations sont sensibles à tout (casse et accents) soient sensibles à rien.. Aucune solution intermédiaire n'est disponible, par exemple CI_AS ou CS_AI.
De plus le terme de "accents sensitive" est trompeur. En effet, il ne s'agit pas que des accents mais de tous les caractères dit diacritiques... (diacritique : dia = 2, critique = différence, symbole composé de deux éléments qui le différencie). Par exemple la cédille, mais aussi les ligature comme l'e dans l'o de cœur, bœuf....
Allez donc faire comprendre à un utilisateur qu'il ne pourra jamais trouver de bœuf parce que MySQL ne sait pas faire !!!!
Enfin, il y a pire : la recherche dans l'index textuelle (Full Text Search) est victime du même phénomène...
Bref, inexploitable pour des sites web en langues latines (français, espagnol, italien...) !
Quand à a fiabilité, aucun logiciel n'est fiable à 100%. Même Oracle et SQL Server comportent de nombreux bugs, mais au moins les produits sont largement testés avant d'être diffusé et les outils de suivi de bugs (comme connect de Microsoft) sont efficaces et les corrections très réactives. Mais quand on a de nombreux bugs et que l'on préfère sortir des nouveautés à peine testées, il est difficile ensuite de les corriger !
19/09/2010 @ 13:33
Commentaire de:
-kiki- [Membre]
Certains types de tables de Mysql peuvent être mises en RAM (MyIsam compressé, NDBCluster...), je pensais que c'était un atout... en fait c'est un boulet car normalement (avec les autres sgbdr) les tables les plus utilisées sont automatiquement mises en RAM !?
Du coup PostgreSql devient séduisant, mais il y a 2 points que j'aimerai que vous développiez :
1- parler nous de la réplication PostGreSQL,... dans la vraie vie
(tempoxav, quelques commentaires plus haut)
2- L'implémentation PGPool II pour PostgreSQL réalise bien une répartition de charge en lecture sur plusieurs instances parallèles de PostgreSQL, mais présent un défaut majeur pour la clusterisation d'une base de données complète. En effet, la négociation des séquences lors d'écritures multiples provoque des erreurs de séries dans les indices, car ce mode de clusterisation n'intègre pas une synchronisation d'écriture dans les différentes bases.
Et puisque vous aimez les gros sites, pour ce 2eme point je tiens à préciser que c'est un extrait d'un compte rendu pour un gros projet (12000 tables et qq milliers d'utilisateurs simultanés) et qu'au final, Mysql a été retenu (pour son NDBCluster)...
Bref ma problématique générale est : PostgreSql semble souffrir de problèmes de réplication et de clusterisation. Qu'en est-il précisément? Peut-on contourner ces problèmes?
En tout cas, merci pour vos explications :)
En effet étant autodidacte et pas très expérimenté, je manque de connaissances.
21/09/2010 @ 15:09
Commentaire de:
sqlpro [Membre]
· http://sqlpro.developpez.com
Ce ne sont pas les tables qui sont mise en mémoire, mais les pages les plus lues. Ainsi si une table de 500 Go n'est fréquemment lue que pour ses données les plus récentes, ce seront les pages concernées qui persisterons en RAM. De manière générale, la mise en cache obéit à un algorithme du genre "plus j'ai demandé à lire (ou écrire) cette page, plus elle persistera longtemps". Inversement, les pages les moins lues dégageront en premier pour laisser la place aux suivantes.
En sus, comme tout ce qui est code dans une base de données (vue, procédure, fonction, déclencheur...) est en fait constitué de données dans des tables système, même le code SQL est donc mis en cache avec la même fréquence d'utilisation, y compris les plans de requêtes que génèrent lesdits codes.
Sur la réplication en général
La réplication ne consiste pas à dupliquer une base, mais à répliquer certaines informations de certaines tables d'une base à l'autre entre différents serveurs.
Dans une réplication, il n'y a aucune obligation que les tables soient identiques. En effet on s'intéresse à répliquer de l'information et non des objets !
Beaucoup confondent la réplication et la haute disponibilité. La haute disponibilité consiste à avoir une seconde base de données contenant les mêmes objets et données que la base source pour qu'en cas de défaillance de la base source on puisse utiliser la base de secours afin d'assurer une certaine continuité applicative.
L'intérêt de la réplication est double :
a) pouvoir augmenter la surface d'attaque des données (scale out) :
Par exemple en répliquant toutes les données de certaines tables d'une base sur plusieurs serveur, on peut servir plus de client qui utilise l'application.
MAIS... l'inconvénient de la chose est qu'une bonne partie des ressources physique des machines est occupé à gérer la réplication, et globalement, la puissance disponible pour servir les clients est très notablement amoindrie par le simple fait de l'exécution des processus de réplication.
En effet, pour cela soit intéressant il faudrait que la réplication soit faite en mode synchrone, hors c'est impossible, car cela reviendrait à verrouiller la même table sur tous les serveurs simultanément avec un allongement dramatique des temps de blocage lié au transit réseau. C'est pourquoi la réplication est toujours asynchrone et il vaut mieux pour la mobilisation des ressources que le temps de latence soit au moins que quelques minutes....
Ce n'est dont pas généralement une bonne solution, et en pratique on utilise cela en dernière limite lorsque le scale up n'est plus possible. Ainsi, si l'on ne peut pas changer le serveur actuel pour un serveur plus puissant (64 CPU, 512 Go de RAM et quelques centaines de To de disque en SAN...), on devra se résigner à faire du scale out, mais il faudra trouver un processus (toujours couteux) pour tenter de synchroniser les données (le commit à deux phases n'ayant aucune garantie de bonne fin...).
En fait il existe très peu de solutions fiables de scale out synchrone et c'est souvent très cher. Le seul exemple que je connaisse est Oracle RAC mais le prix des licences et le cout en installation/admin est extrêmement élevé. La solution proposée par MySQL est encore un embryon peu performant... En effet, allez donc lire les commentaires de ceux qui ont fait des benchmarks sur le sujet : http://forums.mysql.com/read.php?25,257168
Bref, en doublant les ressources on gagne pratiquement rien !!!
Bref, no silvestre boulette comme disent no cousins d'outre atlantique !
b) pouvoir découper une application en différentes bases fonctionnelle
Par exemple pour un site web marchand, on peut découper la base en deux : d'un côté la base "front office" qui présente les produits, les commentaires, les habitudes d'achat et le profilage des clients ainsi que les commandes passées.
De l'autre on peut avoir dans une base "back office" les éléments suivants : client, produits, commandes (données communes), mais aussi stock, facturation, expédition...
Dans ce cas on utilisera différents flux de réplication :
- l'un du BO vers le FO pour les nouveaux produits, avec par exemple un temps de latence de 24h
- l'autre du FO vers le BO pour toute nouvelle commande passée, avec par exemple un temps de latence de 5mn.
Ainsi chaque serveur est indépendant et l'arrêt du BO ne pénalise pas la vente !
C'est plutôt dans ce sens que la réplication est intéressante : le découplage de différentes bases de données et donc serveur qui fonctionnent en mode asynchrone afin de fournir un service complet et répartit.
C'est d'ailleurs dans ce sens qu'évolue les SGBDR aujourd'hui en base de données réparties.
12000 tables et qq milliers d'utilisateurs simultanés
Le nombre de table est élevé, mais ne signifie par forcément un volume de données gigantesque. Ce qui importe est plus le volume global et l'indexation. A ce titre MySQL ne sait pas gérer par exemple les matrices creuses (non stockage des NULL) et son indexation est plus que pauvre :
- pas d'index calculés
- pas d'index couvrant (INCLUDE)
- pas d'index partiaux ou filtrés (WHERE)
- pas de vues matérialisées ou indexées
- pas d'indexation possible des données XML ni SIG (spatial)
Le nombre d'utilisateur simultané supportable par un serveur unique du type SQL Server, oracle ou IBM DB2 est de plusieurs dizaines de milliers en pratique. Mais à cela, il faut la machine correspondante. Pensez à fnac.com, tgv.com, amadeus ou encore euridile, des bases ayant régulièrement des pics à plusieurs dizaines de milliers d'utilisateurs sans broncher, avec un très fort aspect transactionnel, contrairement à facebook qui ne fait quasiment aucune transaction ! (et pour lequel la perte de données et de transactions est acceptable !!!
Bref ma problématique générale est : PostgreSql semble souffrir de problèmes de réplication et de clusterisation. Qu'en est-il précisément? Peut-on contourner ces problèmes?
En définitive, si vous avez réellement ce besoin, je ne choisirait ni MySQL ni PostGreSQL qui ne sont pas encore au point sur ces technologies. Je prendrais Oracle ou SQL Server (ces deux éditeurs maîtrisant ces concepts en production depuis plus d'une décennie) et ce choix à terme à toutes les chances de s'avérer bien moins cher que d'investir sur du soit-disant gratuit qui peut s'avérer très couteux en terme matériel et plus encore en terme d'administration voire catastrophique en cas de perte de données !
30/09/2010 @ 13:42
Commentaire de:
ok.Idriss [Membre]
· http://ineumann.developpez.com/
M'enfin bon, je travaille beaucoup avec les deux mais un des facteur qui fait que MySQL est plus utilisé dans le Web c'est les hébergeurs (gratuits du moins), il ne proposent pas tous l'administration d'une base Postgre (MySQL) et c'est bien dommage ...
C'est dommage parce que Postgre est tout aussi bien géré dans la quasi-totalité des langages permettant l'utilisation de SGBD (en PHP notamment) et il force les développeurs à respecter les schémas relationnels et leur différentes contraintes. [Et puis je n'ai jamais vue de tables corrompues avec Postgre].
Cordialement,
Idriss
08/10/2010 @ 18:52
Commentaire de:
sqlpro [Membre]
· http://sqlpro.developpez.com
C'est normal : MySQL vient d'une société commerciale qui a fait du lobbying pour être présent chez tous les hébergeurs et a plutôt bien réussit son coup puisque grâce à cela elle a bien sut se vendre à SUN puis Oracle. En revanche PostGreSQL n'appartient à personne et il n'y a aucune compagnie au cul pour la pousser quelque part...
Bien souvent en informatique on se retrouve avec des outils populaires, mais médiocre. Cela a été le cas avec les premiers PC dont le choix de microprocesseur a été le plus mauvais. Il a fallu près de 30 ans pour en faire quelque chose d'acceptable !
31/10/2010 @ 18:05
Commentaire de:
ok.Idriss [Membre]
· http://ineumann.developpez.com/
04/11/2010 @ 21:23
Commentaire de:
sqlpro [Membre]
· http://sqlpro.developpez.com
C'est pourquoi je recommande plutôt PostGreSQL qui est du vrai libre et largement plus professionnel que MySQL très limité et brouillon !
05/11/2010 @ 09:24
Commentaire de:
sqlpro [Membre]
· http://sqlpro.developpez.com
http://www.siteduzero.com/forum-83-578392-p1-quel-interet-de-faire-cette-requete.html#r5596787
http://www.siteduzero.com/forum-83-578392-p1-quel-interet-de-faire-cette-requete.html#r5597752
Croustillant non ? C'est la problématique des types ENUM !
Problématiques du type ENUM :
mysql>
SELECT x, x+1, x-1, x=1, x='3'
FROM meeeeeh;
+------+------+------+------+-------+
| x | x+1 | x-1 | x=1 | x='3' |
+------+------+------+------+-------+
| 3 | 2 | 0 | 1 | 1 |
+------+------+------+------+-------+La solution est bien sûr que x est un ENUM( '3','2' ). Or ENUM est en interne un entier, et par la magie des couches d'abstraction poreuses, x est donc compatible avec toutes les opérations sur les entiers, comme +, -, etc. Comme '3' est la première étiquette de l'ENUM, '3' vaut 1 (attention aux quotes). Donc '3'+1 vaut 2, logique. Bien évidemment la signification de tout INSERT ou UPDATE dépend de la présence de quotes ou non autour de la valeur.
Autres exemples :
mysql>
CREATE TABLE meeeeeh
(x ENUM( '3','2' ),
y ENUM( '3','2' ),
z ENUM( '2','3' ),
peutetre ENUM( 'true','false'));
mysql>
INSERT INTO meeeeeh
VALUES (1, NULL, NULL, 1),
(2, NULL, NULL, 0);
mysql>
SELECT *
FROM meeeeeh;
+------+------+------+----------+
| x | y | z | peutetre |
+------+------+------+----------+
| 3 | NULL | NULL | true |
| 2 | NULL | NULL | |
+------+------+------+----------+
mysql>
UPDATE meeeeeh
SET y = x+1,
z = x;
mysql>
SELECT *
FROM meeeeeh;
+------+------+------+----------+
| x | y | z | peutetre |
+------+------+------+----------+
| 3 | 2 | 3 | true |
| 2 | 3 | 2 | |
+------+------+------+----------+
mysql>
UPDATE meeeeeh
SET y = x+1,
z = x+0,
peutetre = NOT peutetre;
mysql>
SELECT *
FROM meeeeeh;
+------+------+------+----------+
| x | y | z | peutetre |
+------+------+------+----------+
| 3 | 2 | 2 | |
| 2 | 3 | 2 | true |
+------+------+------+----------+Quel florilège ! Ce truc rend fou. Certains défendent bec et ongles l'utilité du type ENUM : une bonne question pour un entretien d'embauche, je pense.
Bien évidemment modifier la liste des valeurs de l'enum nécessite un ALTER TABLE avec réécriture complète de la table (et des index) et lock exclusif (ZZZzzzzz).
mysql>
SELECT 0 IN ('a','b');
+----------------+
| 0 IN ('a','b') |
+----------------+
| 1 |
+----------------+Ici, on a un mariage consanguin avec PHP où on trouve les mêmes tares génétiques (où 0 vérifie toujours la première étiquette d'un switch case si celle-ci est une chaîne par exemple) ; cette petite subtilité mysqliste ne manque pas de se manifester dans les cas les plus inattendus ; on trouve de nombreuses variantes, par exemple il est tout à fait possible d'ajouter un nombre à une date et d'obtenir n'importe quoi, la date étant réinterprétée comme un nombre.
Problématique des types entiers :
Pour ce qui est des INT et UNSIGNED qui font des overflow et reviennent à 0, c'est sidérant (en plus ça dépend de la version 32/64 bits).
mysql>
CREATE TABLE truc
(x INT PRIMARY KEY );
mysql>
INSERT INTO truc
VALUES (10),(20),(19),(30);
mysql>
UPDATE truc
SET x = x/2;
ERROR 1062 (23000): Duplicate entry '10' for key 'PRIMARY'
mysql>
SELECT *
FROM truc;
+----+
| x |
+----+
| 5 |
| 10 |
| 19 |
| 30 |
+----+Cas classique : utilisation d'UPDATE sur plusieurs lignes d'une table MyISAM, ça se passe mal. Pas de rollback possible... et c'est toujours le moteur par défaut...
Autres problématiques :
Il y en aurait beaucoup d'autres, un plus sérieux est : l'obtention d'une valeur de la PK auto_increment sur une table InnoDB est soumise à un gros lock, résultat en cas d'inserts massifs multiprocessus, ce petit goulot d'étranglement limite tout.
Et je termine sur l'index FULLTEXT que tu as l'air de beaucoup aimer : as-tu remarqué que toute modification de la table entraîne la modification d'une grande partie de l'index ? Si l'index ne rentre pas dans le key_buffer (en RAM), paf, tu insères un post de forum, 300 Mo d'IO... ça m'avait couché un serveur XD
12/11/2010 @ 14:27
Commentaire de:
cinephil [Membre]
http://www.developpez.net/forums/d998839/bases-donnees/mysql/inserer-espace-champ/#post5591140
Si une donnée n'est constituée que d'un espace, c'est équivalent à la chaîne vide !
15/11/2010 @ 09:09
Commentaire de:
-kiki- [Membre]
Pour ce qui est du type ENUM, pour moi le seul problème est l'obligation de faire un "alter table" quand on veut ajouter un type. (problème proportionnel à la taille de la table^^)
Son fonctionnement, lui, est tout à fait compréhensible! On m'avait déjà renvoyé vers ce topic du site du zero, mais ça n'a fait que confirmé ce que je pensais avoir compris... je trouve tout ça assez logique!
Je ne dis pas que ça respecte la norme, mais encore une fois, sortir de la norme pour faire un outil pratique n'est pas blâmable (sauf que là, l'outil a un gros problème, mais ça aurait pu être un outil intéressant)
15/11/2010 @ 12:49
Commentaire de:
sqlpro [Membre]
· http://sqlpro.developpez.com
15/11/2010 @ 23:23
Commentaire de:
-kiki- [Membre]
Je ne l'ai encore jamais fait, et j'en aurais eu besoin. Je harcelais mon hébergeur pour qu'il mette à jour Mysql (ma version actuelle ne permettait pas les partitions)
Mais depuis que j'ai lu ce topic, j'ai laissé en suspend...
Le partitionnement "contre performant"... Comment est-ce possible? dans quelle mesure est-il contre performant?
J'ai des opérations marketings qui nécessitent chacune plusieurs centaines de milliers d'enregistrements, avec pas mal de lecture/écriture (et ponctuellement, quelques stats à sortir). Dans ce cas, si je partitionne la table pour chaque opé marketing, ce sera moins performant que tout laisser d'un bloc?? (sachant qu'aucune requête n'ira chercher les informations de plusieurs opé simultanément)
ps : désolé, j'ai l'impression de "sous-traiter" mon taff^^ mais je n'ai pas l'occasion de faire de réels tests
16/11/2010 @ 10:09
Commentaire de:
sqlpro [Membre]
· http://sqlpro.developpez.com
1) une gestion des espaces de stockage permettant par exemple de prétailler les "storage" pour pouvoir recevoir n Go de données, ceci afin d'éviter les croissance de fichier et l'inévitable fragmentation physique qui va avec...
2) que le volume de la table partitionnée dépasse la capacité d'un disque
3) qu'on puisse définir des partitions "READ ONLY" c'est à dire faire des lectures sans verrou
4) que l'on puisse partitionner les index indépendamment de la table
5) que la colonne de partitionnement fasse partie d'un critère WHERE de la grande majorité des requêtes, avec un prédicat sargeable et en tête du vecteur de recherche s'il y a lieu
6) que l'on puisse gérer les partitions : fusion, découpage, permutations...
etc...
A lire :
http://blog.developpez.com/sqlpro/p9286/langage-sql-norme/partitionner-vos-tables-pour-ameliorer-l/
Aucune des fonctionnalités spécifique au SGBDR pour pouvoir faire du partitionnement n'est implémenté sous MySQL (points 1, 3, 4, 6). Pour le point 2 c'est en fonction du volume de la table et pour le point 5 c'est à vous d'écrire correctement vos requête.
Bref, ce que fait depuis longtemps Oracle, IBM DB2 ou SQL Server, MySQL n'en arrive même pas à la cheville. C'est inexploitable... C'est ce que je dénonce sous le terme de fonctionnalité poudre aux yeux !
A +
17/11/2010 @ 10:33
Commentaire de:
-kiki- [Membre]
Le seul critère que je remplissais était le point 5 : la colonne de partitionnement fait partie de TOUS les WHERE. je voulais partitionner pour pouvoir simplifier les indexs composés (j'ai peur d'avoir des problèmes de perfs avec plusieurs gros indexs, car avec le temps la table va devenir énorme...).
L'idée est-elle mauvaise? La gestion des partitions est-elle lourde au point d'être moins performante qu'ajouter la colonne en question dans chaque index?
(a lire votre dernier post je me doute de la réponse, mais j'aimerai confirmation)
17/11/2010 @ 11:46
Commentaire de:
sqlpro [Membre]
· http://sqlpro.developpez.com
Déjà que MySQL ne sait pas faire du parallélisme d'accès sur les disque pour répartir les IO d'une même requête... Alors je me marre doucement sur l'intérêt du partitionnement !
A +
21/11/2010 @ 10:49
Commentaire de:
jacqueline [Membre]
Je suis une utilisatrice modeste des bases de données.
J'ai découvert MySQL lorsqu'une amie m'a suppliée de lui faire un site de e-commerce, avec un CMS , bien sur.
Au niveau de l'utilisation de MySQL les CMS c'est encore l'étage en dessous : un seul user avec les mêmes droits sur toutes les tables, connecté en permanence.. On ne distingue même pas le simple visiteur du client authentifié.
Puis est arrivé le rachat de Sun par Oracle. Panique à bord dans le monde du libre ! Et là on découvre que c'est pas si libre que ça et que le coté gratuit peut disparaitre du jour au lendemain..
J'ai pas trop paniqué parce que j'avais un OpenBSD et PostgreSQL, une occasion de voir l'autre SQL.
Je découvre ça seule chez moi, ça me semble plus compliqué que MySQL, mais par exemple sur les transactions , je comprend bien l'exemple qui est donné : "on ne débite un compte bancaire que lorsque l'autre est crédité, sinon on efface tout"( merci !!! ) et quelques autres exemples dans le genre.. Par exemple les clés qui sont mieux expliquées que dans MySQL et leur rôle dans la sécurité des données ou l'intégrité de la base.
Ca m'a donné envie de poursuivre avec PostgreSQL.
La licence , il me semblait qu 'à une époque c'était une licence BSD, je viens de voir que c'est une Licence PostgreSQL, mais leur modèle économique m'a rassurée, ils ne sont pas pendus à une seule boite, qui peut se faire racheter lorsqu 'elle s'endort sur ses lauriers.. ( les ZZ Tops sont fatigués ? )
Les boites utilisatrices qui apportent l'argent nécessaire au développement , ne sont que des "sponsors". parmi elles il y a Sun , mais ça ne remet pas tout en cause.
L'été dernier j'avais acheté une revue qui présentairt la version 8.0, mais il faut laisser le temps d'assimiler toutes ces nouveautés.
Je ne suis pas une intégriste du libre , mais aujourd'hui c'est le tour d' OpenOffice, après c'est le tour de Novell et d'OpenSuse ( mais eux s'ils coulent c'est pas un malheur avec le souq qu'ils ont mis par rapport à la Suse version Derrick, assez bien déboguée ).
Plus du tout envie de me former davantage à MySQL qui peut disparaitre du jour au lendemain si l'autre a un pêt de travers.
En tous cas merci de ce sujet comparatif, qui me sera fort utile quand je replongerais dans PostgreSQL.
26/11/2010 @ 22:38
Commentaire de:
jacqueline [Membre]
Au vu des premières pages, ça me semble bien fait, parce que j'ai horreur des tutos : fais ci , fais ça, et puis voilà , ça y est !
Résultat on a rien capté des principes.
super :)
26/11/2010 @ 22:52
Commentaire de:
-kiki- [Membre]
Pour moi c'est une aubaine ce rachat : Mysql n'était pas vraiment libre? Qu'à celà ne tienne, MariaDB le sera! :) (enfin... j'ose espérer^^)
Faire un site de commerce sous Mysql c'est effectivement pas top, mais utiliser une cms c'est vraiment mal^^.
L'utilisation de mysql, passe encore. Car les transactions existent sur mysql! c'est le moteur de stockage Myisam qui ne gère pas les transactions. C'est le moteur par defaut, mais il vaut mieux ne le garder que pour quelques cas spécifiques. Par exemple, en ce moment je suis sur un site editorial (presque sans concurrence) et pourtant je n'ai même pas 10% de tables Myisam.
Avec Mysql on a plus de chances de se retrouver avec des données incohérentes, mais certains marchands s'en moquent. Alors Mysql ou pas, ça dépend de ce qu'on attend.
En ce qui concerne les cms de commerce, je ne connais que prestashop. Mais vue que c'est un des 2 plus côtés, je me dit qu'il n'est pas pire qu'un autre... Du coup j'ai tendance à me dire que les cms ont été réalisés par des manchos borgnes! :p
Je ne m'y connais pourtant pas plus que ça en bdd, mais je connais au moins les bases qui font qu'un site ne rame pas dès que tu commence à remplir un peu la base et avoir pas mal d'utilisateurs... visiblement ce n'est pas le cas des développeurs de ces cms!
Bref, Mysql n'y est pour rien, les cms sont juste mal développés.
01/12/2010 @ 14:12
Commentaire de:
-kiki- [Membre]
C'est bientôt Noel, et j'ai dans ma hotte une belle question à la con :)
J'essaye de faire précisément le point sur les tables MyIsam...
Elles n'ont pas de cache de données et c'est le page cache de linux qui prend le relais. Apparemment, le page cache de linux fonctionne comme le cache de données des sgbdr : par petites pages de quelques Ko. Une différence notable tout de même : par défaut, linux ne semble pas écrire dans le cache et différer l'écriture sur disque. Je pense qu'il vide le cache lorsqu'il écris une donnée dans une page.
(tout ceci n'est pas sûr... c'est ce que j'ai cru comprendre. il faudrait déjà m'arrêter si je me trompe)
Ma question est alors :
Lors d'une insertion, puisque la donnée à écrire n'est pas présente en cache, les pages resteront-elle en cache?
C'est assez important de savoir car un des intérêts que je porte aux tables Myisam est la possibilité de faire des insertions sans locker aucune lecture.
Par rapport à innoDB, l'avantage est de pouvoir faire de gros range (ou des full scans) en même temps qu'une grande quantité d'insert.
Mais si la moindre insertion vide le cache d'une table MyIsam, cet "avantage" ne sert plus à rien...
sur ce, joyeux Noel! :)
17/12/2010 @ 18:24
Commentaire de:
cinephil [Membre]
18/12/2010 @ 21:46
Commentaire de:
cinephil [Membre]
Il me semblait que, sous certaines conditions très limitantes, on pouvait faire un INSERT sur une vue, mais je n'en ai pas retrouvé mention dans la doc.
Par contre, j'y ai trouvé qu'on ne peut pas faire un trigger sur une vue, alors que chez Postgresql, d'après la doc, on peut créer une vue qui pourra se comporter comme une table.
Voir références dans le message cité.
Et dire qu'on m'oblige à continuer de travailler avec MySQL ! :(
26/01/2011 @ 09:57
Commentaire de:
donino [Membre]
A moins que l'on parle de la préhistoire de l'informatique, faut pas raconter n'importe quoi non plus. Il y a bien longtemps que ce n'est plus au SGBD de gérer le parallélisme des E/S sur plusieurs disques. La moindre petite architecture multi-disques sérieuse de nos jours inclut un RAID 5 ou 10 Hardware, rendant strictement inutile un partitionnement en amont dont l'objectif serait de paralléliser les E/S... Passons.
Dans le même ordre d'idée, "2) que le volume de la table partitionnée dépasse la capacité d'un disque" n'a que très peu de sens, et strictement aucun sur un système RAID.
Pour avoir fait de nombreux tests sur ce thème je peux vous assurer que si une table volumineuse est par exemple partitionnée sur le mois, et que la clause WHERE sélectionne un mois, le gain de performance d'une requête type agrégat sera quasi-proportionnel au nombre de partitions de la table (si les mois sont "équilibrés" bien sur). Par ailleurs les index étant partitionnés en même temps que la table, les indexes des partitions "chaudes" (mois courant, année courante...) pourront plus facilement être entièrement gardés en RAM et améliorer encore plus les performances.
Je ne reviendrai pas sur le parallélisme tant les remarques sont simplistes et à charge pour ce pauvre MySQl. Simplement sur le fait que c'est exactement le contraire de ce qui est évoqué: MySQL est à la ramasse pour une requête mono très complexe, puisque il n'effectue en effet pas de découpage "horizontal" dans sa résolution, mais plus il aura d'utilisateurs/requêtes simultanées, plus il se rapprochera des performances de ses concurrents, pour des raisons assez simples a comprendre.
Loin de moi l'idée de dire que MySQL est aussi performant sur gros volumes que les Oracle, DB2 et autres Teradata... Et je suis d'accord sur certains manques cruels dans le domaine de l'exploitation, mais de là à dire que c'est ultra-buggé, de l'ersatz, qu'il faut tout casser dés qu on atteint le To ou 100 users parce que on a eu le malheur de choisir MySQL c'est absolument n'importe quoi.
Je ne suis pas qu'il existe en France des personnes suffisamment pointues pour définir avec rigueur à partir de quelle dimension de projet on ne devrait plus utiliser MySQL, mais il y a une chose dont on peut être tout à fait certain: l'auteur de l'article n'en fait pas partie
09/02/2011 @ 01:29
Commentaire de:
donino [Membre]
09/02/2011 @ 01:43
Commentaire de:
sqlpro [Membre]
· http://sqlpro.developpez.com
"Il y a bien longtemps que ce n'est plus au SGBD de gérer le parallélisme des E/S sur plusieurs disques..."
Là vous vous trompez complétement. L'intérêt que le SGBDR maitrise la répartition des IO depuis son moteur de stockage et non par le biais de l'OS est plus qu'évident et tous les jours je me bat contre les administrateur système qui tuent les performances des SGBDR en mettant des gros SAN en RAID 10 par exemple sans aucun discernement.
Alors pour votre culture, lisez les articles que j'ai déjà écrit à ce sujet :
http://blog.developpez.com/sqlpro/p8589/ms-sql-server/question-sur-les-fichiers-et-le-stocakge/
http://blog.developpez.com/sqlpro/p5859/ms-sql-server/fragmentation-physique-des-fichiers-et-t/
Comprenez que si le SGBDR connais l'ensemble des "storages" et que ces derniers sont placés sur des disques physiquement indépendant (donc pas du RAID 5 !) alors il lui est possible de traiter en parallèle certaines opérations que l'OS ne pourra jamais faire. Par exemple, calculer un agrégat de type SUM ou COUNT sur une grosse table dont les données ne seraient pas déjà en RAM, oblige le moteur de stockage à monter les lignes en mémoire. Pour ce faire, si la table a été stockée sur une seul espace de stockage la vitesse de remontée des informations sera celle du sous système disque (par exemple avec un RAID 10 cela peut être jusqu'à 4 fois plus rapide). Mais si la table a été stockée en répartissant les IO dans différents espaces de stockage (ce que permet des SGBDR comme DB2, Oracle ou SQL Server) alors la remontée des données pourra être fait en parallèle sur tous les storages simultanément. Ainsi avec 4 espaces de stockage sur 4 agrégats physiques organisés en RAID 10, la vitesse théorique peut allers jusqu'à 16 fois plus vite !
Et croyez moi, j'audite cela à longueur de journée pour mes clients et depuis 10 ans !!!
Sauf que MySQL en est encore à l'âge de pierre dans ces technologies car le pari qui a été fait avec MySQL est de se passer de l'OS interne que tous les bon SGBDR incorporent pour aller justement plus vite !
La tentative de partitionnement qu'a fait MySQL n'est qu'un pis allé pour simuler maladroitement ce que font naturellement et sans partitionnement la plupart des bons SGBDR !
donino :
"MySQL est à la ramasse pour une requête mono très complexe, puisque il n'effectue en effet pas de découpage "horizontal" dans sa résolution, mais plus il aura d'utilisateurs/requêtes simultanées, plus il se rapprochera des performances de ses concurrents, pour des raisons assez simples a comprendre. "
En fait c'est vous qui n'avez pas compris comment fonctionnent un SGBDR... Aucune requête ne se fait sur des données sur disque. Pour traiter la moindre requête (lecture ou écriture comprise) il faut que les données soient présentent en RAM. or le SGBDR conserve toutes les données en mémoire tant qu'il y a de la RAM, donnant ainsi l'impression d'aller de plus en plus vite. Plus vous requêterez, plus vous placerez en RAM, plus ce sera rapide... Il n'y a que lorsque la RAM est saturée que les données les moins utilisées sont déchargée au profit de nouvelles données (algorithme LRU). Cela ne fait que 30 ans que les SGBDR fonctionnent ainsi !
Mais certains SGBRD vont plus loin.. Par exemple dans SQL Server, il est possible que le moteur de requête profite du balayage en cours sur une table pour greffer un autre processus dessus. Le deuxième processus qui profite ainsi du SCAN n'aura plus qu'a finaliser ses lectures avec le début qu'il a raté....
donino :
"Je ne suis pas qu'il existe en France des personnes suffisamment pointues pour définir avec rigueur à partir de quelle dimension de projet on ne devrait plus utiliser MySQL, mais il y a une chose dont on peut être tout à fait certain: l'auteur de l'article n'en fait pas partie "
Mis à par le fait que vous avez oublié le "sûr" au début de votre phrase, je vous invite un jour à vous documenter sur le fonctionnement des SGBDR que visiblement vous ne maîtrisez pas du tout. Il est vrai que la prolétarisation de la société informatique fait que n'importe qui peut dire n'importe quoi sur n'importe quel sujet et passer pour un expert !
En ce qui vous concerne, mon livre, comme mon site web peuvent vous êtes d'une grande utilité pour acquérir les manquent évident de votre culture... En sus, le must pour comprendre comment fonctionne un SGBDR est le livre de Stonebraker qui est le physicien des SGBDR (c'est lui qui a inventé la plupart des mécanismes et algorithmes des SGBDR actuels) : http://www.amazon.com/Readings-Database-Systems-Joseph-Hellerstein/dp/0262693143/ref=sr_1_1?s=books&ie=UTF8&qid=1297235585&sr=1-1
09/02/2011 @ 08:14
Commentaire de:
cinephil [Membre]
Aucune requête ne se fait sur des données sur disque. Pour traiter la moindre requête (lecture ou écriture comprise) il faut que les données soient présentent en RAM. or le SGBDR conserve toutes les données en mémoire tant qu'il y a de la RAM, donnant ainsi l'impression d'aller de plus en plus vite. Plus vous requêterez, plus vous placerez en RAM, plus ce sera rapide...
Je viens de faire un petit test sur ma machine démarrée ce matin donc vierge de toute donnée MySQL en RAM.
Soit les tables des communes, des départements et des régions françaises et soit la requête suivante :
SELECT c.cmn_nom, d.dpt_numero, d.dpt_nom, r.rgn_nom
FROM tr_commune_cmn c
INNER JOIN tr_departement_dpt d ON d.dpt_id = c.cmn_id_departement
INNER JOIN tr_region_rgn r ON r.rgn_id = d.dpt_id_regionPremière exécution en 0,00134 s, extraction des données d'une autre table puis seconde exécution de la requête en 0,0005 s, soit près de 63% plus vite parce que les données étaient présentes en RAM.
Et cette différence n'est que sur 36682 communes, 100 départements et 26 régions. Ce serait sans doute beaucoup plus sensible sur des centaines de milliers de lignes, voire sur des millions, tant que ça peut tenir en RAM.
09/02/2011 @ 11:03
Commentaire de:
donino [Membre]
...
Et croyez moi, j'audite cela à longueur de journée pour mes clients et depuis 10 ans !!!"
Vous n'avez strictement rien compris aux architectures RAID. Si vous disposez d'une baie de stockage de 16 disques en RAID 10, chaque table sera répartie sur tous les disques, et monter une table en RAM pour votre SUM sera parallélisé à la vitesse maximale autorisée par le matériel, c'est à dire avec un gain grosso modo 8 fois plus rapide dans le cas d'un RAID 10, environ 15 * plus rapide dans le cas d'un RAID 5, si bien entendu les contrôleurs sont dimensionnés correctement. Vous semblez croire, si j'ai bien compris, que 2 grappes de 8 disques en RAID 10 sont plus performantes qu'une seule de 16 disques, ce qui est mathématiquement totalement faux.
"En fait c'est vous qui n'avez pas compris comment fonctionnent un SGBDR... Aucune requête ne se fait sur des données sur disque. Pour traiter la moindre requête (lecture ou écriture comprise) il faut que les données soient présentent en RAM."
Heu merci pour la remarque mais j'ai l'impression qu'on ne parle pas du même domaine. Je compléterais même votre phrase en disant qu'aucune requête ne s'effectue sur la RAM, vous avez oublié les caches processeurs de niveau 1 et 2... Et pourquoi pas les registres tant qu'on y est. Essayons de rester un minimum sérieux, même si j'avoue que ce n'est pas facile. Toutefois vous êtes peut être de bonne foi, je vais donc expliciter ma remarque sur le parallélisme qui n'avait strictement rien à voir avec cette histoire de RAM.
Imaginons un machine de 64 processeurs, une table très volumineuse sur laquelle on souhaite faire une lourde requête de type jointures + group by. MySQL saura effectuer un découpage vertical de la requête et créer des process distincts pour les jointures, le tri et l'aggrégation, fonctionnant parallélement en pipe. La machine sera ultra sous-utilisée, puisque seuls quelques processeurs seront sollicités, avec une forte contention sur le processeur chargé du tri. Un SGBD comme Teradata segmentera la table en question pour effectuer en plus un découpage horizontal de la requête: pour simplifier il effectuera par exemple 50 mini tris de la table sur des segments, puis les regroupera afin de produire le résultat final. Ceci afin de garantir que 100% des processeurs de la machine seront utilisées pour résoudre la requête en un temps optimal, soit.
Dans ce genre de cas de figures, sur un même matériel les écarts de perf entre MySQL et Teradata/Oracle peuvent varier sans problème d'un facteur de 100. Le genre de facteur qui peut faire tourner la tête à plus d'un DSI et le pousser à engloutir les millions d'euros pour une migration. Seulement, que se passe t-il si on a cette fois 50 requêtes de ce type simultanées? MySQL sollicitera maintenant lui aussi la majorité des ressources et la courbe de perfs se rapprochera de ses camarades parallélistes. On peut même dire qu'à partir d'un certain seuil de taux d'occupation des processeurs, la gestion du parallélisme finit par coûter plus qu'elle ne rapporte. Mais pour comprendre cela, il faut avoir une volonté de compréhension des algorithmes ensemblistes que visiblement vous n'avez pas.
"Mais certains SGBRD vont plus loin.. Par exemple dans SQL Server, il est possible que le moteur de requête profite du balayage en cours sur une table pour greffer un autre processus dessus. Le deuxième processus qui profite ainsi du SCAN n'aura plus qu'a finaliser ses lectures avec le début qu'il a raté...."
MySQL comme tous les autres SGBD ne va transférer un bloc du disque vers la RAM que si il n'est pas déjà présent en RAM, donc n'y a pas déjà été placé par un autre process en cours ou qui vient de se dérouler. Cela ne correspond certes pas tout à fait à ce que vous décrivez, mais revient dans la pratique presque au même. Attention de ne pas trop se faire flouer par des pseudos capacités heuristiques vendues par les éditeurs, qui ne sont bien souvent efficaces que sur les jolies plaquettes glacées de présentation.
Pour ce qui est de votre livre ou de votre site merci bien mais vu les énormités que j'ai lues et la farce de certains liens (la palme revenant aux "benchmarks depuis une décennie" donnés en appui) je crains devoir m occuper autrement ce soir.
Aprés 15 années de consulting en Data Warehouse, je n'ai acquis qu'une seule certitude: les crises d'un projet n'ont jamais pour véritable origine les outils (les fusibles parfaits), mais toujours les personnes qui les ont mal utilisés soit par ignorance soit par capacités insuffisantes. A vous de trouver votre catégorie.
09/02/2011 @ 19:25
Commentaire de:
sqlpro [Membre]
· http://sqlpro.developpez.com
Ce proverbe signifie que vous vous complaisez dans votre ignorance.
Comme je vous l'ais dit les bons SGBDR ont un OS interne qui s'occupe de tout sauf le réseau : accès RAM, accès disque, multi-threading, gestion des caches et de la RAM. Les fonctionnalité de bas niveau de l'OS sont du pipi de chat et inutilisables en regard des problématiques que doit affronter un SGBDR. En revanche MySQL a été conçu sans cet OS interne, et c'est la raison pour laquelle il se comporte comme un veau à la montée en charge, notamment sur les aspects de concurrence.
La seule chose de correcte que vous avez dit est la suivante :
"Un SGBD comme Teradata segmentera la table en question pour effectuer en plus un découpage horizontal de la requête: pour simplifier il effectuera par exemple 50 mini tris de la table sur des segments, puis les regroupera afin de produire le résultat final. Ceci afin de garantir que 100% des processeurs de la machine seront utilisées pour résoudre la requête en un temps optimal, soit. "
Mais ce n'est pas l'apanage de Terradata, cela se fait depuis plus de 12 ans chez SQL Server et 15 ou 20 chez IBM DB2 et Oracle. Jetez un coup d'œil aux plans de requêtes générés par SQL Server, et quand vous verrez le symbole avec la double flèche apparaître c'est que l'opération unitaire y est fait en parallèle !
http://blog.sqlauthority.com/2010/08/06/sql-server-parallelism-query-in-database/
http://etutorials.org/SQL/microsoft+sql+server+2000/Part+V+SQL+Server+Internals+and+Performance+Tuning/Chapter+35.+Understanding+Query+Optimization/Parallel+Query+Processing/
Visiblement vous n'avez donc pas lu ce que j'avais indiqué précédemment !!!
Pour information, je vous renvoie pour l'exemple à l'OS interne de SQL Server (de nom SQLOS pour "SQL Server Operating System") sur le blog de Slava Oks (l'un des principaux développeurs de SQLOS... : http://blogs.msdn.com/b/slavao/archive/2005/02/05/367816.aspx
A partir du moment ou vous resterez buté à ne pas comprendre qu'il existe un OS interne dans les SGBDR, OS interne qui squeeze l'OS externe (Linux, Windows et autres), nous ne pourrons pas nous comprendre, car les problématique de cache de processeurs dont vous parlez ne concerne nullement directement le fonctionnement d'un SGBDR ! Par exemple et comme je vous l'ai déjà dit, les accès disques se font directement par le SGBDR et non pas l'intermédiaire de l'OS.
Il y a quelques années, Oracle avait même sortie une version de son SGBDR sans OS ! Il suffisait d'introduire le CD pour installer Oracle. Cette version n'a hélas pas pris, car les ingénieurs système y ont vu leurs prérogatives diminuées. Ils se sont donc en quelques sorte "opposés" à cette sortie.
Donc, je vous réinvite a relire encore une fois mes écrits. Je vous offre aussi l'alternative de suivre les cours de Philippe Rigaux qui a fait un bon support (http://www.info.univ-angers.fr/~gh/internet/cbd.pdf, pages 125 à 164 notamment, un peu incomplet, car introductif et http://barzilouik.free.fr/cnam/DEA_STIC_opt_CONCEPT_APP_MULTIMED_2005/UV_BaseDonneesAvancees/AspectSystemesSGBDR.pdf) sur ces sujets (puisque visiblement vous me prenez pour un andouille, je vous donne les référence d'un prof du CNAM Paris...), ou bien d'assister à un de mes cours au CNAM PACA, à l'université de Toulouse, ou encore dans l'une des écoles d'ingénieurs dans lesquelles j'interviens en 5e année : CESI/EXIA d'Aix en Provence ou bien à l'ISEN à Toulon.
Sans doute apprendrez vous bien des choses....
Un petit exemple, extrait des documents cités :
Sauf exception (par exemple MySQL qui a choisi le parti-pris d’une simplicité maximale), les
SGBD ont donc leur propre module de gestion de fichiers et de mémoire cache. Leurs principes
généraux sont décrits dans ce qui suit.
Dixit Philippe Rigaux. Je n'invente rien !
Et pour ma part, ma rencontre avec les SGBDR remonte à 1982 !
Mais j'ai au moins eu la curiosité d'aller voir à l'intérieur comment cela se passe ! Et le livre que je vous recommande à ce sujet est celui de Stonebraker "Readings in Database Systems", chez Morgan Kaufman.
Sans doute me considérerez vous comme un has been, c'est aussi sans doute pour cela que je suis MVP SQL Server depuis 2003...
A +
10/02/2011 @ 17:45
Commentaire de:
donino [Membre]
Oui et alors est ce que j'ai dit le contraire quelquepart? J'ai pris l'exemple de teradata car c'est de très loin le plus performant en ce domaine, c'est tout, ne voyez pas le mal partout.
Has been? Loin de moi cette idée. Vous êtes sans doute compétent dans le domains du SQL et de l'administration/exploitation des SGBD, du moins je vous le souhaite. Vous ne maitrisez en revanche absolument pas les architectures techniques et matérielles, ni les opti avancées des SGBD, et c'est un euphémisme. C'est comme çà, on ne peut pas tout savoir il n'y a pas à en rougir, en revanche il n'est pas très judicieux d'essayer de faire croire à tout le monde le contraire. Un peu d'humilité ainsi qu'un bon correcteur orthographique ne feraient pas de mal.
19/02/2011 @ 17:05
Commentaire de:
sqlpro [Membre]
· http://sqlpro.developpez.com
En ce qui concerne les architectures techniques, je ne sais sans doute rien faire.... Mais les quelques clients avec lesquels j'ai travaillé ces sujets ont apprécié mon savoir faire alors que les concurrents présentaient comme indispensable des architectures modernes ineptes, peu adapté et anti performantes, couteuses et complexes, notamment avec force de serveur d'objet, de framework et d'ORM !!!
Je ne vous donnerais que quelques références :
- DDE du gard (devenu DDTM) / Schapi - système de prévision des crues (SPC) du grand delta du Rhone (Service de prévision des crues) projet terminé fin 2010 (projet à criticité maximum - risque mortel : catastrophe naturelle). Aujourd'hui ce système qui gère l'évolution des cours d'eau affluent du Rhône depuis Lyon jusqu'à la méditerranée est considéré comme le plus puissant, le plus fiable, le plus rapide et le moins cher des SPC. Il va être repris pour de nombreuses autres surveillances comme remplaçant des systèmes actuels (récemment l'épisode tragique des crues de la Nartuby et donc de l'Argens dans le Var ayant fait 25 morts)
Mon travail : conseil dans l'architecture technique du système, aide à la rédaction du cahier des charges, choix du sous traitant, surveillance à titre d'expert sur le développement, participation à la recette finale.
- Santé Service (hospitalisation à domicile, 900 employés, 1200 patients) - ERP permettant de gérer les ressources et les soins à apporter aux patients. Santé Service étant le plus important établissement de soin à domicile en France et le métier étant spécifique à la France (Sécurité Sociale), aucun ERP du commerce ne pouvait donner satisfaction dans un budget assez serré. Là aussi criticité importante : durée d'interruption de service maximale autorisée : 20 minutes. Accès au logiciel : par PC portable sécurisé sans disque dur, accès mobile via RTC ou GSM dans le meilleur des cas. Traçabilité intense systématique pour les mises à jour, et pour certaines données il était indispensable de savoir qui l'a lu et ce que l'on a lu (audit de SELECT...).
Mon travail : conseil en architecture, modélisation de la base de données, lancement des développements dans le concept "base de données épaisses"
L'attaque sur l'orthographe est un excellent signe... quand on a plus grand chose à dire, autant attaquer sur n'importe quoi. Oui, je suis dyslexique... en plus de rédiger quelques centaines d'articles bénévolement par an ce qui ne me laisse pas beaucoup de temps pour me relire !
En ce qui vous concerne, je remarque que vous ne publiez apparemment rien, mais cela ne vous empêche pas de critiquer le travail des autres.
Ayez au moins un peu d'humilité !
20/02/2011 @ 10:27
Commentaire de:
ok.Idriss [Membre]
· http://ineumann.developpez.com/
Je me permet de vous rappeler que Mr SQLpro, en plus d'être un excellent rédacteur et contributeur bénévole, est à la fois professionnel et enseignant dans le domaine. Plutôt que de critiquer son travail, vous feriez bien de concentrer votre énergie et vos connaissances/expériences à en faire de même. C'est beaucoup plus honorable.
20/02/2011 @ 11:19
Commentaire de:
sqlpro [Membre]
· http://sqlpro.developpez.com
Décidément j'en decouvre tous les jours des inepties sous MySQL. Le coup des NULL qui sont pas NULL est particulièrement croustillant... Démonstration :
CREATE TABLE T
(
id INT NOT NULL,
text1 VARCHAR(32) NOT NULL,
text2 VARCHAR(32) NOT NULL DEFAULT 'toto'
);
INSERT INTO T (id) VALUES (1);
INSERT INTO T (text1) VALUES('test');
mysql> SELECT * FROM T;
+----+-------+-------+
| id | text1 | text2 |
+----+-------+-------+
| 1 | | toto |
| 0 | test | toto |
+----+-------+-------+
2 rows in set (0.00 sec)Et comme par magie les NULLs ont été transformé l'un en chaine de caractère vide et l'autre en zéro. Merci MySQL !
17/03/2011 @ 21:53
Commentaire de:
cinephil [Membre]
Le plus stupide reste quand même le type DATE qui a pour valeur par défaut la date inexistante '0000-00-00' !
18/03/2011 @ 01:02
Commentaire de:
sqlpro [Membre]
· http://sqlpro.developpez.com
Normalement ces requêtes devrait conduire à un message d'erreur et rien ne devrait être introduit dans les tables.
Imaginons simplement que votre employeur doivent vous verser un salaire et qu'il oublie de spécifier le montant dans une requête... Seriez vous content de d'être payé ZÉRO euros par ce que MySQL l'a décidé ?
Cela fausse par exemple toutes les statistiques. Imaginons que nous n'ayons pas les notes des absents. La moyenne de la classe plonge alors dramatiquement à cause des faux zéro !!!
Hallucinant !!!!
Mais il y a même pire...
Dans la même veine, il y a les données sciemment corrompues par MySQL !
18/03/2011 @ 10:30
Commentaire de:
ok.Idriss [Membre]
· http://ineumann.developpez.com/
18/03/2011 @ 10:56
Commentaire de:
sqlpro [Membre]
· http://sqlpro.developpez.com
Non, soyons sérieux, c'est dans le SGBDR qu'il faut placer les contraintes et non dans le code client. En sus, contrairement à une idée imbécile largement répandue, les contraintes améliorent les performances... Pour vous en convaincre, lisez l'excellent article de mikedavem sur le sujet...
Bon, évidemment MySQL ne sait absolument pas faire cela d'autant plus que la moitié des contraintes de table (FOREIGN KEY et CHECK) ne sont peu ou pas du tout implémenté sous ce ersatz de SGBDR !
18/03/2011 @ 11:26
Commentaire de:
ok.Idriss [Membre]
· http://ineumann.developpez.com/
Cependant, si on est amené à utiliser MySQL (parce qu'on n'a pas toujours le choix et ça arrive souvent), il faut faire avec et mettre soi-même en place des contrôles suffisants pour sécuriser les échanges avec les utilisateurs.
18/03/2011 @ 12:01
Commentaire de:
sqlpro [Membre]
· http://sqlpro.developpez.com
18/03/2011 @ 12:47
Commentaire de:
sqlpro [Membre]
· http://sqlpro.developpez.com
Un petit exemple :
CREATE TABLE T1 (C1 INT);
INSERT INTO T1 VALUES (1);
INSERT INTO T1 VALUES (1);
INSERT INTO T1 VALUES (2);
CREATE INDEX X ON T1 (C1);
CREATE TABLE T2 (C2 INT, C1 INT);
ALTER TABLE T2 ADD CONSTRAINT FK FOREIGN KEY (C1) REFERENCES T1 (C1);On peut donc créer une contraintes FOREIGN KEY référençant une colonne NON UNIQUE dans la table mère !!!
Ahurissant...
23/03/2011 @ 15:55
Commentaire de:
dudumomo [Membre]
Merci a SQLPro et autres autres participant pour vos messages. Ils sont tres interessant.
Parfois difficile a bien tout saisir vu que ca peut etre tres pointu, ou bien difficile de savoir le vrai du faux puisque chacun se renvoi la balle.
Mais il y a tout de meme des evidences qui sont claires. Et MySQL ne semble pas etre fait pour des gros projets et n'est pas aussi "pro" que les autres.
En revanche, pour des plus petit projet, il semble qu'un grand nombre d'utilisateurs sont satisfait du produit pour ce qu'ils en font.
Je suis de mon cote, defenseur du libre, mais utilisateur avant tout.
Cet article et ses commentaires m'ont fait change d'idee sur le fait de faire tourner un petit proto de Business Intelligence sur MySQL, autant passer a PostGreSQL (Plus libre, moins dependant d'une entreprise et apparament plus abouti) voire carement a Oracle, si je saute le pas, autant le faire avec cette solution et leur version Express qui semble en fait deja assez flexible.
Bref, je continuerai a suivre les commentaires ici et je vous remercie pour toute cette belle lecture.
Apres c'est vrai que j'ai trouve que ProSQL y va un peu fort en cassant MySQL, mais il a en tout cas toute ses raisons et cela m'a permis de decouvrir des nouveaux points.
Je ne serai pas anti-mysql et loin de la, mais je vais maintenant faire un peu plus attention sur ce point la.
Merci.
10/05/2011 @ 12:23
Commentaire de:
sqlpro [Membre]
· http://sqlpro.developpez.com
En revanche je n'ai jamais dit que MySQL n'avait pas sa place ! Pour de petit sites web, avec peu de charge et dans lesquels on se fout de la sécurité ou du transactionnement, alors MySQL peut être parfaitement utilisé. Par exemple pour des blog...
14/05/2011 @ 10:38
Commentaire de:
cinephil [Membre]
J'ai créé une BDD sur ma machine avec l'utilisateur root de MySQL sans problème, y compris un petit trigger d'incrémentation relative dont j'ai d'ailleurs donné le code dans mon blog.
Je fais un dump de la BDD pour la transférer sur le serveur qui contient bien mon trigger et j'essaie d'importer ce dump sur la BDD du serveur, cette fois avec l'utilisateur MySQL qui sera celui de l'application cliente, cet utilisateur ayant les droits ALL PRIVILEGES sur la BDD.
Et là, message d'erreur ! La création du trigger est refusée car il faut les droits SUPER pour le faire !
Est-ce à considérer comme une sécurité normale ou une bizarrerie supplémentaire de MySQL ? En tout cas, je trouve ça pour le moins embêtant ! Je pense par exemple qu'il doit être impossible de transférer une BDD MySQL contenant des triggers sur la plupart des serveurs partagés des hébergeurs web.
28/09/2011 @ 10:14
Commentaire de:
sqlpro [Membre]
· http://sqlpro.developpez.com
Hélas PostGreSQL est du même tonneau en cette matière !
02/10/2011 @ 18:26
Commentaire de:
cinephil [Membre]
A noter que MySQL vous permet d'enregistrer certaines dates qui ne sont pas strictement légales, par exemple 1999-11-31. La raison est que nous pensons que la vérification des dates est à faire niveau application.
De plus, on lit aussi ce qui suit dans la partie sur le type TIME :
Vous pouvez spécifier une valeur de type TIME avec différents formats :
*
Une chaîne au format 'D HH:MM:SS.fraction'. (Notez que MySQL ne stockera pas la fraction d'une valeur TIME.)
Pourtant, dans la section sur les fonctions de date et heure, on trouve la notion de MICROSECOND mais je n'ai pas trouvé comment enregistrer ces microsecondes !
Une lecture rapide de la doc Postgresql semble montrer une plus grande rigueur quant à l'interprétation des dates et on peut sans problème saisir des fractions de secondes (je n'ai pas testé).
19/11/2011 @ 09:33
Commentaire de:
cinephil [Membre]
http://drdobbs.com/database/231902587
Il n'y aura donc plus de raison d'utiliser le moteur MyISAM !
Si par contre c'est un simple portage de la recherche full text de MyISAM vers InnoDB, ce ne sera guère mieux mais bon... Oracle semble vouloir faire évoluer MySQL dans le bon sens quand même !
17/02/2012 @ 09:24
Commentaire de:
haliway [Membre]
Ce que je reproche à MySQL est simple : faire croire qu'il s'agit d'un SGBD Relationnel, alors que cela n'est pas vrai. C'est une simple encapsulation de SQL sur de la gestion de données en fichiers...
Bonjour,
je viens de tomber sur votre blog au demeurant assez intéressant par contre laissez moi mettre en doute vos capacités système (je ne remets pas en doute vos capacités SGBD et j'ai rien à dire à ce niveau la). Je suis moi même ingénieur système Unix (AIX, Linux, Solaris ...) et cette petite phrase ainsi que certaines autres m'ont fait tilté assez rapidement. Depuis quand une base de données peut s'affranchir des caractéristiques système ?
1) Je vous invite à installer Oracle sur un système Unix et voir si le paramétrage des limites n'est pas un prérequis premièrement.
2) Vous qui dites que le SGBD fait sa tambouille avec la RAM... c'est complètement faux. Le système de page replacement est géré par l'OS quelque soit les affirmations que vous pouvez décrire. C'est d'ailleurs bien pour cela que de nombreuses entreprises, par exemple, ont été obligées de faire des revues de tuning sur les AIX 5.3 avec bases de données installées dont les options sur les permanent pages n'avaient pas été configurées correctement (min_perm, max_perm, lru_file_repage) http://www.ibm.com/developerworks/aix/library/au-vmm/.
3) C'est l'OS qui gère les PGIN/PGOUT sur la RAM et la SWAP en gèrant les priorités (définies ou pas par des options de configuration).
4) Concernant le SAN, sur la plupart des baies, le volume n'est pas défini avec un emplacement spécifique sur le disque comme vous souhaitez le préconiser (on faisait ça il y a 10 ans mais vu la complexité d'administration...). De toute façon, une architecture rapide est une architecture tout en un (serveur + disques) car on évite la latence des liens fibre channel en passant par des bus PCI Express (Oracle Exadata ou IBM Netezza)... On revient finalement à une architecture compacte la ou on a passé 20 ans à passer par le SAN prétextant qu'il apporterait une souplesse dans la gestion du stockage.
Il ne faut pas raconter n'importe quoi sous prétexte de faire du SGBD depuis 10 ans. Je fais moi même du système depuis presque 10 ans.
17/04/2012 @ 12:23
Commentaire de:
sqlpro [Membre]
· http://sqlpro.developpez.com
A partir d'un certain volume il faut savoir revenir aux fondamentaux et savoir ce qu'une organisation disque, même en SAN veut dire...
Enfin, UNIX et sa famille (LINUX, AIX...) est plus complexe administration que Windows et cela se ressent fortement aujourd'hui sur les coût d'admin.
A +
24/04/2012 @ 13:41
Commentaire de:
cinephil [Membre]
http://www.developpez.net/forums/d1215854/bases-donnees/mysql/requetes/methode-sous-requete-from-clause/
En tous cas jusqu'à la version 5.0.17 utilisée par ce forumeur.
03/05/2012 @ 09:17 Vous devez être identifié pour poster un commentaire.
![[Valid RSS]](/img/valid-rss.png "Validate my RSS feed")
![[Valid Atom 1.0]](/img/valid-atom.png "Validate my Atom 1.0 feed")
Copyright © 2000-2012 - www.developpez.com