Pour stocker vos tables, MySQL utilise ce qu’on appelle un « moteur de stockage ». C’est ce moteur qui est chargé de définir comment vos données vont être stockés sur le disque, en mémoire, et surtout comment MySQL va y accéder (en lecture, mise à jour ou suppression). Les plus connus sont MyISAM et InnoDB. Seul ce deuxième est « transactionnel », c’est à dire qu’il peut permettre d’effectuer une série de mises à jour sur la base en même temps, ou annuler dse modifications. Mais le but de mon billet n’est pas d’expliquer tout cela, mais d’aller bien plus loin et de vous dire comment Falcon fonctionne globalement.

!!!! Pourquoi un nouveau moteur ? MySQL AB, la société qui édite le gestionnaire de base de données homonyme, est en pleine expansion. La notoriété du logiciel est maintenant telle que la société a pu développé de nouveaux services et souhaite aller encore plus loin dans le monde des SGBD. Sa gratuité en est une grande force, sans remettre en cause sa stabilité et sa sécurité (depuis la version 5 seulement ! je ne me permettrais pas d’écrire « stabilité » et « mysql 4 » dans la même phrase). Quoi qu’il en soit, MySQL repose sur des formats de stockage particuliers. De manière historique MyISAM mais qui malheureusement a maintenant montré ses limites en performance, notamment écriture. De plus, ce format n’est pas transactionnel et n’a aucun support des clefs étrangère, ce qui est une énorme lacune face à la concurrence, notamment le puissant Oracle. Le moteur InnoDB est lui transactionnel et a permis de combler ce fossé de performance. Ce moteur est maintenant largement utilisé et sa stabilité reconnu. Ce n’est pas pour rien que Oracle a racheté InnoBase, la société créatrice de InnoDB. C’est suite à ce rachat que MySQL AB a commencé à se poser des questions : si son moteur phare est maintenant propriété d’un concurrent, comment assurer la survie du logiciel à long terme ? Même si des accords ont été signés entre MySQL AB et Oracle, il est devenu clair et indispensable à MySQL AB de développer son propre moteur en interne. C’est ainsi que Falcon est né, du moins sur le papier.%%% !!!!Buts de Falcon Les principaux objectifs de Falcon sont clairs : * Un moteur qui gère le transactionnel avec toutes les spécifications qu’on attend d’un tel moteur (rollback, commit, clés étrangères, etc.) * Un moteur qui sache s’adapter à la demande et au matériel sur lequel il tourne pour en tirer le meilleur (selon la mémoire, le nombre de CPU, etc.) * Et bien sûr, être un moteur indépendant et propre à MySQL AB pour ne pas dépendre de technologies externes à la société. .%%% !!!!Les points forts Que demande-t-on à un moteur de stockage ? Cela tient en fait en deux critères : * Stabilité : il est important que le moteur ne perde pas de données, même en cas de plantage ou autre. Dans le cas d’un plantage soudain, le moteur doit permettre de retrouver l’intégralité des données intactes moins les dernières données qui aient pu être écrites avant le crash. * Performance : le moteur doit être performant dans la majorité des cas, voir tout le temps. Falcon a été développé dans cette optique. .%%% !!!!Du cache de partout Pour pouvoir servir les données rapidement, il est important de mettre en cache un maximum de données, en se rappelant que plus il y a de données en cache et plus il sera long de lire ce dernier. Le cache est donc avant tout la recherche du meilleur compromis possible (c’est pareil pour les index à un autre niveau !). Falcon implémente plusieurs niveaux de cache : * Un cache de ligne * Un cache de « pages » (un ensemble de lignes) * Un cache de log * Un cache système (entre le logiciel et le matériel, principalement le disque dur) Note : Pour l’instant, les perfs de Falcon sont très en deça des attentes. N’oublions pas qu’il s’agit d’une version alpha, et qu’il faudra donc attendre des versions quasi définitives avant de juger. [Un benchmark InnoDB / MyISAM / Falcon|http://www.mysqlperformanceblog.com/2007/01/08/innodb-vs-myisam-vs-falcon-benchmarks-part-1/|en] .%%% !!!!Gestion des tables et indexes Le moteur Falcon permet de stocker un nombre illimité de lignes. La version alpha actuelle posssède juste une limite (provisoire donc) à 4 milliards de ligne ce qui devrait être suffisant pour la majorité d’entres vous. Il gère également les index auto-incrémentés, même si je rappelle que cette specification ne fait pas vraiment partie du standard (Oracle utilise par exemple des compteurs à part). Comme tout bon moteur transactionnel, le support des clés étrangères est également de la partie mais malheureusement pas encore disponible au moment où j’écris. Le stockage physique est différent des autres moteurs, le comportement est donc différent. Par exemple, le stockage n’est pas fait selon la clef primaire. Ainsi, si vous faites un SELECT sans clause ORDER BY, les enregistrements ne seront pas forcément retournés par ordre ascendant de la clef primaire. Autre point, Falcon ne supporte pas le type FULLTEXT. C’est la même limitation que InnoDB. Il est dommage que ces moteurs transactionnels ne supportent pas cette caractéristique, ou ne développe les mêmes fonctionnalités.