En 2010, YouTube était dans une situation difficile. La plate-forme se développait rapidement et son infrastructure ne pouvait pas suivre son rythme. Pomper dans plus de CPU et de mémoire n’a pas aidé; il était toujours en train de s'effondrer aux coutures.
C'est alors que deux ingénieurs de YouTube, Sugu Sougoumarane et Mike Soloman, ont décidé de prendre du recul et d'analyser le problème sous un angle différent: «Lorsque nous nous sommes assis et avons écrit un énorme tableau de tous les problèmes et solutions, et lorsque nous avons examiné , il était évident que nous devions construire quelque chose entre l’application et la couche MySQL, et modérer toutes ces requêtes », déclare Sugu dans un entretien avec TechRadar Pro en marge de la Percona Live Conference Europe 2019 à Amsterdam.
Sommaire
Routage transparent
Sugu indique que ses utilisateurs préfèrent Vitess au clustering en raison de la flexibilité qu’il offre: «Le clustering MySQL pose des problèmes d’extension. Ainsi, lorsque vous souhaitez évoluer, vous souhaitez que les pièces soient couplées de manière plus souple. Mais si vous utilisez [MySQL] en regroupant alors vous n'obtenez pas cette flexibilité pour déplacer des choses plus facilement Je pense donc que c'est la raison pour laquelle Vitess est préféré par les utilisateurs. ”
Une condition essentielle pour la mise à l'échelle d'une base de données consiste à gérer la manière dont une base de données est partitionnée ou partagée en langage DBA. L’une des raisons de la popularité de Vitess est son système de sharding efficace. VTGate, l'un des deux principaux serveurs proxy de Vitess, conçu à l'origine comme un consolidateur de connexions, est en train de devenir un élément important de la solution: «Lorsque nous avons créé Vitess pour la première fois, nous avions besoin que l'application soit parfaitement consciente. Il fallait donc que l'application dise «Je veux envoyer cette requête, je veux l'envoyer à ce tesson». Ce qui voulait dire que si vous décidiez d'utiliser Vitess, vous deviez réécrire votre application pour faire des appels conscients de tessons et Vitess gère le cluster pour vous. "
Cela a changé en 2013 lorsque VTGate a été en mesure de router les requêtes standard vers le bon fragment: «Cela signifiait que l'application n'avait plus besoin d'être consciente des fragments…. n'importe quel pilote de base de données peut maintenant utiliser Vitess. »Sugu nous dit que le fournisseur de commerce électronique indien, Flipkart, appartenant à Walmart, a été le premier à prendre note de cette fonctionnalité et à créer un pilote JDBC pour Vitess, qui leur permettait ensuite de transférer facilement leur application. à Vitess. Cette caractéristique, qui selon Sugu était relativement facile à mettre en œuvre, a modifié les perspectives du projet.
Solution native au cloud
Vitess se présente comme une solution «cloud native». Sceptiques, nous demandons à Sugu s’il ne s’agit pas seulement de se conformer aux mots à la mode. Il explique que la nature prête pour le cloud de Vitess peut être attribuée au gestionnaire de cluster de Google appelé Borg.
À l'origine, Vitess était conçu pour fonctionner sur les centres de données de YouTube. Jusqu'en 2013, lorsque Google a décidé de les transférer en interne dans Google:
«Le logiciel Borg de Google est une bête, car il s’agit d’un environnement hostile aux systèmes de stockage. Nous devions réellement faire fonctionner Vitess dans cet environnement où Borg viendrait, à sa guise, vider votre pod et effacer vos données, vous permettant de survivre dans cet environnement. "
Cela signifiait que les développeurs devaient créer des fonctionnalités de résilience dans Vitess pour s'assurer que les pods se ressuscitent après leur décrochage par Borg:
«Et pour l’essentiel, ce sont les mêmes règles que Kubernetes. Dans Kubernetes, si un pod tombe en panne, vos données sont perdues. Nous étions donc pratiquement prêts pour Kubernetes, avant la naissance de Kubernetes. "
En outre, ils ont également dû apporter de subtiles modifications au code Vitess car le cycle de vie des déploiements dans le cloud est très différent de leur cycle de vie sur du métal nu: «En métal nu, vous pouvez avoir un maître pendant six mois. Dans Google, une semaine serait un miracle, car Google réorganisait en permanence les pods, ce qui finira par le faire tomber. "
Un autre aspect de cette reprogrammation a contribué à préparer Vitess pour l’environnement en nuage en constante évolution: «Lorsqu’il (le planificateur de Google) est reprogrammé, il affiche parfois autre chose sur la même adresse. Par exemple, il est possible de replanifier un fragment et de le planifier dans un autre. Vous ne saurez même pas parce que le schéma est correct, vous envoyez une requête et il vous enverra des réponses. Nous avons donc dû renforcer notre protection contre ces choses-là.
Open source
Comme tous les bons ingénieurs, Sugu et son co-développeur ne souhaitaient nullement réimplémenter leur solution d’extensibilité à partir de zéro, si et quand leur carrière les mènerait ailleurs. Ils ont donc demandé à Google d’approuver l’approvisionnement en open source Vitess, qui a approuvé la demande après s’être assuré qu’il n’y avait rien de propriétaire dans leur code.
Open Sourcing Vitess est ce qui a finalement conduit Sugu à quitter YouTube pour créer une société de services autour de Vitess appelée PlanetScale:
«YouTube, à un moment donné, était satisfait de l'endroit où se trouvait Vitess. Mais ce qui s'était passé, c'est que la communauté avait pris connaissance du projet et que les personnes souhaitant l'adopter suscitaient un vif intérêt, de même qu'une demande énorme de fonctionnalités.
Ainsi, d’une part, une entreprise qui ne souhaitait pas mettre en commun des ressources pour essentiellement construire une composante d’infrastructure et, de l’autre, une communauté sceptique qui hésitait à s’engager dans un projet émanant d’une entreprise dont la compétence essentielle n’était pas l’infrastructure.
«C’est donc à ce moment-là que nous en sommes venus à la conclusion que ce projet a pris de l’élan et que pour qu’il soit en bonne santé, il doit être confié à une personne. YouTube a fait don du projet à CNCF (Fondation pour l'informatique en nuage native), puis j'ai décidé de lancer PlanetScale avec mon co-fondateur. ”
Inverser la tendance
Interrogé sur certains problèmes de jeunesse avec Vitess, Sugu a déclaré que le plus important pour eux à ce jour est que Vitess n’est toujours pas une solution de remplacement: «Si vous passez à Vitess, 90% de vos requêtes fonctionneront, [but] vous devez traiter ces 10% sous une forme ou une autre. "
Il a également mentionné que Vitess ne prend pas encore en charge les requêtes OLAP (Online Analytical Processing). Mais ce n’est pas une chose qui les inquiète énormément car les utilisateurs n’exportent généralement que les données dans un système OLAP comme Snowflake, Pinot ou Presto: «Ce n’est donc pas un gros problème, mais ils veulent une solution unifiée.»
Sugu est enthousiasmé par une nouvelle fonctionnalité appelée VReplication, qui permet aux utilisateurs «de matérialiser une table d'un espace clé à un autre." Comme les règles de la matérialisation sont complètement flexibles, le nombre d'applications de cette fonctionnalité est énorme: «Et cela résout également certains problèmes fondamentaux que le sharding a lui-même. Par exemple, si vous avez une relation hiérarchique, il est facile de partager. Mais ce n’est pas si simple si vous avez beaucoup de relations. VReplication résout ce problème en vous permettant de matérialiser la même table à plusieurs endroits. »Cette fonction contient environ une demi-douzaine de cas d'utilisation que Sugu a illustrés dans son discours lors de l'événement.
Alors que nous terminons notre conversation, Sugu déclare que son cofondateur et lui-même sont convaincus que le secteur des bases de données a pris la mauvaise décision en se détournant des bases de données relationnelles en magasins de valeurs clés: «C'était une nécessité, car les bases de données relationnelles refusaient de répondre à la demande. d'évolutivité. S'ils avaient répondu à cette demande, les gens ne seraient pas allés dans des magasins à valeur ajoutée. Notre vision est d'inverser, espérons-le, cette tendance dans la mesure du possible, car vous pouvez maintenant faire évoluer les bases de données relationnelles. ”
