Soutenance mémoire
Le NewSQL
Systèmes de gestion de données
Un système de gestion de données est un outil permettant de stocker et de retrouver l’intégralité de données brutes ou d’informations en rapport avec un thème ou une activité, celles-ci peuvent être de natures différentes et plus ou moins reliées entre elles. Dans la très grande majorité des cas, ces informations sont structurées, et la base est localisée dans un même lieu et sur un même support généralement informatisé. Ce chapitre sera consacré à l’évolution des différentes générations des systèmes de gestion de données, en commençant en premier lieu par les fichiers plats, pour rappeler ensuite les principes des bases de données relationnelles, qui ont pris le pas sur les autres modèles de données pendant plusieurs années. Par la suite, on va expliquer les concepts de base de la mouvance NoSQL, pour en finir, par la dernière génération des systèmes de gestion de données connue par « NewSQL » qui semble promettre une architecture combinant les avantages des deux modelés cités précédemment.
Fichiers plats
Les fichiers plats sont l’une des premières formes de fichiers électroniques stockés et sont encore en usage aujourd’hui. Les systèmes d’exploitation DOS, Macintosh et les premières versions de logiciels tels que FileMaker utilisaient une des premières formes de fichiers plats. Ce sont des fichiers de données contenant un enregistrement par ligne, et dont les champs peuvent être délimités les uns des autres par un caractère spécial. La conception d’un fichier plat consiste à identifier certaines caractéristiques des champs dans chaque enregistrement : nombre de domaine, nom de domaine et une description de type de données stockées et sa taille maximale et minimale. Les documents conservés dans un fichier plat sont singuliers et n’ont pas de relation avec d’autres documents dans le dossier, contrairement aux bases de données ou aux fichiers relationnelles. Les fichiers plats prennent beaucoup moins d’espace lorsqu’ils sont stockés.
Pour les entreprises qui détiennent de grandes quantités de données, il peut donner un sens plus économique d’utiliser des fichiers plats. La récupération d’un enregistrement à partir d’un fichier plat se fait dans le code de programmation qui est lié à une interface utilisateur graphique, comme une forme de saisie de données à l’écran. Les enregistrements peuvent également être récupérés via les écrans de commande ou à l’aide d’une requête. Les requêtes sont écrites en connaissant le format de fichier et en utilisant un langage de requête spécifique. Par exemple, dans un système UNIX un langage de requête appelé » cql » est utilisé [1].
•Consistency (Cohérence)
Chaque transaction doit préserver la cohérence de données ; Cela signifie que les modifications apportées à la base doivent être valides, en accord avec l’ensemble de la base et de ses contraintes d’intégrité. Si un changement enfreint l’intégrité des données, alors soit le système doit modifier les données dépendantes, comme dans le cas classique d’une suppression en cascade, soit la transaction doit être interdite. La notion de cohérence est importante, et c’est l’un des éléments les plus sensibles entre le monde du relationnel et le monde NoSQL (qu’on va voir par la suite). Les SGBDR imposent une règle stricte : d’un point de vue transactionnel, les lectures de données se feront toujours sur des données cohérentes. Les modifications en cours sont donc cachées, un peu comme sur la scène d’un théâtre : chaque acte d’une pièce de théâtre se déroule intégralement sous l’oeil des spectateurs. Si le décor va être changé, le rideau se baisse, les spectateurs doivent attendre, les changements s’effectuent derrière le rideau et lorsque le rideau se lève, la scène est de nouveau dans un état totalement cohérent. Les spectateurs n’ont jamais eu accès à l’état intermédiaire. Néanmoins, cet état intermédiaire peut durer longtemps, pour deux raisons : plusieurs instructions de modifications de données peuvent être regroupées dans une unité transactionnelle, qui peut être complexe.
Ensuite, un SGBDR fonctionnant de façon ensembliste, une seule instruction de mise à jour, qui est naturellement et automatiquement transactionnelle, peut très bien déclencher la mise à jour de milliers de ligne de table. Cette modification en masse conservera des verrous d’écriture sur les ressources et écrira dans le journal de transaction ligne par ligne. Tout ceci prend, bien évidemment, du temps. Ce respect strict de la cohérence est concevable si nous restons sur le même serveur, mais dès que nous adoptons une distribution de données, il commence à poser de sérieux problèmes. La modification des données qui résident sur plusieurs serveurs n’est aujourd’hui possible qu’à partir d’un mécanisme nommée transaction distribuée.
La technologie NewSQL
NewSQL est un modèle de stockage distribué potentiellement en mémoire qui peut être requêté classiquement par une interface SQL. Le NewSQL, désigne une catégorie de bases de données modernes, qui a émergé du monde NoSQL mais reste différent sur plusieurs aspects. Comme NoSQL, il s’agit d’une nouvelle architecture logicielle qui propose de repenser le stockage des données pour prendre en charge les masses d’informations. Elle profite des architectures distribuées et des évolutions sur le plan du matériel pour coller aux nouvelles tendances. Contrairement à NoSQL, le New SQL permet de conserver le modèle relationnel au coeur du système. En fait, le NewSQL est né du croisement de 3 types d’architectures, relationnelle, non-relationnelle et grille de données appelée également cache distribué, comme indiqué dans la Figure II.2. Le NewSQL s’appuie sur un stockage distribué issu des architectures NoSQL, pour supporter des accès transactionnels à fort débit, au moyen d’une interface SQL.
D’un point de vue évolutivité, il se situe en tant que concurrent direct des solutions NoSQL, mais contrairement à ces solutions, il conserve une interface relationnelle via le SQL, ce qui est l’une de ses forces. Notons enfin, que la plupart des solutions NewSQL proposent un stockage en mémoire. Ce stockage en mémoire distribué sur plusieurs machines sous forme de grille de données est largement utilisé depuis une dizaine d’années dans les environnements où une faible latence est requise, notamment dans certaines applications des banques d’investissements. Les solutions NewSQL se situent ainsi dans une position intermédiaire entre les solutions NoSQL et les grilles de données [13].
Domaine d’utilisation de VoltDB
VoltDB n’est pas destiné à résoudre tous les problèmes de base de données mais destiné seulement à un segment spécifique de l’informatique commerciale. VoltDB se concentre spécifiquement sur les applications qui doivent traiter de grands flux de données rapidement. Cela comprend les applications financières, les applications des médias sociaux et les champs en plein essor de l’Internet. Les principales exigences pour ces applications sont l’évolutivité, la fiabilité, la haute disponibilité et un rendement exceptionnel. VoltDB est utilisé aujourd’hui pour les applications traditionnelles à haute performance telles que les flux de données sur les marchés de capitaux, le commerce financier, les flux de données de télécommunications et les systèmes de distribution par capteurs. Il est également utilisé dans des applications émergentes comme les jeux en ligne, la détection de fraude, les échanges d’annonces numériques et les systèmes de micro-transaction. Toute application nécessitant un haut débit de base de données, une mise à l’échelle linéaire et une précision de données sans compromis bénéficieront immédiatement de VoltDB.
Cependant, VoltDB n’est pas optimisé pour tous les types de requêtes. Par exemple, VoltDB n’est pas le choix optimal pour la collecte et le rassemblement d’ensembles de données historiques extrêmement importants qui doivent être interrogés sur plusieurs tables. Ce type d’activité se retrouve généralement dans les solutions de business intelligence et d’entreposage de données, pour lesquelles d’autres produits de base de données sont mieux adaptés. Pour aider les entreprises qui exigent à la fois des performances exceptionnelles des transactions et des rapports ad hoc, VoltDB offre des fonctions d’intégration afin que les données historiques puissent être exportées vers une base de données analytique pour l’exploration de données à plus grande échelle. Même si les diverses bases de données NewSQL diffèrent par leurs architectures internes, elles exploitent toutes le modèle de données relationnel et s’exécutent toutes en langage SQL [20].
|
Table des matières
Introduction Générale
Chapitre I : Système de gestion de données
I – Introduction
II – Fichiers plats
III – Bases de données relationnelles
III.1 – Introduction
IiI.2 – Principe de fonctionnement de SGBD relationnel
IiI.3 – Propriétés ACID
III.4 – Limites des bases de données relationnelles
IV – Le NoSQL
IV.1 – Introduction
IV.2 – Théorème de CAP
IV.3 – Types de bases de données NoSQL
IV.4 – Requêtage NoSQL
IV.5 – Avantages du NoSQL
IV.6 – Inconvénients du NoSQL
IV – Le NewSQL
V – Conclusion
Chapitre II : Le NewSQL
I – Introduction
II – La technologie NewSQL
III – Caractéristiques du NewSQL
IV – Architecture du NewSQL
V – Les catégories de bases de données NewSQL
V.1 – New design
V.2 – MySQL Engines
V.3 – Middleware
VI – Les leaders de la Technologie NewSQL
VI.1 – Spanner
VI.2 – ClustrixDB
VI.3 – NuoDB
VI.4 – TransLattice Elastic Database
VI.5 – SQLFire
VI.6 – GridGain IMDB
VI.7 – Drizzle
VI.8 – MemSQL
VI.9 – VoltDB
VI.9.1 – Description
VI.9.2 – Domaine d’utilisation de VoltDB
VI.9.3 – Architecture et fonctionnalités du VoltDB
VII – Les avantages du NewSQL
VIII – Les inconvénients du NewSQL
IX – Conclusion
Chapitre III : Etude comparative MySQL vs NewSQL
I – Introduction
II – Présentation et installation du benchmark
II.1 – Présentation d’YCSB
II.2 – Installation
II.2.1 – JAVA
II.2.2 – YCSB
III – Installation et configuration des SGBD
III.1 – MySQL
III.2 – VoltDB
IV- Résultats expérimentaux
IV.1 – Chargement des données
IV.1.1 – MySQL
IV.1.2 – VoltDB
IV.2 – Execution des workloads
IV.3 – Evaluation globale des tests
V – Conclusion
Conclusion générale et perspectives
Références Bibliographiques
Liste des Abréviations
Liste des Figures
Liste des Tableaux
Télécharger le rapport complet
