VT2017 OpenMP

Présentation

• Sujet : OpenMP
• Auteur : Anthony Geourjon
• Enseignants : Didier Donsez, Georges-Pierre Bonneau
• Date : 12/11/2017

Résumé

Open MP ou Open Multi-Processing est une interface de programmation pour le calcul parallèle. En opposition à Open MPI, Open MP est destiné aux architectures à mémoire partagée. La première version a été publié en 1997, et la versiçon en cours toujours maintenue est la 4.0 sortie en 2013. Open MP est portable et disponible sur les principales plateforemes (Linux, OS X, Windows) et fonctionne avec trois langages C,C++ et Fortran.

Open MP est developpé par tous les acteurs du High Performance Computing que ce soit les entreprises privées comme AMD, IBM, Arm, Nvidia ou les laboratoires de recherche comme Argonne, l’université de Bristol ou le EPCC d’Edinburgh. Open MP a été développé afin de simplifier le développement d’applications parallèles. Ses alternatives sont toujours limitées (bibliothèque pthread.h ou Intel Threading Building Blocks).

Open MP s’utilise en ajoutant une option de compilation au compilateur. Open Mp se veut comme une interface entre l’application et le système. Le principal but d’Open MP est de réduire les goulots d’étranglement comme les boucles. Pour cela on va utiliser les directives que fournit Open MP. Elles sont de 3 types : partage du travail, partage de mémoire, synchronisation des threads. Open MP est basé sur modèle Fork and Join, c’est à dire que la partie séquentiel du programme est réalisé par un thread mare et que seulement une partie du programme (les boucles typiquement) seront partagés entre différents threads. Cela sous entend de la synchronisation et un partage correcte des variables (car Open MP vise les architectures partagé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 ?

Representation des deux types de sharding possible, medium.com

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

Schéma de l'architecture de Vitess, http://vitess.io/

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.

Bibliographie/Webographie

• http://vitess.io/overview/
• https://www.youtube.com/watch?v=q65TleTn2vg
• https://blog.octo.com/sharding/
• https://medium.com/@jeeyoungk/how-sharding-works-b4dec46b3f6
• https://blog.octo.com/sharding/