Articles précédents : Logiciel
- [4] VMime 0.8.0
- [36] Nouvelle version de COPOS
- [20] Synfig passe sous licence GPL
- [24] Sortie de la version 0.7.1 de Looking Glass
- [86] Wine débarque bientôt
- [157] OpenOffice 2.0
- [70] MySQL 5.0 est sorti
- [12] Gnumeric 1.6 disponible
- [86] Galeon fusionne avec Epiphany
- [48] Faire entrer les logiciels libres à l'école
Liens connexes
- La traduction de l'annonce officielle (1096 hits)
- Miroirs (267 hits)
- Bittorrent (152 hits)
- Notes de version (239 hits)
Dépêche modérée par
Dépêche éditée par
Logiciel : PostgreSQL 8.1 disponible
Posté par Xavier Poinsard (page perso, ). Modéré le 09 novembre 2005.
Cette version apporte de nouvelles fonctionnalités comme le "commit à deux phases" ou les paramètres IN / OUT pour les fonctions. Elle contient également de nombreuses améliorations concernant les performances : bitmap index, shared row lock, partitionnement de tables.
Il est savoureux de constater que c'est également aujourd'hui que Computer Associates a annoncé la mise en Open Source de sa base de données Ingres.
NdM : merci à François Suter pour avoir également proposé une dépêche à ce sujet.
![[fr]](../../../images/fr.png)
La traduction de l'annonce officielle (1096 hits)![[en]](../../../images/en.png)
Miroirs (267 hits)-
Bittorrent (152 hits)
-
Notes de version (239 hits)
> Lire la suite (71 commentaires, moyenne: 4,1). [dépêche : 4375 caractères]
Rôles : PostgreSQL supporte désormais les « rôles de bases de données », ce qui simplifie la gestion de grands nombres d'utilisateurs avec des droits d'accès complexes.
Paramètres IN/OUT : Les fonctions de PostgreSQL acceptent maintenant les paramètres IN, OUT et INOUT, ce qui améliore sensiblement le support de logiques applicatives complexes pour les plateformes J2EE et .NET.
Commit à deux phases (2PC) : Réclamé depuis longtemps pour les applications WAN et les centres de calcul hétérogènes, ce dispositif permet des transactions ACID entre des serveurs distants.
Amélioration des performances
Amélioration des performances sur les multiprocesseurs (SMP) : le gestionnaire de la version 8.1 a été retravaillé de manière à fournir une augmentation quasi-linéaire des performances par rapport au nombre de processeurs, apportant des gains significatifs d'exécution sur des unités centrales de type 8-way, 16-way, double-coeur et multi-coeur.
Parcours de cartes («Bitmap scan») : les index seront dynamiquement convertis en cartes (bitmaps) en mémoire lorsqu'un cas approprié se présente, soit une exécution jusqu'à vingt fois plus rapide lors d'interrogations d'index complexes sur de très grandes tables. Cela contribue également à simplifier la gestion de la base de données en réduisant considérablement le besoin d'index à colonnes multiples.
Partitionnement des tables : le planificateur de requêtes est maintenant capable d'éviter de parcourir des sections entières d'une grande table en utilisant une technique connue sous le nom d'« exclusion de contraintes ». Semblable à la division des tables, que l'on rencontre dans d'autres systèmes, ce dispositif améliore la vitesse d'exécution et la gestion des données pour des tables de plusieurs gigaoctets.
Verrous de ligne partagés : Le verrou « plus fin que la ligne » utilisé par PostgreSQL autorise des niveaux encore plus élevés de concurrence d'accès grâce à l'ajout du verrou de ligne partagé pour les clefs secondaires. Les verrous partagés améliorent l'insertion et la mise à jour dans beaucoup d'applications avec un gros volume de transactions (« Online Transaction Processing » ou « OLTP »).
Autres fonctionnalités de cette version
Parmi les 120 nouveautés et améliorations non mentionnées par le communiqué de presse (cf. supra), on trouve :
* GiST : Le « Generalised Search Tree (GiST) » de PostgreSQL (mécanisme d'indexation optionnel) a été amélioré pour supporter la concurrence d'accès à haute vitesse et les performances en mise à jour que l'on n'obtient généralement qu'en utilisant des index de type B-Tree. GiST est la base de l'indexation en texte intégral (TSearch2), des systèmes d'information géographiques (GIS) et des requêtes d'analyse d'indexation arborescente de PostgreSQL. Grâce à ce perfectionnement, les requêtes sur les types de données complexes maintiennent de bonnes performances dans les applications à haute disponibilité.
* Réécriture de COPY : La commande COPY a été réécrite pour un traitement jusqu'à 30% plus rapide des données en bloc. En ajoutant à cela les améliorations de charge obtenues avec CSV, ceci rend le chargement de grosses bases de données dans PostgreSQL plus rapide que jamais.
* Mémoire partagée 64-bit : le gestionnaire de tampons peut maintenant utiliser jusqu'à deux téraoctets de RAM sur les plateformes 64-bits, préparant ainsi PostgreSQL pour les serveurs à grande mémoire du futur.
* Autovacuum intégré : le « ramasse-miettes » de base de données de PostgreSQL a été amélioré et intégré dans le programme principal du serveur, ce qui rend les serveurs PostgreSQL plus simples à installer et administrer.
* Accélération des agrégations : les fonctions d'agrégation ont été améliorées afin d'accélérer encore les requêtes d'analyse. Les développeurs ont à la fois réécrit la gestion de la mémoire pour les agrégations et optimisé l'indexation de MIN() et de MAX().
* Fonctions d'administration : de nouvelles fonctions ont été ajoutées pour récupérer des informations concernant le serveur et effectuer des tâches administratives, le tout en ligne de commande PSQL.
* Fonctions de compatibilité : les fonctions lastval(), greatest() et least() ont été ajoutées pour faciliter le portage des applications MySQL et Oracle.
Avantage pour un néophyte ?
Je profite de cette nouvelle version pour poser une question qui me tarabiscote depuis longtemps :
Est-ce que PostGreSQL apporte un gain par rapport aux autres solutions libres comme MySQL pour un débutant, c'est à dire qui ne maitrisera pas les fonctions avancées.
J'ai cru comprendre que sa spécialité était les relations "complexes" entre les tables, mais je ne sais pas trop ce qui est complexe et ce qui ne l'est pas. Est-ce que les relations des tables d'un forum bourré d'options sont "complexes" ?
-
[^]Re: Avantage pour un néophyte ?
Posté par erik_lallemand (page perso, ) le 09/11/2005 à 18:55. (lien). Évalué à 10.Est-ce que PostGreSQL apporte un gain par rapport aux autres solutions libres comme MySQL pour un débutant, c'est à dire qui ne maitrisera pas les fonctions avancées
Non! Clairement, quand on est débutant sur l'un des 2 systèmes, on utilise uniquement des fonctionalités simples, on traite des petits volumes de données, et on gère peu d'utilisateurs simultanément. Par conséquent, on est loin d'atteindre les limites d'un système ou d'un autre, et il est alors évidemment plus simple de continuer à utiliser le système qu'on connait.-
[^]Re: Avantage pour un néophyte ?
Posté par reno () le 09/11/2005 à 19:19. (lien). Évalué à 9.Euh, pas d'accord: il me semble que PostGreSQL est plus "stricte" dans sa gestion des champs que MySQL, ce qui me parait préférable pour détecter des erreurs.
Maintenant je ne suis pas un expert ni dans l'un ni dans l'autre..-
[^]Re: Avantage pour un néophyte ?
Posté par BiBite () le 09/11/2005 à 22:18. (lien). Évalué à 10.Je suis assez d'accord avec reno. Il y'a quelques trucs non standards dans MySQL qui sont parfois très genants, en vrac:
- Tu fais un update du genre:
update table1 set result = 'OK' where val = '10';
avec MySQL, si tu as 10 tuples (lignes) avec result val = '10' et que tu as déjà 3 lignes avec result = 'OK', MySQL te dit qu'il a modifié 10 tuples...
Super chiant dans certaines applis pour vérifier que tu as bien modifié ce que tu voulais. Les autres BDD auraient retourner 10 lignes modifiées.
- Tu fais un update (encore) du genre:
update table1 set date = '2005-12-32';
MySQL accepte sans broncher, alors que la date n'est pas valide (32 décembre).
Idem si on essaye de mettre un chaine de 20 caractère dans un varchar(10), pas de problème... Sauf que du coup la chaîne est tronquée et tu ne t'en rends pas compte.
Bref, au moins avec postgres tu limite ce genre de mauvaise surprises...-
[^]Re: Avantage pour un néophyte ?
Posté par briaeros007 () le 10/11/2005 à 11:37. (lien). Évalué à 6.Les autres BDD auraient retourner 10 lignes modifiées.
Tu voulais sans doute dire 7, non?--
Subete ga wakatta toki…watashi ga anta wo korosu.-
[^]Re: Avantage pour un néophyte ?
Posté par Xavier Poinsard (page perso, ) le 10/11/2005 à 12:52. (lien). Évalué à 6.Les SGBD doivent retourner 10 sauf si la requête est
update table1 set result = 'OK' where val = '10' and not result='OK'
-
-
[^]Re: Avantage pour un néophyte ?
Posté par Pooly (page perso, ) le 10/11/2005 à 12:38. (lien). Évalué à 4.avec MySQL, si tu as 10 tuples (lignes) avec result val = '10' et que tu as déjà 3 lignes avec result = 'OK', MySQL te dit qu'il a modifié 10 tuples...
Super chiant dans certaines applis pour vérifier que tu as bien modifié ce que tu voulais. Les autres BDD auraient retourner 10 lignes modifiées.
En ligne de commande, MySQL va te sortir le nomber de lignes qui correspondent a ta requete, et le nomber de lignes modifiés. Donc tu as les deux informations. Si tu utilise l'API C, il y a une option pour avoir soit le nombre de 'match' ou le nomber de lignes modifiés.-
[^]Re: Avantage pour un néophyte ?
Posté par Xavier Poinsard (page perso, ) le 10/11/2005 à 12:54. (lien). Évalué à 6.Sans doute intéressant, mais non standard.
Ainsi de nombreuses applis développées pour MySql sont difficilement portables vers d'autres SGBD.
-
-
[^]Re: Avantage pour un néophyte ?
Posté par Dring FirebirdVsMySql () le 10/11/2005 à 13:31. (lien). Évalué à 2.
Tu fais un update du genre:
update table1 set result = 'OK' where val = '10';
avec MySQL, si tu as 10 tuples (lignes) avec result val = '10' et que tu as déjà 3 lignes avec result = 'OK', MySQL te dit qu'il a modifié 10 tuples...
Super chiant dans certaines applis pour vérifier que tu as bien modifié ce que tu voulais. Les autres BDD auraient retourner 10 lignes modifiées.
Comme déjà indiqué plus haut, c'est au contraire un comportement standard. Concernant les "autres BDD", je sais que Sybase au moins fait la même chose ; il me semble que Firebird/Interbase aussi.
D'autre part, je ne vois pas trop l'intérêt de vérifier que le nombre de ligne modifiées correspond, sauf dans le cas où il n'y en a qu'une.
Soit ça marche, soit ça échoue ; et c'est normalement tout ce que tu as à savoir.--
Non, rien.
-
[^]Re: Avantage pour un néophyte ?
Posté par erik_lallemand (page perso, ) le 10/11/2005 à 16:00. (lien). Évalué à 4.Je suis assez d'accord avec reno. Il y'a quelques trucs non standards dans MySQL qui sont parfois très genants
La question concernait le besoin (ou non) de passer de MySQL à PostgreSQL pour un débutant. Alors oui, PostgreSQL est plus strict sur les vérifications de dates. On peut aussi trouver à MySQL des bons points qui font défaut à Postgres.
Mais pour un débutant, ces petites différences ne justifient pas de tout remettre à plat, de tout remettre en cause. Déjà, s'il est vraiment débutant, je tire mon chapeau s'il stocke ses données de dates sous un format de données de type "Date/time". Quand j'ai commencé sous MySQL il y a 5 ans, j'aurais sans doute pu le faire, mais j'ai utilisé des chaines de caractères parce que c'était tellement plus simple et suffisant. Rappelez-vous, les gars! dé-bu-tant!-
[^]Re: Avantage pour un néophyte ?
Posté par briaeros007 () le 10/11/2005 à 17:50. (lien). Évalué à 0.ne justifient pas de tout remettre à plat, de tout remettre en cause
Enfin c'est quand meme du sql a la base . C'est pas completement incompatible. Non?--
Subete ga wakatta toki…watashi ga anta wo korosu.
-
-
-
-
-
[^]Re: Avantage pour un néophyte ?
Posté par Xavier Poinsard (page perso, ) le 09/11/2005 à 20:50. (lien). Évalué à 10.Le problème avec MySql c'est sa syntaxe pas très standard, notamment pour la création de tables.
Travailler avec PostgreSql permet d'être ensuite à l'aise avec la plupart des bases de données.
-
[^]Re: Avantage pour un néophyte ?
Posté par Laurent J (page perso, ) le 10/11/2005 à 09:23. (lien). Évalué à 7.avantage pour un néophyte : étant donné que la cohérence des données est garantie grâce à la prise en charge des clés étrangères, cela t'oblige à faire tes requêtes correctement, dans le bon ordre. Bref, ça apporte de la rigueur.
Si ton programme modifie une donnée qui ne doit pas l'être (mettre un id de categorie qui n'existe pas dans un enregistrement de produit par exemple), postgresql va raler car ce n'est pas normal. C'est donc des bugs vite détéctés.
Mysql ne va pas raler et va laisser faire (sauf si tu utilises des tables Innodb, mais ce n'est hélas pas le format par défaut et les développeurs choisissent implicitement MyIsam, qui ne prend donc pas en charge les clés étrangères)-
[^]Re: Avantage pour un néophyte ?
Posté par Pierre Jarillon (page perso, ) le 10/11/2005 à 11:56. (lien). Évalué à 10.Voici un exemple simple : Soit une base de données pour gérer les comptes des client d'une banque. Une table sert à déclarer les comptes (une ligne par client) et l'autre sert à déclarer les mouvements (crédit/débit).
Dans la table clients, chaque compte ne peut exister qu'une fois. Cette contrainte d'intégrité se nomme primary key ou clé primaire.
On ne peut faire des mouvements que sur des comptes existants. Donc dans la table des mouvements, on va déclarer que le numéro de compte doit exister dans la table des clients; on la nomme foreign key ou clé étrangère.
L'énorme intérêt d'une base de données avec des contraintes d'intégrité fortes, c'est que l'on peut modifier les données avec tous les outils que l'on veut sans risquer de perdre leur cohérence, même sur un bug de programmation.
L'intérêt des fonctions et des triggers est le même : on déclare que lorsqu'on insère/modifie/supprime quelque chose dans la base de données, on exécutera la fonction qui vérifiera/modifiera/archivera/etc les données. Par exemple, si je gère du matériel, le moteur A est dans le stock, casier X. Je le confie au labo d'essais.
Dans la base de données il y a le lien (moteurA)-(stockX) Je modifie avec (moteurA)-(labo essai). Le trigger va alors appeler une fonction qui va stocker dans une table historique que :
- (moteurA) est enlevé de (stockX) par Mr Machin à telle date.
- (moteurA) est associé à (labo essai) par Mr Machin à telle date.
- (stockX) a un (moteurA) de moins certifié par Mr Machin à telle date.
- (labo essai) possède (moteurA) certifié par Mr Machin à telle date.
Je peux vous assurer que lorsque l'on a des milliers d'éléments dans une base de données, un défaut d'intégrité tel que (moteurA) n'est pas à l'endroit indiqué, est bien plus difficile à corriger qu'un bug dans un programme.
J'espère que ces lignes permettront à ceux qui ne sont pas familiarisés avec les contraintes d'intégrité de mieux en percevoir l'intérêt.
-
-
[^]Re: Avantage pour un néophyte ?
Posté par Laurent PELLISSIER () le 12/11/2005 à 19:17. (lien). Évalué à 4.Certes pour un néophyte les 2 produits se valent mais tout dépend si on compte rester débutant ou évoluer au fûr et à mesure que les applications que l'on envisage d'écrire vont se complexifier.
Dans la mesure où les 2 produits ont une durée d'aprentissage équivalente mieux vaut dès le départ choisir celui qui aura le maximum d'évolutivité. Dans ce cas PostgreSQL a montré depuis des années sa plus grande richesse fonctionnelle. Le choix me semble vite fait.
Ingres : trop tard ?
Postgresql est maintenant le compétiteur d'Oracle. Il ne reste que très peu de niches où Oracle soit encore irremplaçable. Ingres qui n'a pas su lutter avec Oracle vient maintenant sur le terrain de Postgresql.
Ouvrir son code est une bonne stratégie à deux conditions ; que la licence soit libre (selon les 4 libertés de la FSF) et que ce soit fait à temps. On peut craindre qu'il ne soit déjà trop tard.
-
[^]Re: Ingres : trop tard ?
Posté par snt () le 09/11/2005 à 20:49. (lien). Évalué à 10.D'ailleurs sur le marché des SGBD, ca bouge pas mal chez les gros SGBD propriétaires puisqu'apres le SQL Server Express de Microsoft ( ex MSDE ) qui est une version bridée mais gratuite de SQL Server, Oracle vient de répliquer en fournissant lui aussi une version light et gratos de son SGBD version 10.
( c'est quand meme un comble : on en arrive à avoir plus de SGBD gratuits et/ou libres que de navigateurs ou de suite bureautique )
-
[^]Re: Ingres : trop tard ?
Posté par lezardbreton (Jabber id, page perso, ) le 09/11/2005 à 21:14. (lien). Évalué à 4.Par rapport à Sybase, ou à Teradata, les différences sont énormes ou pas ?
-
[^]Re: Ingres : trop tard ?
Posté par Xavier Poinsard (page perso, ) le 10/11/2005 à 08:33. (lien). Évalué à 2.Teradata est une base particulière dédiée au data warehouse.
-
-
[^]Re: Ingres : trop tard ?
Posté par Franck Routier () le 17/11/2005 à 10:43. (lien). Évalué à 1.Ce qui est amusant, c'est qu'à l'origine, Ingres et Postgresql ont des origines communes.
cf http://www.postgresql.org/about/history
Ce sont des cousins, comme Sybase et MS Sql*server le sont...
Preuve de la supériorité du modèle économique du libre ? :-)
Il ne lui manque plus que le cluster...
En effet PostGreSQL est certainement l'Alternative à Oracle, Il est cependant regrettable qu'il n'existe que très peu de solutions de clustering fiable pour PostGreSQL (PgPool, Slony). D'autant plus qu'Oracle à vraiment frappé fort avec la version 10g et son RAC (real application Cluster), qui permet du vrai LoadBalancing / Fail Over sur une base de donnée. C'est dommage parce que le clustering et la scalabilité est LA condition pour qu'un SGBD puisse se frayer une place dans l'entreprise...
Félicitation tout de même pour les développeurs de PostGreSQL, ce produit est vraiment très prometteur!
-
[^]Re: Il ne lui manque plus que le cluster...
Posté par Stéphane TRAUMAT (page perso, ) le 09/11/2005 à 19:57. (lien). Évalué à 5.Si vous faites des applications Java... regardez C-JDBC (http://c-jdbc.objectweb.org/), ca permet de faire du cluster de bases de données sans modifier ni l'appli, ni la base de données. On peut meme faire un cluster composé de serveur de bases de données différents !
-
[^]Re: Il ne lui manque plus que le cluster...
Posté par ArBaDaCarBa () le 09/11/2005 à 20:04. (lien). Évalué à 2.Petit problème de lien, -> http://c-jdbc.objectweb.org/
-
-
[^]Re: Il ne lui manque plus que le cluster...
Posté par Philippe Poumaroux () le 09/11/2005 à 20:13. (lien). Évalué à 3.il y en a: de mémoire erserver et pgcluster plus un autre dont le nom m'échappe ...
http://pgfoundry.org/softwaremap/trove_list.php?form_cat=392-
[^]Re: Il ne lui manque plus que le cluster...
Posté par Hubert FONGARNAND () le 10/11/2005 à 08:15. (lien). Évalué à 2.erserver est deprecated :
http://gborg.postgresql.org/project/erserver/projdisplay.php
" is deprecated: the project has been mostly abandoned by the developers in favour of Slony-I. Go to the Slony-I web page for more info."
Slony-I ne permet pas le load balancing.
Par contre le projet pgcluster à l'air interessant, quelqu'un l'aurait-il déjà utilisé en environnement de prod?-
[^]Re: Il ne lui manque plus que le cluster...
Posté par Jean-Max Reymond (Jabber id, page perso, ) le 10/11/2005 à 09:36. (lien). Évalué à 3.basé sur une très vieille version de PostgresQL: la 7.3.10 qui loupe pas mal d'optimisations de perfs.
Alors, avant d'utiliser des 7.3.10 en cluster et en production, vaut mieux aller faire un tour sur pgpool et Slony1 qui permettent la réplication et la répartition de charge ;-)--
CKR Solutions Open Source-
[^]Re: Il ne lui manque plus que le cluster...
Posté par Philippe Poumaroux () le 11/11/2005 à 12:13. (lien). Évalué à 4.pgcluster version 1.3 s'appuie sur Postgres 8.0 ...
http://pgcluster.projects.postgresql.org/
-
-
[^]Re: Il ne lui manque plus que le cluster...
Posté par bastouille () le 12/11/2005 à 16:50. (lien). Évalué à 3.J'ai déjà testé pgcluster, et malheureusement il y a de gros bugs (impossible à utiliser en production donc) : plantage d'un noeud rendant l'ensemble du cluster instable; arrêt d'un noeud volontaire, mais les autres noeuds n'en tiennent pas compte, ...
Par contre, pour avoir testé c-jdbc au mois de février, je pense que ce projet doit maintenant être suffisament avancé pour bien fonctionner (à l'époque, il y avait encore quelques bugs génant : reprise après incident très délicate, octopus très buggué).
Enfin, j'utilise Slony-1 en production depuis maintenant 4 mois : RAS.
Sa seule limitation est la non réplication des blobs.
Couplé avec IPVS, on a un système de fail-over automatique, mais c'est vrai pas de répartition de charge comme avec c-jdbc.-
[^]Re: Il ne lui manque plus que le cluster...
Posté par Hubert FONGARNAND () le 15/11/2005 à 16:25. (lien). Évalué à 1.Quelle version de pgcluster a tu testé... C'est dommage car le projet paraissait vraiment bien!
-
[^]Re: Il ne lui manque plus que le cluster...
Posté par bastouille () le 19/11/2005 à 20:41. (lien). Évalué à 1.C'est la version 1.3 pour le support postgresql 8.0.
-
-
-
-
Comparatif de performances
Bon, je crois qu'avec la sortie officiel de MySQL 5.0 et celle de PostgreSQL 8.1, il est temps de mettre à jour les comparatifs.
Aujourd'hui. En tant que base de données Web, quelle est la plus performante ?
-
[^]Re: Comparatif de performances
Posté par √λιi () le 09/11/2005 à 20:33. (lien). Évalué à 10.En tant que base de données Web, quelle est la plus performante ?
Déjà ca part mal : ca fait plutôt restrictif comme usage, même si c'est la plus répendue, l'utilisation pour le web est limitée.
En fait MySQL et PostgreSQL ont des orientations tellement différentes que ca ne sert a rien de les comparer pour savoir laquelle est la "meilleure".
Mais globalement :
- PostgreSQL est orienté contrainte, procédure stockées et respect de paradygmes de SGBD.
- MySQL est plutôt orienté performances brutes, légerté quitte a un peu rustique (exemple rapide : gestion des clés étrangères), et je ne sais pas si cela a changé dans la version 5, mais les requètes imbriquées n'ont pas été supportée pendant longtemps - alors que c'est élémentaire en l'algère relationnel.-
[+] [^]Re: Comparatif de performances
Posté par Christophe Merlet (page perso, ) le 09/11/2005 à 22:25. (lien). Évalué à -10.Tout cela ne répond pas à la question.
Ton "globalement" n'est qu'un étalage de lieu communs répété depuis plus de 6/7 ans.
On est fin 2005, MySQL et PostgreSQL ont beaucoup évolué. Il est temps de faire table rase des idées reçus et repartir sur des faits avérés. Parler de "paradygmes" et de "fonctionnalités" ne me dit toujours pas lequel est le plus performant pour une application web !-
[^]Re: Comparatif de performances
Posté par crusher () le 10/11/2005 à 00:00. (lien). Évalué à 5.> lequel est le plus performant pour une application web !
Celui que tu auras testé avec ton application web et ton matériel !
Ta question est en fait trop simpliste, il faut tu sois plus précis.
Si réellement ton seul critère est la performance, tu achètes un max de RAM et tu charges toute la base en mémoire et là tu auras des performances excellentes mais sans sauvegarde ...-
[^]Re: Comparatif de performances
-
[+] [^]Re: Comparatif de performances
Posté par billy (page perso, ) le 10/11/2005 à 20:47. (lien). Évalué à -4.> i réellement ton seul critère est la performance, tu achètes un max de RAM et tu charges toute la base en mémoire et là tu auras des performances excellentes mais sans sauvegarde ...
c'est archi faux ca, même avec toute la base de donnée en RAM postgre est incroyablement plus que MySQL/INNODB. c'est un fait.-
[^]Re: Comparatif de performances
Posté par briaeros007 () le 10/11/2005 à 21:39. (lien). Évalué à 0.plus faux je presume.
C'est un fait qui viens d'ou sans indiscretion?--
Subete ga wakatta toki…watashi ga anta wo korosu.-
[^]Re: Comparatif de performances
Posté par briaeros007 () le 10/11/2005 à 21:43. (lien). Évalué à 0.s/faux/lent
(la fatigue...)--
Subete ga wakatta toki…watashi ga anta wo korosu.
-
-
-
-
-
-
[^]Re: Comparatif de performances
Posté par animal_omega () le 09/11/2005 à 20:36. (lien). Évalué à 10.La question n'est pas assez précise pour avoir un réponse.
Pour commencer, "base de donnée web" n'a pas de sens.
BDD c'est un moyen de stocker les données
le Web c'est un protocole de communication.
donc on peut imaginer n'importe quel application, de la plus simple a la plus complexe, qui utilise une BDD pour stocker ces données et le Web pour communiquer.
Donc j'imagine que la question est du style "quelle est la base de donnée la plus performante pour les portails/forum/blog/..."
(ok, je pinaille)
Mais la encore, je serais incapable de repondre. Prennons le cas d'un forum, ben moi je repondrais "ca depend comment c'est codé".
Y'a moyen de coder un forum en utilisant des triggers, des transactions et tout pleins de trucs sympathiques pour quelqu'un qui tiens a garder une certaine intégrité dans ces données, meme en cas d'un bug dans l'application ou d'une interruption brutale du systeme.
Mais il y a aussi moyen de coder un forum sans tout ca, juste avec quelques tables avec des relations basiques.
bref... je crains qu'il va falloir etre plus precis pour avoir une réponse.
Le mieux est de prendre l'appli et de faire des benchmark :)-
[+] [^]Re: Comparatif de performances
Posté par Christophe Merlet (page perso, ) le 09/11/2005 à 22:35. (lien). Évalué à -10.Tu sembles avoir compris la question, pourtant la réponse est a coté de la plaque en parlant du codage des applis.
C'est comme si on te demandait quelle est la voiture la plus rapide entre une clio et une c3 et que tu répondes qu'il y en a une qui est rouge et l'autre qui a une boite à gants ! Merci d'avoir joué-
[^]Re: Comparatif de performances
Posté par Toufou (page perso, ) le 09/11/2005 à 23:40. (lien). Évalué à 10.D'un autre coté tu demandes ce qui est plus rapide entre une Mc Laren F1 et un hummer et il te répond "ça dépend du terrain sur lequel tu utilises la voiture".
Parler de performance sans donner d'informations sur le contexte n'a pas de sens. Base de données web n'est pas un critère ayant un impact sur la performance (en admettant que performance veuille dire rapidité). Ce qui va surtout jouer c'est le nombre de tables, les relations entre ces tables et la complexité des manipulations de données.-
[+] [^]Re: Comparatif de performances
Posté par Christophe Merlet (page perso, ) le 10/11/2005 à 08:49. (lien). Évalué à -9.Bon, ben vu comme ça brasse du vent quand on demande si postgresql est plus rapide que mysql ou non. J'en conclue que le communiqué de presse est quelque peu optimiste et je vais rester sous MySQL.
Ya pa de raisons de passer du temps à migrer sous PostgreSQL vu que ses avantages ne sont pas évidents !-
[^]Re: Comparatif de performances
Posté par Pierre Tramonson () le 10/11/2005 à 09:34. (lien). Évalué à 10.Je te conseille Access, ça marche très bien, mes utilisateurs en sont très contents.
-
[^]Re: Comparatif de performances
Posté par erik_lallemand (page perso, ) le 10/11/2005 à 23:10. (lien). Évalué à 10.Bon, ben vu comme ça brasse du vent quand on demande si postgresql est plus rapide que mysql ou non (...) Ya pa de raisons de passer du temps à (...)
Vu comme tu es poli avec ceux qui font des efforts pour te répondre (même si tu n'es pas satisfait des réponses, tu pourrais réorienter, ou fournir un complément d'informations sur ce que tu souhaites savoir), garde ta config actuelle et consacre ce temps supplémentaire à apprendre le respect! Ca sera plus déterminant pour ton avenir que les subtilités entre 2 SGBD.
-
-
-
[^]Re: Comparatif de performances
Posté par Brice Arnould ( un_brice ) (page perso, ) le 09/11/2005 à 23:41. (lien). Évalué à 10.En gros, ce qu'il veut te dire, c'est que tu ne fournis pas les informations qui lui permetraient de prendre des décisions.
Moi par contre ça m'a pas arrêté : je l'ai joué à pile ou face. J'ai fait pile, tu devrais utiliser MySQL.--
Respect à RMS.
-
-
[^]Re: Comparatif de performances
Posté par pshunter () le 10/11/2005 à 11:30. (lien). Évalué à 4.Entièrement d'accord. En fait la question c'est de savoir si tu veux coder la logique de ton appli dans la base (triggers, PL, etc...) ou non (PHP, java ou autre).
-
[^]Re: Comparatif de performances
Posté par Xavier Poinsard (page perso, ) le 10/11/2005 à 13:00. (lien). Évalué à 4.Coder la logique dans la BDD avec des triggers et des procédures stockées, et avoir certaines garanties d'intégrité avec les transactions et les clés étrangéres/primaires sont deux choses différentes.
Utiliser trigger et procédures stockées diminue fortement la portabilité de l'application, tandis que les transactions et les clés étrangères/primaires sont standardisées (sauf pour la création des contraintes) et donc portables.-
[^]Re: Comparatif de performances
Posté par pshunter () le 12/11/2005 à 02:37. (lien). Évalué à 4.Tu as raison sur le point de la portabilité. Mais ce n'est qu'un aspect technique et son importance peut varier selon les projets.
En revanche je serais moins catégorique sur la notion d'intégrité. On peut parler d'intégrité au-delà de ce que le modèle relationnel peut exprimer, et dans ce cas une partie de la «logique» participe aux contraintes d'intégrité que le standard ne peut exprimer...
Pour en avoir fait l'expérience, il est parfois difficile de tracer la ligne entre ce qui sera fait par la base et ce qui sera fait par l'applicatif sans tomber dans des extrémismes (rabaisser la BDD à un système de fichiers glorifié ou rabaisser l'applicatif à un visionneur/éditeur de la base).
Dans tous les cas, s'il y a une des extrêmes à choisir je prendrais plutôt la deuxième, je trouve ça plus «économique» en quantité de travail ;)-
[^]Re: Comparatif de performances
Posté par Stéphane TRAUMAT (page perso, ) le 12/11/2005 à 10:15. (lien). Évalué à 3.Je ne vois pas le problème à considerer la base comme un système de fichier hyper performant.... ce n'est pas de l'extremisme, c'est juste considrer que le travail de la base de données est de stocker les données.
Et je ne vois pas en quoi il est difficile de tracer cette ligne. Nos applis n'ont pas de problèmes, on les développe et des outils se débrouillent pour tout stocker.-
[^]Re: Comparatif de performances
Posté par Hardy Damien (page perso, ) le 12/11/2005 à 11:33. (lien). Évalué à 4.Non, le travail d'une base de donnée c'est de stockée des données cohérantes qui ont des relations entre elles ...
Dam-
[^]Re: Comparatif de performances
Posté par briaeros007 () le 12/11/2005 à 14:06. (lien). Évalué à 2.s/base de donnée/base de donnée relationnelle/
--
Subete ga wakatta toki…watashi ga anta wo korosu.
-
[+] [^]Re: Comparatif de performances
Posté par Stéphane TRAUMAT (page perso, ) le 12/11/2005 à 14:17. (lien). Évalué à -1.J'ai pas dit le contraire. mais c'est l'application qui y met les données.. et peu importe la base.
-
-
-
-
[^]Re: Comparatif de performances
Posté par canarlake (page perso, ) le 13/11/2005 à 11:08. (lien). Évalué à 1.Pour ce qui est de la portabilité, il faut envisager plusieurs aspects :
1 portabilité de la base de données:
1.1 portabilité entre différents moteurs de bases :
La, c'est clair que les triggers et procédures stockées diminuent la portabilité
1.2 portabilité entre différents OS :
Pas trop de pb pour ce qui est de Mysql et Postgresql
2 portabilité des clients :
L'intégration de procédures au moteur de base allège la tâche des clients, ce qui facilite la conception de clients pour divers environnements. C'est une forme de portabilité.
Daniel-
[^]Re: Comparatif de performances
Posté par Stéphane TRAUMAT (page perso, ) le 13/11/2005 à 12:27. (lien). Évalué à 1.L'intégration de procédures au moteur de base allège la tâche des clients, ce qui facilite la conception de clients pour divers environnements. C'est une forme de portabilité.
mm dans ce cas la, mieux vaut utliser un serveur d'applications, ca permet de garder la portabilité.
-
-
-
-
Un manque dans l'offre
Aujourd'hui on a trois type de base donnée dans le libre:
- PostgreSql, la solution complète
- MySql, la solution optimisant la rapidité
- SqlLite, la solution poids plume
Ceci est une bonne chose, car se sont des besoins différents.
Par contre, il y a un gros manque. Une base de donnée optimisé en lecture seule. C'est à dire que la mise à jour n'est pas implémenté. Les base de données tels que PostgreSql/MySql sont optimisé pour des accès concurrents en écriture ou en mise à jour. Cas typique des applications commerciales. Or ceci a un coût en complexité et en rapidité. Or des données mesurées sont par définition fixe. On pourrait donc obtenir un gain important avec une base de données optimisé pour la lecture seule. Malheureusement, personne ne semble intéressé par ce cas.
-
[^]Re: Un manque dans l'offre
Posté par Olivier Jeannet () le 09/11/2005 à 22:31. (lien). Évalué à 8.Les base de données tels que PostgreSql/MySql sont optimisé pour des accès concurrents en écriture ou en mise à jour.
Je pense que tu te trompes, car une des faiblesses de MySQL depuis toujours a été son écroulement lors d'accès concurrents en écriture, contrairement à (par exemple) PostgreSQL; ceci en particulier pour les tables au format "historique", à savoir MyISAM (je crois que pour InnoDB, qui permet du transactionnel, c'est différent).
On pourrait donc obtenir un gain important avec une base de données optimisé pour la lecture seule.
Dans MySQL, une table de type MyISAM (relativement basique) est réputée être très rapide en lecture. Ce format convient bien si on met peu à jour la table.
-
[^]Re: Un manque dans l'offre
Posté par Xavier Teyssier (Jabber id, page perso, ) le 09/11/2005 à 23:01. (lien). Évalué à 9.Une base de donnée optimisé en lecture seule.
Ça s'appelle un annuaire, et le protocole LDAP est là pour ça : gèrer des annuaires, c'est à dire des données dont le stockage est optimisé pour la lecture.
A noter que LDAP n'est pas vraiment un annuaire en soi, mais juste un protocole permettant de gèrer des annuaires. Après, les données peuvent être stockées dans n'importe quelle base (typiquement, OpenLDAP peut utiliser BerckeleyDB, PostgreSQL, et surement d'autre.).-
[^]Re: Un manque dans l'offre
-
[^]Re: Un manque dans l'offre
Posté par Mr F (page perso, ) le 10/11/2005 à 09:24. (lien). Évalué à 3.L'avantage de LDAP est surtout d'utiliser une hirarchisation des données, contrairement à une base de donnée ou c'est plus "a plat". Système différent, utilisation différente !
-
[^]Re: Un manque dans l'offre
Posté par Guillaume Knispel () le 11/11/2005 à 19:59. (lien). Évalué à 3.Donc un arbre est plus "puissant" qu'un graphe ? (le mot relationel, toussa ;)
Je croyais que c'étais l'inverse ?-
[^]Re: Un manque dans l'offre
Posté par ham () le 12/11/2005 à 00:29. (lien). Évalué à 3."puissant" ca veut rien dire.
Pour la recherche sur des donnée organisé de maniere hiearachique il y a des fortes chances que une structure d'arbre soit plus puissante dans ce cas.
Si tu veut modeliser des relations complexe entre objet, la la base de donnée peut etre plus a l'aise.
Ensuite qu'est ce qui est plus puissant, un graphe orienté ou un hypergraphe, les chenilles (sisi )??-
[^]Re: Un manque dans l'offre
Posté par Guillaume Knispel () le 12/11/2005 à 14:34. (lien). Évalué à 1.C'est bien parce que "puissant" ne veut rien dire que je l'avais mis entre guillemets :)
Mais c'était juste une réaction pour dire que les DB n'était pas forcement "à plat", et que d'ailleurs un de leur aspects faisait des arbres un sous ensemble.
-
-
-
-
-
[^]Re: Un manque dans l'offre
Posté par Mat () le 10/11/2005 à 17:54. (lien). Évalué à 5.Sqlite peut de par son poids plume faire l'affaire dans certains cas.
J'ai déjà rencontré le problématique que tu évoques. J'avais à travailler avec une base de données qui donnait des relations entre des mots. (synonymie, antonymie, ....) donc jamais mise à jour.
J'y faisais d'intenses requêtes dessus. Là où sqlite s'est avéré décisif dans mon choix c'est que la base de données (le fichier .sqlite) pesait environ 800Mos, ce qui faisait quelques milliers de relations sur un lexique de 300 000 mots. (j'ai utilisé sqlite2 et non sqlite3 car les fichiers sont moins volumineux avec le 2 qu'avec le 3 et les nombreux indexes ajoutés lors du passage à la version 3 n'amélioraient pas vraiment les perfs)
Donc hop, en chargeant toute la base en RAM, les temps de réponse étaient devenus bien meilleurs que lors de mes tests sur MySql ou Postgres.
Ca implique cependant d'avoir moult RAM ou bien une machine dédiée à cet usage. Et puis, avec sqlite de base, il n'y a pas de serveur...
-
[^]Re: Un manque dans l'offre
Posté par Christophe Garault (page perso, ) le 11/11/2005 à 11:50. (lien). Évalué à 10.> Par contre, il y a un gros manque. Une base de donnée optimisé en lecture seule.
Le standard SQL 92 a définit une norme sur les niveaux d'isolation des transactions (source: Second Informal Review Draft ISO/IEC 9075:1992, Database Language SQL- July 30, 1992). Document très coûteux mais certainement dispo quelque part...
Il existe trois phénomènes qui peuvent apparaître durant une lecture des données dans la base: les Dirty read, les Non-repeatable read et enfin les Phantoms. Selon le niveau d'isolation choisi pour la transaction, il se peut que l'un ou plusieurs (voire aucun pour serializable) de ces phénomènes apparaisse (C.f. tableau page 69 pour ceux qui ont le document normatif).
Tout SGBD voulant être conforme avec cette norme se doit donc d'implémenter les 4 niveaux d'isolation suivants:
- READ UNCOMMITTED
- READ COMMITTED
- REPEATABLE READ
- SERIALIZABLE
Mettre en place une solution style Datawarehouse (lecture seule) avec PostgreSQL est très simple: il suffit d'éditer le fichier postgresql.conf et d'y placer les paramètres suivant:
default_transaction_isolation = 'READ UNCOMMITTED'
default_transaction_read_only = yes
Dans la mesure où les transactions ne poserons pas de verrou exclusif sur les ressources, la lecture sera extrèmement rapide si les index sont correctement définis. On peut également penser qu'une telle base de données serait parfaitement adaptée à une pile de disques en RAID 0. Avec de bons disques et une carte Raid munie d'une bonne quantité de RAM, on devrait obtenir des perfs à faire pâlir mySQL en isam.
Conclusion: tous les bons SGBDR savent remplir ce rôle. J'ajoute qu'avant qu'une base puisse être en lecture seule il faut quand même l'avoir alimentée avec des données...
ps: pour ceux qui aiment les chiffres bruts qui ne veulent rien dire (suivez mon regard qui remonte dans les commentaires), j'ai chargé hier une table de 150 millions de lignes à la vitesse de 48000 lignes/sec.-
[^]Re: Un manque dans l'offre
Posté par Franck Routier () le 17/11/2005 à 10:55. (lien). Évalué à 1.Ce qui manque qund même un peu à Postgresql, c'est un type d'index bitmap pour le datawarehousing.
Attention, ne pas confondre un index bitmap à la nouveauté de la 8.1, qui est (si j'ai bien compris) de construire et garder une image bitmap de l'index en mémoire pour les interrogations ultérieures (une sorte de cache).
Les index bitmap sont des index très compacts, donc très vite lus, mais très long à mettre à jour. Ils sont donc particulièrement adaptés aux datawarehouses...
Dans Postgresql, ils existe des tentatives d'implémentation ou des prototypes, mais rien de de vraiment intégré au standard...
cf http://www.sai.msu.su/~megera/postgres/gist/
Dommage.
-
-
[^]Les vues
Posté par Sytoka Modon (page perso, ) le 13/11/2005 à 16:03. (lien). Évalué à 2.> Par contre, il y a un gros manque. Une base de donnée optimisé en
> lecture seule. C'est à dire que la mise
A mes souvenirs, une vue est en lecture seule (je ne suis pas spécialiste des bases de données). Donc, normalement, il suffit de créer une vue pour avoir un accés en lecture seule donc optimisé (mais ca, c'est la boulot de la base de donnée).
D'ailleurs, un client qui n'a pas besoin d'écrire devrait toujours utiliser des vues, rien que par principe de précausion.-
[^]Re: Les vues
Posté par Xavier Poinsard (page perso, ) le 14/11/2005 à 09:01. (lien). Évalué à 1.Une vue n'est pas forcément en lecture seule. C'est juste une facilité : on utilise le résultat d'une requête comme une table "normale".
Il est toutefois vrai que la mise à jour d'une vue implique que les clés primaires des tables modifiées soient présentes dans la vue.
-
table héritée
y'a un truc bien sympa sur PostGres ce sont les tables héritées, c'est comme en objet, tu as une table "individu", tu as deux tables qui en hérites "homme" et "femme" et dans la table "femme" tu mets "nom marital".
Quand tu créer une ligne dans "femme", ça créer en même temps une ligne dans "individu"...
Bon, c'est juste pour expliquer en vitesse ce que c'est, mais je peux vous assurer que c'est vachement pratique. En ce moment, je travaille pour un projet qui utilise PostGres et nous avons toutes nos tables qui hérites d'une même table (parfois avec des tables intermédiaires). Et nous avons ainsi tout nos clefs primaires qui sont uniques (pas uniquement au sein d'une même table)
L'inconvénient c'est que la gestion des clefs étrangeres ne se fait pas très bien, on devrait pouvoir faire une table adresse qui aurait un champ qui pointe vers individu (ou "homme",ou "femme"), mais ça gere strictement les clefs alors qu'en programmation objet, si un objet possede une instance d'individu, il peut de la même façon posseder une instance d'homme ou une instance de femme.
Axel
-
[^]Re: table héritée
Posté par Laurent J (page perso, ) le 10/11/2005 à 10:46. (lien). Évalué à 5.alors qu'en programmation objet, si un objet possede une instance d'individu, il peut de la même façon posseder une instance d'homme ou une instance de femme.
C'est ce qu'on appelle en objet le polymorphisme ;-)
-
[^]Re: table héritée
Posté par nouguier () le 10/11/2005 à 15:24. (lien). Évalué à 3.http://www.postgresql.org/docs/8.1/static/tutorial-inheritance.html
L'exemple est peut etre plus parlant, noter le "FROM ONLY"-
[^]Re: table héritée
Posté par Axel R. (page perso, ) le 21/11/2005 à 16:10. (lien). Évalué à 1.le probleme est la note en bas de la page :
Note: Although inheritance is frequently useful, it has not been integrated with unique constraints or foreign keys, which limits its usefulness. See Section 5.8 for more detail.
et je confirme que c'est un truc super, et que ce serait aussi très bien si les clés étrangeres géraient ce truc :-)
Axel
-
Cette page a été générée par Templeet en 0.2473s (dont 0.0414 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.