Depuis quand le goulot d'étranglement se situe au niveau de la CPU quand on a un seul disque fut-ce un raptor ?
Depuis qu'on peut avoir une base de taille raisonnable (quelques Go), qui tient en RAM, avec assez peu d'écritures, des requêtes en lecture très complexes, une BP mémoire suffisante et que du coup le point limitant est le CPU ?
Ce benchmark vaut ce qu'il vaut mais il est au moins représentatif d'une partie de la base installée et montre aussi que la légende de la lenteur de PostgreSQL comparé à MySQL est bien une légende, au moins dans ce cas précis de benchmark.
Je me bat tous les jours pour que des serveurs dédiés aux SGBDR soient correctement équipés en sous-sytème disque et qu'on arrête cette course effrénée à la puissance CPU qui n'est de toutes façons jamais utilisée (au contraire de la RAM).
Sur la première partie, on est d'accord. Sur la deuxième pas du tout. Quand tes I/O ne sont plus un point limitant (donc si le sous-sytème disque est dimensionné correctement et si la base est orienté lecture - le cas de pas mal de bases), ce sont les CPU qui deviennent la limite.
Nous avons le cas sur au moins une de nos grosses (pas par la taille un peu > à 2 Go mais par la criticité métier et la charge) bases. Le serveur est un quadri xeon 2.2, 2 disques pour le WAL, 4 pour les données en RAID 10, 4 Go de RAM et la limite est clairement le CPU.
Accessoirement, l'objectif de tweakers était plus de comparer des plate-formes dans une utilisation SGBD (sun, opteron, woodcrest) donc le fait de baser le benchmark sur le CPU est assez normal.
En fait, il s'agit plus de finition qu'autre chose. Cette fonctionnalité était déjà très largement utilisable et utilisée depuis la 8.1.
La 8.2 apporte plus de facilité dans ce processus.
* Intégration du projet Google SoC d'algorithme de jointure dit "unions complètes".
Non, il n'a pas été intégré dans PostgreSQL. C'est un projet sur pgFoundry ( http://pgfoundry.org/projects/fulldisjunction/ ). La raison pour laquelle cela n'a pas été intégré est que la version actuelle est plus vue comme un proof of concept qu'autre chose.
A priori, elle ne sera intégrée que réécrite complètement différemment (si quelqu'un le fait).
Je trouve que PostGreSQL est vraiment un des projets dont le libre peut-être le plus fier. Un bon support des standards, un développement dynamique, des performances toujours meilleures, que du bon.
Et j'ajouterai une communauté fort sympathique. C'est vraiment un plaisir de suivre et de participer aux discussions que ce soit sur les ML ou sur IRC.
A noter qu'il est normalement prévu que la 8.3 sorte très vite (vers juin) histoire de décaler le cycle de release de 6 mois et ainsi éviter le freeze pendant les mois d'été qui a posé pas mal de souci pour la 8.2.
Pourquoi pas un sponsoring massif de PostgreSQL par Red Hat ?
Massif, je ne sais pas, mais un des plus importants développeurs de PostgreSQL (Tom Lane - AMHA le plus important) est un employé de Red Hat depuis quelques années déjà.
> 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.
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.
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.
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.
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.
> À 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.
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).
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.
Skype a annoncé au PostgreSQL Anniversary Summit qu'ils utilisaient PostgreSQL, qu'ils avaient développé des outils en interne et qu'ils avaient bien l'intention de les contribuer (un projet a été créé sur pgfoundry.org à cet effet - il s'agit du projet Skytools et il avance effectivement bien en ce moment). Ils ont également développé une solution de réplication/partitionnement de données appelée pl/proxy qui devrait être libre également.
Hannu Krosing, un employé de Skype, est également très présent sur les listes de diffusion.
PQA jusque sa version 1.4 pouvait analyser des logs MySQL également donc cela fera peut-être ton bonheur.
Au départ, je pensais aussi que pgFouine évoluerait peut-être dans ce sens donc il était assez générique pour pouvoir accueillir MySQL (et ou n'importe quel autre SGBD). Au fur et à mesure, je dois avouer que quelques PostgreSQLismes se sont glissés dans le code. Ceci dit, l'effort ne doit pas être énorme pour les remettre à leur place.
Si tu as des logs MySQL bien parlants et variés qui ne sont pas confidentiels, je peux y jeter un oeil rapide, voir si cela peut se faire vite, Je vais avoir un peu de temps prochainement.
En fait, je m'étais dit que j'aurai probablement l'occasion au niveau du boulot de bosser dessus (cela me saoûle pas mal de faire du MySQL sur mon temps perso) mais pour l'instant, cela ne s'est pas présenté donc c'est resté comme ça.
S'il y a une demande et des gens pour fournir des fichiers de logs et faire des tests, ça peut s'arranger (note que je n'ai aucune idée de la tête d'un fichier de log MySQL donc je ne sais même pas s'il est possible de le faire :)).
Je suis également en train de travailler sur Sequoia (mais tu l'as ptet vu étant donné ton clin d'oeil :)) et c'est loin d'être tout rose. Cela introduit tout de même un sacré overhead et sur des données dont l'intégrité est vraiment critique (plate-forme des impôts par exemple), je dois avouer que je préférerai une solution au niveau de la base elle-même. Ceci dit, Sequoia est une très belle bête. On devrait le mettre en production assez rapidement pour deux de nos clients et je pense qu'il répondra parfaitement aux besoins.
Pour ton "MySQL/PhPMyadmin (facilité d'installation, d'utilisation, perf, documentation...)", je dirai que c'est une question de goût :
* sous Linux, il est aussi facile d'installer l'un que l'autre ;
* pour l'utilisation, je trouve PostgreSQL beaucoup plus logique (mais c'est peut-être parce que je le pratique plus que MySQL depuis 2001) ;
* pour les perfs, cela dépend de la complexité des requêtes et s'il y a plus d'un utilisateur :) ;
* pour la documentation, je préfère celle de PostgreSQL (je trouve le moteur de recherche plus pertinent notamment et la doc globalement plus claire et moins touffue/bordélique).
Perso, j'utilise presqu'exclusivement le client en ligne de commande psql donc je ne suis pas une référence. Ce que j'apprécie, ce sont la complétion sur les noms des objets, l'historique des requêtes, la recherche dans l'historique et la possibilité d'éditer les requêtes dans vim. C'est en fait un outil très efficace une fois qu'on en a pris l'habitude.
PostgreSQL est clairement une des bases de données les plus matures du moment. C'est notre base de données de prédilection dès que les projets atteignent une certaine taille (ou demandent des fonctionnalités avancées) et nous en sommes très très satisfaits.
Les outils d'administration qu'ils soient libres ou propriétaires sont très complets. La communauté autour de PostgreSQL (principalement autour des listes de diffusion et du channel #postgresql sur freenode) est très active/réactive et les discussions sont en général de très bon niveau (ceci s'explique aussi par le fait que les débutants passent souvent par la case MySQL).
Côté support aux entreprises, que ce soit aux Etats-Unis (Red Hat, Command Prompt, EntrepriseDB ou Greenplum pour les datawarehouses et le business intelligence), au Japon, en Australie ou plus proche en France (que je connais personnellement, il y a au moins Dalibo et nous - Open Wide), des entreprises proposent du support/de l'hébergement autour de PostgreSQL.
L'avantage d'avoir plein d'entreprises différentes autour est que le projet n'est pas noyauté et est vraiment très ouvert.
PostgreSQL reste une des bases qui suit le mieux les standards et cela se sent dans l'utilisation quotidienne car tout est très logique et tombe en général sous le sens. C'est un des plus qui fait la différence avec un client (psql) très bien conçu, un EXPLAIN ANALYZE très détaillé qui permet de vraiment comprendre comment s'exécute une requête en vue de l'optimiser et tout plein de petites choses qui simplifient la vie au quotidien.
Pour prendre un cas concret, nous avons accompagné Cityvox (gros site d'informations sur les villes) dans leur migration d'Oracle vers PostgreSQL il y a plus d'un an maintenant et ils en sont plus que très satisfaits. Ca va plus vite, ça coûte _beaucoup_ moins cher et le fonctionnement est beaucoup plus transparent.
Il reste un point sur lequel Oracle a de l'avance, ce sont les solutions de clustering. Les solutions de réplication pour PostgreSQL sont maintenant matures mais il leur reste un sacré chemin avant d'atteindre ce que peuvent faire les solutions de type Oracle RAC.
Le principe de compression se baserai sur une technologie de reconnaissance d'objets dans la vidéo qui seraient alors compressés/stockés une seule fois. Par exemple la face d'un acteur qui apparaît tout au long du film.
... et qui a toujours la même expression donc.
Dommage que ca ne permette d'encoder que les films avec Nicolas Cage.
quand on veut envoyer en prison des internautes parcequ'ils ont téléchargé du Lorie sur leur mule.
Cela me paraît normal et même souhaitable. Par contre, il est clair que c'est dommage de stigmatiser les gens qui téléchargent du Lorie alors que ceux qui achètent ses CDs sont bien pires.
A ce sujet: Ca va venir, les fans du Web2.0 parle déja de taguer les tags. Bientôt, j'espère qu'ils penseront à taguer les taguages (c'est à dire les relations tag-ressource), et peut-être à unifier les tags et les ressources taguées, (pourquoi distinguer les 2? pourquoi ne pas tagguer des ressources avec une autre ressource comme par exemple une image).: Paf! on obtiendra un graphe de flèches. Si tu ne comprends rien à ce que je dis, c'est pas grave, j'ai l'habitude.
Les topics maps proposent cela depuis pas mal de temps. C'est assez intéressant comme concept. Le seul inconvénient étant qu'il n'y a pas vraiment d'applications web libres finalisées qui permettent vraiment d'exploiter le principe (je pense principalement à des applications de knowledge management basées sur ce principe).
En général, ces petits serveurs http sont surtout utilisés pour servir du statique (pages html, images, css, fichiers js...) donc un test de type hello world est assez proche de la réalité.
lighttppd a l'air de vouloir apporter des fonctionnalités applicatives beaucoup plus avancées par contre.
Mmmmh, déjà un serveur http dans le noyau, ce n'est pas forcément la meilleure idée du siècle.
Et accessoirement, il me semble que tux n'est plus maintenu depuis un bail et d'après les benchs que j'avais fait, il n'offrait pas non plus un gain énorme par rapport à thttpd comparé aux problèmes qu'il pose.
Nous, on utilise thttpd pour servir les images statiques sur un site à trafic plutôt élevé. Ca va vite et ca correspond bien à notre besoin.
A l'époque, j'avais évalué tux, thttpd et l'utilisation des squid dont on se sert pour les reverse et j'avais feuilleté les benchs qui étaient fait sur pas mal de sites. thttpd sortait du lot en terme de perfs / squid et n'allait pas beaucoup moins vite qu'un tux (et tux pose pas mal de souci et n'a plus l'air vraiment maintenu).
Le gros avantage de lighttpd sur thttpd est la gestion du keep-alive.
Pour les benchs, apache bench pour tester des perfs brutes, ce n'est pas mal mais ca reste assez basique forcément.
Oui et non. Pour une utilisation normale, 256 mo sont largement suffisants. Ca tourne parfaitement sur mon vieux portable (celeron 650, 256mo) et je l'utilise au jour le jour (FC3 et e16 comme wm) avec thunderbird et firefox lancés à côté.
Evidemment, pour des gros projets java, 1go, c'est mieux voire indispensable, mais perso, je l'utilise pas mal pour du PHP et pour son plugin CVS et c'est nickel.
En trois mots, ca se tente, au moins pour l'utilisation que tu veux en faire.
Tu devrais jeter un oeil à Eclipse et à son plugin Azzurri Clay http://www.azzurri.jp/en/index.jsp(...) . Cela permet de faire du reverse engineering à travers un driver jdbc. Cela marche plutot pas mal avec PostgreSQL.
Non, il y a eu la création d'un groupement d'un certain nombre de sociétés qui gravitent autour du libre à Lyon (pas forcément des SSLL d'ailleurs). Pas mal de ces boites utilisent le logiciel libre mais font du proprio.
L'idée a effectivement été proposée lors d'une réunion du club des logiciels libres de Lyon Infocité. Je n'arrive plus à remettre la main sur le nom par contre, ni sur le site web qui a été créé par la suite.
[^] # Re: très jolies perfs
Posté par Guillaume Smet (site web personnel) . En réponse à la dépêche Sortie de PostgreSQL 8.2. Évalué à 5.
Depuis qu'on peut avoir une base de taille raisonnable (quelques Go), qui tient en RAM, avec assez peu d'écritures, des requêtes en lecture très complexes, une BP mémoire suffisante et que du coup le point limitant est le CPU ?
Ce benchmark vaut ce qu'il vaut mais il est au moins représentatif d'une partie de la base installée et montre aussi que la légende de la lenteur de PostgreSQL comparé à MySQL est bien une légende, au moins dans ce cas précis de benchmark.
Sur la première partie, on est d'accord. Sur la deuxième pas du tout. Quand tes I/O ne sont plus un point limitant (donc si le sous-sytème disque est dimensionné correctement et si la base est orienté lecture - le cas de pas mal de bases), ce sont les CPU qui deviennent la limite.
Nous avons le cas sur au moins une de nos grosses (pas par la taille un peu > à 2 Go mais par la criticité métier et la charge) bases. Le serveur est un quadri xeon 2.2, 2 disques pour le WAL, 4 pour les données en RAID 10, 4 Go de RAM et la limite est clairement le CPU.
Accessoirement, l'objectif de tweakers était plus de comparer des plate-formes dans une utilisation SGBD (sun, opteron, woodcrest) donc le fait de baser le benchmark sur le CPU est assez normal.
--
Guillaume
[^] # Re: Détails ?
Posté par Guillaume Smet (site web personnel) . En réponse au journal PostgreSQL 8.2.0 est sorti. Évalué à 3.
Quelques petites précisions :
En fait, il s'agit plus de finition qu'autre chose. Cette fonctionnalité était déjà très largement utilisable et utilisée depuis la 8.1.
La 8.2 apporte plus de facilité dans ce processus.
Non, il n'a pas été intégré dans PostgreSQL. C'est un projet sur pgFoundry ( http://pgfoundry.org/projects/fulldisjunction/ ). La raison pour laquelle cela n'a pas été intégré est que la version actuelle est plus vue comme un proof of concept qu'autre chose.
A priori, elle ne sera intégrée que réécrite complètement différemment (si quelqu'un le fait).
Et j'ajouterai une communauté fort sympathique. C'est vraiment un plaisir de suivre et de participer aux discussions que ce soit sur les ML ou sur IRC.
A noter qu'il est normalement prévu que la 8.3 sorte très vite (vers juin) histoire de décaler le cycle de release de 6 mois et ainsi éviter le freeze pendant les mois d'été qui a posé pas mal de souci pour la 8.2.
--
Guillaume
# Pourquoi pas un sponsoring massif de PostgreSQL par Red Hat ?
Posté par Guillaume Smet (site web personnel) . En réponse au journal Oracle Unbreakable Linux. Évalué à 3.
Massif, je ne sais pas, mais un des plus importants développeurs de PostgreSQL (Tom Lane - AMHA le plus important) est un employé de Red Hat depuis quelques années déjà.
[^] # Re: Bonne nouvelle
Posté par Guillaume Smet (site web personnel) . En réponse au journal free & postgresql 8 & php 5. É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 Guillaume Smet (site web personnel) . En réponse au journal free & postgresql 8 & php 5. É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 Guillaume Smet (site web personnel) . En réponse au journal free & postgresql 8 & php 5. É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 Guillaume Smet (site web personnel) . En réponse au journal free & postgresql 8 & php 5. É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 Guillaume Smet (site web personnel) . En réponse au journal free & postgresql 8 & php 5. É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 Guillaume Smet (site web personnel) . En réponse au journal free & postgresql 8 & php 5. Évalué à 1.
Cf http://feedlounge.com/blog/2005/11/20/switched-to-postgresql(...) par exemple.
[^] # Re: Bonne nouvelle
Posté par Guillaume Smet (site web personnel) . En réponse au journal free & postgresql 8 & php 5. É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.
# Skype contribue aussi au libre
Posté par Guillaume Smet (site web personnel) . En réponse au journal Wengo dans La Tribune. Évalué à 5.
Skype a annoncé au PostgreSQL Anniversary Summit qu'ils utilisaient PostgreSQL, qu'ils avaient développé des outils en interne et qu'ils avaient bien l'intention de les contribuer (un projet a été créé sur pgfoundry.org à cet effet - il s'agit du projet Skytools et il avance effectivement bien en ce moment). Ils ont également développé une solution de réplication/partitionnement de données appelée pl/proxy qui devrait être libre également.
Hannu Krosing, un employé de Skype, est également très présent sur les listes de diffusion.
Et Skype était l'un des Gold Sponsors du Anniversary Summit et est désormais un des sponsors du projet PostgreSQL (sources : http://conference.postgresql.org/Sponsors et http://www.postgresql.org/about/sponsors ).
Donc si le client est effectivement fermé, Skype joue aussi le jeu du libre à sa manière et c'en est une fort belle pour l'instant AMHA.
[^] # Re: Et sous MySQL ?
Posté par Guillaume Smet (site web personnel) . En réponse à la dépêche Nouvelle version de pgFouine, l'analyseur de logs PostgreSQL. Évalué à 1.
C'est pas grave :).
PQA jusque sa version 1.4 pouvait analyser des logs MySQL également donc cela fera peut-être ton bonheur.
Au départ, je pensais aussi que pgFouine évoluerait peut-être dans ce sens donc il était assez générique pour pouvoir accueillir MySQL (et ou n'importe quel autre SGBD). Au fur et à mesure, je dois avouer que quelques PostgreSQLismes se sont glissés dans le code. Ceci dit, l'effort ne doit pas être énorme pour les remettre à leur place.
Si tu as des logs MySQL bien parlants et variés qui ne sont pas confidentiels, je peux y jeter un oeil rapide, voir si cela peut se faire vite, Je vais avoir un peu de temps prochainement.
En fait, je m'étais dit que j'aurai probablement l'occasion au niveau du boulot de bosser dessus (cela me saoûle pas mal de faire du MySQL sur mon temps perso) mais pour l'instant, cela ne s'est pas présenté donc c'est resté comme ça.
S'il y a une demande et des gens pour fournir des fichiers de logs et faire des tests, ça peut s'arranger (note que je n'ai aucune idée de la tête d'un fichier de log MySQL donc je ne sais même pas s'il est possible de le faire :)).
La balle est donc dans ton camp :).
[^] # Re: Comparaison avec Oracle
Posté par Guillaume Smet (site web personnel) . En réponse à la dépêche Nouvelle version de pgFouine, l'analyseur de logs PostgreSQL. Évalué à 6.
Pour ton "MySQL/PhPMyadmin (facilité d'installation, d'utilisation, perf, documentation...)", je dirai que c'est une question de goût :
* sous Linux, il est aussi facile d'installer l'un que l'autre ;
* pour l'utilisation, je trouve PostgreSQL beaucoup plus logique (mais c'est peut-être parce que je le pratique plus que MySQL depuis 2001) ;
* pour les perfs, cela dépend de la complexité des requêtes et s'il y a plus d'un utilisateur :) ;
* pour la documentation, je préfère celle de PostgreSQL (je trouve le moteur de recherche plus pertinent notamment et la doc globalement plus claire et moins touffue/bordélique).
[^] # Re: Comparaison avec Oracle
Posté par Guillaume Smet (site web personnel) . En réponse à la dépêche Nouvelle version de pgFouine, l'analyseur de logs PostgreSQL. Évalué à 3.
De manière plus générale au boulot, nous utilisons phpPgAdmin ( http://phppgadmin.org/ ) et aussi pgAdmin III ( http://www.pgadmin.org ) qui sont libres et assez classiques.
Pour les outils propriétaires, j'ai entendu des bruits et vu des screenshots mais nous ne les utilisons pas.
[^] # Re: Comparaison avec Oracle
Posté par Guillaume Smet (site web personnel) . En réponse à la dépêche Nouvelle version de pgFouine, l'analyseur de logs PostgreSQL. Évalué à 10.
Les outils d'administration qu'ils soient libres ou propriétaires sont très complets. La communauté autour de PostgreSQL (principalement autour des listes de diffusion et du channel #postgresql sur freenode) est très active/réactive et les discussions sont en général de très bon niveau (ceci s'explique aussi par le fait que les débutants passent souvent par la case MySQL).
Côté support aux entreprises, que ce soit aux Etats-Unis (Red Hat, Command Prompt, EntrepriseDB ou Greenplum pour les datawarehouses et le business intelligence), au Japon, en Australie ou plus proche en France (que je connais personnellement, il y a au moins Dalibo et nous - Open Wide), des entreprises proposent du support/de l'hébergement autour de PostgreSQL.
L'avantage d'avoir plein d'entreprises différentes autour est que le projet n'est pas noyauté et est vraiment très ouvert.
PostgreSQL reste une des bases qui suit le mieux les standards et cela se sent dans l'utilisation quotidienne car tout est très logique et tombe en général sous le sens. C'est un des plus qui fait la différence avec un client (psql) très bien conçu, un EXPLAIN ANALYZE très détaillé qui permet de vraiment comprendre comment s'exécute une requête en vue de l'optimiser et tout plein de petites choses qui simplifient la vie au quotidien.
Pour prendre un cas concret, nous avons accompagné Cityvox (gros site d'informations sur les villes) dans leur migration d'Oracle vers PostgreSQL il y a plus d'un an maintenant et ils en sont plus que très satisfaits. Ca va plus vite, ça coûte _beaucoup_ moins cher et le fonctionnement est beaucoup plus transparent.
Il reste un point sur lequel Oracle a de l'avance, ce sont les solutions de clustering. Les solutions de réplication pour PostgreSQL sont maintenant matures mais il leur reste un sacré chemin avant d'atteindre ce que peuvent faire les solutions de type Oracle RAC.
En espérant avoir répondu à tes interrogations.
# Dommage...
Posté par Guillaume Smet (site web personnel) . En réponse au journal Le retour d'I2BP ?. Évalué à 10.
... et qui a toujours la même expression donc.
Dommage que ca ne permette d'encoder que les films avec Nicolas Cage.
[^] # Re: Au sujet de La Ligue.
Posté par Guillaume Smet (site web personnel) . En réponse au journal Demande de démission du Ministre de la Culture. Évalué à 8.
Cela me paraît normal et même souhaitable. Par contre, il est clair que c'est dommage de stigmatiser les gens qui téléchargent du Lorie alors que ceux qui achètent ses CDs sont bien pires.
# Topic maps
Posté par Guillaume Smet (site web personnel) . En réponse au journal Gmail et simplicité volontaire. Évalué à 2.
Les topics maps proposent cela depuis pas mal de temps. C'est assez intéressant comme concept. Le seul inconvénient étant qu'il n'y a pas vraiment d'applications web libres finalisées qui permettent vraiment d'exploiter le principe (je pense principalement à des applications de knowledge management basées sur ce principe).
Il y a une belle application (pas libre) réalisée par Ontopia qui permet de naviguer dans des topics maps : http://www.ontopia.net/omnigator/models/index.jsp .
[^] # Re: Je confirme...
Posté par Guillaume Smet (site web personnel) . En réponse au journal gaim et jabber sur grand écran. Évalué à 2.
Comprenne qui aura vu le film que je conseille aussi très chaudement. Certainement un des meilleurs films que j'ai vu dernièrement.
[^] # Re: et les autres...
Posté par Guillaume Smet (site web personnel) . En réponse à la dépêche Lighttpd : un concurrent pour Apache. Évalué à 1.
lighttppd a l'air de vouloir apporter des fonctionnalités applicatives beaucoup plus avancées par contre.
[^] # Re: Oui !
Posté par Guillaume Smet (site web personnel) . En réponse à la dépêche Lighttpd : un concurrent pour Apache. Évalué à 7.
Et accessoirement, il me semble que tux n'est plus maintenu depuis un bail et d'après les benchs que j'avais fait, il n'offrait pas non plus un gain énorme par rapport à thttpd comparé aux problèmes qu'il pose.
[^] # Re: et les autres...
Posté par Guillaume Smet (site web personnel) . En réponse à la dépêche Lighttpd : un concurrent pour Apache. Évalué à 5.
A l'époque, j'avais évalué tux, thttpd et l'utilisation des squid dont on se sert pour les reverse et j'avais feuilleté les benchs qui étaient fait sur pas mal de sites. thttpd sortait du lot en terme de perfs / squid et n'allait pas beaucoup moins vite qu'un tux (et tux pose pas mal de souci et n'a plus l'air vraiment maintenu).
Le gros avantage de lighttpd sur thttpd est la gestion du keep-alive.
Pour les benchs, apache bench pour tester des perfs brutes, ce n'est pas mal mais ca reste assez basique forcément.
[^] # Re: Eclipse
Posté par Guillaume Smet (site web personnel) . En réponse au journal Conversions MySql / PostgreSQL et MCD/MPD. Évalué à 2.
Evidemment, pour des gros projets java, 1go, c'est mieux voire indispensable, mais perso, je l'utilise pas mal pour du PHP et pour son plugin CVS et c'est nickel.
En trois mots, ca se tente, au moins pour l'utilisation que tu veux en faire.
# Eclipse
Posté par Guillaume Smet (site web personnel) . En réponse au journal Conversions MySql / PostgreSQL et MCD/MPD. Évalué à 4.
[^] # Re: Lyon Infocité
Posté par Guillaume Smet (site web personnel) . En réponse au journal Boîtes d'info lyonnaises faisant dans le LL. Évalué à 1.
L'idée a effectivement été proposée lors d'une réunion du club des logiciels libres de Lyon Infocité. Je n'arrive plus à remettre la main sur le nom par contre, ni sur le site web qui a été créé par la suite.
Aucune idée de ce que cette initiative a donné.