[gull] Il faut reconnaitre que la Wikipedia est drole
Daniel Cordey
dc at mjt.ch
Mon Sep 26 14:41:15 CEST 2005
On Monday 26 September 2005 13:59, Marc SCHAEFER wrote:
> MySQL est une base de données non générale, qui n'implémente pas tout ce
> à quoi on pourrait s'attendre après avoir compris les fondements des
> systèmes de gestion de bases de données. Même si ses dernières versions
> vont dans la bonne direction, ce n'est pas encore un système
> qui permet de véritables développement corrects SGBD. Et pire, il donne
> l'illusion à ses utilisateurs de les offrir.
Cela depend de la version dont on parle. Dans tous les cas MySQL a fait le
choix de ne pas integrer de moteur transactionnel dans le but d'atteindre
les meilleures performances. Celui qui utilise MySQL comme un base
transactionnelle joue a la roulette russe... avec la garantie que la balle
finira par partir :-) De plus, et jusqu'a la version 4.1 (pas encore regarde
la 5.0), l'emploir de "FOREIGN KEYS" implique des fichiers d'indexes en
InoDB, au lieu des standard MyISAM. Ceci a pour effet de doubler la taille
des fichiers de cles...
Bref MySQL a des limitations et elles sont clairement expliquees. Cette SGDB
ne pretend pas offrir les memes fonctionalites que PostGress, Oracle, DB2,
Sybase, etc. Mais, les meilleures performances dans une utilisation bien
precise.
> Il y a certes des cas où une base de données non générale peut suffire,
> mais alors il y a d'autres choix que MySQL (p.ex. DBM, voire SQL-DBM).
Je ne connais pas SQL-DBM, mais le veritable probleme de DBM est l'adjonction
d'enregistrements nouveaux qui ralentissent massivement les performances. A
contrario, pour un "domaine" de donnees connues, les performances en
interrogations sont les meilleures. Il importe donc de bien determiner
l'usage de ses donnees et de decider en fontion des ces imperatifs. Inutile
d'employer un canon a mouche !
> Justement, c'est souvent parce qu'on n'a que MySQL qu'on ne voit pas les
> fonctionnalités qui pourraient être utilisées déjà dans le design de
> l'application.
Je dirais : "que l'on ne connait pas ce qu'est une vraie DB relationnelle...
incluant la fiabilite.". Il faut etre bien conscient des limitations de
MySQL; et dans ce cas, le choix peut parfaitement s'averer logique.
> Il est évident que le portage d'une application limitée à MySQL sur
> PostgreSQL ne donnera pas forcément de meilleurs résultats.
C'est presque certain. Sauf, s'il s'agit d'une etape parceque l'on a besoin
d'un moteur transactionnel. Auquel cas le retour vers MySQL ne sera plus
possible.
> Le seul cas où une base de données hyper-simple peut être employée c'est
> lorsqu'une couche intermédiaire (moniteur transactionnel, etc) sort de
> la base de données les fonctionnalités SGBD correspondantes.
On utilise alors pleinement MySQL car il a ete concu dans cette optique
uniquement. Il n'est pas necessaire de mettre du transactionnel la ou cela
n'est pas necessaire.
> Dans mon expérience pratique jusqu'ici, MySQL m'est apparu comme ayant
> plus de problèmes de fiabilité que PostgreSQL. Mais il faut bien dire
> que depuis 2-3 ans je n'ai plus véritablement utilisé MySQL, il se peut
> que la situation se soit améliorée.
Pour repondre, il faudrait que l'on utilise les deux en // avec la meme
application. Lors du choix que nous avons effectues pour nos applications,
nous nous sommes pose la question Postgress/mySQL. Nous avions (et avons
toujours) un besoin de performance absolue et une architecture transtionnelle
ne nous servait a rien. Donc, je ne peux que donner une statisqtique
concernant nos serveurs. Nous avons deux gros serveurs MySQL avec des bases
pour chaque serveur : ~40GB data, 130 tables et 12 bases; certaines tables
ont >20 millions de cles. Il y a deux ans, une coupure de courant a necessite
l'execution d'un "REPAIR TABLE" sur certaines tables et tout est rentre dans
l'ordre. Sans cela, notre serveur de production n'a pas ete redemarre depuis
295 jours et a depuis traite plus de 2.4 milliards de transactions...
(moyenne 101 transations par seconde 24/24 - 7/7) sans aucun probeleme
quelqconque... zero. Bien sur, ce n'est pas une garantie, mais uns simple
statistique concernant un usage determine. Ceci concerne la version 4.0 et
nous nous appretons a passer a la 4.1. Je ne sais pas ce qui en est de
Postgress, mais j'imagine que ca ne doit pas etre inferieur :-)
> [*] troll
Nous sommes deux participant de "troll" puisque nous ecrivons des choses qui
n'ont rien a voir avec le sujet initial ("Re: [gull] Il faut reconnaitre que
la Wikipedia est drole"). Quoique... cela peut aussi un moyen d'empecher un
vrai "troll" a ce sujet :-)
dc
More information about the gull
mailing list