Discussion :

[SQLpro]

Bonjour

Bon, je crois que je crois me faire encore quelques ennemis de plus...

Voici un article détaillant les inconvénients d'une migration d'Oracle ou de SQL Server vers PostGreSQL...
http://blog.developpez.com/sqlpro/p1...esql-ou-com-2/

Au sommaire :

1 - Aucune gestion des espaces de stockage.
2 - Une gestion des transactions "curieuse".
3 - Un partitionnement plus que léger
4 - Pas de tag (hint) pour forcer les plans de requête
5 - un optimiseur très limité
6 - Une indexation à la traine
7 - Pas de parallélisme des requêtes
8 - Une administration couteuse
9 - pas de pooling des connexions
10 - Pas de vision d'un plan en cours d'utilisation
11 - Un processus de sauvegarde peu performant
12 - Pas de compression ni de cryptage des données
13 - Pas de réplication des données
14 - PostGreSQL reste un bon SGBDR réellement libre
15 - En conclusion

Merci d'avance pour vos commentaires.

A +

[scheu]

Quelques retours d'expérience personnels qui peuvent éventuellement compléter ton article si tu les juges utiles :

Paragraphe 4 (hints)
Effectivement le fait que les hints soient intégrés dans la version payante laisse à penser que jamais la version communautaire gratuite de Postgresql ne les intègrera jamais, au grand regret des DBA ...
La seule marge de manoeuvre quand un plan d'exécution est mauvais se situe au niveau des paramètres du serveur (enable_mergejoin, enable_nestloop, enable_seqscan, ...) que l'on peut modifier dans le SQL, ou par login Postgresql.
Par exemple si une requête fait un nested loop alors que c'est contre-performant comparé à un hash join, on peut faire avant la requête un "set enable_nestloop to off"
Bien que parfois même en modifiant ces paramètres ça n'empêche pas tel ou tel type d'opération ...
Mais ça doit rester exceptionnel, car ça devient vite une usine à gaz si on modifie ces paramètres spécifiquement pour chaque requête

Or la philosophe particulièrement croustillante des développeurs de PG est que c'est très mal de mettre des tags dans les requêtes : "Why PostgreSQL Doesn't Have Query Hints"
Dans un monde parfait, cela serait absolument génial... Mais malheureusement il y a la réalité, et là force est de constater que l'optimisation des requêtes par PostGreSQL est loin d'être... optimale !

