Sun Microsystems fait l'acquisition de MySQL

Posté par  (site web personnel) . Modéré par j.
Étiquettes :
0
16
jan.
2008
Base de données
Aujourd'hui, la société Sun Microsystems a annoncé le rachat de la société MySQL AB pour la somme d'un milliard de dollars. MySQL est une société suédoise créée en 1995 qui développe le logiciel de base de données MySQL et compte aujourd'hui 360 employés. Son modèle économique est similaire à celui de la société Trolltech pour la bibliothèque Qt : distribuer librement un produit sous licence GPL, et le commercialiser à ceux qui souhaitent l'utiliser comme base pour des produits propriétaires.

Jonathan Schwartz, CEO de Sun depuis 2006, et à l'origine de plusieurs mouvements de l'entreprise vers le Libre, explique ainsi sur son blog : we're putting a billion dollars behind the M in LAMP. Dans un long billet intitulé Apprendre aux dauphins à voler, en référence au logo de MySQL, il explique les raisons qui ont poussé Sun à faire l'acquisition de la société MySQL AB. Du coté de MySQL, Kaj Arnö, vice-président en charge de la communauté, explique ce que cette acquisition va signifier pour les utilisateurs de MySQL.

Pour la communauté du Libre, c'est un nouveau mouvement de concentration (on se rappelle par exemple du rachat de JBoss par RedHat), mais également une nouvelle preuve de la viabilité du modèle économique choisi par une entreprise du libre comme MySQL, avec une valorisation très importante.

NdM : merci également à dark_moule pour sa proposition d'article à ce sujet.

