choix MySQL & Postgres

Le
Pif
Bonjour,

dans ma boite on utilise de l'oracle. Les licences coutent cher, et on
prévoie une montée en charge qui pousserait à partir vers un systèm=
e
libre fiable.

J'ai eu de bons échos de PG qui propose des système de loadbalancing,
des réplication, réspecte bien les standard et le transactionnel.

MySQL a une réputation d'être moins "solide" pour un usage réellement
d'entreprise. Quand je dis "a", c'est avais il y a quelques années
quand je m'y intéressait. Donc ma question est de savoir si il y a
toujours un écart important et si MySQL est plutot dédié à
l'hébergement de blogs, CMS, et compagnie ou si aujourd'hui il égale
ou dépasse PG ?

De même, la migration me semble préférable vers PG : il propose les
séquences, un PL/SQL plus proche d'oracle, etc. Qu'en pensez vous ?

Merci.
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
JKB
Le #21924961
Le 22-01-2010, ? propos de
choix MySQL & Postgres,
Pif ?crivait dans fr.comp.applications.sgbd :
Bonjour,



Bonjour,

dans ma boite on utilise de l'oracle. Les licences coutent cher, et on
prévoie une montée en charge qui pousserait à partir vers un système
libre fiable.

J'ai eu de bons échos de PG qui propose des système de loadbalancing,
des réplication, réspecte bien les standard et le transactionnel.

MySQL a une réputation d'être moins "solide" pour un usage réellement
d'entreprise. Quand je dis "a", c'est avais il y a quelques années
quand je m'y intéressait. Donc ma question est de savoir si il y a
toujours un écart important et si MySQL est plutot dédié à
l'hébergement de blogs, CMS, et compagnie ou si aujourd'hui il égale
ou dépasse PG ?

De même, la migration me semble préférable vers PG : il propose les
séquences, un PL/SQL plus proche d'oracle, etc. Qu'en pensez vous ?