Tout-à-fait d'accord avec toi
Autant sur des applications développées "maison" on peut éventuellement chercher à modifier le SQL pour optimiser (et encore, ce n'est pas toujours simple), autant quand on a à faire à un progiciel dont nous n'avons pas la main pour modifier les requêtes, c'est impossible.
Et quand un plan d'exécution pourri arrive du jour au lendemain en production et qu'on demande au DBA de trouver une "rustine" rapide, c'est souvent mission impossible et on regrette de ne pas être sur Oracle ou SQL Server

Paragraphe 5 (optimiseur)
Ca arrive encore trop souvent que les plans d'exécution soient pourris sur Postgresql (même avec des stats à jour et des indexes bien placés) dès qu'on a des requêtes un peu complexes (jointure entre 6-7 tables, auto-jointures, sous-jointures, ...), ou comportant trop de colonnes filtrées sur les tables

Le principal défaut est qu'il sous-estime trop souvent les cardinalités (nombre de lignes retournées à chaque étape du plan), ce qui conduit au bout d'un moment :
- soit à lui faire choisir des "nested loop" au lieu de "hash join" en cas de jointure
- soit à des "index range scan" trop coûteux alors qu'un full scan de la table serait au final meilleur
Je pense que ce problème est lié au fait que Postgresql sait très mal évaluer les nombres de lignes retournés pour des filtres qui comportent plusieurs colonnes
Là où Oracle ou SQL Server, sur un index (col1,col2,col3), sait faire des stats dessus et savoir estimer, pour chaque valeur du triplet, le nombre de lignes dans la table, Postgresql ne sait le faire que dans de très rares cas, les histogrammes se limitant sur des colonnes uniques et pas des t-uples


Paragraphe 10 (plans d'exécution)
Oui, tu ne peux que les voir une fois que la requête est exécutée, et encore ce n'est pas en natif, il faut utiliser pour cela la contrib "auto_explain" qui permet de les récupérer dans la trace du serveur Postgresql, même si ce n'est pas toujours lisible facilement et qu'il faut souvent reformater le fichier à la main

Autre
Concernant la migration de Oracle vers PG (je ne connais pas suffisamment bien SQL Server pour comparer) : tu pourrais aussi éventuellement rajouter un paragraphe sur les principales différences de comportement entre Oracle et Postgresql quand on fait une migration en laissant les paramètres par défaut des 2 côtés, notamment :
- mode "autocommit" par défaut sur Postgresql
- gestion des NULL différentes (sous Oracle, NULL = chaîne de caractères vide, mais pas sous PG, donc différences de comportement d'une même requête)
- conversions de type implicites qui passent sous Oracle mais pas sous PG (test des requêtes d'une appli et réécriture éventuelle à prévoir)
- syntaxe des jointures ouvertes (+) spécifique à Oracle
- sous PG, mot clé "AS" obligatoire pour renommer les colonnes dans une requête SQL
- pas de synonymes ni de packages sous PG
- type "date" de Oracle = type "timestamp" de Postgresql
- ordre de tri différente selon la casse
- PG sensible à la casse sur les noms d'objets

Vous comprendrez que présenter PostGreSQL comme une alternative crédible à Oracle ou même SQL Server sur des bases à forte volumétrie, important trafic ou grande concurrence et est un phantasme de nerd mais est loin d'être une réalité !
Soyons modeste pour ne pas avoir de couteuses déconvenues et évitons les dogmes.
Je sais qu'en rédigeant un tel article je vais m'attirer les foudres de nombreux internautes. Je m'y attend et reste serein. J'ai des arguments et une expérience acquise depuis plus de 20 ans par mon travail avec de nombreux SGBDR...
Mais je sais hélas que, chez certains, la passion du libre l'emporte souvent contre la raison du technique !

Je suis assez d'accord avec toi.
Postgresql a depuis quelques versions de nombreuses fonctionnalités qui se rapprochent des besoins des entreprises (hot standby, sauvegarde à chaud en continu, fonctions analytiques, ...)
Au jour d'aujourd'hui Postgresql peut faire l'affaire pour des petites applications non critiques, à faible volumétrie (quelques dizaines de Go) et à faible complexité (pas de grosses requêtes faisant des jointures sur plus de 5-6 tables)
Mais dès qu'on arrive dans des environnements complexes, volumineux ou critiques, Postgresql montre quand-même ses limites, et ça peut vite devenir critique quand par exemple (c'est du vécu) un problème de mauvais plan d'exécution survient en production, la requête vous mange 100% de CPU et dure 15 heures, et qu'aucune rustine rapide n'est envisageable
C'est toujours le compromis à trouver entre budget et risque pour une entreprise ...

[SQLpro]

Intéressant, cela confirme mes modestes expériences et celles que m'ont racontés de nombreux DBA qui ont du migrer...

Puis-je poster ton texte dans le blog, mais un peu différemment ?

Je vais créer deux entrées :
1 retour d'expérience tel quel
Ton paragraphe "autre" spécifiqaue à Oracle

A +

[scheu]

Intéressant, cela confirme mes modestes expériences et celles que m'ont racontés de nombreux DBA qui ont du migrer...

Puis-je poster ton texte dans le blog, mais un peu différemment ?

Je vais créer deux entrées :
1 retour d'expérience tel quel
Ton paragraphe "autre" spécifiqaue à Oracle

A +

No problemo

[MaitrePylos]

ne payons plus de licences et migrons que diable !

Ceci est le nerf de la guerre, encore faut-il que le DBA Oracle, puisse gérer PostgreSQL.

Perso, je trouve que la politique de prix de Oracle n'est pas cohérente, faites venir deux commerciaux différents et vos prix seront différents.

la passion du libre l'emporte souvent contre la raison du technique !

C'est vrai....dans l'enseignement....autour du café.....sur les forums, beaucoup moins en entreprise.

Je ne suis pas contre de payer pour un produit de qualité et qui répond à mes besoins, mes besoins sont mieux rencontrés par PostgreSQL-PostGis que par Oracle-Spatial (le prix n'est pas innocent).

J'ai également vu l'inverse, un déploiement Oracle pour un schéma de quatre tables et 1247 records au total et refus total de migrer vers Oracle Express.

Il convient donc de cantonner PostGreSQL a ce qu'il sait bien faire. C'est à dire comme tout bon outil, lui faire faire ce pourquoi il est fait.

Ceci est la phrase qui faut retenir, quelque soit le SGBDR.

Peux-tu faire le même article avec Firebird ?


MaitrePylos

[SQLpro]

Je ne suis pas contre de payer pour un produit de qualité et qui répond à mes besoins, mes besoins sont mieux rencontrés par PostgreSQL-PostGis que par Oracle-Spatial (le prix n'est pas innocent).

Tu n'as pas essayé SQL Server 2008 ? J'ai publié dans cet article un comparatif des solution GIS de PG et SQL Server. Il sont très comparable à 3 exceptions près :
la fonction MakeValid qui n'existe pas dans PG
les SRID qui ne sont pas gérés sous PG
l'agrégat d'objet spatiaux qui n'existe pas sous SQL Server (faut faire des requêtes récursives.
SQL Server 2012 va intégrer les agrégats spatiaux et les courbes.
Et en plus c'est gratuit le spatial, car intégré dans toutes les éditions, même Express !

Peux-tu faire le même article avec Firebird ?

Hélas non, car cela fait des années que je n'ai plus donné dans IB/FB... Et ce serait plus pitoyable encore...

A +

[estofilo]

Il y a de nombreuses erreurs montrant que tu ne connais que superficiellement le sujet.
C'est un article à charge, rien qu'au sommaire on sait déjà à quoi s'en tenir.
La mauvaise foi déployée est stupéfiante pour arriver à prétendre que "PostGreSQL ne dispose d'aucun mécanisme intégré de réplication des données".

[punkoff]

Il y a de nombreuses erreurs montrant que tu ne connais que superficiellement le sujet.

Pourriez-vous pointer les erreurs, ommissions, ou autre ?

[SQLpro]

Il y a de nombreuses erreurs montrant que tu ne connais que superficiellement le sujet.
C'est un article à charge, rien qu'au sommaire on sait déjà à quoi s'en tenir.
La mauvaise foi déployée est stupéfiante pour arriver à prétendre que "PostGreSQL ne dispose d'aucun mécanisme intégré de réplication des données".

Tu commet la même erreur que beaucoup en confondant réplication de données et réplication de base (ce qui d'ailleurs n'est pas une réplication, mais une duplication, soyons précis ! _lis bien la note en bas...). A part Slony I et Londiste (deux modules à part et basés sur des triggers...) qui permet de faire de la réplication de données, c'est pauvre et peu performant...

D'autre part, soit précis dans tes arguments. Tu dis que c'est farci d'erreur, mais tu ne m'en cite qu'une (la réplication) et encore ce n'est pas une erreur, c'est une incompréhension de ta part. L'honnêteté voudrais que tu me sortes quelques arguments techniques, des affirmations tenus sur des sites crédibles, des exemples de code... Mais sans aucun autre argument que d'affirmer que ce je dis dans cet article est un tissus de mensonges...
Je pensais que tu étais pragmatique et j'ai l'impression de découvrir un partisan aveugle.... dommage.

[cleray.fr]

Postgre est utilisée par meteo france 100 serveurs et 80TB de données

Mais à part ça Postgre est faite seulement pour, je cite, "des petites applications non critiques, à faible volumétrie (quelques dizaines de Go) " !!!!

Je n'avais pasautant rigolé depuis longtemps

Quelques retours d'expérience personnels qui peuvent éventuellement compléter ton article si tu les juges utiles :

Je suis assez d'accord avec toi.
Postgresql a depuis quelques versions de nombreuses fonctionnalités qui se rapprochent des besoins des entreprises (hot standby, sauvegarde à chaud en continu, fonctions analytiques, ...)
Au jour d'aujourd'hui Postgresql peut faire l'affaire pour des petites applications non critiques, à faible volumétrie (quelques dizaines de Go) et à faible complexité (pas de grosses requêtes faisant des jointures sur plus de 5-6 tables)
Mais dès qu'on arrive dans des environnements complexes, volumineux ou critiques, Postgresql montre quand-même ses limites, et ça peut vite devenir critique quand par exemple (c'est du vécu) un problème de mauvais plan d'exécution survient en production, la requête vous mange 100% de CPU et dure 15 heures, et qu'aucune rustine rapide n'est envisageable
C'est toujours le compromis à trouver entre budget et risque pour une entreprise ...

[SQLpro]

Postgre est utilisée par meteo france 100 serveurs et 80TB de données

Mais à part ça Postgre est faite seulement pour, je cite, "des petites applications non critiques, à faible volumétrie (quelques dizaines de Go) " !!!!

Je n'avais pasautant rigolé depuis longtemps

C'est une application totalement atypique et pas du tout relationnelle... Météo France fait-elle des transactions ???
Pour rappel, le but d'un SGBDR est de faire de l'OLTP, c'est à dire OnLine Transaction Processing...

Dans le cas de météo france, dont le site est d'ailleurs en sérieuse perte de vitesse et très lent par rapport à la concurrence (merci PG...) il n'y a pas de mise à jour concurrentielles !

A +