Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

Chapitre 1 : Bases de données NOSQL Plan  Forces des SGBD  Propriétés ACID 

Chapitre 1 : Bases de données NOSQL Plan  Forces des SGBD  Propriétés ACID  Limites des BDR  BD NOSQL  BDR vs BD NOSQL 2 Forces des SGBDR  Indépendance entre : Modèle de données et structures de stockage Requêtes déclaratives et exécution  Possibilité d’exécuter des requêtes complexes  Optimisation très fine des requêtes, index permettant un accès rapide aux données  Logiciels mûrs, stables, efficaces, riches en fonctionnalités et en interfaces 3 Forces des SGBDR  Contraintes d’intégrité permettant d’assurer des invariants sur les données.  Gestion efficace de grands volumes de données (gigaoctet, voire téraoctet).  Gestion des transactions (ensembles d’opérations atomiques) garantissant la gestion de la concurrence, la reprise sur panne. 4 Propriétés ACID Les transactions des SGBD relationnels classiques respectent les propriétés ACID. Atomicité – Cohérence – Isolation – Durabilité 5 Limites des BDR  Incapable de gérer de très grands volumes de données (de l’ordre du péta-octets)  Impossible de gérer des débits extrêmes (plus que quelques milliers de requêtes par seconde)  Le modèle relationnel est parfois peu adapté au stockage et à l’interrogation de certains types de données Données hiérarchiques, semi-structurées 6 Limites des BDR  Les propriétés ACID entraînent de sérieux surcoûts en latence, accès disques, temps CPU (verrous, journalisation, etc.)  Performances limitées par les accès disque. 7 Bases de données NOSQL  Not Only SQL  SGBD avec d’autres compromis que ceux faits par les systèmes classiques.  Caractéristiques recherchées : modèle de données différent, passage à l’échelle, performances extrêmes  Caractéristiques abandonnées : ACID, (parfois) requêtes complexes. 8 Bases de données NOSQL 9 Types des bases de données NOSQL :  Clef/valeur  Orientées colonnes  Orientées documents  Orientées graphes Bases de données NOSQL Modèle Clef-Valeur  L’un des types les plus simples, sorte de Hashmap distribuée.  Conçues pour sauvegarder les données sans définir de schéma.  Toutes les données sont sous forme de clef/valeur 10 Bases de données NOSQL Communications se résumant surtout aux opérations PUT, GET et DELETE Absence de typage a un impact sur le requêtage : toute l’intelligence portée avant par les requêtes devra être portée par l’applicatif qui interroge la BD Exemple : DynamoDB (Amazon), Azure Table Storage (ATS), Redis, BerkeleyDB, Voldemort (LinkedIn) 11 Bases de données NOSQL 12 Id Nom Humeur Date_naissance Couleur 12 Stella Heureuse 2007-04-01 NULL 13 Wimma Faim NULL Noire 9 Ninja NULL NULL NULL Nom_$#_Stella~~Humeur_$#_Heureuse ~~Date_naissance_$#_2007-04-01… Chien_12 Bases de données NOSQL BD orientées documents  Étendent le paradigme clef/valeur, avec des « documents » plus complexes à la place des données simples, et une clef unique pour chacun d’eux.  Documents de type JSON, XML…  Chaque document est un objet, contient un ou plusieurs champs, et chaque champ contient une valeur typée (string, date, binary ou array) 13 Bases de données NOSQL  Permettent de stocker, extraire et gérer les informations orientées documents (données semi-structurées) Avantage : pouvoir récupérer, via une seule clef, un ensemble d’informations structurées de manière hiérarchique. Dans les bases relationnelles, cela impliquerait plusieurs jointures Exemples : Mongo DB (SourceForge), Couch DB (Apache), RavenDB (destiné aux plateformes .Net/Windows, interrogation via LINQ) 14 Bases de données NOSQL 15 Id Nom Humeur Date_naissanc e Couleur 12 Stella Heureuse 2007-04-01 NULL 13 Wimma Faim NULL Noire 9 Ninja NULL NULL NULL Chien_12 { type : « Chien », nom : « Stella », humeur : « Heureuse », date_naissance : 2007-04-01 } Clef Document(V1) { type : « Chien », nom : « Stella », humeur : « Heureuse », date_naissance : 2007-04-01 aboiement : [ { texte : « j’ai mangé de la pâtée » commentaires : [ { id_chien : « chien_4 », } texte : « on s’en fout! » } ] ] } Document(V2) Bases de données NOSQL BD orientées colonnes  Évolution des BD clef/valeur  Ressemble aux SGBDR, mais avec un nombre de colonnes dynamique, différent d’un enregistrement à un autre (pas de colonnes portant les valeurs NULL)  Offrent de très hautes performances et une architecture hautement évolutive. 16 Bases de données NOSQL 17 Exemples : Hbase (Hadoop), Cassandra (Facebook, Twitter), BigTable (Google) ID Nom Prénom Prime 1 Doe John 8000 2 Smith Jane 4000 3 Beck Sam 1000 Dans une BD orientée Colonnes les données sont stockées comme suit : 1,2,3;Doe,Smith,Beck;John,Jane,Sam;8000,4000,1000; Bases de données NOSQL BD orientées Graphes  Basées sur les théories des graphes  S’appuient sur les notions de nœuds, de relations et des propriétés qui leur sont rattachées  Conçues pour les données dont les relations sont représentées comme graphes, et ayant des éléments interconnectés, avec un nombre indéterminé de relations entre elles.  Adapté aux traitements des données des réseaux sociaux  Exemples : Neo4J et InfiniteGraph, OrientDB 18 Bases de données NOSQL 19 Id Nom Humeur Date_naissance Couleur 12 Stella Heureuse 2007-04-01 NULL 13 Wimma Faim NULL Noire 9 Ninja NULL NULL NULL Chien_12 Chien Stella Heureuse 2007-04-01 Aboiement_ 5 9 Commentaire _ 83 « On s’en fout! » « J’ai mangé de la pâtée! » type nom humeur date_naissance aboiements Commentaire_à texte Chien_4 commente texte NOSQL vs BDR Le choix de NOSQL plutôt que les bases de données relationnelles est conduit par les contraintes du marché et les besoins techniques suivants :  Big Data Adaptation des BD NOSQL aux Big Data o Vitesse (Velocity) : beaucoup de données qui arrivent rapidement, à partir de plusieurs sources o Variété (Variety) : données structurées, semi-structurées ou non-structurées o Volume (Volume) : données massives (To et Po) 20 NOSQL vs BDR  Modèles de données flexibles o Une des raisons majeures o Dans le modèle relationnel :  Les relations entre les tables sont prédéfinies, fixes et organisées dans un schéma strict et uniforme  Problèmes d’évolutivité et de performance en gérant de grands volumes de données. o Les BD NOSQL peuvent accepter tout type de données (structurées, semi-structurées ou non-structurées) plus facilement. o Dans les BDR, les performances posent problème, surtout quand des lignes « larges » sont utilisées et les actions de modification sont nombreuses. 21 NOSQL vs BDR  Disponibilité continue des données ◦Le manque de disponibilité peut être fatal pour une entreprise. ◦BD NOSQL utilisent une architecture hautement distribuée : pas de SPOF ◦Redondance des données et traitements : tolérance aux fautes ◦Toute mise à jour ou modification est faite sans déconnecter la base 22 NOSQL vs BDR  Indépendance de l’emplacement oPossibilité de consulter et modifier une BD sans savoir où est-ce que ces opérations ont réellement lieu. oToute fonctionnalité d’écriture est propagée à partir d’un emplacement, pour être disponible aux utilisateurs à partir d’autres sites. 23 NOSQL vs BDR  Capacité des bases NOSQL à exploiter les données collectées pour dériver des idées oExtraction d’informations décisionnelles à partir d’un grand volume de données : difficile à obtenir avec des bases relationnelles. oBases NOSQL permettent le stockage et la gestion des données des applications métier, et fournissent une possibilité de comprendre les données complexes, et de prendre des décisions. 24 NOSQL vs BDR  Capacités transactionnelles modernes oNouvelles définitions du principe de transaction oUtilisation des propriétés BASE au lieu des propriétés ACID 25 NOSQL vs BDR Toutes les BDR supportent les transactions ACID. Mais : ◦Données de plus en plus volumineuses + Besoin de systèmes évolutifs. ◦Besoin de BD distribuées sur le réseau, pour une évolutivité horizontale. 26 NOSQL vs BDR Théorème CAP : Dans les systèmes distribués, il est impossible de satisfaire les trois propriétés CAP en même temps. CAP = Consistency, Availability, Partition Tolerance 27 NOSQL vs BDR Pourquoi est-il impossible de satisfaire les 3 propriétés CAP en même temps? Soit un système distribué. On est entrain de modifier une donnée sur le nœud N1 et d’essayer de la lire à partir du nœud N2 : N2 peut retourner la dernière bonne valeur dont il dispose, ce qui viole la Consistance. N2 attend que la nouvelle valeur lui parvienne. Comme c’est un système distribué, les risques d’un échec de transmission sont assez importantes, ce qui provoquera une attente infinie de N2. D’où une violation de la Disponibilité. Si on veut satisfaire à la fois la consistance et la disponibilité, le système de stockage ne doit pas être partitionné. D’où violation de la Tolérance au partitionnement. 28 NOSQL vs BDR BASE Basically Available Le système garantit la disponibilité, comme définie dans le théorème CAP Soft-State L’état du système peut changer dans le temps, même sans nouvelles entrées, et ce à cause du principe de consistance éventuelle. Eventual Consistency Les modifications arriveront éventuellement à tous les serveurs, si on leur donne suffisamment de temps. 29 NOSQL vs BDR - Synthèse Bases de données NOSQL : o Performances sur de gros volumes de données o Performances sur des données non structurées o Evolutivité très importante, même pour de faibles volumes Cependant :  Technologie assez jeune => Manque d’outils la supportant  Encore en évolution, pas de standards  Pas de langage de requête commun comme SQL, mais divers : o Requêtes spécifiques au langage (Java, uploads/Management/ module-1-sql-vers-nosql.pdf