[isf-wifidog] postgresql vs mysql, get into the flamebait

Pierre-Luc Bacon pierrelucbacon at aqra.ca
Lun 25 Mai 16:04:53 EDT 2009 

There is an ongoing discussion on the AllianceCSF mailing list about
different problems related to maintaining a Postegresql, especially
about the replication aspect. Some solutions were suggested, such as
using Slony for replication. Marc Blanchet adds his comment by saying
that they had done (at ZAP Québec) some benchmarking about that issue.
Their results were not as good as they would have liked. Also, he is
pointing out that the need for database replication might not be
existent if something like Radius were adopted.

Once again, the idea of a database abstraction was brought back to the
discussion by Jimmy Godbout. Sylvain Carle finally pointed out that
the deadline for a 2.0 release, which is due in September, makes that
project unrealistic unless some people (organizations) can put some
substantial efforts into it.

This is a short summary of what is going on at the moment. I thought
it would be relevant to post it on this list since this might a
problem (if it is a problem at all !) that some of you have
experienced. What solution have you chosen ? The everlasting question
with wifidog-auth: Would that be a useful step to support MySQL as
well ? Ans: probably yes. But now, how would that impact code
complexity and how maintainable would that be ?

Pierre-Luc Bacon

---------- Forwarded message ----------
From: Marc Blanchet <marc.blanchet at viagenie.ca>
Date: 2009/5/25
Subject: Re: [AllianceCSF] Que pensez-vous de Slony-I
To: Alliance des groupes sans-fil communautaires
<alliancecsf at diffusion.zapquebec.org>


Helene Gauthier a écrit :
> On peut discuter longuement sur le sujet, comme le font ces derniers
>
> http://www.xaprb.com/blog/2008/05/18/why-is-mysql-more-popular-than-postgresql/
>
> parfois, les discussions sont plus houleuses....
>
> http://www.developpez.net/forums/d26350/bases-donnees/postgresql/replication-postgresql-master-mysql-slave/
>
> mais les réponses intéressantes
>
> Que pensez-vous de Slony-I
>
> http://www.slony.info/

l'as-tu essayé?  (car, dans ce cas, comme souvent, il faut tester et
essayer pour s'assurer que ça fait la route...)

