Journal Arrivée de Falcon dans MySQL

Posté par  .
Étiquettes : aucune
0
3
jan.
2007
Qu'ouïs-je ? Qu'entends-je ? N'est-ce point là le buzz caractéristique entourant une nouvelle porteuse de moult espoirs ?

Jim Starkey vient de rendre public la première version alpha de Falcon, un moteur de stockage dédié à MySQL (uniquement disponible sur un fork de la version 5.1).

C'est pas moi qui le dit, c'est Slashdot (http://it.slashdot.org/it/07/01/02/209227.shtml).

Pour ceux qui ne savent pas, Jim est connu pour avoir créé Interbase, puis participé à la réécriture de FirebirdSQL, la version opensource d'Interbase.

Voici enfin venu le temps d'un MySQL riche en fonctionnalités, sans les bridages actuels (oui, je sais, les perfs s'en sortent mieux comme ça).

Il a manifestement repris un des fondements d'Interbase : le versionning d'enregistrement, qui permet de conserver plusieurs versions d'une ligne, une par transaction en cours. Cela limite les phénomènes de verrou fatal ("deadlock").

Bref, la gestion des transactions dans MySQL, dans pas longtemps, ça va roxer grave sa race.
  • # Falcon / Firebird

    Posté par  . Évalué à 1.

    Tiens, j'avais pas fait le lien. Encore un nom d'oiseau !
  • # questions

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

    Ce Jim Starkey il travaille pour la boite derrière MySQL ou est-il indépendant ?
    C'est un fork de la base MySQL ou pas ?
    Ce versionning d'enregistrement est-il déjà dispo dans PostgreSQL ou est-ce une exclusivité de Falcon ?
    • [^] # Re: questions

      Posté par  . Évalué à 6.

      Ce Jim Starkey il travaille pour la boite derrière MySQL ou est-il indépendant ?

      Il a été embauché par MySQL AG.

      C'est un fork de la base MySQL ou pas ?

      C'est un fork "temporaire", le temps que le moteur soit considéré comme suffisamment stable.

      Ce versionning d'enregistrement est-il déjà dispo dans PostgreSQL ou est-ce une exclusivité de Falcon ?

      Ce n'est pas une exclusivité, mais ce n'est pas non plus le choix fait par l'ensemble des SGBDR. Sybase & Microsoft ne l'ont pas par exemple. Oracle l'a. Pour Postgresql, j'en sais rien :-(
  • # les transactions ...

    Posté par  . Évalué à 3.

    postgresql les fait pas déja ?

    Il y aurait pas un site qui explicite de facon clair en gros les différentes fonctionnalités entre postgresql , mysql, db2 et oracle ?
    (/me ne cherche pas a lancer un troll : les gens utilisent la bd qu'ils préfèrent , et c'est leurs choix)
    • [^] # Commentaire supprimé

      Posté par  . Évalué à 4.

      Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Re: les transactions ...

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

      Le mot magique n'est pas transaction. Le mot magique est versioning des lignes : c'est la grosse nouveauté apporté par ce moteur. PostgreSQL implémente un modèle MVCC (multi version concurrency control) depuis très longtemps (ca a été ajouté entre la 6 et la 7, ca a toujours été le cas dans la branche 7 en tout cas donc déjà en 2000).
      Le principe est d'avoir plusieurs versions de la même ligne afin de permettre à des transactions différentes d'avoir une vue différente de la base.
      Les implémentations peuvent être assez différentes suivant les bases : Oracle utilise un undo log pour gérer cela (d'après mes lectures, jamais utilisé Oracle), PostgreSQL conserve toutes les versions jusqu'à un VACUUM qui supprime les versions plus vieilles que la plus ancienne des transactions.

      Pour information :
      http://www.pervasive-postgres.com/instantkb13/article.aspx?i(...)
      http://en.wikipedia.org/wiki/Multiversion_concurrency_contro(...)

      C'était un _gros_ manque de MySQL et ça l'est toujours en attendant d'avoir une version stable l'implémentant.
      • [^] # Re: les transactions ...

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

        et Firebird fait ça depuis toujours ;)

        ce n'est pas un fork, c'est un nouveau type de gestion de données pour Mysql qui s'ajoute à la longue liste en plus de MyIsam, InnoDB, ...

        et Jim est employé par MySQL AB pour ce projet, c'est une reprise partielle de choses qu'il avait écrites dans son produit Netfrastructure qu'il a vendu à MySQL AB

        mais il y a d'autres nouveautés dans Falcon

        et voilà ce qu'en dit Jim :
        "Architecturally, Falcon is a clean sheet of paper relative to Interbase
        / Firebird. Index scans are highly similar, but that's about that.
        Much of the difference comes from Falcon designed as a single process
        engine rather than the cluster-friendly Interbase model. Once you give
        up the idea that the database must be sharable at the file / lock level,
        all of the design considerations change.

        I'd be delighted to discuss at length why I did one thing in Interbase,
        another in Vulcan, and third in Falcon.

        Oh, Falcon beats both InnoDB and MyIsam for retrieval operations. The
        jury is still out on update operations (a couple of important
        performance features aren't in the Falcon alpha). I probably shouldn't
        talk about that, yet."
        • [^] # Re: les transactions ...

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

          et Firebird fait ça depuis toujours ;)


          Et a aussi des inconvénients :). Le but n'était pas de troller sur qui était preum's, juste de répondre à la question par rapport à PostgreSQL. Le lien de wikipedia reprend toute la liste des bases supportant MVCC et Interbase était effectivement une des premières à l'implémenter.

          ce n'est pas un fork, c'est un nouveau type de gestion de données pour Mysql qui s'ajoute à la longue liste en plus de MyIsam, InnoDB, ...


          Oui, oui, je connais le fonctionnement du moteur MySQL. Ce que je voulais signaler, c'est le fait que c'est à conjuguer au futur. Il _va_ s'ajouter à la liste quand il sera stable. MySQL AB a un peu tendance à faire du marketing bien avant qu'une fonctionnalité soit dans une version stable.
          Même après l'intégration dans une version stable, il se passera un petit moment avant que ce backend soit vraiment considéré comme production ready (résistance aux pannes, scalabilité, traitement de requêtes complexes...).

          Je suis curieux de voir ce que cela va donner en terme de scalabilité, de performances et de sécurité des données. Je n'aime pas MySQL pour plein d'autres raisons que les problèmes avec les moteurs actuels donc ça ne me fera pas abandonner ma préférence pour PostgreSQL mais c'est toujours intéressant de jeter un oeil sur un petit nouveau.
          • [^] # Re: les transactions ...

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

            oui au futur, c'est certain
            MySQL semble compter vraiment sur Falcon
            mais connaissant Jim, il va faire du très bon boulot sur l'architecture, c'est certain, mais après je souhaite bon courage aux gens de MySQL quand il s'agira de vraiment passer en prod et modifier les bugs laissés par Jim et traiter avec son sale caractère, j'espère pour eux qu'ils ont aussi embauché des diplomates ;)
  • # Un peu de lecture

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

    Bref, la gestion des transactions dans MySQL, dans pas longtemps, ça va roxer grave sa race.


    Donc d'après toi MySQL rox déjà des ours parce que des moteurs gérant les transactions il y en a déjà deux dans MySQL : InnoDB et BDB. BDB a été rendu obsolète il n'y a pas très longtemps, mais InnoDB tourne sans problème.
    http://dev.mysql.com/doc/refman/5.1/en/storage-engine-overvi(...)

    Pour les "bridages" actuels de MySQL, tu peux me les rappeller ? Triggers/procédures stockés/transaction tout celà est déjà dans MySQL 5.0...
    Les vieux trolls ont la peau dure.
  • # WinFS ?

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

    Bref, la gestion des transactions dans MySQL, dans pas longtemps, ça va roxer grave sa race.

    Euh, comment dire, ça fait bien cinq ans qu'on entend dire ça, non ?

Suivre le flux des commentaires

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