VT2017 Vitess - Revision history

Oriane.Dalle at 15:01, 29 September 2017

2017-09-29T15:01:11Z

← Older revision		Revision as of 15:01, 29 September 2017
Line 80:		Line 80:

	Enfin du côté admin on trouve le ''vtctld'' qui est un dashboard permettant de gérer ca base de données.		Enfin du côté admin on trouve le ''vtctld'' qui est un dashboard permettant de gérer ca base de données.









	=Bibliographie/Webographie=		=Bibliographie/Webographie=

Oriane.Dalle: /* Architecture */

2017-09-29T15:00:45Z

Architecture

← Older revision		Revision as of 15:00, 29 September 2017
Line 75:		Line 75:


	On peut voir sur le ~~schema~~ de l'architecture les différentes parties de la base de ~~données~~ stockées sur des serveurs différents. Chaque bout de base de ~~donnée~~ 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.		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 ~~les~~ détruire en fonctions des besoins. On le retrouve directement relié à la topologie ou sont stockés les ~~emplacement~~ 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ée~~.









		⚫	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.

	=Bibliographie/Webographie=		=Bibliographie/Webographie=

Oriane.Dalle: /* Sharding */

2017-09-29T14:58:40Z

Sharding

← Older revision		Revision as of 14:58, 29 September 2017
Line 55:		Line 55:
	[[File:Sharding.png\|\|thumb\|300px\|Representation des deux types de sharding possible, medium.com ]]		[[File:Sharding.png\|\|thumb\|300px\|Representation des deux types de sharding possible, medium.com ]]

	Comme je l'ai du précédemment le Sharding est aussi ~~appeler~~ distribution ~~des~~ 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és~~ sur un seul serveur mais sur un cluster de serveurs.		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 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.		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.


Line 63:		Line 63:
	*En quoi cela rend la base de donnée plus performante ?		*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ées~~ est rangée. De cette façon à chaque ~~requêtes~~ on aura une sur couche qui va ~~orienté~~ les requêtes sur le serveur concerné.(''cf : Architecture'')		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 ?		*Quand utilise-t-on le sharding ?

	On utilise cette méthode lorsque une base de ~~donnée~~ est devenu trop grande pour être ~~stocké~~ sur une seul et même machine.		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ée~~ mais ces méthodes sont moins ~~perenne~~ dans le temps, surtout si l’extension de la base de ~~donnée~~ est importante		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==		==Architecture==

Oriane.Dalle: /* Differences avec le NoSQL */

2017-09-29T14:55:12Z

Differences avec le NoSQL

← Older revision		Revision as of 14:55, 29 September 2017
Line 45:		Line 45:
	Vitess reprend les avantages de mise à l’échelle du NoSQL mais tout en restant très different.		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égation~~, alors que le NoSQL ne supporte pas ce type de requêtes. Une autre difference ~~important~~ est que Vitess prend en charge les transactions, une transaction est une suite d'operations qui font passer la base de ~~donnée~~ 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 ~~different~~ 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.		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==		==Sharding==

Oriane.Dalle: /* Differences avec le MySQL */

2017-09-29T14:53:49Z

Differences avec le MySQL

← Older revision		Revision as of 14:53, 29 September 2017
Line 39:		Line 39:
	Vitess reprend les grandes lignes de MySQL avec quelques améliorations.		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ée~~ 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 a l’échelle notre base de ~~donnée~~ 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 à 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éplique~~ de notre ~~bases~~ afin qu’elle soit à jour en cas de panne de la base principale.		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==		==Differences avec le NoSQL==

Oriane.Dalle: /* Contexte */

2017-09-29T14:51:59Z

Contexte

← Older revision		Revision as of 14:51, 29 September 2017
Line 27:		Line 27:
	==Contexte==		==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ée~~ et la gérer convenablement.		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".		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 à évidement des limites visibles.		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 ~~redirigé~~ les requêtes faites sur la base. De cette façon Vitess à pu augmenter 50 fois la taille de la base de ~~donné~~ de Youtube, tout en la rendant plus facilement administrable.		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==		==Differences avec le MySQL==

Donsez: /* Contexte */

2017-09-29T14:48:50Z

Contexte

← Older revision		Revision as of 14:48, 29 September 2017
Line 29:		Line 29:
	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ée et la gérer convenablement.		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ée et la gérer convenablement.

	Deux solutions s'~~offrait~~ à eux : Faire de la "scalabilité verticale" ou de la "scalabilité horizontale".		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 à évidement des limites visibles.		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 à évidement des limites visibles.

Oriane.Dalle: /* Abstract */

2017-09-29T09:02:57Z

Abstract

← Older revision		Revision as of 09:02, 29 September 2017
Line 17:		Line 17:

	=Abstract=		=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=		=Synthèse=

Oriane.Dalle: /* Résumé */

2017-09-28T19:17:20Z

Résumé

← Older revision		Revision as of 19:17, 28 September 2017
Line 14:		Line 14:
	=Résumé=		=Résumé=

	Les bases de donnée des sites web deviennent de plus en plus ~~importante~~, 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, 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~~. C'est un projet open-source qui est développé depuis 2011 par Youtube et qui est en pleine croissance~~.		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=		=Abstract=

Oriane.Dalle at 18:56, 28 September 2017

2017-09-28T18:56:56Z

← Older revision		Revision as of 18:56, 28 September 2017
Line 86:		Line 86:


	=Conclusion=

	=Bibliographie/Webographie=		=Bibliographie/Webographie=