J'en pense que MySQL est le dernier des choix à faire si on veut
quelque chose d'efficace. J'ai du MySQL et du PostgreSQL, PG se
comporte bien, MySQL se comporte comme un goret. Je ne compte plus
les répliques qui plantent, les interruptions de service et j'en
passe. Bref, je n'utilise plus MySQL que lorsque je n'ai pas le
choix (j'ai tout de même du 5, du 5.1 et du 6 sur mes serveurs).
Pour tout ce qui est critique, j'ai une nette préférence pour Postgre.

C'était juste mon avis, prière de ne pas lancer bataille de
clochers.

Cordialement,

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Alcovia
Le #21924951
Le 22/01/2010 11:10, Pif a écrit :
Bonjour,

dans ma boite on utilise de l'oracle. Les licences coutent cher, et on
prévoie une montée en charge qui pousserait à partir vers un système
libre fiable.

J'ai eu de bons échos de PG qui propose des système de loadbalancing,
des réplication, réspecte bien les standard et le transactionnel.

MySQL a une réputation d'être moins "solide" pour un usage réellement
d'entreprise. Quand je dis "a", c'est avais il y a quelques années
quand je m'y intéressait. Donc ma question est de savoir si il y a
toujours un écart important et si MySQL est plutot dédié à
l'hébergement de blogs, CMS, et compagnie ou si aujourd'hui il égale
ou dépasse PG ?

De même, la migration me semble préférable vers PG : il propose les
séquences, un PL/SQL plus proche d'oracle, etc. Qu'en pensez vous ?

Merci.


si tu viens d'oracle, il n'y a pas photo: le choix PostgreSQL s'impose
tant ils sont similaires. Mysql fait jouet à côté
WebShaker
Le #21924941
Pif a écrit :
Bonjour,

dans ma boite on utilise de l'oracle. Les licences coutent cher, et on
prévoie une montée en charge qui pousserait à partir vers un système
libre fiable.

J'ai eu de bons échos de PG qui propose des système de loadbalancing,
des réplication, réspecte bien les standard et le transactionnel.

MySQL a une réputation d'être moins "solide" pour un usage réellement
d'entreprise. Quand je dis "a", c'est avais il y a quelques années
quand je m'y intéressait. Donc ma question est de savoir si il y a
toujours un écart important et si MySQL est plutot dédié à
l'hébergement de blogs, CMS, et compagnie ou si aujourd'hui il égale
ou dépasse PG ?

De même, la migration me semble préférable vers PG : il propose les
séquences, un PL/SQL plus proche d'oracle, etc. Qu'en pensez vous ?

Merci.



Moi aussi j'opterai pour postgreSQL.
Mais attention coté réplication, ca reste très limité.
Je ne sais pas si la réplication MySQL fonctionne ou ne fonctionne pas,
mais les outils sont plus nombreux dans ce domaine.

Etienne
JKB
Le #21924931
Le 22-01-2010, ? propos de
Re: choix MySQL & Postgres,
WebShaker ?crivait dans fr.comp.applications.sgbd :
Pif a écrit :
Bonjour,

dans ma boite on utilise de l'oracle. Les licences coutent cher, et on
prévoie une montée en charge qui pousserait à partir vers un système
libre fiable.

J'ai eu de bons échos de PG qui propose des système de loadbalancing,
des réplication, réspecte bien les standard et le transactionnel.

MySQL a une réputation d'être moins "solide" pour un usage réellement
d'entreprise. Quand je dis "a", c'est avais il y a quelques années
quand je m'y intéressait. Donc ma question est de savoir si il y a
toujours un écart important et si MySQL est plutot dédié à
l'hébergement de blogs, CMS, et compagnie ou si aujourd'hui il égale
ou dépasse PG ?

De même, la migration me semble préférable vers PG : il propose les
séquences, un PL/SQL plus proche d'oracle, etc. Qu'en pensez vous ?

Merci.



Moi aussi j'opterai pour postgreSQL.
Mais attention coté réplication, ca reste très limité.
Je ne sais pas si la réplication MySQL fonctionne ou ne fonctionne pas,
mais les outils sont plus nombreux dans ce domaine.



Il y a Slony-I. Je n'ai jamais utilisé, mais a priori, je ne vois
pas pourquoi ce serait plus merdique que la réplication selon MySQL.
Pour être tout à fait honnête, je ne vois pas comment on pourrait
faire pire ;-) La réplication selon MySQL, c'est bourrin, sans
vérification d'erreur (ou plutôt la réplique arrive à planter sur
des transactions acceptées par le noeud maître sans aucune raison
valable).

Cordialement,

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Sebastien Lardiere
Le #21924921
Le 22/01/2010 14:10, WebShaker a écrit :
Pif a écrit :
Bonjour,

dans ma boite on utilise de l'oracle. Les licences coutent cher, et on
prévoie une montée en charge qui pousserait à partir vers un système
libre fiable.

J'ai eu de bons échos de PG qui propose des système de loadbalancing,
des réplication, réspecte bien les standard et le transactionnel.

[...]




Moi aussi j'opterai pour postgreSQL.
Mais attention coté réplication, ca reste très limité.
Je ne sais pas si la réplication MySQL fonctionne ou ne fonctionne pas,
mais les outils sont plus nombreux dans ce domaine.



De même, PostgreSQL est sans aucun doute le meilleur choix.

Pour les outils de réplication, je dirais au contraire qu'il y a plus
d'outils disponible avec PostgreSQL, couvrant plus de cas de figure que
MySQL.

Je me permettrais d'orienter vers les skytools¹, londiste ( similaire à
Slony-I) et walmgr.py ( WAL Shipping ), ça tourne en prod sans probleme.

J'ajouterais qu'au dela d'une communauté de développeurs, très actifs,
on trouve un éco-système logiciel très fourni ...


--
Sébastien
Alain Montfranc
Le #21924911
Le 22/01/2010, Sebastien Lardiere a supposé :

Pour les outils de réplication, je dirais au contraire qu'il y a plus
d'outils disponible avec PostgreSQL, couvrant plus de cas de figure que
MySQL.




C'est pas natif depuis la 8.2 avec le log shiping ?
Sebastien Lardiere
Le #21924901
Alain Montfranc a écrit :
Le 22/01/2010, Sebastien Lardiere a supposé :

