Journal : free & postgresql 8 & php 5
Posté par clearstream () le 27 septembre 2006
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 ?
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 ?
> Lire le journal (31 commentaires, moyenne: 2,6).
Vous avez demandé le commentaire #759675.
Run by 
Cette page a été générée par Templeet en 0.1019s (dont 0.0095 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Bonne nouvelle
C'est une bonne nouvelle pour PostgreSQL.
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
Si avec postgresql tu fais exactement la même chose qu'avec mysql, il n'y a aucun intérêt à passer à postgresql.
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
Je suis au courant que postgresql est un vrai SGBD, et qu'il permet donc de faire plus de chose qu'avec MySQL.
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
Tu t'y prend à l'envers. Tu regardes ce qui se fait aujoud'hui, alors que tu devrais te demander ce qui se fera demain. Html 3 c'était bien à l'époque.
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 ?
[^]Re: Bonne nouvelle
Avec les table InnoDB, MySQL gère les transactions et effectue les contrôles d'intégrité : comme pour toute base de donnée, il suffit de faire les bons choix à la conception. Depuis MySQL 4.1.x, MySQL gère aussi les requêtes imbriquées. À 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 et la quasi-totalité des applications Web populaires utilisant PostreSql n'en font même pas usage !
[^]Re: Bonne nouvelle
J'avais fait un développement perso (il y a moins d'un an) sur mon compte Free, et il n'était pas possible de créer une table InnoDB. Donc pas de transactions, donc contournements ultra-chiants.
Pas de bureau 3d libre sans drivers libres!
[^]Re: Bonne nouvelle
Si Free décide de désactiver telle ou telle fonctionnalité pour les logiciels MySQL ou PHP, il s'agit de choix personnels de Free et non pas de limitation des logiciels !
[^]Re: Bonne nouvelle
Je suis tout à fait d'accord. Je voulais juste dire que c'est un progrès pour l'utilisateur-développeur que je suis, comme si Free activait le support InnoDB (enfin, je ne sais pas ce qu'il en est à l'heure actuelle). Je ne voulais pas me lancer dans un comparatif MySQL/Postgresql.
Pas de bureau 3d libre sans drivers libres!
[^]Re: Bonne nouvelle
C'est bien beau de brandir InnoDB comme la solution à tous les problèmes de MySQL mais quand on a lu ça :
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
MySQL est "un poil" plus rapide, mais comme contre argument je dirais que, s'il on a besoin de performances, les pages persos de free ne sont certainnement pas la meilleure solution.
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
> C'est un bijou de technologie
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
[^]Re: Bonne nouvelle
Faux ! Avec les tables InnoDB, tu n'as pas besoin de verrouiller les tables et à ce niveau, MySQL supporte les trasactions conformes ACID [1]. Si dès la conception tu décides de te passer des tables InnoDB et d'utiliser les tables primitives MyIsam, c'est que tu as fait un mauvais choix à la conception : MySQL n'y est pour rien.
[1] http://en.wikipedia.org/wiki/ACID
À quel problème tu as été confronté avec les "transactions MySQL sur plusieurs tables" ?
[^]Re: Bonne nouvelle
InnoDB n'est pas la solution à tout... Il a ses propres problèmes et limitations.
Cf http://feedlounge.com/blog/2005/11/20/switched-to-postgresql(...) par exemple.
[^]Re: Bonne nouvelle
Sortir un exemple de problème recherché à l'arrache sur Google pour dire que tel logiciel des limitations, c'est le degré zéro de l'argumentation. Tiens, je me suis amusé à faire pareil :
http://www.omnistarinc.com/~fonin/devtools.php : « Main PostgreSQL drawback is a large number of critical bugs in it. Once when I have a few PostgreSQL-driven applications the most part of my time was wasted to fix the problems produced by this database. PostgreSQL is claimed to be a transactional database, and this means that your data should be safe in the case of software crashes. It is still possible that you will loose your data with PostgreSQL, because of bugs in it. MySQL have no transactional support in its standard distribution (although it has transactional support with extended distribution called mysql-max). However I've never seen data loss with MySQL even with often power-offs, when the system was shut down uncleanly. PostgreSQL is an example of excellent idea and poor implementation. It has much more functions and tools than MySQL and had the transactional support from the start of its development. Moreover, PostgreSQL transaction concept is more powerful than MySQL one (multiversioning vs. table/page/row-level locking). Unfortunately all this cannot be regarded because of lack of reliability. Additionally, MySQL is much faster database and has better performance than PostgreSQL. That's why MySQL is more popular than its competitor. On the contrary, MySQL has attracted a huge number of users during its lifetime. It is very reliable. It gained a lot of functions that are associated with the commercial databases (transactional support, full-text search, replication). Most part of these functions are absent in the PostgreSQL. »
[^]Re: Bonne nouvelle
Sauf que mon article est récent, documenté et porte sur un exemple concret d'un site concret qui a rencontré des problèmes concrets... Et pas trouvé à l'arrache sur google car je l'ai lu il y a quelques mois et trouvé particulièrement intéressant.
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
> Tiens, je me suis amusé à faire pareil :
>
> 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
Pour avoir essayer les deux bases, MySQL et PostGRE, je dois avouer que chacune de ces deux bases ont leurs avantages et leurs défauts (comme par hasard) :
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.
"Quand on est l'homme le plus viril du monde, c'est comme pour les ordinateurs surpuissants : on a besoin d'un putain de système d'exploitation en béton pour faire tourner tout ça sans plantage." P.B.
[^]Re: Bonne nouvelle
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.
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
Clairement, c'est un de soucis qui peut se poser.
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
encore plus simple, tu peux demander à postgres de te sortir un bon vieux fichier SQL pour refaire ta bd si un probleme survient.
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 ;)
Subete ga wakatta toki…watashi ga anta wo korosu.
[^]Re: Bonne nouvelle
C'est la méthode standard.
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
> Une autre méthode est la réplication avec slony-1. Mais dans ce cas il faut deux serveurs.
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
> 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.
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
Ce n'est pas plus simple, c'est différent.
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
On peut faire des sauvegardes cohérentes des bases de données depuis longtemps avec MySQL:
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
> MySQL est "un poil" plus rapide
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
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
Pour info, j'ai eu partiquement aucune difficulté pour faire tourner doclear 2 sous free. Les seuls pépins étaient évidents à corriger et c'étaient des problèmes de configuration.