Pour stocker vos tables, MySQL utilise ce qu’on appelle un \u00ab\u00a0moteur de stockage\u00a0\u00bb. C’est ce moteur qui est charg\u00e9 de d\u00e9finir comment vos donn\u00e9es vont \u00eatre stock\u00e9s sur le disque, en m\u00e9moire, et surtout comment MySQL va y acc\u00e9der (en lecture, mise \u00e0 jour ou suppression). Les plus connus sont MyISAM et InnoDB. Seul ce deuxi\u00e8me est \u00ab\u00a0transactionnel\u00a0\u00bb, c’est \u00e0 dire qu’il peut permettre d’effectuer une s\u00e9rie de mises \u00e0 jour sur la base en m\u00eame 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.
\n
\n!!!! Pourquoi un nouveau moteur ? MySQL AB, la soci\u00e9t\u00e9 qui \u00e9dite le gestionnaire de base de donn\u00e9es homonyme, est en pleine expansion. La notori\u00e9t\u00e9 du logiciel est maintenant telle que la soci\u00e9t\u00e9 a pu d\u00e9velopp\u00e9 de nouveaux services et souhaite aller encore plus loin dans le monde des SGBD. Sa gratuit\u00e9 en est une grande force, sans remettre en cause sa stabilit\u00e9 et sa s\u00e9curit\u00e9 (depuis la version 5 seulement ! je ne me permettrais pas d’\u00e9crire \u00ab\u00a0stabilit\u00e9\u00a0\u00bb et \u00ab\u00a0mysql 4\u00a0\u00bb dans la m\u00eame phrase). Quoi qu’il en soit, MySQL repose sur des formats de stockage particuliers. De mani\u00e8re historique MyISAM mais qui malheureusement a maintenant montr\u00e9 ses limites en performance, notamment \u00e9criture. De plus, ce format n’est pas transactionnel et n’a aucun support des clefs \u00e9trang\u00e8re, ce qui est une \u00e9norme lacune face \u00e0 la concurrence, notamment le puissant Oracle. Le moteur InnoDB est lui transactionnel et a permis de combler ce foss\u00e9 de performance. Ce moteur est maintenant largement utilis\u00e9 et sa stabilit\u00e9 reconnu. Ce n’est pas pour rien que Oracle a rachet\u00e9 InnoBase, la soci\u00e9t\u00e9 cr\u00e9atrice de InnoDB. C’est suite \u00e0 ce rachat que MySQL AB a commenc\u00e9 \u00e0 se poser des questions : si son moteur phare est maintenant propri\u00e9t\u00e9 d’un concurrent, comment assurer la survie du logiciel \u00e0 long terme ? M\u00eame si des accords ont \u00e9t\u00e9 sign\u00e9s entre MySQL AB et Oracle, il est devenu clair et indispensable \u00e0 MySQL AB de d\u00e9velopper son propre moteur en interne. C’est ainsi que Falcon est n\u00e9, du moins sur le papier.%%% !!!!Buts de Falcon Les principaux objectifs de Falcon sont clairs : * Un moteur qui g\u00e8re le transactionnel avec toutes les sp\u00e9cifications qu’on attend d’un tel moteur (rollback, commit, cl\u00e9s \u00e9trang\u00e8res, etc.) * Un moteur qui sache s’adapter \u00e0 la demande et au mat\u00e9riel sur lequel il tourne pour en tirer le meilleur (selon la m\u00e9moire, le nombre de CPU, etc.) * Et bien s\u00fbr, \u00eatre un moteur ind\u00e9pendant et propre \u00e0 MySQL AB pour ne pas d\u00e9pendre de technologies externes \u00e0 la soci\u00e9t\u00e9. .%%% !!!!Les points forts Que demande-t-on \u00e0 un moteur de stockage ? Cela tient en fait en deux crit\u00e8res : * Stabilit\u00e9 : il est important que le moteur ne perde pas de donn\u00e9es, m\u00eame en cas de plantage ou autre. Dans le cas d’un plantage soudain, le moteur doit permettre de retrouver l’int\u00e9gralit\u00e9 des donn\u00e9es intactes moins les derni\u00e8res donn\u00e9es qui aient pu \u00eatre \u00e9crites avant le crash. * Performance : le moteur doit \u00eatre performant dans la majorit\u00e9 des cas, voir tout le temps. Falcon a \u00e9t\u00e9 d\u00e9velopp\u00e9 dans cette optique. .%%% !!!!Du cache de partout Pour pouvoir servir les donn\u00e9es rapidement, il est important de mettre en cache un maximum de donn\u00e9es, en se rappelant que plus il y a de donn\u00e9es 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 \u00e0 un autre niveau !). Falcon impl\u00e9mente plusieurs niveaux de cache : * Un cache de ligne * Un cache de \u00ab\u00a0pages\u00a0\u00bb (un ensemble de lignes) * Un cache de log * Un cache syst\u00e8me (entre le logiciel et le mat\u00e9riel, principalement le disque dur) Note : Pour l’instant, les perfs de Falcon sont tr\u00e8s en de\u00e7a des attentes. N’oublions pas qu’il s’agit d’une version alpha, et qu’il faudra donc attendre des versions quasi d\u00e9finitives 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\u00e9 de lignes. La version alpha actuelle posss\u00e8de juste une limite (provisoire donc) \u00e0 4 milliards de ligne ce qui devrait \u00eatre suffisant pour la majorit\u00e9 d’entres vous. Il g\u00e8re \u00e9galement les index auto-incr\u00e9ment\u00e9s, m\u00eame si je rappelle que cette specification ne fait pas vraiment partie du standard (Oracle utilise par exemple des compteurs \u00e0 part). Comme tout bon moteur transactionnel, le support des cl\u00e9s \u00e9trang\u00e8res est \u00e9galement de la partie mais malheureusement pas encore disponible au moment o\u00f9 j’\u00e9cris. Le stockage physique est diff\u00e9rent des autres moteurs, le comportement est donc diff\u00e9rent. 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\u00e9ment retourn\u00e9s par ordre ascendant de la clef primaire. Autre point, Falcon ne supporte pas le type FULLTEXT. C’est la m\u00eame limitation que InnoDB. Il est dommage que ces moteurs transactionnels ne supportent pas cette caract\u00e9ristique, ou ne d\u00e9veloppe les m\u00eames fonctionnalit\u00e9s.<\/p>\n","protected":false},"excerpt":{"rendered":"
Pour stocker vos tables, MySQL utilise ce qu’on appelle un \u00ab\u00a0moteur de stockage\u00a0\u00bb. C’est ce moteur qui est charg\u00e9 de d\u00e9finir comment vos donn\u00e9es vont \u00eatre stock\u00e9s sur le disque, en m\u00e9moire, et surtout comment MySQL va y acc\u00e9der (en lecture, mise \u00e0 jour ou suppression). Les plus connus sont MyISAM et InnoDB. Seul ce deuxi\u00e8me est \u00ab\u00a0transactionnel\u00a0\u00bb, c’est \u00e0 dire qu’il peut permettre d’effectuer une s\u00e9rie de mises \u00e0 jour sur la base en m\u00eame 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.<\/p>\n","protected":false},"author":3,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[6],"tags":[36],"class_list":["post-36","post","type-post","status-publish","format-standard","hentry","category-php-sql","tag-mysql"],"yoast_head":"\n