- la v7.2.4 : cette version corrige des problèmes découverts récemment, et est destinée aux utilisateurs ne pouvant pas migrer en 7.3.x,
- la v7.3.2 : il est recommandé de passer à cette version; elle corrige également des problèmes découverts récemment sur la v7.3.x ("overrun and memory leak issues").
Ensuite saviez-vous qu'il existe une interface web d'administration à l'image de phpMyAdmin pour MySQL ? Elle s'appelle tout naturellement phpPgAdmin, et est basée sur PHP.
Toujours en parlant d'interface d'administration basée sur le web, webmin améliore son support PostgreSQL avec sa version 1.060 (Updated the PostgreSQL module to support configuration file format changes in version 7.3, Added backup and restore functions to the PostgreSQL module, for versions 7.2 and above).
Début octobre 2002, le site advocacy a démarré. Il est un petit peu à l'image du groupe marketing de OpenOffice.org et Promo de KDE : news, études de cas, présentations des avantages, invitations à rejoindre le développement et le suivi de PostgreSQL... à visiter.
Et enfin, on termine par un lien sur les papiers des présentations du FOSDEM.
Aller plus loin
- PostgreSQL.org (3 clics)
- PostgreSQL 7.2.4 released (2003-01-31) (1 clic)
- PostgreSQL 7.3.2 released (2003-02-05) (1 clic)
- phpPgAdmin -- Web-bases PostgreSQL Administration (3 clics)
- PostgreSQL Advocacy (9 clics)
- FOSDEM PostgreSQL Track 2003 (3 clics)
# Re: PostgreSQL : le plein de nouvelles
Posté par Tulan . Évalué à 7.
- gestion des raw devices
- backups à chaud
- stabilité et performances par rapport à Sybase (qu'on utilise en ce moment)
[^] # Re: PostgreSQL : le plein de nouvelles
Posté par matiasf . Évalué à 7.
http://www.postgresql.org/docs/view.php?version=7.3&idoc=0&(...)
Les backups à chaud dépendent aussi d'une bonne utilisation de la base de donnée. Par exemple utiliser les transactions si plusieurs manipulations font partis d'un tout, utilisation des rules, etc... Quoiqu'il en soit, PostgreSQL fourni les outils nécessaires pour faire des backups à chaud.
> - stabilité et performances par rapport à Sybase
C'est stable. Il est aussi utilisé/promu par RedHat.
Performance : PostgreSQL a la réputation de bien supporté les montées en charge avec beaucoup d'écritures. Par contre j'ai eu écho de problèmes de performance en lecture pour certaines requêtes et avec certaines versions de PostgreSQL.
> - gestion des raw devices
C'est quoi l'intérêt ? A ma connaissance, PostgreSQL n'utilise pas les raw devices.
Plus globalement, PostgreSQL est un SGBD très fourni en fonctionnalité. Si vous envisagez d'utiliser PostgreSQL, le meilleur point d'entré est la doc :
http://www.postgresql.org/docs/view.php?version=7.3&idoc=0&(...)
PostgreSQL est disponible pour Windows mais cette plateforme n'est pas la cible principale. C'est un OS a évité pour utiliser PostgreSQL.
[^] # Re: PostgreSQL : le plein de nouvelles
Posté par Jerome Alet (site web personnel) . Évalué à 10.
> C'est quoi l'intérêt ? A ma connaissance, PostgreSQL n'utilise pas les raw
> devices.
L'intérêt est de laisser le SGBDR gérer comme il le souhaite la répartition des données sur le disque, ainsi que de passer outre le noyau pour la mise en cache.
En fait le SGBDR construit son propre système de fichiers, adapté à ses besoins et optimisé spécialement.
Oracle fait cela je crois. Unify fait cela c'est sûr. D'autres aussi sans doute.
C'est une question de performances, mais quand ta partition dédiée est tellement pleine que tu ne peux plus rien faire avec, bin t'es mort !
[^] # Re: PostgreSQL : le plein de nouvelles
Posté par Pierre Jarillon (site web personnel) . Évalué à 10.
Il en résulte que l'on doit déclarer la taille initiale de la table ainsi que la taille de ses extensions. Quand il y a beaucoup d'extensions, les performances diminuent et l'administrateur doit tout surveiller et restructurer. C'est à dire qu'il fait le travail d'un bon file system. On a bien entendu un peu plus de performance sur un raw device mais à quel prix ! A mon avis, cette technique archaïque revient cher en ressources humaines et n'est que très rarement utile.
C'est pour cela que je préfère de beaucoup Postgresql à Oracle et aussi parce que les outils de sauvegarde, de restauration et de manipulation de la base de données postgresql sont vraiment commodes.
[^] # Re: PostgreSQL : le plein de nouvelles
Posté par Jerome Alet (site web personnel) . Évalué à -1.
> n'est que très rarement utile.
tout à fait d'accord !
[^] # Re: PostgreSQL : le plein de nouvelles
Posté par Delahaye Matthieu . Évalué à 3.
Je dis pas que c'etait pas le cas a l'epoque, mais je ne suis pas certain du lien de cause a effet avec les raw devices mais bon.
Perso, a une epoque ou on se felicite de pouvoir utiliser des configurations hardware plus legere sous Linux pour des fonctionalites equivalentes, je suis etonne que d'un seul coup l'argument performance passe a la trappe parce qu'il a un coup en ressource humaine. A noter que ce fut le cas il y a quelques annees avec Linux. Fallait il laisser tomber?
Ma preference pour PostGreSql se fait certe par choix philosophique, mais aussi parce qu'il repond largement a mes besoins. Si les besoins changent et qu'Oracle (ou autre) s'impose, je vais pas freiner des quatre fers parce qu'il est moins commode. C'est le resultat que l'on fournit aux utilisateurs qui compte, pas l'huile de coude qu'il a fallu utiliser. Et pour les meme raisons on utilisera les raw devices ou pas.
[^] # Re: PostgreSQL : le plein de nouvelles
Posté par PLuG . Évalué à 6.
Mais de moins en moins d'installations d'oracle se servent de cette "feature".
A une certaine époque, les filesystemes etaient LENTS, un accès raw-device se justifiait.
De nos jours, les filesystèmes sont très rapides, la différence est quasiement invisible, en pratique si la bdd ne tiens pas la charge avec un accès filesystème, passer en raw-device ne changera rien, et surtout montre que les futures évolutions du besoin (montée en charge progressive) ne pourront de toute manière pas être pris en compte.
Si la tenue en charge passe par un accès en raw-device, il est préférable dès aujourd'hui de charger d'architecture (ou de hardware, ou les deux) plutot que d'hypothéquer a ce point les évolutions futures du système mis en place.
Voila, c'est mon avis, je le partage... avec beaucoup d'admin oracle d'ailleur !!
[^] # Re: PostgreSQL : le plein de nouvelles
Posté par Jean-Paul ARGUDO (site web personnel) . Évalué à 10.
Sauf dans le cas des clusters Oracle, ou le RAWFS est obligatoire, pour ce que j'en sais. Dans le cas des clusters, il se pose en effet bon nombre de problèmes complexes et Oracle par ce biais, contrôle absolument toutes les IOs.
-*-
Je ne résiste pas à la tentation de faire part de ma petite expérience à tous ici:
1) Que dire de PostgreSQL?
C'est une SGBDR (et aussi OO pour ceux que ça interresse) robuste et fiable. Les possibilités d'extension sont extraordinaires, tant par la qualité et le nombre de fonctionalités avancées. Je suis DBA Oracle au quotidien, depuis plusieurs années, et je suis sans cesse emerveillé par PostgreSQL, tant par les performances qu'on peut en tirer que par sa souplesse d'utilisation.
2) Une anecdote sur les performances comparées Oracle / PG
Pour la petite histoire, je fus jadis le "consultant base de données" d'une SS2L (sniff...) . Un "client grand compte" était intérressé par une migration Oracle 7.3.4 sous NT4 SP6 vers PostgreSQL 7.2 sous Red Hat 7. Nous devions obtenir des performances au maximum 1,5 fois celle d'Oracle. Au final, nous avons obtenu:
- temps identiques à Oracle sur des SELECT complexes
(dont portage des formes CONNECT BY)
- temps 1,33 fois à Oracle sur des traitements lourds nocturnes par batch..
Sur ce dernier point, il s'agissait de porter un programme représentatif de l'ensemble à migrer. Le programme était à l'origine en PRO*C, nous l'avons naturellement porté en ECPG. L'isofonctionalité était parfaite, jusque dans l'affichage lors de l'exécution du programe (merci à Sebastien, il se recconaîtra...).
Nous avons juste souffert à cause des curseurs à bind variables, par exemple:
SELECT toto, tata, tutu
FROM table
WHERE toto = :id;
:id est la bind variable.
Eh bien, A L'EPOQUE PostgreSQL ne permettait pas cela. A chaque ouverture de notre curseur, PG re-parsait l'ordre et donc re calculait le plan d'exécution, d'où le surcout par rapport à Oracle, qui lui ne parse et calcule le plan d'exécution qu'à la 1ere ouverture du curseur. D'ou le 33% de temps perdu en plus...
Depuis la 7.3 PG sait maintenant faire cela (PREPARE et EXECUTE statment...), donc il faudrait reccomencer cette partie...
...TO BE CONTINUED...
3) La formation Oracle comparé à PG
Il faut en effet plusieurs semaines de formation pour commencer à comprendre et maîtriser Oracle, alors qu'il faut quelques jours pour maîtriser PostgreSQL.
De même pour le tuning. Sous Oracle, il est compliqué, vraiment. Mais d'un autre côté, il est plus fin, on maîtrise plus de choses, même si au final on se rends compte que pour que la base Oracle marche mieux, il faut lui donner plus plus toujours plus de mémoire!
Comme le dit Bruce MOMJIAN, PostgreSQL est finalement un SGBD qui n'a pas besoin de beaucoup de tuning. Et c'est tant mieux!
(cf son article sur le hardware tuning).
4) Les benchmarks
Je voulais enfin ajouter qu'il ne faut pas croire les benchmark. J'ai personellement abandonné toute idée de comparer les performances des SGBD entre eux: aucun ne fonctionnant de la même façon, ils ont tous leurs forces et leurs faiblesses. Il faut arrêter de comparer des pommes et des bananes.
Le seul benchmark qui tienne la route, c'est d'essayer les performances de son application sur tel SGBD ou tel autre. En fonction de ce que l'on veut faire, tel SGBD sera plus approprié que tel autre.
My 2 cents.
[^] # Re: PostgreSQL : le plein de nouvelles
Posté par PLuG . Évalué à 1.
Il y a 3 ou 4 ans, on avait fait faire le test pour rire a un consultant oracle (bossant en direct pour oracle), et sur l'appli testée on avait un rapport 2 sur quasiement toutes les requetes ... en faveur de linux bien sur ;-))
meme hardware, meme datas, meme version d'oracle... et meme appli.
[^] # Re: PostgreSQL : le plein de nouvelles
Posté par Jean-Paul ARGUDO (site web personnel) . Évalué à 1.
Par contre, je n'ai pas le souvenir d'une telle différence entre Oracle/NT et Oracle/RH!!... C'est cependant vrai que sous Linux (Debian pour mes tests), j'avais toujours des résultats plus rapides mais c'était de l'ordre de 10% hein, pas 200%.
Il est cependant indéniable qu'Oracle est vraiment plus souple à gérer sous Unix que sous Windows. Et c'est la véritable raison qui me fait préferer Unix à Windows pour Oracle.
Un exemple tout bête: sous windows quand tu veux faire une sauvegarde à froid (comprendre copie des fichiers de la bdd, une fois celle ci complètement fermée) d'une BD, t'est obligé d'attendre qques minutes que Windows "libère" les fichiers. Autrement, lorsque tu copies les fichiers, ils te jette parceque un "autre processus utilise actuellement le fichier'"!! Sous Unix c'est immédiat. Des que la Bd est fermée, tu peux copier les fichiers dessuite.
Sinon, Oracle sous NT, Unix ou autre (VMS par ex) c'est le MEME PRODUIT. C'est en tout cas ce que je constate depuis 98 que je fais mumuse avec Oracle. Et c'est ce qui ce dit dans les classes d'Oracle University.
Je regrette juste un truc, c'est l'installer graphique en Java qui est là depuis la 8i... C'est franchement n'importequoi et ça n'emène que des emmerdes, notament sous unix.
Sans parler des problemes de compatibilité, vu qu'Oracle est livré avec des objets pré-compilés dans une vieille glibc, et que pour pouvoir les linker, il faut installer les compat-* ...
Sinon, une fois le stade pas toujours simple de l'install d'Oracle sur linux (pour cela, utilisez et abusez de http://staff.in2.hr/denis/oracle/(...) Denis Klaric à fait un super travail...), Oracle sous Linux c'est un pur bonheur: stabilité et performance d'Unix avec la souplesse de Linux.....
... un régal :-)
[^] # Re: PostgreSQL : le plein de nouvelles
Posté par Jean-Paul ARGUDO (site web personnel) . Évalué à 1.
J'ai retrouvé qques liens:
Je vous donne le point d'entrée:
http://www.doc.ic.ac.uk/~sue/475/oss_fs_why.html(...)
A partir de là cherchez le mot "oracle"
Vous allez tomber sur le Chapitre 4, 1er paragraphe:
"In 2002, TPC-C database measures found that a Linux based system was faster than a Windows 2000 based system. More specifically, an HP ProLiant DL580 with 32 Intel Xeon 900MHz CPUs running Oracle 9i R2 Enterprise edition ran faster running on a stock Red Hat Linux Advanced Server than on Microsoft Windows 2000 Advanced Server. You can see the Linux and Windows reports; note that HP did not modify the Linux kernel to get these results."
Il y a des liens sur cet article, suivez les jusqu'aux PDFs vous verez alors les résultats chiffrés.... "Linux" se débrouille mieux que W2K.. et HP certifie ne même pas avoir "tuné" le kernel pour ça.
Bonne lecture!
[^] # Re: PostgreSQL : le plein de nouvelles
Posté par PLuG . Évalué à 1.
Effectivement sous linux c'etait notablement plus rapide, mais je n'aurai pas du donner de chiffres (je ne m'en souviens pas), surtout 200% c'est ridicule. mea culpa.
[^] # Re: PostgreSQL : le plein de nouvelles
Posté par Laurent Vaills . Évalué à 5.
De même que pour Oracle, il faut déclarer la taille maximale de la base de données à la création.
http://www.sapdb.org(...)
[^] # Re: PostgreSQL : le plein de nouvelles
Posté par kesako . Évalué à 1.
Il y a des mecanismes d'extensions ?
des possibilités de prolonger une table sur une autre base ?
[^] # Re: PostgreSQL : le plein de nouvelles
Posté par Laurent Vaills . Évalué à 1.
[^] # Re: PostgreSQL : le plein de nouvelles
Posté par kesako . Évalué à 1.
- fonctionnement sur multipro
- fonctionnement en cluser
comme ces deux points se comparent vis a vis de oracle ou sybase ?
[^] # Re: PostgreSQL : le plein de nouvelles
Posté par Jean-Paul ARGUDO (site web personnel) . Évalué à 4.
****
PG tire complètement parti des plates-formes SMP de part son architecture.
C'est le cas d'Oracle sous Unix (dont Linux). Oracle est composé d'un ensemble de processus qui sont dédiés à des tâches bien particulières.
Sous windows par contre, mise à part la toute derniere mouture de la 9i Database, qui serait multi-threadée vraiment (pas testé, d'où le conditionnel), Oracle est monolithique. Donc, Oracle sous Windows ne tire pas parti du SMP.
Cluster:
*******
Existant sous Oracle depuis longtemps.
A l'étude sous PostgreSQL, c'est dans la TODO list, en priorité "URGENT"!
Pour Sybase, je ne connais pas du tout, je laisse le soin à d'autres pour la comparaison
[^] # Re: PostgreSQL : le plein de nouvelles
Posté par Olivier Jeannet . Évalué à 1.
Il me semble que oui, tout simplement avec l'outil de base livré avec Postgres, qui s'appelle pg_dump.
Tiré de la documentation de Postgres 7.3 :
Dumps created by pg_dump are internally consistent, that is, updates to the database while pg_dump is running will not be in the dump. pg_dump does not block other operations on the database while it is working.
stabilité
Personnellement, je n'ai jamais vu Postgres planter. Un copain qui l'utilise en production sur des serveurs m'a dit que lui non plus n'avait pas eu de problème.
[^] # Re: PostgreSQL : le plein de nouvelles
Posté par VACHOR (site web personnel) . Évalué à 1.
Par ailleurs je confirme la qualité du soft : je l'utilise de 1998, en dev et prod, et jamais eu de problème, ni de stabilité ni de sauvegarde à chaud (sur une base multimédia de plus de 2 Go) ou de restauration. C'est du "install (2min) and forget", et en plus on peut l'utiliser.
Faut quand même mettre le vacuum dans le cron, gros boulot cela prend 1 ligne.
Un petit conseil pour la route : si vous utilisez des caractères accentués dans les textes stockés, vous pouvez éviter des problèmes avec des bases unicode (createdb -E UNICODE).
[^] # Re: PostgreSQL : le plein de nouvelles
Posté par Olivier Jeannet . Évalué à 1.
D'après divers échos que j'ai eus, dont un échange récent sur linuxfr il y a une ou deux semaines, le vacuum peut prendre beaucoup de temps si la base subit beaucoup de modifications, ce qui peut être gênant voire rédhibitoire dans le cas où on a besoin d'un base 24h/24. Cela dit, je suppose que la grande majorité des bases connaît des périodes bien creuses la nuit.
Au sujet du vacuum, je viens de parcourir la doc de la version majeure actuelle (7.3), et ils donnent des précisions intéressantes sur la façon de l'utiliser (la nuit ou plus souvent, seulement pour certaines tables, etc). Apparemment le vacuum simple (plus rapide que le vacuum full et surtout non bloquant) semble tout à fait suffisant dans la mesure où il permet de réutiliser les tuples vides (les trous créés) car il les marque comme tels; le vacuum full permet lui de réduire la place prise sur le disque par les tables, en bouchant les trous. En résumé, le vacuum bien géré ne semble pas un réel problème.
# Re: PostgreSQL : le plein de nouvelles
Posté par _seb_ . Évalué à 2.
Le dev. de PostgreSQl est permanent et est vraiment très actif depuis ces derniers mois. La contribution de Redhat y est certainement pour quelque chose.
Ci dessous quelques liens:
Red Hat Database Project
http://sources.redhat.com/rhdb/(...)
Tools and Utilities (utilitaires graphiques d'administration)
http://sources.redhat.com/rhdb/tools.html(...)
TODO list for PostgreSQL
http://developer.postgresql.org/todo.php(...)
# MySQL / PostgreSQL
Posté par Clément Stenac (site web personnel) . Évalué à 1.
Personnelement, j'utilise MySQL. J'aimerais savoir quels sont les avantages et inconvénients de Postgres, sachant que la performance n'est pas un critère déterminant pour moi (faible nombre de requêtes)....
Donc, plutôt en terme de simplicité, d'interfacage avec PHP...
Puis, le problème de la license MySQL, bien sûr...
[^] # Re: MySQL / PostgreSQL
Posté par matiasf . Évalué à 0.
PostgreSQL.
Les avantages nombreux et les inconvénients rares. C'est un SGBS de haute volée.
> Donc, plutôt en terme de simplicité, d'interfacage avec PHP...
PostgreSQL peut s'utiliser comme MySQL. Toutes les commandes SQL de mysql existe partiquement à l'identique sous PostgreSQL. Si je peux faire cette analogie douteuse :
- C++ est au C ce que PostgreSQL est à MySQL.
- Tu peux faire du C avec C++ et tu peux faire de MySQL avec PostgreSQL.
> d'interfacage avec PHP
L'interfaçage PHP de PostgreSQL est pratiquement équivalent à MySQL. A une différence notable : Il n'y a pas de paramètre par défaut dans les fonctions postgresql. Je trouve cette approche meilleur.
> Puis, le problème de la license MySQL, bien sûr...
PostgreSQL est sous un équivalent de BSD.
[^] # Re: MySQL / PostgreSQL
Posté par matiasf . Évalué à 0.
http://www.postgresql.org/docs/(...)
[^] # Re: MySQL / PostgreSQL
Posté par kesako . Évalué à 1.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.