Journal Arrivée de Falcon dans MySQL

Posté par Dring le 03 janvier 2007 à 13:35.

Étiquettes : aucune

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 Dring le 03 janvier 2007 à 13:37. Évalué à 1.

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

Posté par patrick_g (site web personnel) le 03 janvier 2007 à 14:04. É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 Dring le 03 janvier 2007 à 15:48. É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 :-(
  - [^] # Re: questions
    
    Posté par Guillaume Smet (site web personnel) le 03 janvier 2007 à 17:47. Évalué à 5.
    
    Pour Postgresql, j'en sais rien :-(
    
    PostgreSQL implémente également un modèle MVCC, depuis très longtemps. Voir mon commentaire plus complet plus bas : http://linuxfr.org/comments/790027.html#790027 avec notamment la liste des SGBD(R) qui l'implémentent.
# les transactions ...

Posté par briaeros007 le 03 janvier 2007 à 14:04. É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 Anonyme le 03 janvier 2007 à 17:34. Évalué à 4.
  
  Ce commentaire a été supprimé par l’équipe de modération.
  - [^] # Re: les transactions ...
    
    Posté par Guillaume Smet (site web personnel) le 03 janvier 2007 à 17:44. Évalué à 3.
    
    > les tables MyIsam ne sont là que pour les applications légères qui n'ont pas besoin des avantages/inconvénients/fonctionnalités des transactions
    
    Sans oublier les "avantages/inconvénients/fonctionnalités" du moteur InnoDB car le moteur InnoDB a des inconvénients qui ne sont pas forcément dans les autres bases transactionnelles (et peut-être vice versa d'ailleurs).
  - [^] # Re: les transactions ...
    
    Posté par Gniarf le 04 janvier 2007 à 10:04. Évalué à -2.
    
    pour rappel, cette comparaison s'est faite assez démontée ici :
    
    http://developers.slashdot.org/article.pl?sid=06/12/18/11522(...)
    
    "Vague, unscientific and out of date"
    - [^] # Re: les transactions ...
      
      Posté par Gniarf le 04 janvier 2007 à 12:40. Évalué à 0.
      
      (repost) pour rappel, cette comparaison s'est faite assez démontée ici :
      
      http://developers.slashdot.org/article.pl?sid=06/12/18/11522(...)
      
      "Vague, unscientific and out of date"
- [^] # Re: les transactions ...
  
  Posté par Guillaume Smet (site web personnel) le 03 janvier 2007 à 17:42. É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 Philippe Makowski (site web personnel) le 03 janvier 2007 à 19:08. É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 Guillaume Smet (site web personnel) le 03 janvier 2007 à 20:59. É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 Philippe Makowski (site web personnel) le 04 janvier 2007 à 09:36. É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 Pooly (site web personnel) le 06 janvier 2007 à 11:17. É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 Tonton Th (Mastodon) le 07 janvier 2007 à 19:39. É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.