Vous n'êtes pas identifié(e).
Bonjour à tous...
pouvez-vous répondre à ces quelques questions :
1°) Pensez-vous que Postgrès soit plus complexe à installer que Mysql
2°) Vous avez l'air de penser que Postgrès est plus adapté que Mysql pour les gros volumes => Ok... mais pensez-vous à contario qu'il soit moins performant dans le cas de petits volumes (entre 1 et 10 gigas de données)(bien sûr on est dans un monde parfait avec un modèle de donné bien modélisé !)
3°) La compression des tables via TOAST, est-elle compliqué à implémenter
4°) Est-il possible, facilement, de changer de taille de page dans une database ou une table (par exemple de passer de 8K à 32 K)
5°) Etant donné que les le support est assuré par ddes intégrateurs, combien de temps prend la correction d'un bug important
6°) Quels sont les outils payants sur postgrès... et que font-ils de plus ?
7°) Pensez-vous que postgrès sera un jour supporté par TOAD (comme Mysql) ou Embarcadero
8°) Y a t'il un outil pour lire la log ?
Merci pour vos réponses...
Hors ligne
Bonjour,
1) Non, un setup existe sous windows et des paquets sont disponible sous GNU/Linux
2) Difficile à comparer, mySQL gérant plusieurs moteurs de stockages, certains plus rapides que d'autre, un seul gérant les contraintes d'intégrité référentiel par exemple. Je ne connais pas de comparatifs récents comparant les 2, mais comme ils sont gratuit vous pouvez toujours comparer facilement sur une de vos base des requêtes un peu gourmandes.
3) La compression est transparente pour vous.
4) Non, c'est une valeur défnie pour l'ensemble du serveur lors de la compilation.
5) Le développement reste entièrement libre. Si un bug important est découvert, une nouvelle version arrive assez vite, le temps de le corriger et faire des tests pour la non régression et les effets de bords. Vous avez toujours la possibilité de compiler depuis les sources la version avec le bug corrigé pour ne pas attendre ce délai supplémentaire.
6) Personnellement je n'en connais pas beaucoup et n'en ai testé aucun. J'utilise postgresql depuis des années et je n'ai jamais eu de problèmes ne pouvant être résolu sans acheter un outil payant.
7) Aucune idée. Il existe déjà des solutions open source pour gérer postgresql comme pgAdmin. Je ne connais pas assez TOAD pour savoir quelles fonctionnalités intéressantes ils proposent qu'on ne retrouve pas chez postgresql.
8) Il existe des outils pour lire les log et fournir des rapport. Il y a pgFouine et très récemment pgBadger.
Julien.
https://rjuju.github.io/
Hors ligne
Merci pour vos réponses...
3°) Quand vous dites que la compression est transparente, cela veut-il dire que toutes les données sont compressées dans une database... où faut-il, par exemple à la création d'une instance, lui dire par un paramètre quelconque qu'il faut compresser les données..
8°) en fait je me suis mal exprimé au sujet des logs (j'ai implémenté pgfouine et cela fonctionne très bien !)... je voulais parler des WAL ... de pouvoir détricoter les WAl pour en extraire par exemple, les ordres qui ont été passés et par qui (comme log analyzer sur DB2 mainframe) ?
9°) Autre question : j'ai lu un post qui parle de performance sur les grosses volumétries qui ne seraient pas si bonnes que cela quand, par exemple, postgrès traite des requêtes complexes (jointure entre 6-7 tables, auto-jointures, sous-jointures etc...) le confirmez-vous ?
Hors ligne
3) Postgresql compresse tout seul si besoin avec le mécanisme TOAST. Le plus simple est de voir la doc associée : http://docs.postgresqlfr.org/9.1/storage-toast.html
8) C'est un problème assez complexe. Vous pouvez regarder http://pgfoundry.org/projects/xlogviewer/ par exemple, peut-être y a-t-il d'autres outils. Si vous voulez vraiment une analyze fine de ce qui se passe les logs sont tout de même la meilleure alternative.
9) Je n'ai jamais rencontré ce genre de problème personnellement, même en dépassant largement ces contraintes. De quand date ce post, et la requête ainsi que la structure ou la configuration étaient correctes ? De nombreuses personnes ont de très bonnes performances, vous pouvez d'ailleurs voir sur ce site différents témoignages: http://www.postgresql.fr/temoignages:accueil par exemple "le bon coin" ou "le moteur d'orange".
Julien.
https://rjuju.github.io/
Hors ligne
3°) Vous semblez dire qu'il y a deux types de compression ... celle de postgrès et si besoin est, le rajout du mécanisme TOAST (par exemple sur une nouvelle colonne d'une table)... me trompe-je ? et sinon, quel est la différence de compression (en %) entre les deux ... et faut-il seulement effectuer un ALTER sur une colonne pour mettre celle-ci en mode TOAST...
9°) post incriminé : http://www.developpez.com/actu/36925/Po … ouveautes/ du 06/05/2011 (voir la réponse de scheu)
Hors ligne
Et une petire dernière : l'installation et le paramètrage de pgadminIII il compliqué ?
Hors ligne
3) Non, le mécanisme TOAST sert à stocker les lignes faisant plus d'une page (8Ko par défaut), en compressant automatiquement si besoin. Vous n'avez pas à le gérer, cela sera fait de manière transparente.
9) Si ça lui est arrivé j'aurais tendance à le croire. Le planificateur n'est pas parfait, mais il y a toujours moyen de résoudre le problème comme il le dit dans son post (enable_netsloop ...). Si cela doit être fait spécifiquement sur toutes les requêtes ça devient compliqué, mais j'ai du mal à croire que cela concerne la majorité des cas.
PgAdmin est un logiciel très facile à utiliser. Vous n'avez qu'à paramétrer les informations de connexion et suivre l'arborescence des objets.
Julien.
https://rjuju.github.io/
Hors ligne
Non pas facile à 'utiliser' (je l'ai et cela fonctionne bien) mais facile à 'installer' ?
Hors ligne
3) Donc cette compression est implicite quand une ligne fait plus de 8 K ?
Hors ligne
Pour pgAdmin: sous windows, un setup à lancer. Sous linux, un paquet à installer, rien de compliqué.
3) Oui
Julien.
https://rjuju.github.io/
Hors ligne
Merci pour vos réponses...
Hors ligne
en fait je me suis mal exprimé au sujet des logs (j'ai implémenté pgfouine et cela fonctionne très bien !)... je voulais parler des WAL ... de pouvoir détricoter les WAl pour en extraire par exemple, les ordres qui ont été passés et par qui (comme log analyzer sur DB2 mainframe) ?
Très clairement, il est impossible de reconstruire les ordres SQL à partir des WAL. Les WAL ne contiennent que les blocs disques modifiés.
j'ai lu un post qui parle de performance sur les grosses volumétries qui ne seraient pas si bonnes que cela quand, par exemple, postgrès traite des requêtes complexes (jointure entre 6-7 tables, auto-jointures, sous-jointures etc...) le confirmez-vous ?
Tout dépend des cas. Il y a des utilisateurs ayant des bases de plusieurs To sans aucun problème, et d'autres ne pouvant pas utiliser PostgreSQL alors qu'ils ont des bases beaucoup plus réduites.
Guillaume.
Hors ligne
Merci Guillaume pour ces précisions...
Vous citez le cas de personne ne pouvant utiliser postgresq dans le cas de petites basounettes... pourquoi ?
Hors ligne
Parce que le contexte n'est pas le bon. Vous pouvez vouloir une base pour de l'embarqué, ou pour des smartphones. Clairement, PostgreSQL n'est pas la bonne solution à ce genre de contextes car il est plutôt prévu pour fonctionner sur des serveurs.
Mais en fait, ce que je voulais dire, c'est que vous ne pouvez pas savoir si tel ou tel SGBD vous conviendra à moins de le tester.
Guillaume.
Hors ligne
Ok pour ces contextes là... moi je parlais d'un contexte de 'production' dans une entreprise...
J'ai une autre question plus générale : Y a t'il des 'guide' Postgrès ? et si oui, à quelle intervalles se tiennent-ils ? et où ?
Hors ligne
si vous parlez de conférences, il y a les pgdays tous les ans en France et partout dans le monde.
Hors ligne
La prochaine conférence, à ma connaissance, sera le pgconf.eu 2012, qui se tiendra à Prague en octobre.
Guillaume.
Hors ligne
Oui je parlais bien de cela...
Merci encore pour vos réponses...
Hors ligne
