MySQL est l’un des systèmes de bases de données relationnelles les plus utilisés dans des projets de petite et moyenne envergure. Sa gratuité et sa simplicité d’installation, de maintenance, sa simplicité d’utilisation ainsi que sa communauté sont des arguments principaux de ce système.

Son plus gros problème reste que s’il est parfaitement adapté à un projet de petite / moyenne envergure, il est rapidement écarté pour de plus gros projets à cause de la difficulté d’installation / administration d’un cluster MySQL par des utilisateurs non aguerris.

D’autres difficultés arrivent également avec la montée en popularité d’une application utilisant MySQL, soit les clusters deviennent suffisamment conséquents pour être difficilement gérables, soit l’application contient trop de données, et un sharding doit être envisagé. Sharding qui, sous MySQL de base, doit se faire le plus souvent au sein de l’application elle-même.

En clair, MySQL est parfaitement adapté à de petits projets, mais lorsqu’on en vient à s’appuyer dessus pour un projet en production et à forte expansion, on est vite débordés, et c’est ici que Vitess entre en jeu.

 

Vitess est un système entamé en 2010 par Youtube afin de répondre aux problèmes de scalabilité qu’ils rencontraient avec MySQL, puis publié sous licence Open Source (CC-BY-4.0). Le projet a reçu la certification CNCF, car s’insérant parfaitement dans un contexte d’exécution et de management Kubernetes. Le projet est utilisé dans des entreprises comme Youtube, Slack, GitHub, Weave, Better Cloud et Pinterest, pour n’en citer que quelques-uns.

La topologie de Vitess est simple : le serveur est composé d’un daemon, chargé de recevoir les connexions SQL, de les traiter et de les proxiser, traitées, au bon serveur MySQL sous-jacent. Vitess est donc un proxy MySQL capable de faire de l’optimisation à la volée,  ainsi que du sharding, le tout en un temps minimal pour des performances spectaculaires.

Les principaux arguments de Vitess sont une gestion facilitée, apportant des fonctionnalités de failover et de réplication automatique, de performance, en optimisant automatiquement les requêtes les plus gourmandes avant de les passer à MySQL, ainsi qu’en permettant un « Connection Pooling » au-dessus de MySQL, et de scalabilité en abstrayant la notion de sharding, inexistante dans MySQL de base et qui, nous serons d’accord, n’a rien à faire en dur dans une application, car « on ne va quand même pas rendre notre application dépendante de la topologie de la base de données, n’est-ce pas ? »

Il est possible de déployer Vitess de trois façons principales :

  • Local (bare metal) : installation de Vitess sur un cluster de serveurs, mise en cluster manuelle
  • Docker (« bare docker »)
  • Kubernetes (helm) : déploiement d’un cluster automatique avec Helm. L’intérêt n’est pas à prouver pour quiconque utilise Kubernetes au quotidien. On peut même imaginer créer un cluster qui grossirait de lui-même avec les besoins de son application…

 

Le projet propose sur son site plusieurs exemples de quickstart pour chacune des solutions d’installation. N’hésitez pas à aller y jeter un œil !

Julien Pontillo