Cours - Introduction au NoSQL PDF

Introduction au NoSQL (Not Only SQL) Pegdwendé Nicolas SAWADOGO Université Virtuelle du Burkina Faso Version 1.0, Dernière modification : 14 octobre 2023  Préface Du Relationnel au NoSQL : Une Évolution Naturelle des Bases de Données Le paysage...

Introduction au NoSQL (Not Only SQL) Pegdwendé Nicolas SAWADOGO Université Virtuelle du Burkina Faso Version 1.0, Dernière modification : 14 octobre 2023  Préface Du Relationnel au NoSQL : Une Évolution Naturelle des Bases de Données Le paysage technologique a connu de profondes mutations au cours des dernières décen- nies. L’une des transitions les plus marquantes a été le passage progressif des bases de don- nées relationnelles traditionnelles (RDBMS) vers les bases de données NoSQL. Comprendre cette évolution nécessite un retour en arrière pour saisir les origines, les forces et les limites des RDBMS, ainsi que les impératifs qui ont conduit à l’émergence du NoSQL (encore ap- pelles bases de données non relationnelles). Les Bases de Données Relationnelles Depuis les années 1970, les bases de données relationnelles, telles que Oracle, SQL Server et MySQL, ont été la pierre angulaire de la gestion des données pour les entreprises. Elles reposent sur le principe des tables structurées avec des relations bien définies, le tout gou- verné par un schéma strict. La puissance des RDBMS réside dans leur capacité à garantir l’intégrité, la cohérence et la durabilité des données grâce à des transactions ACID (Atomi- cité, Cohérence, Isolation, Durabilité). Nouveaux besoins de stockage à l’Ère du Web 2.0 et du Big Data Avec l’explosion de l’internet et la montée du Big Data, les défis ont évolué : — Volume croissant : Les RDBMS, bien que capables de gérer de grandes quantités de données, commencent à rencontrer des difficultés d’évolutivité horizontale lorsqu’il s’agit de gérer des pétaoctets de données. — Diversité des données : L’ère numérique a introduit une variété de données (textes, 2  images, vidéos, données de capteurs) qui ne s’adaptent pas toujours bien à la structure tabulaire rigide des SGBDR. — Demande de faible latence : Les applications modernes, telles que les médias sociaux ou les jeux en ligne, nécessitent des réponses presque en temps réel, difficilement garanties par les bases de données relationnelles dans des contextes de très haute de- mande. L’Émergence du NoSQL En réponse à ces défis, le NoSQL est apparu comme une solution alternative aux SGBDR. Ces bases de données ont été conçues pour offrir une scalabilité horizontale, une flexibi- lité de schéma et une capacité à gérer une grande variété de données. Les NoSQL, comme MongoDB ou Cassandra, abandonnent souvent certaines garanties ACID au profit de la per- formance et de la flexibilité, optant pour des modèles de cohérence éventuelle. Conclusion Le passage des bases de données relationnelles aux bases de données NoSQL n’est pas un remplacement, mais plutôt une expansion des approches de gestion des données. Alors que les SGBDR restent cruciaux pour des applications nécessitant des garanties strictes et une structure définie, le NoSQL offre des solutions pour les scénarios qui exigent flexibilité, évo- lutivité et performance. Dans le paysage actuel, les architectes de bases de données ont la chance d’avoir le choix entre plusieurs outils chacun spécifique à un besoin. 3  C HAPITRE 1 Limites des Bases de don- nées relationnelles 1.1 Propriétés ACID Definition 1 Les propriétés ACID constituent un ensemble de garanties fournies par les sys- tèmes de gestion de bases de données relationnelles (SGBDR) pour assurer la fia- bilité des transactions dans une base de données. L’acronyme "ACID" représente les quatre propriétés essentielles : Atomicité, Cohérence, Isolation et Durabilité. 1.1.1 Atomicité L’atomicité garantit que les transactions sont traitées de manière indivisible et irréductible. Cela signifie que lorsqu’une transaction est exécutée, soit toutes ses opérations sont com- plétées avec succès, soit aucune d’entre elles ne l’est. En d’autres termes, une transaction est considérée comme une unité "atomique" qui, en cas d’échec, est entièrement annulée (roll- back) pour laisser la base de données dans son état initial. Par exemple, si une transaction bancaire vise à transférer des fonds d’un compte à un autre, l’atomicité garantit que si l’une des opérations (débit ou crédit) échoue, l’autre sera annulée, évitant ainsi toute incohérence. 1.1.2 Cohérence La cohérence assure que chaque transaction amène la base de données d’un état valide à un autre état valide. Les contraintes d’intégrité, les règles métier et les conditions préalablement définies doivent être respectées avant et après la transaction. Prenons encore l’exemple de la transaction bancaire : si un compte ne peut pas être débiteur, la cohérence garantit qu’après le transfert, le solde du compte débité ne sera pas négatif. 4 1.1.3 Isolation CHAPITRE 1. LIMITES DES SGBDR 1.1.3 Isolation L’isolation garantit qu’une transaction en cours d’exécution est isolée des autres transac- tions. Cela signifie que les opérations d’une transaction temporaire ne sont pas visibles pour les autres transactions avant qu’elle ne soit complétée. Cela évite que deux transactions qui s’exécutent en parallèle interfèrent entre elles. Par exemple, si deux personnes essaient d’acheter le dernier billet d’un événement en même temps, l’isolation garantit que l’une des transactions sera exécutée avant l’autre, évitant ainsi la vente de plus de billets que dispo- nibles. 1.1.4 Durabilité La durabilité assure qu’une fois qu’une transaction est validée et terminée, ses effets sont permanents et persistants, même en cas de panne du système. Cela est généralement réalisé en enregistrant les transactions dans un journal ou un log, puis en appliquant périodique- ment ces transactions au stockage principal. En reprenant l’exemple bancaire, la durabilité garantit que, une fois le transfert d’argent validé, il ne sera pas perdu, même si la base de données tombe en panne immédiatement après la transaction. 1.2 Théorême CAP Definition 2 Le théorème CAP, souvent appelé le théorème de Brewer en référence à Eric Bre- wer qui l’a formulé en 2000, est un concept fondamental pour les systèmes de bases de données distribuées. Ce théorème énonce qu’il est impossible pour un système de bases de données distribué de garantir simultanément les trois pro- priétés suivantes : Cohérence, Disponibilité et Tolérance au partitionnement. Un système peut, à tout moment, garantir au plus deux de ces propriétés. 1.2.1 Cohérence (Consistency en anglais) Chaque lecture récupère la dernière écriture ou une erreur. En d’autres termes, tous les nœuds du système voient les mêmes données en même temps. Si une opération d’écriture a 5 Introduction au NoSQL (Not Only SQL)- Pegdwendé Nicolas SAWADOGO lieu sur un nœud, elle sera immédiatement visible pour toutes les lectures sur tous les autres nœuds. 1.2.2 Cohérence Disponibilité (Availability en anglais) Chaque requête (lecture ou écriture) reçoit une réponse sans erreur : soit la valeur deman- dée, soit une confirmation de l’écriture. Cela signifie que le système continue de fonctionner (accepte les lectures et les écritures) même si certains nœuds sont inaccessibles. 1.2.3 Tolérance au partitionnement (Partition Tolerance en anglais) Le système continue de fonctionner même en cas de communication rompue entre les nœuds. Les "partitions" sont les communications réseau entre les nœuds, et si elles échouent, les nœuds ne peuvent plus communiquer. La tolérance au partitionnement garantit que le sys- tème fonctionnera, même si des informations ne peuvent pas être partagées entre tous les nœuds du réseau. 1.2.4 Classification des SGBD en lien avec le théorême CAP En tenant compte de ces trois propriétés, les systèmes de bases de données distribuées sont souvent classifiés selon les deux propriétés qu’ils choisissent de privilégier : — CP (Cohérence et Tolérance au partitionnement) : Ces systèmes garantissent que tous les nœuds voient les mêmes données en même temps et que le système fonc- tionne même en cas de partition, mais peuvent refuser des requêtes si un nœud est inaccessibles. — CA (Cohérence et Disponibilité) : Ces systèmes garantissent que tous les nœuds voient les mêmes données en même temps et répondent à toutes les demandes, mais ils ne tolèrent pas les partitions. — AP (Disponibilité et Tolérance au partitionnement) : Ces systèmes répondent à toutes les demandes et tolèrent les partitions, mais ne garantissent pas que tous les nœuds voient les mêmes données en même temps. Dans la pratique, la tolérance au partitionnement est souvent considérée comme indispen- sable pour les systèmes distribués, en particulier dans les environnements sujets à des er- reurs réseau. Par conséquent, le véritable débat porte souvent sur l’équilibre entre la cohé- rence et la disponibilité. 6 1.2.4 SGBD vs. théorème CAP CHAPITRE 1. LIMITES DES SGBDR F IGURE 1.1 – Classification des SGBD par rapport au théorême CAP 7  C HAPITRE 2 Présentations des Bases de données NoSQL 2.1 Notion de Base de données NoSQL La notion de bases de données NoSQL est devenue centrale dans le monde des systèmes d’information moderne, notamment avec l’émergence du Big Data, du cloud computing et des applications web à grande échelle. Definition 3 L’acronyme "NoSQL" signifie "Not Only SQL", soulignant que, bien que le SQL (Structured Query Language) ait été la norme dominante pour interroger et gérer les bases de données, d’autres approches ont émergé pour répondre à des besoins spécifiques non couverts par les bases de données relationnelles traditionnelles. La nécessité de bases de données NoSQL a été ressentie principalement en raison de l’évo- lution rapide du web et des défis posés par l’ampleur et la nature des données générées. Les géants du web comme Google, Amazon et Facebook, confrontés à des volumes massifs de données non structurées et à la nécessité d’une disponibilité et d’une scalabilité constantes, ont été parmi les premiers à adopter et à promouvoir des technologies NoSQL. Les SGDB NoSQL se distinguent des SGBDR à travers 3 principales caractéristiques : — Flexibilité schématique : Contrairement aux bases de données relationnelles qui né- cessitent un schéma fixe, les bases NoSQL sont souvent flexibles en termes de struc- ture des données. Cela permet une évolution plus fluide des applications. — Scalabilité horizontale : Les bases NoSQL sont conçues pour être déployées sur plu- sieurs serveurs, facilitant ainsi la scalabilité horizontale, ce qui est idéal pour les ap- plications nécessitant une croissance rapide ou imprévisible. — Haute performance : Grâce à leur conception simplifiée et à leur capacité à être dis- tribuées, les bases NoSQL peuvent souvent traiter un grand nombre de requêtes par seconde. 8 2.2.1 Bases de données CHAPITRE orientées document 2. PRÉSENTATIONS DES BASES DE DONNÉES NOSQL 2.2 Classification des Base de données NoSQL Les bases de données NoSQL peuvent être classées en plusieurs types, chacun étant conçu pour répondre à des besoins spécifiques. Voici une présentation des principaux types de bases de données NoSQL : 2.2.1 Bases de données orientées document Description : Elles stockent les données sous forme de documents, le plus souvent au for- mat JSON ou BSON. Chaque document possède une clé unique qui le distingue. Exemples : MongoDB, CouchDB. Cas d’utilisation : Elles conviennent particulièrement aux catalogues de produits, aux systèmes de gestion de contenu et à toute application nécessitant une flexi- bilité dans les données. 2.2.2 Bases de données orientées colonnes — Description : Ces bases stockent les données par colonne plutôt que par ligne, ce qui est différent des bases relationnelles traditionnelles. Elles sont efficaces pour des re- quêtes sur de grands ensembles de données et pour des opérations de lecture et d’écri- ture rapides. — Exemples : Cassandra, HBase. — Cas d’utilisation : Elles sont idéales pour des systèmes de gestion de données analy- tiques et pour des applications nécessitant une haute performance et une scalabilité, comme les plateformes publicitaires ou certaines applications de Big Data. 2.2.3 Bases de données orientées clés - valeurs — Description : Elles fonctionnent sur le principe simple de l’association clé-valeur. Elles sont optimisées pour des opérations de récupération rapide grâce à une clé unique. — Exemples : Redis, DynamoDB, Riak. — Cas d’utilisation : Convient aux applications nécessitant des accès rapides à leurs données, comme les systèmes de cache, les sessions utilisateurs ou les jeux en ligne. 2.2.4 Bases de données orientées graphes — Description : Conçues pour stocker des données interconnectées, elles utilisent des nœuds, des arêtes et des propriétés pour représenter et stocker des données. Les bases de données de graphes sont optimisées pour naviguer rapidement dans les connexions. 9 Introduction au NoSQL (Not Only SQL)- Pegdwendé Nicolas SAWADOGO — Exemples : Neo4j, OrientDB. — Cas d’utilisation : Parfaites pour les réseaux sociaux, les systèmes de recommandation ou toute application nécessitant de traiter des données interconnectées, comme les systèmes de gestion des connaissances. 2.3 Cas d’utilisation des Base de données NoSQL Leurs caractéristiques distinctes les rendent idéales pour une variété de cas d’utilisation qui pourraient poser des défis aux bases de données relationnelles traditionnelles. Voici quelques-uns des principaux cas d’utilisation des bases de données NoSQL : — Applications Web à grande échelle : Avec l’émergence des services web qui servent des millions, voire des milliards d’uti- lisateurs, la scalabilité est devenue cruciale. Les bases NoSQL, telles que Cassandra ou MongoDB, peuvent être déployées sur plusieurs serveurs pour gérer de grandes quantités de trafic et de données — Réseaux sociaux : Les interactions sur les plateformes sociales impliquent des rela- tions complexes entre les utilisateurs, leurs publications, leurs amis, leurs abonne- ments, etc. Les bases de données orientées graphe, comme Neo4j, sont particulière- ment adaptées pour modéliser et interroger ces relations complexes. — Systèmes de recommandation : Qu’il s’agisse de recommander des produits sur un site e-commerce, des films sur une plateforme de streaming ou des articles de blog, les bases NoSQL peuvent gérer et analyser d’énormes volumes de données d’utilisateurs pour fournir des recommandations personnalisées. — Données géospatiales et localisation : Pour les applications qui nécessitent le suivi de la localisation, comme les applications de livraison, de cartographie ou de géolocali- sation, certaines bases NoSQL offrent des capacités géospatiales natives pour stocker et interroger des données basées sur la localisation. — Stockage de logs et détection de fraudes : Les entreprises génèrent d’énormes vo- lumes de logs qui doivent être analysés en temps réel pour détecter les anomalies ou les fraudes. Les bases NoSQL, en particulier les bases orientées colonne comme Cas- sandra, peuvent stocker et analyser efficacement ces logs — Systèmes de gestion de contenu (CMS) : La flexibilité des bases de données orientées document, telles que MongoDB, les rend idéales pour gérer du contenu dynamique et varié pour les sites web, les blogs et autres plateformes. — Jeux en ligne : Les jeux à grande échelle nécessitent des bases de données rapides pour suivre l’état du jeu, les scores des joueurs, les inventaires virtuels, etc. Les magasins 10 2.2.4 Bases de données CHAPITRE orientées graphes 2. PRÉSENTATIONS DES BASES DE DONNÉES NOSQL clé-valeur, comme Redis, sont souvent utilisés pour ces cas d’utilisation. — Données de capteurs et données en temps réel : Les dispositifs IoT génèrent d’énormes flux de données en temps réel. Les bases NoSQL peuvent gérer ces flux massifs, sto- cker les données et fournir des analyses en temps réel. — Plateformes de e-commerce : Les sites e-commerce nécessitent des bases de données flexibles pour gérer les catalogues de produits en constante évolution, les historiques des utilisateurs, les paniers d’achat, etc. La flexibilité des schémas des bases NoSQL est un avantage majeur ici. 11  C HAPITRE 3 Conclusion Alors que les bases de données relationnelles continueront de jouer un rôle crucial dans de nombreux domaines, les bases de données NoSQL offrent des alternatives flexibles et évolutives pour répondre aux besoins changeants du monde numérique actuel. Le choix entre SQL et NoSQL dépendra toujours des besoins spécifiques du projet ou de l’application en question. Il est necessaire de comprendre le fonctionnement de chaque type de Base de données NoSQL afin de faire le bon choix en fonction du besoin. Dans le cadre de ce cours, nous nous focaliserons sur les bases de données orientées documents à l’image de Mongo DB, et nous aborderons également une base de données orientée graphes, en l’occurrence Neo4J. 12  Références 1. "NoSQL : Bases de données pour Big Data et temps réel" de Jean-Marc Rozet, Éditions ENI. 2. "Bases de données NoSQL et le Big Data : Comprendre et mettre en oeuvre" de Luc Gougeon, Éditions Eyrolles. 3. "MongoDB - Définition et déploiement d’une base de données NoSQL" de Sébastien Bollée, Éditions ENI. "Cassandra - Le guide du praticien du Big Data" de Gurunath Hariharan, Éditions Dunod. 4. "Neo4j - Des données et des graphes - Prise en main" de Sylvain Roussy, D-BookeR Éditions. 5. "Redis - Pratique et mise en oeuvre" de François-Guillaume Ribreau, D-BookeR Édi- tions. Articles académiques : 6. MongoDB France : https ://www.mongodb.com/fr - Site officiel de MongoDB avec des ressources, tutoriels, et documentation en français. 7. Le Journal du Net (JDN) : Dossier NoSQL : https ://www.journaldunet.com/solutions/dsi/dossier- nosql/ - Un dossier sur le NoSQL, comprenant des articles, des études de cas et des comparatifs. 8. "Introduction aux bases de données NoSQL" sur OpenClassrooms : https ://openclassrooms.com/fr/ introduction-aux-bases-de-donnees-nosql - Un cours en ligne complet pour ceux qui débutent avec le NoSQL. 13 Introduction au NoSQL (Not Only SQL)- Pegdwendé Nicolas SAWADOGO 14 CHAPITRE 3. CONCLUSION 15 Pegdwendé Nicolas SAWADOGO, Université Virtuelle du Burkina Faso, 14 octobre 2023