Base de donnée
Un petit tour d'horizon des forks de Mysql, motivé par son rachat par Oracle et les polémiques déclenchées par la gestion "propriétaire" des bugs.
Drizzle
Drizzle (bruine, en VF) a été crée au moment de l'apparition des procédures stocké dans Mysql et des cafouillages qui ont suivi. Il est basé sur la version 6 de Mysql, mi 2008. Drizzle défends l'idée d'un Mysql simple et résiliant, servant de socle à de grosses applications dans le cloud. Ils conservent une compatibilité au niveau du protocole mais fait le ménage à la hache dans les fonctionnalités exotiques, comme les différents charsets ou les requêtes multiples. Le code a été refactorisé et utilise Boost. Il prône l'usage d'un C++ standard. l'architecture basé sur un micro kernel et un ensemble de plugin, facilitant les essais (stratégie d'exécution de requêtes, authentification, gestion d'événements) et permet aussi de composer son serveur selon son usage. La réplication utilise un format neutre permettant de récupérer les données dans d'autres bases. Un gros travail a aussi été effectué sur la partie cliente et leur API permet même de suivre les événements binlogs (utilisés par la réplication).
MariaDB
MariaDB est un fork de Mysql, crée par un de ses fondateurs, Monty, qui a pris sa part d'argent lors du rachat, puis fait un fork mesquin, dans le but de proposer un produit avec une licence clair. Le nom est un hommage à sa fille. MariaDb propose diverse amélioration dont un nouveau moteur de persistance, Aria, débuté en 2007, qui a pour but de remplacer myISAM comme stockage par défaut. Aria ne gère pas encore les transactions, mais se veut plus résiliant aux crashs que MyISAM. Il est utilisé en interne pour tout ce qui est table temporaire et apporte ainsi un gain de performance non négligeable pour les requêtes complexes nécessitant l'usage de tables temporaires. MariaDB intègre aussi XtraDB à la place d'Innodb, et, inversement, PerconaDB propose Aria comme stockage possible.
Wikipedia est en train de faire la migration de Mysql vers MariaDB, et Drupal le supporte officiellement.
PerconaDB
Percona est le leader du consulting Mysql, connu pour son blog, Mysql performance blog , son livre, High Performance Mysql et sa suite d'outil d'analyse et de sauvegarde . Ils ont aussi forké InnoDB, le moteur transactionnel de Mysql pour en faire XtraDB, et en ont profité pour proposer une version patché de Mysql avec leur XtraDB : PerconaDB .
TokuDB
TokuDB est un peu à part dans cette série, issu de la recherche, ils proposent un moteur de stockage propriétaire basé sur les index fractals. Optimisé pour les gros débits d'écritures, les grosses volumétries, il prends en compte les spécificité du stockage sur SSD. Supportant officiellement Mysql et MariaDB ils ont aussi porté leur index pour Mongodb. J'attends de voir apparaitre des implémentations libres des fractals trees qui résolvent les soucis de réecritures constantes des B-trees pour conserver l'ordonnancement.
NoSQL
RethinkDB
Un petit nouveau dans la jungle des serveurs NoSQL, rethinkDB , vient de sortir, bien qu'il ait déja 3 ans. Pour résumer, on pourrait le qualifier de MongoDB qui aurait pris le temps de réfléchir. Base orienté documents JSON, il propose une réplication master/slave garantissant une cohérence des données, avec un seul nœud responsable d'un shard. Un cas de perte d'un master, on commence à avoir des soucis en écriture, jusqu'à ce que l'on promeuve un nouveau maitre. Le théorème CAP est intransigeant.
Étrangement, RethinkDB ne propose pas pour l'instant d'index secondaire ou composé, faisant confiance à l'efficacité de ses requêtes et à la dénormalisation.
Grosse différence avec Mongodb, il n'utilise pas de javascript pour effectuer les requêtes. L'API met en valeur un système de fonctions chainés spécifiques à chacun des langages, qui sera ensuite traité sur le serveur en parallélisant au maximum le travail (entre les nodes et les CPUs). Concrètement, le langage hôte expose une API native, qui, transformé en AST est transféré sur le serveur qui l'exécute. On évite le double saut périlleux traditionnels ORM->SQL->AST->exécution. Il y a aussi un langage de requêtes, le ReQL. Aurait-on atteint le Graal de la base orienté objet?
Comme toute base NoSQL qui se respecte, elle est orienté devops et propose une jolie interface HTTP, la réplication inter-site et même une astuce pour backuper : on crée un datacenter (un groupe de noeuds, dans leur jargon) d'une seule machine, que l'on éteint, rsync, puis rallume.
Je ne sais pas si il faut à tout prix se précipiter sur ce nouveau jouet, mais il est toujours plaisant de voir comment ils ont résolus des problèmes d'autres produits et de voir comment ils vont évoluer.
Daemon
Un petit tour des outils pour gérer des applications tournants sur un serveur. On est habitué à avoir ce travail effectué par le serveur Web, mais les besoins évoluent et il est de plus en plus courant d'avoir des applications en productions qui ne soit pas un service web. Cette notion est très compliqué pour les développeurs PHP traditionalistes qui font tous les sauts périlleux possibles pour contourner ça et se retrouver dans un contexte http. La contraintes des hébergements mutualisés les pousse à faire ça, mais la virtualisation et les containers légers commencent à détrôner le choix manichéen dédié/mutualisé.
La deuxième réponse spontané pourrait être le cron (avec un wget pour les plus traditionaliste) ou les serveurs de taches pour les plus enthousiastes. La réponse est en fait bien plus simple, et c'est l'un des piliers fondateurs d'UNIX. Un process va lancer des fils et les relancer si ils se vautrent. Les workers se débrouillent ensuite avec une seul boucle infinie (la tendance du moment), des threads, une boucle événementiel, ou un mix de tout ça. Le superviseur va en profiter pour gérer différents utilisateurs pour les services et proposer un script de boot pour que le service démarre et s'arrête avec le serveur. Un de ses outils historiques est le violent daemon-tools, mais une approche plus fine, spécifique à chaque langage est plutôt la tendance actuelle.
Python propose le traditionnel et massif supervisord , mais il existe aussi pistil qui est en fait un gunicorn sans la partie spécifique http ou gaffer qui propose un ensemble d'outils asynchrones.
Nodejs est un peu martyrisé, il ne propose que forever qui a oublié la possibilité de changer l'utilisateur.
Ruby est foisonnant et propose par exemple bluepill et god , foreman , mais avec une préférence vers des outils complets comme resqueue et SideKiq .
Ces outils permettent de lancer des workers dans une boucle infinie, il faut ensuite leur confier du travail. Certaines fonctions commencent à apparaitre, comme une url de ping, pour faciliter le monitoriing, des stats d'utilisation, l'abattage de process qui flippe, et l'ajout/retrait de workers.
Une fois lancé, ces workers peuvent écouter des événements, une simple socket, ou utiliser un pubsub ou des outils plus lourd de traitement de taches comme RabbitMQ. Il existe des outils spécialisé dans le traitement de taches (distribués, pour la plupart) comme Celery , SideKiq ou Beanstalk plus historique. Ces outils commencent à s'intégrer aux serveurs web, comme Rails4, pour partager configurations et contexte. Celery est conçu pour travailler avec Django et propose moult connecteurs pour différents serveurs de taches (RabbitMQ, Redis voir même Postgres). C'est assez ironique de voir apparaitre ce genre d'outil qui sont en fait une des briques de base d'Erlang OTP. Il faut aller lire les articles de bitly, ainsi que leur nsq , qui a fondé toute son architecture sur de simple liste de messages et de pub/sub. Les plus acharné iront voir Storm ou Kafka , outils indispensable pour gérer des quantités titanesques de données.
En bref, les architectures webs s'orientent tranquillement vers la notion de services, avec des produits tout fait (ElasticSearch, Redis...) ou specifique (REST ou non) avec une arrivée discrète et indispensable de l'asynchrone. Pour ne pas rendre fou les admins, il faut que les dits services soit monitorables, polis, et suivent le cycle de vie du serveur.