Aller plus loin

  • # Voler ?

    Posté par  . Évalué à 4.

    Mais les dauphins savent déjà voler, ils sont la seconde race la plus intelligente sur Terre après tout.

  • # Et Derby alors ?

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

    Sun a déjà son produit BD qui pointe le bout de son nez, Derby ou plutôt Java DB :
    http://developers.sun.com/javadb/
    http://fr.wikipedia.org/wiki/Apache_Derby

    Donc, au final, c'est purement stratégique ce rachat. Qu'est-ce qu'il vont en faire ? Une œuvre charitable pour rendre MySQL libre, c'est tout ?

    • [^] # Re: Et Derby alors ?

      Posté par  . Évalué à 7.

      Qu'est-ce qu'il vont en faire ? Une œuvre charitable pour rendre MySQL libre, c'est tout ?


      Euh ... MySQL n'est pas déjà libre ?

      • [^] # Re: Et Derby alors ?

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

        Ben pas au sens profond du terme, puisqu'il n'est pas exclusivement distribué sous licence libre. Mais bon, je te l'accorde, on ne peut pas dire qu'il n'est pas libre. C'est juste une question provocatrice, parce que je me pose des questions sur leurs motivations, c'est tout.

        • [^] # Re: Et Derby alors ?

          Posté par  . Évalué à 8.

          Mysql m'apporte
          - La liberté d'exécuter le programme, pour tous les usages
          - La liberté d'étudier le fonctionnement du programme, et de l'adapter à mes besoins
          - La liberté de redistribuer des copies, donc d'aider mon voisin
          - La liberté d'améliorer le programme et de publier mes améliorations, pour en faire profiter toute la communauté


          En quoi ne serait-il "pas fondamentalement libre" ? Ça te gêne qu'ils fassent de l'argent à côté ?

          • [^] # Re: Et Derby alors ?

            Posté par  . Évalué à -2.

            La liberté d'exécuter le programme, pour tous les usages


            Si c'est un usage commercial il faut payer, ce n'est donc pas libre pour tous les usages. Enfin, c'est ce que j'ai compris de la licence MySQL, qu'il fallait payer pour un usage commercial, mais c'est peut-être inexact.

            • [^] # Re: Et Derby alors ?

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

              MySQL est libre pour tous les usages tant que tu ne l'utilises pas dans un logiciel non-libre.
              C'est pour ce dernier cas, ou si tu veux bénéficier du support de la société, qu'il faut payer

              • [^] # Re: Et Derby alors ?

                Posté par  . Évalué à -2.

                > MySQL est libre pour tous les usages tant que tu ne l'utilises pas dans un logiciel non-libre.

                il n'est donc pas libre pour tous les usages, non ?

                • [^] # Re: Et Derby alors ?

                  Posté par  . Évalué à 4.

                  Ben pas moi que n'importe quel logiciel sous GPL.

                  • [^] # Re: Et Derby alors ?

                    Posté par  . Évalué à 4.

                    Et alors?
                    La GPL non plus n'est *pas* libre pour tous usage: fermer les sources et revendre, c'est aussi un usage, non autorisé par la GPL ou la license de MySQL, de Berkeley DB, etc.

                    Je suis tout a fait d'accord avec la philosophie de la GPL, mais il ne faut pas pour autant dire qu'elle est "libre pour tous usage": c'est incorrecte..

                    Tu peux dire 'libre pour tous usage respectant la liberté du code et de ses dérivés' si tu veux mais pas juste 'libre pour tous usage'..

                    • [^] # Re: Et Derby alors ?

                      Posté par  . Évalué à 5.

                      oui exactement, donc il n'y a que la licence BSD qui est vraiment libre pour tous les usages...

                      Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

                      • [^] # Re: Et Derby alors ?

                        Posté par  . Évalué à 4.

                        ça c'est de la licence libre : la STFUPL

                        SHUT THE FUCK UP PUBLIC LICENSE
                        Version 1, December 2007

                        Copyright (C) 2007 Kika Ecrissa


                        Everyone is permitted to copy and distribute verbatim or modified
                        copies of this license document, and changing it is allowed as long
                        as the name is changed.


                        SHUT THE FUCK UP PUBLIC LICENSE TERMS AND CONDITIONS
                        FOR COPYING, DISTRIBUTION AND MODIFICATION :

                        0. You DO WHAT THE FUCK YOU WANT TO, as long as
                        0.0 You just SHUT THE FUCK UP.


                        évidemment dérivée de la WTFPL

                        • [^] # Re: Et Derby alors ?

                          Posté par  . Évalué à 2.

                          Justement, si tu dois te taire pour avoir l'autorisation d'utiliser le logiciel, c'est un restriction des libertés normalement fournies par un logiciel libre.

                          • [^] # Re: Et Derby alors ?

                            Posté par  . Évalué à 3.

                            non, ce 0.0 est une clause dite de dégagement de responsabilité ("no warranty")

                    • [^] # Re: Et Derby alors ?

                      Posté par  . Évalué à 2.

                      Alors quand on parle de "libre pour tout les usages" on parle, pour moi, de l'utilisation du binaire créé avec les sources, autrement dit l'exécuter à toutes les fins que tu veux.

                      Liberté 0, je crois.

            • [^] # Re: Et Derby alors ?

              Posté par  . Évalué à 1.

              C'est ca que j'ai jamais aimé avec MySQL, c'est leur FUD : si, tu peux l'utiliser sans payer pour un usage commercial, comme la GPL te l'autorise, mais sur leur site ils disaient a une époque que "non, pas vraiment ... vous devez payer la version commerciale".

            • [^] # Re: Et Derby alors ?

              Posté par  . Évalué à 4.

              MySQL est disponible en version GPL, donc tu a le droit d'exécuter pour tous les usages... Par contre, si tu crée un logiciel qui as besoin de mysql, et que tu fournit mysql avec, le logiciel doit aussi être sous GPL.
              Soit dit en passant, on peut faire une utilisation commercial d'un logiciel sous GPL.

              Par contre, si doit veut distribuer un logiciel «proprietaire» couplé avec MySQL, tu dois prendre l'autre licence.

              Plus d'infos :
              http://www.mysql.com/company/legal/licensing/

              • [^] # Re: Et Derby alors ?

                Posté par  . Évalué à 0.

                Oui, l'on peut faire une utilisation commercial d'un logiciel sous GPL, tant que cela n'enfreint pas la troisième loi. Si tu oblige à payer pour redistribuer une copie, ce n'est plus libre. C'est ça que j'ai du al à comprendre avec MySQL, que le code soit sous GPL mais que l'on soit obligé de payer pour une utilisation commerciale, cre qui me semble en contradiction avec la troisième loi.

                • [^] # Re: Et Derby alors ?

                  Posté par  . Évalué à 6.

                  C'est pourtant tres simple, MySQL est sous double licence GPL + proprio.

                  Si tu n'es pas gene par le fait de devoir mettre les sources de ton code qui utilise MySQL en GPL, la version GPL de MySQL te suffit et tu ne paies rien a personne.

                  Si tu as envie de garder tes sources pour toi, il te faut la version non-GPL de MySQL, et la tu dois payer.

                  Bref, tout le monde est libre d'utiliser MySQL en GPL, c'est uniquement si tu VEUX la version non-GPL que tu paies.

                  • [^] # Re: Et Derby alors ?

                    Posté par  . Évalué à 4.

                    La ou je bloque perso, c'est pas sur la double licence dont le concept est ecule, mais sur le fait que l'utilisation commerciale d'un serveur mysql soit payante.

                    Le business model de Trolltech, c'est que le link de leur lib vers une appli proprio est interdit par la GPL et c'est la qu'intervient la deuxieme licence.
                    Dans le cas de MySQL, on a pas de link au niveau du code, juste une connexion vers un serveur distant, ce qui n'est clairmeent pas interdit par la GPL. Ou sinon Apache va avoir du mouron a se faire vu la predominance d'IE chez les browsers web.

                    Comment interdire l'utilisation de la version GPL par un soft proprietaire dans ce cas la?

                    • [^] # Re: Et Derby alors ?

                      Posté par  . Évalué à 0.

                      En fait, il me semble qu'on en revient au problème du «linkage» des logiciels.

                      Si tu crée un logiciel qui nécessite imagemagick (il est bien sous gpl ?) pour fonctionner, tu dois redistribuer ton logiciel avec une licence compatible avec celle d'imagemagick puisque ton logiciel l'utilise.
                      Si au contraire, tu crée un logiciel "indépendant" d'imagemagick (qui fonctionne correctement etc) et qu'il a juste la possibilité de s'interfacer avec imagemagick pour avoir une fonctionnalité avancée, comme tu n'as pas besoin d'imagemagick, ton logiciel fait ce qu'il veut.

                      C'est pareil pour MySQL.

                      Si ton logiciel peut interface avec Oracle PostgreSQL, un fichier XML et MySQL, ton logiciel peut avoir la licence que tu veux, si en revanche, l'utilisation de MySQL est codée en dur, tu dois respecter la licence de MySQL.
                      Donc ce n'est pas l'utilisation commerciale de MySQL qui est interdite. Comme tout logiciel sous GPL, tu peux le revendre, le revendre modifié etc. seulement, tu dois fournir les sources et donner le droit aux autres de le redistribuer comme ils le veulent.

                      En fait, tout est dans le :

                      Dans le cas de MySQL, on a pas de link au niveau du code, juste une connexion vers un serveur distant, ce qui n'est clairmeent pas interdit par la GPL.Ou sinon Apache va avoir du mouron a se faire vu la predominance d'IE chez les browsers web.

                      Eh bien si, sa arrive, car pour que le logiciel gere tout du debut à la fin, on fixe le serveur SQL et on code tout pour MySQL qui est d'ailleurs livré avec le logiciel

                      • [^] # Re: Et Derby alors ?

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

                        Euh, là, je ne vois pas trop.

                        Le problème du linkage dynamique, c'est que si j'écris une lib compatible au niveau binaire avec une lib GPL, et que j'autorise le linkage avec cette lib sans condition, alors l'utilisateur pourra linker indépendamment sont application avec ma lib ou avec la lib GPL.

                        Pour MySQL, le problème est, amha, que l'application cliente n'attaque pas en brut les sockets pour se connecter au serveur. Elle repose sur une lib qui gère la connexion, et qui elle est GPL.

                      • [^] # Re: Et Derby alors ?

                        Posté par  . Évalué à 1.

                        C'est bien joli ce que tu racontes là, mais qu'en est-il pour les différentes couches d'abstractions aux bases de données qui existent ?

                        A un moment, ils sont bien obligé de faire des "drivers" pour chaque moteur de base de données qu'ils gèrent... qui sont forcément spécifiques au moteur.

                        Comment ça se passe dans ce cas-là ? Ils sont obligés d'utiliser la license payante pour le "driver" si l'utilisation est commerciale ? Comment ça se passe si la bibliothèque qui fait l'abstraction est sous license libre ?

                        C'est plus compliqué, à mon avis. Je pense que ça serait nettement moins le bordel si les logiciels proprios n'existaient pas.

                    • [^] # Re: Et Derby alors ?

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

                      MySQL, ce n'est pas seulement un serveur, mais aussi une bibliothèque qui facilite l'interaction avec ce serveur. Et cette bibliothèque (libmysqlclientXXX sous Debian) est distribuée sous licence GPL avec une exception permettant aux logiciels libres sous d'autres licences d'utiliser la bibliothèque sans être eux-mêmes sous licence GPL. Donc si tu utilises MySQL au travers de cette bibliothèque, ton logiciel doit être sous licence libre (ou alors tu dois acheter une licence à MySQL).

                      Par contre, si tu attaques directement le serveur MySQL au travers de la chaussette Unix ou TCP sans utiliser leur bibliothèque, je ne vois pas trop pourquoi il faudrait que ton logiciel soit sous licence libre.

                      Peut-être que c'est juste sur cet aspect là que se fait la différence ?

            • [^] # Re: Et Derby alors ?

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

              il fallait payer pour un usage commercial, mais c'est peut-être inexact.

              C'est inexact : il faut payer si tu veux ne pas respecter la GPL, c'est tout. la GPL, c'est la GPL, elle autorise les usages commerciaux, tant que tu respectes la GPL.

              Donc en quoi c'est pas libre? A part si tu considère la GPL non libre (bataille BSD vs GPL...), MySQL est libre autant que peut l'etre Linux (sous GPL aussi!), avec option de faire du non-libre, c'est tout.

    • [^] # Re: Et Derby alors ?

      Posté par  . Évalué à 3.

      Derby est assez loin de MySQL en terme de qualité et fonctionnalités que l'on peut attendre d'un SGBD.

      L'avantage de Derby/JavaDB pour les développeurs java c'est la possibilité de l'embarquer simplement dans une application.

      • [^] # Re: Et Derby alors ?

        Posté par  . Évalué à 7.

        > Derby est assez loin de MySQL en terme de qualité et fonctionnalités que l'on peut attendre d'un SGBD.

        On peut dire de même de MySQL. MySQL a un vague support de transaction, pas de support pour les languages embarqués, vaguement compatible SQL, pas de hot backup (qui garde l'ensemble de la base de donnée cohérent), pas de vieux, pas de rules, une tenu en charge très moyenne si on compare à PostgreSQL, etc...

        Dès qu'on étude techniquement MySQL, ben c'est un SGBD très très moyen.
        Avant de répondre, assurez-vous de bien connaitre Oracle ou PostgreSQL voir SQL Server.

        • [^] # Re: Et Derby alors ?

          Posté par  . Évalué à 5.

          Celà s'éloigne du sujet mais MySQL 5 est très performant globalement.
          Le support de transaction n'est pas vague, il est réel sur le moteur InnoDB, pareil pour le hotbakcup, sans soucis sur des gros volumes de données.

          Les views sont bien présentes, au moins depuis MySQL 4, et la tenue en charge bien tuné est très correcte.

          PostgreSQL ne gère pas les réplications, Oracle et SQL Server ont des fonctionnalités en plus, mais ne sont que rarement nécessaires à la grande majorité des projets par rapport à un MySQL.

          Est-il nécessaire de rapeler que c'est le SGBD le plus utilisé au monde et donc vraissemblablement le plus stressé / testé ? Il souffre certes d'un historique et de débuts difficiles, mais je pense qu'il est de grande qualité depuis quelques temps déjà.

        • [^] # Re: Et Derby alors ?

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

          On peut dire de même de MySQL. MySQL a un vague support de transaction, pas de support pour les languages embarqués, vaguement compatible SQL, pas de hot backup (qui garde l'ensemble de la base de donnée cohérent), pas de vieux, pas de rules, une tenu en charge très moyenne si on compare à PostgreSQL, etc...

          Dès qu'on étude techniquement MySQL, ben c'est un SGBD très très moyen.
          Avant de répondre, assurez-vous de bien connaitre Oracle ou PostgreSQL voir SQL Server.


          C'est quand même dommage de comparer MySQL 3.x et PostgreSQL 8 tant d'années après la sortie de la version 5, non ? :)

          Je comprends que, comme une partie de mes relations, tu puisses ne pas aimer MySQL, mais j'aimerais mieux voir des critiques valides en 2008.

          • [^] # Re: Et Derby alors ?

            Posté par  . Évalué à 2.

            J'ai fait quelques tests de NDOutils, extension servant à stocker les événements générés par Nagios dans une base (My)SQL. Le schéma de base de NDOutils utilise InnoDB. Qui dit transactions, dit journal de ces transactions. Lorsque tu as un volume conséquent de transactions, disons entre 20 et 30 requêtes/seconde, le volume des ces journaux est important, environ 8GO/jour dans ce cas. Logiquement, j'espère, j'en suis venu à tweaker la configuration de Mysql pour ne pas conserver ces 8GO. Et là, petite surprise: tu peux jouer sur deux paramètres: la taille des fichiers (max_binlog_size) et le nombre de jours pendant lesquels tu les conserves (expire_logs_days). Ce nombre de jour est un entier comprit entre 0 et 99, 0 désactive la suppression des logs de manière automatique. Tu peux tout de même passer des requêtes pour supprimer les journaux.

            Là ou pour moi c'est une, mauvaise, surprise, c'est dans la comparaison avec PostgreSQL. j'avais eu à configurer la gestion des journaux sur un PostgreSQL, et tu pouvais, de mémoire, jouer sur: la taille d'un fichier, le nombre total de fichiers (avec une rotation automatique) et, éventuellement, une commande shell à éxecuter automatiquement juste avant la suppression d'un journal: par exemple, copier le journal sur un système de fichier réseau, faire un scp, ...

            Avec PostgreSQL, tu n'as aucun mal à prévoir la taille totale des journaux: taille d'un fichier x nombre de fichiers. Avec MySQL, c'est impossible. De plus, si tu veux conserver les journaux, il te faut une moulinette qui va mêler SQL et commandes shell.

            Ce point particulier illustre bien pourquoi je préfère PostgreSQL à Mysql: la moindre fonctionnalité un tant soit peu intéressante de MySQL souffre de limitations franchement absurdes.

            J'ai joué avec tout ça cette semaine, donc en 2008, avec le mysql d'une debian stable. Si on me montre comment mieux gérer ces journaux, j'en serais particulièrement heureux !

            • [^] # Re: Et Derby alors ?

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

              Juste quelques précisions :

              éventuellement, une commande shell à éxecuter automatiquement juste avant la suppression d'un journal

              En l'occurrence, cette action est effectuée quand PostgreSQL passe au fichier de journal suivant, pas quand le journal est supprimé ou réutilisé. C'est ce qui est utilisé pour la réplication via log shipping.

              Avec PostgreSQL, tu n'as aucun mal à prévoir la taille totale des journaux: taille d'un fichier x nombre de fichiers.

              En l'occurrence, ce n'est pas tout à fait vrai. PostgreSQL n'offre aucune garantie à ce niveau. A très très forte charge en écriture, tu peux dépasser les (2 * checkpoint_segments + 1) fichiers habituels. Ce n'est pas un cas qui se produit souvent mais il n'y a pas de garantie.

        • [^] # Re: Et Derby alors ?

          Posté par  . Évalué à 8.

          Je ne suis pas un spécialiste DB loin de là mais en me basant sur un comparatif du magazine Programmez no98 il y quelques elts de comparaison.

          "vaguement compatible SQL"
          MySQL supporte la norme SQL 92 et 99
          Pg supporte "en partie"" SQL 2003 et est le seul du comparatif
          Avantage à Pg certes mais de là à dire "vaguement compatible" pour mySQL
          Le langage étendu est classé plus riche que MySQL

          Les transactions sont supportées en ft du moteur de stockage utilisé.

          MySQL supporte l'UTF 8 et 16 pG 8 uniquement

          Pour les performances:
          outre le fait que tu peux choisir ton moteur de stockage en fonction des usages (par exemple une base accédée beaucoup plus en lecture n'aura pas les mêmes contraintes qu'une base plus sollicitée en écriture, tables en mémoire, fichiers à plat...). Par ailleurs la 6.0 est encore plus ouverte et facilite encore plus l'interchangeabilité des moteurs.
          MySQL 5.1 dispose d'un cache de procédures, pg non
          La granularité du verrouillage dans le moteur Falcon sera encore plus fine et en fonction des moteurs on peut choisir la ligne, table ou page. pG se limite à la ligne.


          Pour le hot backup je crois que c'est main tenant le cas de MySQL 6.0 avec Falcon , InnoDB le propose en payant pour la 5.0 et en 5.0 on a aussi le moteur NDB cluster (surcouche).
          De même MySql permet aussi la sauvegarde par cliché (base gelée en écriture mais pas en lectureà alors que pg est le seul de la liste à ne pas le supporter).

          Concernant la securité:
          MySQL ne supporte pas la gestion des utilisateurs au niveau de l'OS (bien que je n'y vois guère d'avantage ayant à pâtir d'outils de gestion de version qui gèrent les droits au niveau de l'OS comparé à des ACLs intégrés ou des annuaires)

          MySQL ne supporte pas non plus la gestion des rôles et des groupes, ni l'interfacage avec un annuaire LDAP)

          avantage à pG sur ce point

          Pour la disponibilité
          MySQL permet le clustering ACTIF/ACTIF alors que pG n'en est qu'au ACTIF/PASSIF (le noeud redondant ne prend le relais qu'en cas de coupoure, pas de load balancing)

          MySQL dispose d'un outil de réplication intégré et pG non.
          MySQL supporte la réplication partielle et pG non

          Il faudrait revérifier tout ça avec MySQL6.0 et le pG du test est la version v8
          .
          Il faut aussi tempérer l'article car il n'est pas indiqué si toutes ces caractéristiques sont propres à MySQL ou à certains moteurs.
          En choisissant un moteur est-ce que le comparatif est tjs valable ?


          En tout cas, je n'ai pas l'impression que MySql soit si en retard par rapport à tes sous-entendus et le fait de déléguer une partie du boulot (storage engines) à d'autres acteurs potentiels me parait plutôt une bonne stratégie

          PS: je n'ai vérifié aucune source, juste résumé les différences du comparatif

          • [^] # Re: Et Derby alors ?

            Posté par  . Évalué à 0.

            Pour un comparatif MySQL/PostgreSQL : http://www.postgresqlfr.org/?q=node/1432
            On y apprend beaucoup de choses.

            • [^] # Re: Et Derby alors ?

              Posté par  . Évalué à 5.

              Je me méfie en général des comparatifs hébergés par l'un des protagonistes.

              L'article de Programmez comparait 5 db et uniquement les features en précisant que l'on fait tjs dire ce qu'on veut aux benchmarks.
              Sur ce point je ne leur donne pas tort

              • [^] # Re: Et Derby alors ?

                Posté par  . Évalué à 1.

                On est bien d'accord.. Ceci dit, le comparatif que j'ai donné s'appuie sur des exemples concrets. Qui plus est, il n'est pas dit "MySQL sucks et PostgreSQL rules".
                Il s'agit d'une vision que je trouve plutot juste sur certains points de comparaison.

          • [^] # Re: Et Derby alors ?

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

            Juste quelques remarques générales sur les comparaisons avec MySQL :
            * l'un des soucis que j'ai avec les papiers sur MySQL (et tu le soulignes à la fin de ton post), c'est que les gens additionnent l'ensemble des fonctionnalités de tous les moteurs. Pour chaque objet que tu crées, tu as un et un seul moteur donc parler des avantages d'InnoDB quand on utilise du MySQL Cluster et donc le moteur NDB est un non-sens. C'est soit l'un soit l'autre pour chaque objet. Chaque moteur a une page Known limitations assez conséquente en plus de ses spécificités en terme de performances donc ce n'est clairement pas une addition qu'il faut faire.
            * je rappelle que la version stable de MySQL est la 5.0, que la 5.1 est encore en pre-release et on parle déjà des fonctionnalités de la 6.0 comme d'un fait et du moteur Falcon comme de quelque chose de stable. La 6.0 est loin d'être sortie (la 5.1 n'est toujours pas considérée stable alors qu'ils en sont à la 5.1.22...) et Falcon, aussi bon qu'il pourra être, sera très très très jeune comparé à tous les autres moteurs actuels. Seul l'avenir nous dira s'il vaut vraiment le coup et s'il est fiable, performant et pérenne dans toutes sortes de situations et de cas réels. Ni les fonctionnalités de la 5.1 ni celles de la 6 ne sont utilisables à l'heure actuelle en production.

            Ensuite, juste pour info :
            De même MySql permet aussi la sauvegarde par cliché (base gelée en écriture mais pas en lectureà alors que pg est le seul de la liste à ne pas le supporter)

            Avec PostgreSQL, tu fais un SELECT pg_start_backup('ton_backup'); et non seulement tu peux faire un cliché mais ta base est toujours accessible en lecture *ET* en écriture. Cette fonctionnalité existe depuis la 8.1 soit depuis novembre 2005 (et je parle d'une vraie 8.1 finale, pas d'une pre-release).

            • [^] # Re: Et Derby alors ?

              Posté par  . Évalué à 3.

              Merci pour tes remarques vraiment intéressantes.

              Comme je l'avais précisé , je n'ai fait que retranscrire un dossier de comparaison et suis loin d'être un spécialiste db.

              Concernant le moteur NDB, l'article précisait qu'il s'agissait d'une surcouche et sous-entendait qu'on pouvait donc le coupler avec un autre moteur par exemple transactionnel.
              Il faudrait peut-être vérifier.
              Quoiqu'il en soit ca tout ce choix de moteurs fait un peu bazar face à la cathédrale pG.

              • [^] # Re: Et Derby alors ?

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

                Ben, pour citer quelqu'un de chez MySQL "InnoDB is not a clustered engine" [http://forums.mysql.com/read.php?25,131517,131704#msg-131704].
                Donc, quand on me dit que MySQL gère telle et telle fonctionnalité via InnoDB (les foreign keys par exemple) et qu'il ne faut évidemment pas utiliser MyISAM et qu'on me parle ensuite de MySQL Cluster, je me dis qu'il y a un bug quelque part :).

                Sur le principe, l'idée d'avoir plusieurs moteurs est plutôt pas mal. Ce qui me gêne personnellement, c'est qu'ils ne sont vraiment pas homogènes et que certains ont des limitations vraiment tordues.
                On retrouve un peu les mêmes limitations bizarres sur pas mal de fonctionnalités ajoutées ces dernières années un peu à la va-vite à mon goût.

                Pour prendre un exemple concret sur les triggers : "Triggers currently are not activated by foreign key actions." [http://dev.mysql.com/doc/refman/5.0/en/routine-restrictions.(...)]
                Si on imagine un forum avec des topics et des messages. On pose un trigger sur la table messages pour mettre à jour le nombre de messages dans un forum. Si on supprime un topic qui via une foreign key supprime les messages qui en dépendent, cela ne déclenchera pas le trigger de mise à jour du nombre de messages.
                Il y a pas mal d'autres exemples dans le manuel (beaucoup de fonctionnalités ont une page avec les limitations).

                C'est notamment toutes ces petites limitations bizarres qui me font éviter MySQL au maximum. PostgreSQL est, de manière générale, beaucoup plus cohérente.

                • [^] # Re: Et Derby alors ?

                  Posté par  . Évalué à 1.

                  Si on imagine un forum avec des topics et des messages. On pose un trigger sur la table messages pour mettre à jour le nombre de messages dans un forum.

                  Si le forum_id dans la table messages est un index, le COUNT(DISTINCT forum_id) sera très rapide, donc ton trigger n'a pas grand intérêt.

                  • [^] # Re: Et Derby alors ?

                    Posté par  . Évalué à 2.

                    https://linuxfr.org//comments/896989.html#896989

                    • [^] # Re: Et Derby alors ?

                      Posté par  . Évalué à 1.

                      Tu as le droit de t'esclaffer bruyamment, mais mettre un trigger sans raison valable c'est faire de l'optimisation prématurée, et aussi rendre ta BD plus difficile à gérer puisque plus compliquée.
                      Après chacun est maître de ses propres développements et a le droit de concevoir des usines à gaz si ça lui chante :-)

                      (soit dit en passant, le moindre des respects quand on répond à un thread est d'exprimer ses idées en français au lieu de se contenter d'un lien vers un message humoristique)

                      • [^] # Re: Et Derby alors ?

                        Posté par  . Évalué à 3.

                        Tu as le droit de t'esclaffer bruyamment


                        Merci.

                        mais mettre un trigger sans raison valable c'est faire de l'optimisation prématurée, et aussi rendre ta BD plus difficile à gérer puisque plus compliquée.


                        Non.

                        Après chacun est maître de ses propres développements et a le droit de concevoir des usines à gaz si ça lui chante :-)


                        Oui.

                        (soit dit en passant, le moindre des respects quand on répond à un thread est d'exprimer ses idées en français au lieu de se contenter d'un lien vers un message humoristique)


                        Alors, à ma droite: https://linuxfr.org//comments/897074.html#897074
                        une solution qui met à jour un compteur lors de l'insertion et de la suppression d'une ligne. Le compteur est consultable sans autre opération que la lecture.

                        Puis à ma gauche: https://linuxfr.org//comments/897299.html#897299 une solution qui va utiliser une fonction d'agrégat (COUNT) sur une opération de tri des résultats d'une requête (DISTINCT) chaque fois que l'on voudra connaître la valeur de ce compteur.

                        Cette deuxième solution est cocasse. Le contournement poussif d'une limitation absurde propre à MySQL. Il me semble urgent d'en rire.

                        • [^] # Re: Et Derby alors ?

                          Posté par  . Évalué à 1.

                          utiliser une fonction d'agrégat (COUNT) sur une opération de tri des résultats d'une requête (DISTINCT)

                          DISTINCT n'est pas un tri. Si la colonne est un index, COUNT DISTINCT va simplement compter le nombre de clés dans l'index, ce qui normalement est très rapide (avec MyISAM en tout cas - fais un EXPLAIN SELECT pour t'en convaincre). Si ça ne te plaît pas, je m'en fous et tu peux continuer à te marrer en refusant de voir la réalité en face :-))

                          Le contournement poussif d'une limitation absurde propre à MySQL

                          Très drôle. Si MySQL permet de faire rapidement un COUNT(DISTINCT mon_index) alors que ses concurrents imposent d'utiliser un trigger pour mettre en cache la valeur en question, ce n'est pas MySQL qui impose un "contournement poussif".

                          Il me semble urgent d'en rire.

                          Tourner sept fois sa langue dans sa bouche avant d'intervenir me semble plus approprié dans ton cas.

                          • [^] # Re: Et Derby alors ?

                            Posté par  . Évalué à 2.

                            DISTINCT n'est pas un tri. Si la colonne est un index, COUNT DISTINCT va simplement compter le nombre de clés dans l'index, ce qui normalement est très rapide (avec MyISAM en tout cas - fais un EXPLAIN SELECT pour t'en convaincre).

                            DISTINCT est un tri. Il ne retourne pas les enregistrements identiques, il les détecte et les exclus du résultat. Que ce soit rapide ne veut pas dire que c'est plus rapide que la consultation d'un compteur (un champ de type entier dans une table forums pour cet exemple). Faire une somme a également un coût. Que tu veuilles payer ce coût à chaque consultation d'un total, plutôt que quand il change, c'est Poussif By Design.
                            Par ailleurs, il y a quelques chances que ton index possède une contrainte UNIQUE, auquel cas, l'utilisation de DISTINCT relève de la perversion.

                            ses concurrents imposent d'utiliser un trigger pour mettre en cache la valeur en question

                            Ses concurrents n'imposent pas de passer par un COUNT, cela ne veut pas dire qu'ils imposent de passer par un trigger.

                            Tourner sept fois sa langue dans sa bouche avant d'intervenir me semble plus approprié dans ton cas.

                            Dans ton cas, je me renseignerais sur ce que font les concurrents avant de proposer des solutions que, visiblement, tu peines à justifier.

                            • [^] # Re: Et Derby alors ?

                              Posté par  . Évalué à 1.

                              DISTINCT est un tri.

                              Non. On n'a pas besoin de trier un ensemble pour en extraire les éléments uniques. D'ailleurs il est parfaitement possible d'extraire les éléments uniques d'un ensemble sur lequel n'existe pas de relation d'ordre, c'est-à-dire sur lequel il est impossible de faire un tri.

                              Par ailleurs un index sur une table MyISAM est déjà trié par construction, puisque c'est un b-tree.

                              Faire une somme a également un coût.

                              D'une part ce n'est pas une somme, c'est un décompte, de l'autre cela n'a pas de coût si l'information est déjà stockée par le moteur sous-jacent. Par exemple COUNT(*) sur une table MyISAM retourne immédiatement.

                              il y a quelques chances que ton index possède une contrainte UNIQUE

                              Relis l'exemple original avant de dire n'importe quoi. On ne met pas de contrainte UNIQUE sur le numéro de forum associé à un message...

                              Je vais te laisser troller dans ton coin, tu es là visiblement pour casser du MySQL sans même être capable de comprendre quelques notions d'algorithmique de base (comme : DISTINCT n'est pas un tri), la discussion n'a pas grand intérêt.

                              • [^] # Re: Et Derby alors ?

                                Posté par  . Évalué à 2.

                                > Non. On n'a pas besoin de trier un ensemble pour en extraire les éléments uniques.
                                Oui, mais avec une complexité (algorithmique, s'entend) beaucoup plus grande...

                                • [^] # Re: Et Derby alors ?

                                  Posté par  . Évalué à 1.

                                  > Non. On n'a pas besoin de trier un ensemble pour en extraire les éléments uniques.
                                  Oui, mais avec une complexité (algorithmique, s'entend) beaucoup plus grande...

                                  Ah bon ? Je serais curieux d'entendre une justification.
                                  Par exemple, une table hash a des opérations en O(1) temps amorti, ce qui donne un O(n) pour extraire les éléments uniques d'un ensemble, même s'il n'est pas trié a priori.

                                  • [^] # Re: Et Derby alors ?

                                    Posté par  . Évalué à 3.

                                    Tu as raison, j'ai posté trop vite.
                                    Mea culpa, la prochaine fois je tournerai ma langue 7 fois avant de cliquer sur envoyer (je dis ça à chaque fois...)

                              • [^] # Re: Et Derby alors ?

                                Posté par  . Évalué à -1.

                                Rigolo. Apparemment il y a un groupe de fanboys anti-MySQL qui ne supporte pas qu'on mette en doute leurs préjugés et qui s'échinent à voter contre les messages qui leur déplaisent :-))

                      • [^] # Re: Et Derby alors ?

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

                        Prendre un exemple pour illustrer mon propos, ce n'est pas de l'optimisation prématurée :). J'aurai pu prendre d'autres exemples mais celui-là a l'avantage de parler à tout le monde.

                        Le fait que MySQL puisse se limiter à une passe sur l'index en MyISAM est principalement dû au fait que MyISAM n'est pas MVCC (multi-version concurrency control). Donc en l'occurrence, c'est une limite de MyISAM qui permet de contourner le problème. De ce que j'ai lu, la musique est différente avec InnoDB. Et MyISAM a tellement d'autres limitations que je ne suis pas super motivé pour l'utiliser.
                        PostgreSQL ne stocke pas les infos de visibilité des tuples dans l'index et ne peut donc pas se limiter au parcours d'un index.

                        Bref, on peut sans doute trouver des contournements avec MySQL et trouver des raisons pour lesquelles c'est inutile (en l'occurrence, c'est assez dangereux de présager que ce sera inutile pour tout le monde...), mais il n'en reste pas moins que c'est une limitation dangereuse et qui peut surprendre parce que ce n'est pas dans l'ordre naturel des choses. A mon sens, il aurait mieux valu attendre d'avoir réglé ce problème avant de mettre à disposition les triggers dans MySQL.

                        • [^] # Re: Et Derby alors ?

                          Posté par  . Évalué à 1.

                          De ce que j'ai lu, la musique est différente avec InnoDB. Et MyISAM a tellement d'autres limitations que je ne suis pas super motivé pour l'utiliser.

                          Certes, il faut se familiariser avec ces limitations. Il faudrait faire des tests de performance poussés sur MyISAM vs. InnoDB vs. autre chose pour voir dans quel cas le jeu en vaut la chandelle.

                          et qui peut surprendre parce que ce n'est pas dans l'ordre naturel des choses

                          Mouais, je ne savais pas que les SGBD avaient à voir avec un quelconque « ordre naturel » :-)
                          Qu'il y ait des idiomes utiles voire recommandés, je ne le nie pas, mais on peut très bien vivre sans, de même que Postgres (ou un autre SGBD) peut très bien vivre sans laisser le choix de 5 (4 ? 6 ? j'ai arrêté de suivre) moteurs de stockage différents.

                          • [^] # Re: Et Derby alors ?

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

                            Il y a les benchs de Tweakers :
                            http://tweakers.net/reviews/657/2/database-test-dual-intel-x(...)

                            Il y en a plusieurs différents sur des archis différentes (de mémoire, MySQL AB a participé à celui sur la plate-forme Sun d'ailleurs)

                            Mouais, je ne savais pas que les SGBD avaient à voir avec un quelconque « ordre naturel »


                            Disons que ça a à voir avec la cohérence.

                            de même que Postgres (ou un autre SGBD) peut très bien vivre sans laisser le choix de 5 (4 ? 6 ? j'ai arrêté de suivre) moteurs de stockage différents


                            Mouais. Ca n'a pas grand chose à voir avec ce dont je parlais. PostgreSQL offre une cohérence globale et un ensemble de fonctionnalités qui l'est tout autant (avec comme principe général que si c'est présent, ça marche sans limite). Et je préfère avoir cette cohérence que plein de moteurs différents qui ont tous des limitations bizarroïdes différentes, limitations qui ont des conséquences sur l'intégrité de mes données. Après, chacun ses choix :).
                            Evidemment, on peut apprendre à faire avec (ou plutôt sans), je me rappelle encore le temps où MySQL AB expliquait comment on pouvait se passer de toutes les fonctionnalités qu'ils intègrent maintenant. Il n'en reste pas moins que c'est tellement plus simple et tellement plus sécurisant avec.

        • [^] # Re: Et Derby alors ?

          Posté par  . Évalué à 3.

          J'ai bossé 3 ans sur mysql 4.1. En véritable production pour un gros site français de vente en ligne. 200Go 10k requetes/s, du backup à chaud, des transactions, 5 serveurs réplicas. Aujourd'hui je bosse sur du oracle et du db2 et pour être franc mysql me manque. Il est simple, robuste et j'ai toujours trouvé très clair la doc pour faire le tunning.

          Ces remarques concernants mysql me hérisse vraiment le poil !

          • [^] # Re: Et Derby alors ?

            Posté par  . Évalué à 0.

            Ces remarques concernants mysql me hérisse vraiment le poil !

            /me passe un peigne à OAUDRY

    • [^] # Re: Et Derby alors ?

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

      Vous n'avez rien compris... C'est MySQL AB qui a racheté Sun pour répondre à Oracle qui a racheté BEA Systems

    • [^] # Re: Et Derby alors ?

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

      Il l'on achetée pour pouvoir la re-développer en Java. :o)

  • # Concentration du marché

    Posté par  . Évalué à 1.

    Avec l'acquisition de BEA par Oracle aujourd'hui et cette annonce de rachat de Mysql AB par Sun, le secteur informatique semble de + en + plus en clin à la concentration: Est-ce un signe de maturité du secteur, un phénomène lié à une baisse de l'innovation, une perte de vitesse du secteur ?

    L'industrialisation semble vraiment se confirmer.

    Au moins cela réjouira les DSI et architectes qui auront moins de questions à se poser...

    • [^] # Re: Concentration du marché

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

      en clin
      enclin au clin d'oeil ? ;-)

      Au moins cela réjouira les DSI et architectes qui auront moins de questions à se poser...
      pour diversifier les fournisseurs au niveau des achats, PostgreSQL pourrait être pris en compte :D

  • # Une question de support client et de licence

    Posté par  . Évalué à 3.

    Sun fournit déjà de l'Oracle et du Postgres sur Solaris.

    Vu que Mysql est la DB la plus employée, le cout de l'achat, 800 millions de dollards (qu'on me corrige si je me plante) reste très valable, avec tout le support client qu'il vont engranger plus toutes les licences payantes sur les applis non-GPL.

    Les codeurs DB Java doivent déjà se frotter les mains.

    Bonne route, petit dauphin ...

    PS :
    Je préfère tout de même Postgres,
    ... j'ai toujours eut un faible pour les éléphants.


  • # Et Oracle, alors ?

    Posté par  . Évalué à 2.

    Il me semble qu'Oracle avait acheté Innobase / InnoDB qui d'après ce que j'avais compris est une composante importante de MySQL.

    Qu'est ce que cela peut donner ce ménage à trois ?

    • [^] # Re: Et Oracle, alors ?

      Posté par  . Évalué à 3.

      En fait "Inno DB "n'est qu'un moteur de stockage parmi beaucoup d'autres.

      MySQL 6.0 est conçu pour qu'ils soient interchangeables en fonction des besoins (transactionnel, cluster ) ce qui est une approche originale
      http://dev.mysql.com/doc/refman/5.0/en/storage-engines.html
      MySql AB pousse son petit dernier "Falcon"
      http://www.google.fr/url?sa=t&ct=res&cd=8&url=ht(...)
      Une liste presque exhaustive a été publiée sur le programmez! no98

      Bien entendu, le but inavoué etait certainement de faire un pied de nez à Oracle.

      • [^] # Re: Et Oracle, alors ?

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

        Jul a raison, c'est un troll, mais comme tout troll, il y a un fond de vérité.

        Ce que j'ai voulu dire c'est que BSD permet de faire du propriétaire sans aucune contribution au logiciel libre.
        Le modèle de double licence de MySQL fait qu'il y a retour vers l'entreprise qui maintient le logiciel libre.

        • [^] # Re: Et Oracle, alors ?

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

          oui, mais bon, je préfère les retours discrets des utilisateurs de freebsd/openbsd tel que altéon. Altéon dont les rares sysadmin pros que j'ai rencontré trouve qu'il est une excellente alternative au "je fais tout moi même" pour le loadbalancing web, et qui contribue en retour.

          De l'autre en linux/GPL je trouve qu'il y a beaucoup de posture dans la contribution :
          - intel/SUN qui prétendent faire le jeu du libre, et qui oublient d'ouvrir les specs matériel importantes ;
          - parlons pas du pitoyable spip agora fork hostile, et contre productif d'un projet libre ;
          - pour ceux qui ont du utiliser l'outil samba ldap d'idealix qui par le passé (je l'ai pas regardé depuis 2 ans) était en shell script imbitable, non utilisable, ni réutilisable .... c'est sous GPL, mais qu'est ce que ça vaut ?

          Quand je vois tout ça, j'appelle pas faire ça du libre tellement le coût pour s'approprier (utiliser, modifier, étudier) les technologies/codes soit disant "libérés" sont élevés.

          Je parle de ce que j'ai vu... hein.

          Tout ça pour dire que c'est pas parce que la communauté BSD a pas autant de contributions tapageuses éditées sur linuxfr qu'il n'y a pas de retour. Et d'autre part, mieux vaut une petite communauté concernée et active sur un projet pas trop visible pour avancer. Parce que quand un truc libre devient à la mode, c'est parfois dur d'avancer dans la marée de pipotron à la 01 informatique qui se met à apparaître.

          Donc oui BSD permet de faire du propriétaire, et c'est pas plus mal car toute l'informatique en profite (windows s'améliore en prenant du code BSD) http://www.pcinpact.com/actu/news/29117-ALSR-une-securite-de(...)
          et non rien n'empêche de faire du propriétaire sous licence libre.

          PS je suis linuxien certes, mais je vais pas taper sur BSD pour de mauvais arguments : ils ont juste pas urbanterror qui tourne à une cadence convenable avec leur OS.

  • # Soulagement énorme pour les développeurs Java

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

    Aujourd'hui, Java et MySQL ne font pas bon ménage : les timestamps mysql sont limités en [1970-2038] (avec des datetime ca marche...), leur précision est en seconde et non en millisecondes, et pas mal de choses implicites en Java du genre unicode et transactions sont optionnelles sur mysql.

    Pour moi, développeur java devant greffer régulièrement des applications sur des bases mysql existantes, c'est une super nouvelle. A mon avis la première choses que sun va faire, c'est faire de MySQL une base supportant le minimum de fonctionnalité imposé par JDBC.

    Aujourd'hui, mon quotidien avec mysql, c'est lutter avec des détails obscurs de configuration du type (extrait de la doc du driver jdbc mysql) :

    useGmtMillisForDatetimes : Convert between session timezone and GMT before creating Date and Timestamp instances (value of "false" is legacy behavior, "true" leads to more JDBC-compliant behavior. default : false


    Avec un peu de chance (pour moi), certains réglages "par défaut" de mysql vont changer de valeur...

    • [^] # Re: Soulagement énorme pour les développeurs Java

      Posté par  . Évalué à 2.

      Aujourd'hui, Java et MySQL ne font pas bon ménage

      Pauvres petits chéris Javaïstes, ah lala.

      c'est lutter avec des détails obscurs de configuration du type (extrait de la doc du driver jdbc mysql)

      Ca n'a pas l'air si « obscur » que ça vu que c'est clairement documenté dans l'extrait que tu as cité. En même temps, c'est vrai que les fichiers de config de MySQL sont pas en XML, on comprend que ça puisse dérouter :-)

  • # Opinion

    Posté par  . Évalué à 2.

    Une opinion intéressante de Rod Johnson d'un autre projet libre à succès (Spring)
    http://blog.springsource.com/main/2008/01/16/the-power-of-ad(...)

  • # MySQL sous le giron SUN

    Posté par  . Évalué à 3.

    Il n'y a plus qu'à espérer que SUN ne rende pas MySQL aussi merdique que leur système d'exploitation Solaris ! En interne SUN est dédaigneux envers tout ce qui n'est pas SUN pur. De nombreux mails de propagande sont envoyés aux clients vantant les mérite de Solaris par exemple "The most powerfull OS of the Universe" comme ils disent...
    Mais là où certains proposent de vraies solutions de virtualisations (Xen , KVM etc...) SUN ne propose que leurs Zones... Creusez un peu le sujet et vous verrez qu'avec les Zones vous ne ferez jamais de serveur NFS car la couche NFS n'a pas encore été développé ! Honteux de la part du "Most powerfull OS of the Universe" non ?
    D'autres documents circulent sur ZFS, le système de fichier révolutionnaire de SUN. Tellement révolutionnaire que le support SUN ne préconise pas de l'installer sur les partitions systèmes de son OS mais juste pour les partitions de données... En gros ZFS est super robuste pour vos données mais pas pour notre Solaris ! il y a de quoi se poser des questions non ?
    Il y a quelques temps j'ai fait un bench sur le filesystem de base de Solaris 8. Le test consistait à copier une arborescence de fichiers HTML (22000 fichiers, plutôt petits). D'un côté une machine SUN V890 avec disques fibres channel ou SCSI 10000 tr/min, de l'autre une pauvre machine de bureau avec un Celeron 400 ou 600 et un disque IDE 5400tr/min sous Linux. Résultat 24 secondes sous Linux et.... 20minutes sous le "Most powerfull OS of the Universe" !!! Même aprés passage d'un consultant SUN sur la machine qui a mis la journée à tuner la machine, le meillieur résultat était de 8 minutes... optimisation par un patch qui annulait du coup le support SUN !!! Je rêve !

    • [^] # Re: MySQL sous le giron SUN

      Posté par  . Évalué à 1.

      J'adore les critiques.

      Peut-être est-ce plus long parce que c'est programmé en Java ?

      Si ca travaillait plus vite, la moitié de ta société serait au chomage. il faut pouvoir travaillé moins vite et donner la faute au hardware.


      Tu peux prendre plein d'examples en info. On passe plus de temps à attendre parce qu'on a developper Java, .Net, PHP pour que les programmeur travaille plus vite mais le produit final est moins rapide que c'il est developpez en C d'il y a 5 ans. Sans oublier que c'est pour notre bien (Ergonomie, option, Design, backup/restauration...)


      Mon Amstrad PC1512 (16 Mhz ?) demarrait plus vite, non ?

      • [^] # Re: MySQL sous le giron SUN

        Posté par  . Évalué à 1.

        mais le produit final est moins rapide que c'il est developpez en C d'il y a 5 ans

        Sauf que ton produit final écrit en C par le même genre de développeur médiocre aurait pris beaucoup plus de temps à développer, serait perclus de fuites de mémoire, de débordements de tampons, de plantages aléatoires, etc.

    • [^] # Re: MySQL sous le giron SUN

      Posté par  . Évalué à 3.

      Haaaa ! Le gros troll !
      Donc un OS est merdique parcequ'il ne virtualise pas NFS ... Sympa tes critères.
      D'ailleurs c'est même plus vrais en S10update3.

      Pour tes test de perf, tente avec une version de solaris 10 ou 9. Solaris 8 a plus de 8 ans... C'est un peu comme si tu test windows 98 au lieu de XP ou vista. Ou encore MNIS (yes, je l'ai casé) au lieu de Ubuntu 7.10

      En plus, ton test veut rien dire. 20 minutes de transfert pour qques fichiers, il y avait un pb de conf c'est sure. NFSv4 sature un lien gigabit en transfert entre 2 Solaris 10, je l'ai testé en lab.

    • [^] # Re: MySQL sous le giron SUN

      Posté par  (Mastodon) . Évalué à 3.

      Il n'y a plus qu'à espérer que SUN ne rende pas MySQL aussi merdique que leur système d'exploitation Solaris ! En interne SUN est dédaigneux envers tout ce qui n'est pas SUN pur. De nombreux mails de propagande sont envoyés aux clients vantant les mérite de Solaris par exemple "The most powerfull OS of the Universe" comme ils disent...


      J'utilises du solaris et je ne le trouve pas merdique du tout. Pas plus qu'un linux ou un bsd. Chacun a ses avantages et inconvénients. Pour ce qui est des mails, j'en reçois pas mais toutes les sociétés qui vendent du softwares font ça.

      Mais là où certains proposent de vraies solutions de virtualisations (Xen , KVM etc...) SUN ne propose que leurs Zones... Creusez un peu le sujet et vous verrez qu'avec les Zones vous ne ferez jamais de serveur NFS car la couche NFS n'a pas encore été développé ! Honteux de la part du "Most powerfull OS of the Universe" non ?


      Sun fait de la virtualisation : xVM [1]. C'est basé sur Xen. Il y'a aussi les logical domains sur les serveurs coolthreads

      D'autres documents circulent sur ZFS, le système de fichier révolutionnaire de SUN. Tellement révolutionnaire que le support SUN ne préconise pas de l'installer sur les partitions systèmes de son OS mais juste pour les partitions de données... En gros ZFS est super robuste pour vos données mais pas pour notre Solaris ! il y a de quoi se poser des questions non ?


      Ce n'est pas une question de robustesse. Solaris ne peut pas (encore) booter sur une partition root en ZFS. Mais bon Linux ni FreeBSD ne le peuvent non plus que je sache.

      Il y a quelques temps j'ai fait un bench sur le filesystem de base de Solaris 8.


      super ta comparaison avec un OS qui a 8 ans, dans un contexte bien particulier.

      [1] http://www.sun.com/software/products/xvm/index.jsp

      • [^] # Re: MySQL sous le giron SUN

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

        FreeBSD peut disposer de sa partition root sous ZFS : http://wiki.freebsd.org/ZFSOnRoot

        • [^] # Re: MySQL sous le giron SUN

          Posté par  . Évalué à 2.

          Mauvaise comparaison ? Que ce soir ext2 ou ext3, meme si je reprend un vieux Linux je suis quasi certain de faire mieux que Solaris8. Maintenant je veux bien que la machine ai un problème mais j'ai renouvelé l'expérience sur du V440 et autre: même problème. Mais ce qui est d'autant plus grave c'est que quelqu'un de SUN n'ai pu me proposer qu'une solution boiteuse à la fin de la journée à ce problème et qui annulait en plus le support de la machine auprès de SUN, trop fort non (et l'affaire est remonté bien haut chez SUN !) ?
          Quand à ZFS oui Solaris ne boot pas encore dessus mais alors pourquoi le support SUN préconise de ne l'utiliser sur AUCUNE partition système ? C'est que ZFS est trop jeune et que SUN laisse le soin au clients de se casser les dents dessus. Au passage si vous vous retrouvez avec des alertes mémoire remontées par vos outils de surveillance système, sachez que ZFS bouffe toute la mémoire qu'il peut, évidement il la libère si une appli en a besoin mais c'est ça affole quand meme les outils de surveillance.
          Je n'ai pas eu l'occasion de refaire le bench sur du ZFS, je ne doute pas que SUN s'est amélioré sur ce point... qu'il poursuive ses efforts sur son support !

          • [^] # Re: MySQL sous le giron SUN

            Posté par  . Évalué à 0.

            Merci pour tes quasi certitude, mais c'est pas avec des quasi certitudes qu'on peut dire qu'un OS est "merdique"

            Tu es tombé sur un mauvais mec de chez Sun. Ca existe partout et je te crois sans problème. Mais rien à voir avec l'OS.

            • [^] # Re: MySQL sous le giron SUN

              Posté par  . Évalué à 1.

              Méa culpa, le mot était un peu fort c'est vrai. Mais voir passer de la propagande comme ça en entreprise en cassant en plus du sucre sur le dos d'autres Unix ça me faisait penser aux pratiques de chez Microsoft...
              Les entreprises devraient être quand même être conscientes qu'il y a peut être mieux ailleur et ne pas prendre au pied de la lettre ce genre de messages trompeur !
              Le gros problème de Linux est qu'il n'y a jamais de visite de commerciaux au sein de l'entreprise pour promouvoir et défendre la solution de l'OpenSource (que les commerciaux des grosses compagnies ne se privent pas de dénigrer !).

          • [^] # Re: MySQL sous le giron SUN

            Posté par  . Évalué à 1.

            Il y a une sacré différence entre le terme "supporté" sous Linux et "supporté" par SUN pour Solaris hein!

        • [^] # Re: MySQL sous le giron SUN

          Posté par  (Mastodon) . Évalué à 2.

          Oui mais tu as quand même besoin d'un petit volume ufs (bon c'est pas la mort non plus)...

          le même genre de bidouille peut se faire aussi sous solaris depuis un petit moment (pour l'instant uniquement en x86). [1] [2]

          Le hic, c'est qu'à présent, il n'est pas possible d'installer l'OS (que ce soit fribi ou solaris) depuis l'installeur directement sur du ZFS, donc en attendant ça reste du bricolage.

          [1] http://blogs.sun.com/tabriz/category/ZFS
          [2] http://solaristhings.blogspot.com/2006/06/zfs-root-on-solari(...)

    • [^] # Re: MySQL sous le giron SUN

      Posté par  . Évalué à 1.

      TU REAGIS MAL !!!

    • [^] # Re: MySQL sous le giron SUN

      Posté par  . Évalué à 1.

      hahaha.

      (je ris ou je pleure.... ou je pleure de rire; a vous de décider)

  • # une bulle ?

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

    très difficile d'obtenir une estimation du chiffre d'affaires de Mysql mais il est certain que Sun a racheté Mysql à plus de 10 fois (1àà fois?) le chiffre d'affaire, très, très loin des ratio en cours sauf si on estime facebook à 15 milliards de dollars !
    bref, il me semble qu'on fonce dans la bull 2.0 mais tant mieux pour les fondateurs de Mysql qui démontrent par là même qu'on peut s'enrichir avec le libre

    • [^] # Re: une bulle ?

      Posté par  . Évalué à 1.

      bref, il me semble qu'on fonce dans la bull 2.0

      MySQL existe depuis beaucoup plus longtemps que Facebook et a un "business" sérieux et robuste. Je ne vois pas trop le rapport avec le Web 2.0, même si le prix d'acquisition est peut-être élevé.

      • [^] # Re: une bulle ?

        Posté par  . Évalué à 1.

        Enfin quelque chose de sérieux et robuste dans MySQL.

  • # Pilote JDBC

    Posté par  . Évalué à -4.

    Un petit peu HS mais est-ce que le type de valeur "Array' de MySQL est enfin supporté ?? Si toujours pas le cas peut être ce rachat facilitera grandement ce genre d'intégration.

    PS : Pas taper trop fort si je raconte n'importe quoi. ^^

Suivre le flux des commentaires

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