(contexte: pour zapquebec, on a fait une config de redondance des
serveurs d'authentification. On a étudié toutes les solutions de
redondance BD disponible sur postgres (slony, mammoth, warm standby,
...) et c'est super-pénible, pas toujours bien supporté, ne fait pas ce
qu'on a besoin, ... ).

slony:
- ne réplique pas les changements de schéma (e.g. ALTER TABLE).
- Les deux serveurs doivent être dans la même timezone.
- Le master doit pouvoir se connecter au client, contrairement à MySQL.
- Très complexe.
- slony n'est pas intégré dans postgres, alors que c'est complètement
intégré dans mysql.
- Il faut spécifier une primary key pour chaque table. pas supporté dans
wifidog actuel.

si une réécriture de wifidog est considérée, certaines des limitations
des solutions de réplication de postgres peuvent être "résolues".

encore une fois: il y a de multiples façons de faire de la redondance
pour le système au complet. S'attarder à la redondance uniquement de la
BD n'est pas suffisant. On peut perdre de vue l'ensemble. Et il faudrait
identifier quels sont les besoins réel de redondance dans la "nouvelle"
architecture (surtout avec RADIUS dans le décor). Peut-être que le
résultat est que nous n'avons pas besoin de redondance BD et que le
point de comparaison Postgres/MySQL sur la redondance BD devient
non-pertinent. Encore une fois, il faut regarder l'ensemble de la
problématique.

Je réécris mon point original: la réplication MySQL est beaucoup plus
facile à implanter que postgres. (Je parle juste avec assez d'expérience
de déploiement d'applications MySQL/postgres... en production. Et la
réplication MySQL est un charme: pour une config async-write avec
slaves, 3 lignes de config et c'est fonctionnel. vraiment.)

Faudrait faire une "architecture" de la solution, après identifier les
endroits nécessaires pour la redondance avec les exigences. Ensuite, on
pourra mieux discuter des particularités des solutions.

Marc.

>
> -----Message d'origine-----
> De : alliancecsf-bounces at diffusion.zapquebec.org [mailto:alliancecsf-bounces at diffusion.zapquebec.org] De la part de Marc Blanchet
> Envoyé : 25 mai 2009 13:38
> À : Alliance des groupes sans-fil communautaires
> Objet : Re: [AllianceCSF] PHP ou PostGreSQL ?
>
> Jimmy Godbout a écrit :
>> Pourquoi ne pas utiliser une couche d'abstraction ? De cette façon, le type de bd n'aura pas vraiment d'importance.
>>
> - bien sûr... mais la réalité te rattrape souvent:
>  + tu veux utiliser telle ou telle fonctionalité disponible seulement
> sur la BD que tu utilises.
>  + un programmeur, plus tard, ajoute une toute petite fonctionalité mais
> qui, sans que le programmeur le sache, est spécifique à la BD (genre un
> énoncé SQL spécifique à la BD). un an plus tard, tu veux changer la BD
> et tu te retrouves avec un paquet de code qui n'est pas transportable
> facilement. Tu n'es jamais cuit, mais souvent, finalement, tu ne fais
> pas le changement car moins prioritaire que d'autres besoins.
> - bref, 100% d'accord avec toi, mais en même temps, se souvenir que
> souvent, avec le temps, on devient coincé dans un seul "produit"
> - une autre fois, tu installes une nouvelle version d'un produit pour
> bénéficier d,une nouvelle fonctionalité (ex: redondance). Cela n'a pas
> d'impact sur la programmation et sur la couche d'abstraction, mais ça
> fait que tu restes pris avec le produit. Oui, la programmation reste
> indépendante, mais le résultat est le même: c'est plus compliqué de
> changer de BD.
>
> Il est aussi évident que la redondance, il faut bien identifier ce qu'on
> veut faire. Par exemple, si on prend RADIUS, la redondance pour
> l'authentification/provisionning des users peut se faire par
> l'infrastructure des serveurs RADIUS.
>
> bref, il y a de multiples facettes.
>
> Je voulais juste mentionner que MySQL devance largement postgres pour la
> fonctionalité de la réplication. Et donc à tenir compte dans le choix.
>
> Marc.
>
>> Jimmy
>>
>>> -----Original Message-----
>>> From: bremy at zapquebec.org
>>> Sent: Mon, 25 May 2009 12:40:35 -0400
>>> To: alliancecsf at diffusion.zapquebec.org
>>> Subject: Re: [AllianceCSF] PHP ou PostGreSQL ?
>>>
>>> Merci Marc : c'est un argument qui (à mes yeux au moins...) à une
>>> bien + grande importance que les tendances mondiales sur les outils de
>>> base de données. Car c'est "trés risqué" de bâtir une belle
>>> infrastructure Wifidog 2.0 flambant-neuve, stable et user-friendly,
>>> mais qui demande des efforts humains compliqués lors de redondance
>>> d'un serveur à un autre :
>>> Quand un serveur de PROD tombe... les minutes sont longues et
>>> précieuses.... avant de basculer au serveur de relève :
>>> pensez-y à deux fois ;0))))
>>>
>>> Bruno
>>> PS : n'y voyez là aucune critique ...je ne suis pas programmeur..,
>>> mais je m'occupe des opérations et la disponibilité du service est à
>>> mes yeux + importante que l'architecture en-dessous ;)))
>>>
>>>
>>> Message originalMarc Blanchet <marc.blanchet at viagenie.ca>:
>>>
>>>> pour votre information, assurer la redondance de la BD avec postgresql
>>>> est 100 fois plus compliqué qu'avec MySQL. Avec MySQL, 3 lignes de
>>>> configs, 5 min max et c'est réglé.
>>>>
>>>> Marc.
>>>>
>>>> Frédéric Sheedy a écrit :
>>>>> Bonjour,
>>>>>
>>>>> Je suis plutôt du même avis que Hélène, postgreSQL semble de plus en
>>>>> plus populaire, surtout à cause des performances et des standards
>>>>> respectés par postgreSQL.
>>>>>
>>>>> Le seul problème, c'est que Wordpress n'a pas encore pris en charge
>>>>> postgreSQL, et cela risque de prendre du temps, beaucoup de temps.
>>>>>
>>>>> --
>>>>> Frédéric Sheedy
>>>>>
>>>>>
>>>>> Le 24 mai 2009 09:03, Helene Gauthier
>>>>> <webmaster at zapbas-saint-laurent.org> a écrit :
>>>>>> Bonjour,
>>>>>>
>>>>>>
>>>>>>
>>>>>> Lors des derniers échanges, j’ai cru comprendre qu’il y a des
>>>>>> discussions
>>>>>> entre conserver PostGreSQL pour Wifidog ou Migrer vers MySQL
>>>>>>
>>>>>>
>>>>>>
>>>>>> En ce qui me concerne, cela ne fait pas de différence
>>>>>>
>>>>>>
>>>>>>
>>>>>> par contre si on pense à un avenir sur une durée de 5 ans, il faut
>>>>>> tenir
>>>>>> compte de l’avenir des deux bases en fonction des éventuels
>>>>>> utilisateurs (de
>>>>>> nouvelles zaps)
>>>>>>
>>>>>>
>>>>>>
>>>>>> Difficile de dire lequel l’emportera !
>>>>>>
>>>>>>
>>>>>>
>>>>>> MySQL est évidemment la base la plus utilisée dans le monde
>>>>>> actuellement
>>>>>> mais depuis l’acquisition de Sun par Oracle, il règne une certaine
>>>>>> incertitude
>>>>>>
>>>>>>
>>>>>>
>>>>>> http://www.zdnet.fr/actualites/informatique/0,39040745,39393180,00.htm
>>>>>>
>>>>>>
>>>>>>
>>>>>> pgFoundry a développé tous les outils de migration de MySQL à
>>>>>> PostGreSQL
>>>>>>
>>>>>>
>>>>>>
>>>>>> http://pgfoundry.org/
>>>>>>
>>>>>>
>>>>>>
>>>>>> PHPPgMyadmin est l’équivalent de PhpMyAdmin
>>>>>>
>>>>>>
>>>>>>
>>>>>> http://phppgadmin.sourceforge.net/index.php
>>>>>>
>>>>>>
>>>>>>
>>>>>> La documentation française est de plus en plus abondante
>>>>>>
>>>>>>
>>>>>>
>>>>>> http://postgresql.fr/
>>>>>>
>>>>>>
>>>>>>
>>>>>> WordPress envisage de gérer multiples bases de données dont PostGreSQL
>>>>>>
>>>>>>
>>>>>>
>>>>>> « Puis-je Utiliser une Autre Base de Données que MySQL ?
>>>>>>
>>>>>>
>>>>>>
>>>>>> Les autres bases de données ne sont pas supportées pour le moment.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Il existe de nombreux autres excellents gestionnaires de base de
>>>>>> données,
>>>>>> tels que PostgreSQL ou SQLite auquel WordPress s'intéresse pour les
>>>>>> supporter dans le futur. Prendre en charge plusieurs bases de données
>>>>>> est
>>>>>> plus compliqué qu'il n'y paraît et ne fait pas partie des
>>>>>> développements
>>>>>> actuels, bien que de nombreuses discussions aient été engagées sur la
>>>>>> meilleure approche à envisager. Ces approches pour augmenter le nombre
>>>>>> de
>>>>>> bases de données prises en charge sont étudiées dans l'article
>>>>>> Utiliser des
>>>>>> Bases de Données Alternatives (en anglais). Il existe un portage de
>>>>>> WordPress pour PostgreSQL appelé WordPress-Pg (en anglais). »
>>>>>>
>>>>>>
>>>>>>
>>>>>> MediaWiki fonctionne déjà avec PostGreSQL
>>>>>>
>>>>>>
>>>>>>
>>>>>> GForge qui intègre MailMan est un outil plus convivial que TRAC et
>>>>>> offre
>>>>>> gratuitement un espace de 75 M
>>>>>>
>>>>>>
>>>>>>
>>>>>> http://gforgegroup.com/
>>>>>>
>>>>>>
>>>>>>
>>>>>> Il offre un espace gratuit de 75Mg avec 5 développeurs
>>>>>>
>>>>>>
>>>>>>
>>>>>> “GForge Group is providing a free, 75MB GForge AS project space
>>>>>> with up to 5
>>>>>> developers and a subversion tree at http://gforge.com/. When you
>>>>>> register an
>>>>>> account, you can set up your project and be set as an administrator.
>>>>>> Need
>>>>>> more storage or project members? Add them at the Online Store.”
>>>>>>
>>>>>>
>>>>>>
>>>>>> Joomla l’utilise
>>>>>>
>>>>>>
>>>>>>
>>>>>> http://joomlacode.org/
>>>>>>
>>>>>>
>>>>>>
>>>>>> et quelques autres….
>>>>>>
>>>>>>
>>>>>>
>>>>>> http://gforgegroup.com/customerlist.php
>>>>>>
>>>>>>
>>>>>>
>>>>>> Je vois donc plus davantage à conserver PostGreSQL en fonction de la
>>>>>> convivialité et de la gratuité d’un espace de développement de version
>>>>>>
>>>>>>
>>>>>>
>>>>>> Helene Gauthier
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Liste de diffusion «AllianceCSF»
>>>>>> AllianceCSF at diffusion.zapquebec.org
>>>>>> http://zapquebec.org/cgi-bin/mailman/listinfo/alliancecsf
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> Liste de diffusion «AllianceCSF»
>>>>> AllianceCSF at diffusion.zapquebec.org
>>>>> http://zapquebec.org/cgi-bin/mailman/listinfo/alliancecsf
>>>> --
>>>> =========
>>>> IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca
>>>> Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca
>>>> DTN news service: http://reeves.viagenie.ca
>>>>
>>>> _______________________________________________
>>>> Liste de diffusion «AllianceCSF»
>>>> AllianceCSF at diffusion.zapquebec.org
>>>> http://zapquebec.org/cgi-bin/mailman/listinfo/alliancecsf
>>>>
>>>
>>> --
>>> Bruno Remy
>>> ZAP Québec
>>> _______________________________________________
>>> Liste de diffusion «AllianceCSF»
>>> AllianceCSF at diffusion.zapquebec.org
>>> http://zapquebec.org/cgi-bin/mailman/listinfo/alliancecsf
>> ____________________________________________________________
>> FREE 3D EARTH SCREENSAVER - Watch the Earth right on your desktop!
>> Check it out at http://www.inbox.com/earth
>> _______________________________________________
>> Liste de diffusion «AllianceCSF»
>> AllianceCSF at diffusion.zapquebec.org
>> http://zapquebec.org/cgi-bin/mailman/listinfo/alliancecsf
>
>


--
=========
IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca
Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca
DTN news service: http://reeves.viagenie.ca

_______________________________________________
Liste de diffusion «AllianceCSF»
AllianceCSF at diffusion.zapquebec.org
http://zapquebec.org/cgi-bin/mailman/listinfo/alliancecsf



-- 
Pierre-Luc Bacon
http://pierreluc.aqra.ca

Plus d'informations sur la liste de diffusion WiFiDog