Pour les outils de réplication, je dirais au contraire qu'il y a plus
d'outils disponible avec PostgreSQL, couvrant plus de cas de figure que
MySQL.




C'est pas natif depuis la 8.2 avec le log shiping ?





Il s'agit d'une technique de réplication parmi d'autre, qui nécessite
pour le moment un outil externe ( walmgr.py, pg_standby )

On réplique l'ensemble du cluster, et le 'slave' n'est pas disponible,
ça ne sert que pour avoir un serveur disponible en cas de panne du
serveur principal.

Pour la prochaine version ( 9.0 ), ces 2 points seront largement
améliorer : plus besoin d'outils externes pour la réplication, et
possibilité de se connecter au 'slave' en lecture seule.

Il existe d'autres techniques de réplication, avec londiste ou slony-I,
asyncrhone, basé sur des triggers, qui consiste à répliquer les DMLs
vers un autre serveur actif.

Ces 2 modes de réplications répondent à des besoins tout à fait différent.

--
Sébastien
JKB
Le #21924891
Le 23-01-2010, ? propos de
Re: choix MySQL & Postgres,
Sebastien Lardiere ?crivait dans fr.comp.applications.sgbd :
Alain Montfranc a écrit :
Le 22/01/2010, Sebastien Lardiere a supposé :

Pour les outils de réplication, je dirais au contraire qu'il y a plus
d'outils disponible avec PostgreSQL, couvrant plus de cas de figure que
MySQL.




C'est pas natif depuis la 8.2 avec le log shiping ?





Il s'agit d'une technique de réplication parmi d'autre, qui nécessite
pour le moment un outil externe ( walmgr.py, pg_standby )

On réplique l'ensemble du cluster, et le 'slave' n'est pas disponible,
ça ne sert que pour avoir un serveur disponible en cas de panne du
serveur principal.

Pour la prochaine version ( 9.0 ), ces 2 points seront largement
améliorer : plus besoin d'outils externes pour la réplication, et
possibilité de se connecter au 'slave' en lecture seule.



Oui, ça c'est un point négatif pou MySQL. Les connexions sur
l'esclave peuvent se faire en _écriture_. C'est très casse-gueule.

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Sebastien Lardiere
Le #21924841
Le 23/01/2010 12:21, JKB a écrit :

Pour la prochaine version ( 9.0 ), ces 2 points seront largement
améliorer : plus besoin d'outils externes pour la réplication, et
possibilité de se connecter au 'slave' en lecture seule.



Oui, ça c'est un point négatif pou MySQL. Les connexions sur
l'esclave peuvent se faire en _écriture_. C'est très casse-gueule.



Oui, ça, c'est pour la future version de PostgreSQL. La version actuelle
de ce mode de réplication ne permet pas de connexion au slave, du coup,
on est tranquille de ce coté là.

Par contre, l'autre mode de réplication, basé sur des triggers (
londiste, slony-I ), n'empeche pas de faire des betises sur le slave. Il
faut donc utiliser les ACLs ( grant, revoke ), et du coup, on peut
appliquer la même recette dans MySQL.

Bon, si j'étais de mauvaise fois, je dirais que l'unique mode de
réplication de MySQL est assez batard, et bancal, voire carrément
foireux, mais comme je ne suis pas de mauvaise fois, je ne l'ai pas dit ...

--
Sébastien
Pif
Le #21924831
Bonjour,

merci pour vos recommandations pour PG. Coté réplication, on m'avait
dit du bien de Sequoia, et PG Pool II est recommandé par la doc PG....
personne ne les cite. Ils sont moins bon ?

Il s'agit d'une appli interne avec des données de facturations qui
nécessite une fiabilité importante pour pouvoir récupérer les donn ées.
Je n'ai pas besoin d'une ultra haute dispo, mais la redondance était
pour moi un outil permettant de faire de la redondance
- pour la sauvegarde des données,
- la dispo éventuellement
- le load balancing (certains clients consomme beaucoup pour du
reporting, d'autres vont etre ouverts en internet et pas seulement
intranet, etc.).

Merci.
Publicité
Poster une réponse
Anonyme