VT2017 Vitess
Présentation
- Sujet : Vitess
- Auteur : Oriane Dalle
- Enseignants : Didier Donsez, Georges-Pierre Bonneau
- Date : 29/09/2017
Résumé
Les bases de donnée des sites web deviennent de plus en plus importants, cela entraîne des complications comme la perte de performance lors d'appel de requête mais aussi la gestion de la base devient de plus en plus ingérable. Vitess est une solution open-source qui est développé depuis 2011 par Youtube et qui est en pleine croissance, qui permet de mettre à l'échelle une base de donnée MySQL, ce qui lui permet de rester performante et gérable. Elle regroupe les grands avantages du MySQL en y alliant la mise à l'échelle du NoSQL. Cela se base sur un découpage de la base de données de façon organisé sur des serveurs et aussi sur une topologie de la base de données qui permet de mieux orienter les requêtes. D'autres outils de gestion de base de données sont également proposé afin de facilité la gestion d'un base de données.
Abstract
Databases and web sites were more and more oversized as a result it loses performance when calling query but also the manageability becomes more and more unmanageable. Vitess is an open source project developed since 2011 by Youtube and is actually in a state of growth. Its a database clustering system for horizontal scaling of MySQL in order to improve te performance and the manageability. It has the advantages of MySQL combining the scalability of the NoSQL. It is based splitting and storing a single logical dataset in multiple databases including a topology of the splitting so as to guide query and improve the performances. Other troubleshooting was developed to facilitate management of databases.
Synthèse
Cette partie a pour but de présenter les aspects générals de Vitess ainsi que d'expliquer quelques points techniques utilisés pour ca mise en place.
Contexte
Vitess est un projet open-source qui a vu le jour, grâce à Sugu Sougoumarane et Mike Solomon, en 2011 suite à l’expansion de YouTube. La taille de la base de donnée de Youtube ainsi que le nombre de connexion journalière étaient devenu trop important pour assurer la performance de la base de données et la gérer convenablement.
Deux solutions s'offraient à eux : Faire de la "scalabilité verticale" ou de la "scalabilité horizontale".
La scalabilité verticale revient à acheter une machine encore plus puissante afin de pouvoir gérer plus de données et plus de requêtes. Cette solution a évidement des limites visibles. La deuxième solution, qui est celle de Vitess, est la scalabilité horizontale, utilise le "Sharding" ou autrement dit la "distribution des données". Cette technique vise à repartir la base de données sur plusieurs machines de façon ordonné afin de mieux rediriger les requêtes faites sur la base. De cette façon Vitess à pu augmenter 50 fois la taille de la base de donnés de Youtube, tout en la rendant plus facilement administrable.
Differences avec le MySQL
Vitess reprend les grandes lignes de MySQL avec quelques améliorations.
Dans un premier temps les connexions entre les nœuds de la base de données ont étaient allégés avec l’utilisation du protocole gRPC et de Go (langage de programmation servant à mapper les connexions). Vitess a également intégré un système d’analyse de requêtes SQL qui permet de vérifier avant chaque envoie de requête si elle ne va pas endommager la base de données et si elle va pouvoir aboutir. De plus comme je l’ai dis précédemment Vitess support le sharding, ce qui n’est pas le cas du MySQL natif. Le sharding permet de mettre à l’échelle notre base de données quand elle est devenu trop grande pour une machine, en MySQL cela est possible uniquement si l’on le gère manuellement, avec Vitess cela est gérer automatiquement mais on a encore la possibilité de le gérer sois même, si le cœur nous en dis. Enfin Vitess gère lui meme le cycle de vie de la base de donnée alors que en MySQL il faut gérer nous même les répliques de notre base afin qu’elle soit à jour en cas de panne de la base principale.
Differences avec le NoSQL
Vitess reprend les avantages de mise à l’échelle du NoSQL mais tout en restant très different.
Pour commencer Vitess fonctionne avec des requêtes SQL complexes, comme des fonctions d’agrégations, alors que le NoSQL ne supporte pas ce type de requêtes. Une autre difference importante est que Vitess prend en charge les transactions, une transaction est une suite d'operations qui font passer la base de données d'un état A à un état B, alors que le NoSQL ne les supporte pas. Enfin Vitess reprend deux principes du MySQL qui sont totalement differents du NoSQL. Tout d'abord l’impossibilité de modifier le comportement de l'API, cela dans le but de garder base de donnée au quel les utilisateurs sont habitués. Enfin une possibilité d'indexation assez puissante qui permet d’améliorer la performance lors de l'envoie de requêtes.
Sharding
Vitess utilise un système de sharding afin d'organiser les bases de données et les rendre plus performantes et plus facilement gérables.
- Mais le sharding c'est quoi exactement ?
Comme je l'ai dis précédemment le Sharding est aussi appelé distribution de données. C'est une méthode de mise à l'échelle visant à diviser les données de façon ordonnée afin de gagner en performance lors d'appel à la base de données. Les donnés ne sont plus stockées sur un seul serveur mais sur un cluster de serveurs. Il existe deux types de sharding, le sharding horizontal qui consiste à séparer une table de données dans deux serveurs différents, et le sharding vertical qui consiste à stocker différentes tables dans différents serveurs.
- En quoi cela rend la base de donnée plus performante ?
En plus de diviser la base de donnés il faut aussi mettre en place une topologie qui va permettre de savoir exactement ou chaque donnée est rangée. De cette façon à chaque requête on aura une sur-couche qui va orienter les requêtes sur le serveur concerné.(cf : Architecture)
- Quand utilise-t-on le sharding ?
On utilise cette méthode lorsque une base de données est devenu trop grande pour être stockée sur une seul et même machine. Il existe d'autre moyen de mettre à l’échelle ca base de données mais ces méthodes sont moins pérenne dans le temps, surtout si l’extension de la base de données est importante
Architecture
On peut voir sur le schéma de l'architecture les différentes parties de la base de donnée stockées sur des serveurs différents. Chaque bout de base de données possède un vttablet, sur le même serveur, c'est lui qui va gérer la lecture des requêtes et les refuser si elles sont potentiellement dangereuses pour le système.
Juste au dessus on retrouve le vtgate c'est un serveur 'statless', sans état, qui va s'occuper de router les requêtes vers le bon serveur. Comme il est sans état on peut en déployer et en détruire en fonctions des besoins. On le retrouve directement relié à la topologie ou sont stockés les emplacements des données dans les serveurs.
Enfin du côté admin on trouve le vtctld qui est un dashboard permettant de gérer ca base de données.