Je l'ai dit dans un autre journal mais je crois que c'est passé inaperçu.
Donc l'hébergeur free proposer postgresql (version 8.1.4) et php 5 (version 5.1.3RC4-dev).
Cet une excellente nouvelle pour postgresql.
Pour ceux qui ne connaissent ce fabuleux SGBD, voici la doc (somptueuse) :
http://www.postgresql.org/docs/8.1/static/index.html
http://docs.postgresqlfr.org/8.1/ (en français)
Pour avoir php 5, il faut faire un fichier .htaccess avec :
php 1
L'administration de postgresql se fait à cette adresse : http://sql.free.fr/phpPgAdmin/
J'ai un petit problème. Je n'arrive pas à récupérer de dump de la base. phpPgAdmin propose Import et Export mais ça ne marche pas. Aussi bien avec la version de phpPgAdmin de free qu'avec un phpPgAdmin installé à la main.
Quelqu'un aurait une idée pour contourner ce problème ?
Il n'y a pas urgence mais ça me rendrait bien service.
Question annexe, comment avoir les logs d'accès au site ?
Journal free & postgresql 8 & php 5
27
sept.
2006
# Bonne nouvelle
Posté par chl (site web personnel) . Évalué à 6.
Cependant, je m'interroge sur son utilité pour les pages perso de Free. J'aimerais bien connaitre des applications web qui ont un intéret à fontionner avec PostgreSQL plutôt que son concurrent direct, à savoir MySQL ?
Merci pour vos eclaircissements
[^] # Re: Bonne nouvelle
Posté par clearstream . Évalué à 1.
Par contre postgresql à des fonctionnalité que n'a pas mysql (voir la doc). En plus il est mieux foutu (la gestion des dates sous mysql est à s'arracher les cheveux).
C'est vrai qu'un mec qui ne connais que mysql, qui crois qu'un SGBD ne peut faire que ce que fait mysql peut penser que postgresql ne sert à rien.
> je m'interroge sur son utilité pour les pages perso de Free.
Avec free tu as déjà 1 Go d'espace !
Et plus, il y a une option pour 10 Go d'espace !
Ça donne des idées.
[^] # Re: Bonne nouvelle
Posté par chl (site web personnel) . Évalué à 3.
Mais je n'arrive pas a voir quelles applications web auraient besoin d'un vrai SGBD, plutot que d'un simple MySQL, qui, étant plus simple, est censé etre plus rapide.
[^] # Re: Bonne nouvelle
Posté par clearstream . Évalué à 5.
Un grand messieur à dit que 640 Ko était suffisant. Vu ce qui se faisait à l'époque, il avait raison.
Toi tu dis la même chose mais avec mysql.
Un autre a dit vers les débuts de Linux que le multitache ne sert à rien pour une station de travail ! A l'époque il avait aussi raison.
Tu veux revenir au systèmes monotaches avec 640 Ko ?
> Mais je n'arrive pas a voir quelles applications web auraient besoin d'un vrai SGBD
Il y a plein de code php/perl/etc qui font des trucs que DEVRAIENT faire le SGDB. Il le font car mysql ne sait pas le faire. Requêtes imbriquée, transaction, contrôle d'intégrité, rêgles, convertion de type de données, etc...
> un simple MySQL, qui, étant plus simple, est censé etre plus rapide.
Linux 1.2 est plus simple que Linux 2.6. Tu crois que Linux 1.2 est plus rapide que Linux 2.6 ?
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Bonne nouvelle
Posté par Fabimaru (site web personnel) . Évalué à 1.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Bonne nouvelle
Posté par Fabimaru (site web personnel) . Évalué à 3.
[^] # Re: Bonne nouvelle
Posté par Guillaume Smet (site web personnel) . Évalué à 4.
http://dev.mysql.com/doc/refman/5.0/en/innodb-restrictions.h(...)
on est tout de suite moins partant...
Perso, c'est l'un des gros soucis que je trouve à MySQL, les fonctionnalités à moitié implémentées avec des PS dans la doc et le manque de cohérence global.
Certains de ces problèmes (notamment la problématique du COUNT(*)) transparaissent dans cet article :
http://feedlounge.com/blog/2005/11/20/switched-to-postgresql(...)
> À la rigueur, tu aurais été pertinent en disant que MySQL ne supporte pas les triggers ou les procédures stockées mais MySQL 5.x le permet
Parlons de rigueur justement, je cite "Currently, triggers are not activated by cascaded foreign key actions." (présent dans le lien donné plus haut). La version 5.0 qui est donc la dernière version stable ne permet pas d'utiliser des triggers en étant certain de l'intégrité de la base.
C'est à mon avis un autre gros problème : faire de la publicité sur des fonctionnalités qui sont implémentées partiellement et remettent en cause la véracité des données.
MySQL correspond tout à fait à pas mal de cas d'usage. Mais il ne faut pas non plus pousser le bouchon...
> et la quasi-totalité des applications Web populaires utilisant PostreSql n'en font même pas usage
Tu parles de celles qui ont été développées avec une couche d'abstraction, qui sont compatibles avec MySQL en MyISAM et qui donc doivent tenir compte de ses limitations ?
En tous les cas, je n'ai pas développé une application web qui utilise PostgreSQL sans avoir recours à des triggers.
[^] # Re: Bonne nouvelle
Posté par Anonyme . Évalué à 4.
Sinon, pour l'intéret, je dirais simplement : le confort.
Je connais assez bien les SGBD et les fonctionnalités que les "vrais" doivent fournir (quoique j'ai cru comprendre que mysql avait d'énormes progrès de ce côté), et j'ai pas du tout envie de me retrouver a me dire "a zut, ca je peux pas le faire". C'est jamais agréable, donc si j'ai le choix, direct je prend postgresql. C'est un bijou de technologie, je n'aurais aucune envie de m'en priver.
[^] # Re: Bonne nouvelle
Posté par clearstream . Évalué à 3.
La doc aussi est un bijou. Un grand bravo pour ce travail.
Postgresql est un bijou et pas plus compliqué à utiliser que mysql. D'ailleurs il est souvent plus simple d'utiliser postgresql que de se prendre la tête à contourner les limitations de mysql.
Il y a peut-être la configuration (!= utilisation) qui est plus compliqué. Mais ici la configuration est faite par free.
> quoique j'ai cru comprendre que mysql avait d'énormes progrès de ce côté
Je dois reconnaitre que je fuis mysql depuis plusieures années maintenant. Je l'ai utilisé jusqu'à la version 3.54 (?). Je n'ai pas regardé les versions suivantes (V4 et V5). Même pour des petits projets je préfère postresql.
> MySQL est "un poil" plus rapide,
Ça dépend. Pour les benchs probablement. Mais le manque de fonctionnalité de Mysql fait que tu donnes plus de boulot à php par exemple.
Faire un insert "brut" sous Mysql est plus rapide. Mais avec postgresql (et bien utilisé) tu fais l'insert et tous les contrôles (+requêtes annexes) sont faits. Avec mysql il faut locker les tables (donc la base est indisponible pour les autres), faires des requêtes pour voir si les nouvelles données sont ok, puis faire l'insert. Et ne parlons pas de problème compliqué avec transaction sur plusieurs tables. Au final (somme php+mysql), je doute que mysql donne un gain en performance .
Un peu de pub l'excelle pgadmin :
http://www.pgadmin.org/
copies d'écran : http://www.pgadmin.org/screenshots/
Cerise sur le gâteau, il marche aussi sous windows et mac.
Pour info, la beta de postgresql 8.2 est lancé :
http://www.postgresql.org/developer/beta
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Bonne nouvelle
Posté par Guillaume Smet (site web personnel) . Évalué à 1.
Cf http://feedlounge.com/blog/2005/11/20/switched-to-postgresql(...) par exemple.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Bonne nouvelle
Posté par Guillaume Smet (site web personnel) . Évalué à 4.
Dans l'article que tu cites, je vois surtout des généralités trouvées sur Internet de quelqu'un qui ne connaît pas son sujet.
Tes réponses à mon autre commentaire m'intéresse plus : http://linuxfr.org/comments/759276.html#759276 parce que là, tu ne réponds pas vraiment au problème de fond à savoir qu'InnoDB a aussi des soucis et limitations qu'il vaut mieux connaître plutôt que de l'utiliser sans se poser de questions.
[^] # Re: Bonne nouvelle
Posté par clearstream . Évalué à 2.
>
> http://www.omnistarinc.com/~fonin/devtools.php
Sauf que là il n'y a aucun argument. Ce sont des affirmations gratuites.
> Additionally, MySQL is much faster database and has better performance than PostgreSQL. That's why MySQL is more popular than its competitor.
C'est faux. Ce qui a fait la popularité de Mysql :
- Les hébergeurs de site prenaient Mysl. Normal mysql était adapté à l'utilisation des quota du FS contrairement à PostgreSQL. PostgreSQL a corrigé ça.
- Mysql trouvait sur Windows. Postgresql tourne maintenant aussi sous Windows.
> However I've never seen data loss with MySQL even with often power-offs
Alors c'est bien rigolo. Mysql ne fait pas de fsync à la fin de transaction/modification. Au contraire PostgreSQL fait un fsync. Un confirmation de modification par postgresql se fait TOUJOURS après un fsync.
Si postgresql te dit "les données sont enregistrés sur disque", alors ils sont enregistrés sur le disque.
Si mysql te dit "les données sont enregistrés sur le disque", alors il faut comprendre qu'ils sont peut-être enregistrés sur le disque.
Et ce n'est même un bug temporaire. C'est un choix que fait Mysql pour être plus rapide. Tu vas dire que c'est une "feature".
C'est principalement pour cette raison que Mysql est plus rapide que postgresql. Mais dès qu'on monte en charge, l'avantage s'estompe car pendant l'attente d'un fsync postgresql a aussi autre chose à faire.
On le sait que Mysql ne supporte pas les test acid, je peux aussi t'affirmer qu'il ne supporte pas les coupures de courant.
[^] # Re: Bonne nouvelle
Posté par jemore . Évalué à 3.
MySQL est facilement installable sous windows, depuis la version 3.
Les hébergeurs proposent beaucoup plus MySQL que PG (car il est probablement plus facile a administrer dans un environnement de serveur mutualisé).
Pour faire un backup de la base, il suffit de copier dans un coin les fichiers binaires de la base, qui sont classés dans un répertoire du nom même de la base. Facile a faire.
Il existe de tres bons outils d'admin (MySQLFront, PhpMyAdmin)
Mais depuis que mon hebergeur de page perso (nerim) ne propose QUE Postgre, j'ai bien été obligé de passer à cette base.
Les requetes imbriqués permettent d'éviter de bien trop nombreux "hack" en php (exemple : ... where date = ( select max(date) from table ) n'a pas d'équivalent dans une version stable de MySQL ).
Le jour où les hébergeur gratuit et payant proposeront PG, cette base s'imposera d'elle même.
[^] # Re: Bonne nouvelle
Posté par chl (site web personnel) . Évalué à 2.
T'as pas peur de te retrouver avec une base non cohérente en faisant comme ca ? Imagine la base est en train d'inserer des entrées, et tu copies le fichier alors qu'il n'est pas completement flushé sur disque.
[^] # Re: Bonne nouvelle
Posté par Guillaume Smet (site web personnel) . Évalué à 2.
PostgreSQL a réglé ce problème assez élégamment dans ses dernières versions avec le WAL shipping.
Tu indiques à PostgreSQL que tu vas faire un backup, il bloque la base dans un état cohérent, tu copies les fichiers sur un autre serveur : c'est ta version de référence.
Tu indiques que tu as fini le backup, PostgreSQL reprend son activité normale et tu peux faire en sorte d'envoyer tous les fichiers WAL (en gros le journal pré-écriture de PostgreSQL) sur l'autre serveur.
Tu peux ainsi remonter la machine à côté en démarrant PostgreSQL, cela va partir de la version de référence, appliquer le WAL et zou.
Ca permet notamment de faire du failover assez facilement avec un très petit décalage si tu envoies les fichiers WAL régulièrement.
[^] # Re: Bonne nouvelle
Posté par briaeros007 . Évalué à 2.
Tu as qu'a créer une bd et a faire psql ta_bd -f ton_fichier de tete
(voir pg_dump et pg_dumpall)
Et comme postgres fait des opérations atomique etc ... , le snapshot que tu as de ta bd est cohérent.
bon pour une grosse bd , il faut mieux un |gzip , mais j'ai trouvé cette facon de faire assez sympatique ;)
/me qui est en aucun cas un admin bd, juste un utilisateur de linux curieux ;)
[^] # Re: Bonne nouvelle
Posté par clearstream . Évalué à 1.
Le problème est qu'elle consomme beaucoup de ressource et n'est pas incrémentale. Néanmoins elle est indispensable (au moins pour les mises à jours de postgresql).
Une autre méthode est la réplication avec slony-1. Mais dans ce cas il faut deux serveurs.
[^] # Re: Bonne nouvelle
Posté par Guillaume Smet (site web personnel) . Évalué à 1.
Ce n'est pas un problème de 1 ou 2 serveurs. De toute manière, si tu veux avoir une machine en failover, il t'en faudra toujours 2.
L'intérêt de Slony est d'offrir la possibilité d'avoir une base _active_ à côté de la base principale qui accepte les écritures. Du coup, on peut répartir la lecture (en tout cas, les lectures qui ne demandent pas une synchro parfaite avec l'écriture juste avant) sur plusieurs serveurs. Il faudra toujours envoyer les écritures sur le maître.
L'inconvénient majeur de Slony est que ça introduit des contraintes sur les modifications de schéma et ça demande quand même une surveillance accrue.
Le WAL shipping, c'est beaucoup plus simple à mettre en oeuvre, ça fonctionne tout seul et demande peu de surveillance. L'inconvénient est que le deuxième serveur est entièrement passif ce qui a deux conséquences :
- pas possible de répartir la lecture,
- il y a un petit temps d'indisponibilité, le temps de démarrer le serveur PostgreSQL et qu'il applique les WAL segments.
[^] # Re: Bonne nouvelle
Posté par clearstream . Évalué à 1.
Le "problème" est d'en avoir deux qui tournent en permanence alors que dans 99,9 % des cas un seul suffit.
Si t'as un parc de 10 serveurs, tu peux prévoir 2 bécanes en cas de pénin. Avec Slony-1, il en faut 10.
Il est vrai qu'on peut aussi arranger la "redondance" : serveur A fait backup (failover) pour le serveur B et vice versa. Ça ajoute aussi des contraintes.
Slony-1, pg_(dump|restore) et WAL ont tous leurs intérêts/défauts.
[^] # Re: Bonne nouvelle
Posté par Guillaume Smet (site web personnel) . Évalué à 2.
Toutes les bases de données permettent de faire un dump de la base que ce soit MySQL ou PostgreSQL. C'est ce qu'on utilise en général pour les sauvegardes et pour transporter un dump d'un serveur à un autre.
Là, l'objectif est différent : être capable de remonter une base de manière incrémentale.
Exemple typique :
- si tu fais un pg_dump nocturne et que ton serveur tombe, tu remontes le dump sur une machine à côté. Ca peut être très long pour une grosse base et tu as perdu des données entre le moment où tu as fait ton dump et le moment où le serveur tombe
- avec du wal shipping, tu n'as pas ce problème : la version de la nuit de ta base est déjà OK, tu as les écritures entre le moment où tu as copié le répertoire de données et le moment où c'est tombé (enfin, un peu avant évidemment) et tu peux les réappliquer sur ton serveur en failover. Du coup, ton serveur en failover est prêt beaucoup plus vite et est beaucoup plus synchro.
En espérant avoir été clair.
[^] # Re: Bonne nouvelle
Posté par netsurfeur . Évalué à 1.
1. FLUSH TABLES WITH READ LOCK
2. Backup du répertoire contenant la base de données
3. UNLOCK TABLES
Si en plus on utilise un filesystem permettant les snapshots (ex: lvm), on peut faire:
1. FLUSH TABLES WITH READ LOCK
2. Activer un snapshot
3. UNLOCK TABLES
4. Sauvegarder à partir du snapshot
5. Désactiver le snapshot
La sauvegarde est consistante ET le blocage de la base de données minimal (l'activation du snapshot ne prend qu'une fraction de seconde)
[^] # Re: Bonne nouvelle
Posté par Guillaume Smet (site web personnel) . Évalué à 6.
Sur des requêtes simples à faible charge et avec peu d'écritures, effectivement. Ceci dit, c'est le cas de pas mal d'applications web (des fois parce qu'elles sont écrites à la base pour MySQL d'ailleurs) donc cela convient pour pas mal de besoins.
Pour le reste, PostgreSQL est clairement devant, en terme d'exécution de requêtes complexes, en terme de tenue en charge, quand il y a beaucoup d'écriture et en terme de scalabilité (à partir de la 8.1 sur les archis multi-Xeon - c'était plutôt la cata avant).
Il y a des articles pas mal sur un site néerlandais dont certains sont traduits en anglais :
http://tweakers.net/reviews/646/13 (anglais)
http://tweakers.net/reviews/633/7 (néerlandais mais les graphiques sont compréhensibles)
Quand on y ajoute le confort d'utilisation, la qualité des outils de diagnostic (comparer les EXPLAIN des deux par exemple), la doc et l'absence de petites notes de bas de page (du genre telle fonctionnalité qui ne fonctionne pas dans tel ou tel cas qu'on voit assez souvent chez MySQL), on se dit que PostgreSQL mérite bien sa place chez les hébergeurs et que cela aidera peut-être à sa popularisation et au fait que plus d'applications le supporteront nativement.
[^] # Re: Bonne nouvelle
Posté par dovik (site web personnel) . Évalué à 2.
le moteur de blog DotClear 2 (actuellement en Beta 2) (qui fonctionnait très bien en V1 sur MySQL chez Free).
à priori, la V2 ne fonctionne pas avec MySQL sans innoDB.
http://www.dotclear.net/log/post/2006/08/31/PostgreSQL-Free.(...)
http://www.dotclear.net/forum/viewtopic.php?id=20750
[^] # Re: Bonne nouvelle
Posté par clearstream . Évalué à 1.
# Excellente nouvelle
Posté par blackshack . Évalué à 4.
P.S.: si je peux avoir la crémière et sa fille je prends aussi.
[^] # Re: Excellente nouvelle
Posté par Anonyme . Évalué à 3.
Rails tourne bien avec FastCGI, mais je ne pense pas que ce soit aproprié pour des pages persos mutualisées.
[^] # Re: Excellente nouvelle
Posté par blackshack . Évalué à 2.
A brule pourpoint, c'est impossible à mettre dans un serveur de type mutualisé comme Free non?
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.