NewSQL: Difference between revisions
Line 18: | Line 18: | ||
=Abstract= |
=Abstract= |
||
For decades, relational database management systems (RDBMS) were the best solution for storing and retrieving data. But because of the rapidly growing volume of data and changes in demand, major groups such as Google and Facebook have developed new technology as NoSQL or NewSQL to manage their data. This growth is faster than the growth of the storage capacity, which leads to the emergence of information management systems where the data is stored in a distributed way, but accessible and analyzed as if it resides on a single machine.In addition to solving the problem of data size, these solutions must also meet the massive performance requirements to ensure the speed of data processing (OLTP for example) |
|||
So there are two new categories that is an alternative way to traditional RDBMS systems (NoSQL, NewSQL). Regarding NewSQL, this is not really a new format, but a new approach in the implementation of a database. In this presentation, we will focus on the NewSQL, it works and why you have been impleme |
|||
=Synthése= |
=Synthése= |
Latest revision as of 14:22, 24 October 2015
Contexte
Enseignants :
Georges-Pierre Bonneau, Didier Donsez (VT2015)
Sujet :
Présentation de NewSQL
Auteur :
Vincent MESNIER
Date :
23 Octobre 2015
Mots clés
SQL,Base de donnée, SGBD, BigData, ACID, , Architecture distribuée, OLTP
Résumé
Pendant des décennies, les systèmes de gestion de base de données relationnelles (SGBDR) ont été la meilleur solution pour stocker et récupérer des données. Mais en raison de la croissance rapide du volume de données et des évolutions de la demande, des grands groupes comme Google ou Facebook ont développé de nouvelle technologie comme NoSQL ou NewSQL pour gérer leur donnée . Cette croissance est plus rapide que la croissance de la capacité de stockage, ce qui conduit à l'émergence de systèmes de gestion d'information où les données sont stockées de manière distribuée, mais accessibles et analysée comme si elle réside sur une seule machine. Outre la résolution du problème de la taille des données, ces solutions doivent également répondre aux exigences de performance massives pour assurer la rapidité du traitement des données (pour des application OLTP par exemple)
Il y a donc deux nouvelle catégorie qui servent d'alternative aux système classique SGBDR (NoSQL, NewSQL). Concernant NewSQL, ce n'est pas vraiment un nouveaux format mais une nouvelle approche dans la mise en oeuvre d'une base de données. Dans cette présentation, nous nous focaliserons sur le NewSQL, son fonctionnement et pourquoi a t'il été mis en oeuvre.
Abstract
For decades, relational database management systems (RDBMS) were the best solution for storing and retrieving data. But because of the rapidly growing volume of data and changes in demand, major groups such as Google and Facebook have developed new technology as NoSQL or NewSQL to manage their data. This growth is faster than the growth of the storage capacity, which leads to the emergence of information management systems where the data is stored in a distributed way, but accessible and analyzed as if it resides on a single machine.In addition to solving the problem of data size, these solutions must also meet the massive performance requirements to ensure the speed of data processing (OLTP for example) So there are two new categories that is an alternative way to traditional RDBMS systems (NoSQL, NewSQL). Regarding NewSQL, this is not really a new format, but a new approach in the implementation of a database. In this presentation, we will focus on the NewSQL, it works and why you have been impleme
Synthése
Introduction
Depuis l'émergence du BigData et des base de donnée NoSQL, les besoins des entreprises ont changé et même si NoSQL répond parfois à ces nouveaux besoins, il apparait que cette technologie sacrifie la plupart du temps la forte cohérence des données si chère au modèle relationnel, au bénéfice de la haute disponibilité et de la scalabilité horizontale. En revanche, cela ne plait pas à tout les entreprises.. Certaines ne peuvent simplement pas se passer de transactions ACID (par exemple: les banques). De plus, le développeur sera conduit à "jongler" avec l'éventuelle cohérence des données. De plus, chaque système de gestion de base de données NoSQL vient avec son propre langage de requête (manque de standard dans les interfaces). Durant l'année deux-milles onze, un groupe de recherche nommé "451 Research" a analysé le problème évoqué ci-dessus et défini le nom "ScalableSQL" (avant de s'appeler NewSQL) pour une base de données regroupant les avantages du NoSQL et des SGBDR classique.
Présentation générale de NewSQL
NewSQL est une catégorie de SGBD relationnelle moderne qui cherche à fournir :
- La même puissance évolutive (c'est à dire le faite de s'adapter à un changement d'ordre de grandeur, par exemple une forte demande) que le système NoSQL pour les applications concernant les traitement transactionnel en ligne ( type d'application qui sert a modifier des informations en temps réel, par exemple des applications bancaire)
- maintient les propriété ACID d'un système de gestion de base de donnée traditionnel (atomicité, cohérence, isolation et durabilité).
- Elle tire aussi partie des évolutions du matériel et des nouvelle architectures distribuées.
Une définition faites par un groupe de recherche (451 group's) dit que NewSQL est "un SGBD qui offre l'évolutivité et la flexibilité promise par NoSQL, tout en conservant le support pour les requêtes SQL et les propriétés ACID" NewSQL provient d'un modèle relationnel (contrairement à NoSQL qui est non-relationnel) orienté colonne et utilise totalement ou en partie le langage SQL. Les grandes applications visée par ce système sont caractérisé par un grand nombre de transactions, répétitives et utilisant un petit sous ensemble de donnée
NewSQL est tiré du monde NoSQL mais reste différent. Comme NoSQL elle tire partie des architectures distribuées, des progrès du matériel lors de ces dernières années. Mais contrairement à NoSQL elle permet de conserver le modèle relationnel au coeur du système. Ce schéma montre que NewSQL est né de la rencontre de 3 types d’architecture : relationnelle, NoSQL et grille de données (ou cache distribué) :
En effet, NewSQL se positionne comme 1 stockage distribué (les ressources ne sont pas toutes sur la même machine) conçue dans le prolongement de NoSQL. De plus, la plupart des solutions NewSQL proposent un stockage en mémoire (cache distribué sur plusieurs machine). Ce système est utilisé quand une faible latence est critique.
L’architecture NewSQL n’est donc pas totalement nouvelle mais reprend de ces expériences antérieures plusieurs caractéristiques tout en faisant des choix qui lui sont propres.
- Le choix d’une interface SQL et d’un schéma relationnel. C’est un argument majeur par rapport aux autres solutions.
- Un schéma relationnel avec des limitations pour faciliter la distribution des données et des traitements
- Utiliser la distribution et la réplication des données pour assurer la scalabilité et la résilience des données.
Caractéristiques
Le NewSQL est une architecture qui reprend donc les avantages du NoSQL et comble son principal désavantage. Il palie à l'éventuel cohérence des données de ce dernier grâce au support de transaction ACID via un langage pour les requêtes le SQL. Ci-dessous quelques-unes de ces caractéristiques:
- Le SQL comme langage commun de requétage
- Transaction ACID
- Un mécanisme qui évite la pause de verrous lors d'opérations concurrentes de lecture avec les opérations d'écritures. La lecture en temps réel en est ainsi facilitée (moins de perte de temps).
- Une architecture qui a de meilleures performances par nœud que les solutions classiques de type SGBDR.
- Architecture distribuée
- la plupart utilise des base de données en mémoire
Au vu de ce qui précède, on peut penser que ce type d'architecture sera celle adoptée demain en entreprise. En revanche, c'est une technologie assez récente et plutôt jeune et n'a pas encore pu faire suffisamment ses preuves. Par conséquent, les entreprises sont encore réticentes à l'adoption de cette toute nouvelle architecture
Pourquoi ?
Cette technologie a vu le jour pour plusieurs raison. Premièrement, elle tire partie des évolution du matériel et des architectures distribuées. Ce qui faut savoir c'est que SQL est une technologie assez vieille ( à peu prés 30 ans). SQL a bénéficié de quelques évolutions mais reste basé sur le matériel de l'époque. Deuxièmement, les besoins ont aussi évolué dû à l'émergence du BigData et des réseaux sociaux qui manipule un grand nombre de données. Par exemple Facebook stocke par moi 135 milliard de messages ou encore Twitter stocke 7 TB de données par jour. NoSQL permet d'offrir une bonne évolutivité et de bonne performance mais ne respecte pas les propriété ACID ce qui peut être un frein pour les entreprises.
Catégories
Comme le NoSQL, il existe plusieurs types de catégorie. Elles sont basées sur les différentes approches adoptées par le fournisseur de preserver l'interface SQL et d'aborder les problèmes de performance et d'évolutivité
- New design : Dans ce cas là, les bases de données sont souvent écrits à partir de zéro avec une architecture distribuée à l'esprit, et comprennent des composants tels que le contrôle distribué de la concurrence, contrôle de flux, et le traitement de requêtes distribuées. Elle est utilisé pour fonctionner dans un cluster de noeuds distribués sans partage (shared-nothing) dans lequel chaque noeud possèdent un sous ensemble de donnée.
- MySQL Engine : La deuxième catégorie sont fortement orienté moteurs de stockage optimisé pour SQL. Ces systèmes fournissent la même interface de programmation que SQL, mais adaptent mieux que cette intégration.
- Middleware : Ces systèmes fournissent une couche "sharding"qui permet de diviser automatiquement les bases de données sur plusieurs nœuds.
Comparaison
Les principaux éléments permettant d'opposer et de choisir ces technologies (relationnel, NoSQL, newSQL) sont la cohérence des données et la scalabilité. On peut dire qu'on choisira plus un système relationnel si on n'a besoin d'une forte cohérence des données et si notre système ne nécessite pas de forte monté en charge (capacité du système à maintenir ses fonctionnalisées en cas de forte demande) Le noSQL est plutôt adapté pour une scalabilité horizontal (rajouter des serveurs en parallèle) et si on a besoin de moins de cohérence. Exemple : Une banque peut utiliser SGBDR pour stocker l'historique de toutes les transactions de la clientèle car les transactions sont vraiment important pour une banque, mais la banque va également utiliser NoSQL pour l les erreurs de serveur et recueillir le comportement des utilisateurs. Si nous devons placer NewSQL sur le graphique, il se placerai en haut à droite.
Alors, est-ce aujourd’hui la fin des bases de données relationnelles? Pas forcément car elles ont prouvé leur efficacité pendant plus de 30 ans. De la même façon que les fichiers indexés sont encore là, les applications existantes continueront de fonctionner sur les bases de données relationnelles. Mais dans certains environnements, notamment les environnements virtualisés et le cloud, stocker la donnée de façon distribuée sur un ensemble de machines peut constituer un avantage décisif.
Est ce que NewSQL est un concurrent de NoSQL ? Non, pas forcément car NoSQL a des avantages de flexibilité qui lui son propre mais le faite que SQL soient beaucoup utiliser permet à NewSQL de se démarquer.
Ci-dessous un petit tableau récapitulatif sur ces 3 technologies :
Conclusion
NewSQL est donc utiliser pour des stockages distribué et stocker potentiellement entièrement en mémoire, utilise en partie SQL comme langage de requête, et offre des capacité moderne et une architecture moderne qui correspond aux architectures d'aujourd'hui. NewSQL est plutôt destiné aux entreprises qui gèrent beaucoup de données (comme les grands groupes Google ou Amazon) et nécessitent une certaine évolutivité mais aussi plus de cohérence dans leurs données Au final, beaucoup d'entreprise font pas vraiment le choix entre ces technologies. Ils utilisent différentes technologie de stockage de données pour différents besoins (c'est ce qu'on appelle "Polyglot persistance). Par exemple Facebook utilise MySQL pour stocker les posts, informations de l'utilisateur et Cassandra (NoSQL) pour les messages privés