PostgreSQL 8.1 disponible

Posté par  . Modéré par Amaury.
Étiquettes :
0
9
nov.
2005
Base de données
La nouvelle version du plus complet des SGBD libres est disponible.
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. Nouvelles fonctionnalités avancées

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.

Aller plus loin

  • # Avantage pour un néophyte ?

    Posté par  . Évalué à 7.

    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  . É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  . É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  . É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  . Évalué à 6.

            Les autres BDD auraient retourner 10 lignes modifiées.
            Tu voulais sans doute dire 7, non?
          • [^] # Re: Avantage pour un néophyte ?

            Posté par  (site web personnel) . É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  . É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  . É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.
          • [^] # Re: Avantage pour un néophyte ?

            Posté par  . É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  . É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?
    • [^] # Re: Avantage pour un néophyte ?

      Posté par  . É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  (site web personnel, Mastodon) . É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  (site web personnel) . É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  . É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 ?

    Posté par  (site web personnel) . Évalué à 10.

    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  . É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  . Évalué à 4.

      Par rapport à Sybase, ou à Teradata, les différences sont énormes ou pas ?
    • [^] # Re: Ingres : trop tard ?

      Posté par  (Mastodon) . É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...

    Posté par  . Évalué à 10.

    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!
  • # Comparatif de performances

    Posté par  (site web personnel) . Évalué à 0.

    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  . É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  (site web personnel) . É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  . É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

            Posté par  . Évalué à 1.

            Aucun rapport mais la RAM c'est tellement lent que les apps pus grande que le L1 sont pourries ;)
          • [^] # Re: Comparatif de performances

            Posté par  . É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  . É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  (site web personnel) . É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  (site web personnel) . É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  (site web personnel) . É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  . Évalué à 10.

              Je te conseille Access, ça marche très bien, mes utilisateurs en sont très contents.
            • [^] # Re: Comparatif de performances

              Posté par  . É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  (site web personnel) . É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.
      • [^] # Re: Comparatif de performances

        Posté par  . É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  . É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  . É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  (site web personnel) . É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.

              http://about.me/straumat

          • [^] # Re: Comparatif de performances

            Posté par  . É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  (site web personnel) . É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é.

              http://about.me/straumat

  • # Un manque dans l'offre

    Posté par  . Évalué à 7.

    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  . É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  (site web personnel) . É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

        Posté par  . Évalué à 4.

        Un annuaire cela n'a rien à voir! Surtout LDAP!

        Je parle de données en général. Par exemple, une base de donnée contenant la morphologie d'une population.
      • [^] # Re: Un manque dans l'offre

        Posté par  . É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  . É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  . É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  . É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  (site web personnel) . É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  (site web personnel) . É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  (Mastodon) . É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  (site web personnel) . É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  . É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

    Posté par  (site web personnel) . Évalué à 9.

    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  (site web personnel, Mastodon) . É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  . É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  (site web personnel) . É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

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.