Je rejoins les remarques de Pierre sur le RAWFS d'Oracle. C'est effectivement archaïque et à éviter à tout prix.
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.
[^] # Re: PostgreSQL : le plein de nouvelles
Posté par Jean-Paul ARGUDO . En réponse à la dépêche PostgreSQL : le plein de nouvelles. É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.