Chapitre V: Bases de données NOSQL

Chapitre V : Bases de données NOSQL Plan  Forces des SGBD  Propriétés ACID  Limites des BDR  BD NOSQL  BDR vs BD NOSQL  Etude d’instances de BD NOSQL Cassandra MongoDB 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 Types des bases de données NOSQL : Clef/valeur Orientées colonnes Orientées documents Orientées graphes 9 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 Id Nom Humeur Date_naissance Couleur 12 Stella Heureuse 2007-04-01 NULL 13 Wimma Faim NULL Noire 9 Ninja NULL NULL NULL 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 Id Nom Humeur Date_naissanc e Couleur 12 Stella Heureuse 2007-04-01 NULL 13 Wimma Faim NULL Noire 9 Ninja NULL NULL NULL Document(V2) { type: « Chien», nom : « Stella», humeur : « Heureuse», date_naissance : 2007-04-01 aboiement : [ { texte: « j’ai mangédela pâtée» commentaires :[ { id chien : « chien 4», Document(V1) } []] ] } } 15 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 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; 17 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 Id Nom Humeur Date_naissance Couleur 12 Stella Heureuse 2007-04-01 NULL 13 Wimma Faim NULL Noire 9 Ninja NULL NULL NULL 19 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 o Possibilité de consulter et modifier une BD sans savoir où est-ce que ces opérations ont réellement lieu. o Toute 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 o Extraction d’informations décisionnelles à partir d’un grand volume de données : difficile à obtenir avec des bases relationnelles. o Bases 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 o Nouvelles définitions du principe de transaction o Utilisation 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, Python…) o Requêtes spéciales pour la base (Cassandra Query Language) o API basée sur Map Reduce… 30 NOSQL vs BDR Quand utiliser NOSQL? Si l’évolutivité est une préoccupation Mais attention, ce n’est pas toujours un MUST : Flickr et Wikipédia utilisent des SGBDR Si l’absence de schéma est une préoccupation Si être IN et FASHION est une préoccupation Pour un nombre important de personnes, l’utilisation d’un nouveau paradigme ou technologie est nécessaire ! 31 Cassandra Base de données :  Distribuée  À haute performance  Extrêmement évolutive  Tolérante aux fautes (pas de SPOF)  Non-relationnelle Peut être utilisée à la fois comme :  Base de données temps réel  Base de données pour une lecture intensive pour les systèmes décisionnels 32 Cassandra - Architecture  Inspirée de Big Table  Cassandra est développée par Facebook en 2007  En 2008, le projet est cédé à la fondation Apache et devient "top-level-project" à partir de 2010.  Indépendante de Hadoop 33 Cassandra - Architecture Lecture et écriture à partir de n’importe quel nœud, indépendamment de l’emplacement des données. Utilisation du protocole Gossip pour la communication entre les différents nœuds du cluster. 34 Cassandra - Architecture Structure orientée colonnes Vocabulaire : Keyspace Column Row Column Family 35 Cassandra - Architecture Colonne (Column) : une colonne est composée d'un nom, d'une valeur et d'un timestamp (instant de création). Ligne (Row) : les colonnes sont regroupées en Rows. Une Row est représentée par une clé et une valeur . Il existe deux types de rows : les « wide row » permettant de stocker énormément de données, avec beaucoup de colonnes et les « skinny row » permettant de stocker peu de données. 36 Cassandra - Architecture Une famille de colonnes (Column family) : c'est l'objet principal de données et peut être assimilé à une table dans le monde des bases de données relationnelles. Toutes les rows sont regroupées dans les column family. Une famille de colonnes regroupe un ensemble de colonnes destinées à être consultées ensemble pour satisfaire les requêtes spécifiques à l'application. Keyspace : c'est l'équivalent d'une base de données dans le monde du relationnel. À noter qu'il est possible d'avoir plusieurs « Keyspaces » sur un même serveur. 37 Cassandra - Architecture Il y a deux types de familles de colonnes : Les familles de colonnes statiques : elles utilisent un ensemble statique de noms de colonne et sont très similaires à une table d'une base de données relationnelle même si toutes les colonnes n'ont pas à être obligatoirement renseignées . Les familles de colonnes dynamiques : elles permettent, par exemple, de précalculer un ensemble de résultats et de les stocker dans une même ligne afin de pouvoir y accéder plus tard. Chaque ligne correspond donc à un snapshot de données correspondant à une requête donnée. 38 Partitionnement Partitionnement facile des données à travers les différents nœuds participants du cluster Chaque nœud accueille une partie de la base de données Les données sont insérées par l’utilisateur dans une famille de colonnes 39 Partitionnement Stratégies de partitionnement Partitionnement aléatoire o Par défaut, recommandé o Données partitionnées le plus équitablement possible à travers les différents nœuds o Utilisation de MD5 (ou Murmur3) pour le hachage de chaque clef de ligne 40 Partitionnement Partitionnement ordonné o Sauvegarde les clefs des lignes par ordre à travers les nœuds d’un cluster o Peut provoquer des problèmes, surtout pour la répartition des charges (des nœuds avec des données plus volumineuses que d’autres) Stratégie spécifiée dans un fichier de configuration cassandra.yaml Si la stratégie d’une base est modifiée, il faut recharger toutes les données 41 Cassandra - Réplication Pour assurer la tolérance aux pannes, il est possible de créer une ou plusieurs copie(s) de chaque colonne à travers les nœuds participants. L’utilisateur spécifie le facteur de réplication désiré à la création du keyspace. Les données sont insérées par l’utilisateur dans une famille de colonnes. La colonne est répliquée dans les nœuds du cluster selon le facteur de réplication. 42 Cassandra - Réplication Stratégies de réplication Stratégie Simple : o La colonne originelle est placée sur un nœud déterminé par le partitionneur . o La réplique est placée sur le nœud suivant de l’anneau (clockwise). o Pas de considération de l’emplacement dans un data center ou dans une baie (approprié pour les déploiements sur un seul data center) 43 Cassandra - Réplication Stratégie par topologie du réseau : o Plus sophistiquée o Plus de contrôle sur l’emplacement des répliques de colonnes o Parcourt le cluster (clockwise) à la recherche d’un nœud dans une baie différente . o Si introuvable, stocker la colonne dans un nœud de la même baie o Un groupe de réplication est spécifié, pour distinguer entre plusieurs data centers . 44 Cassandra - Réplication Mécanisme de réplication Utilisation de SNITCH : o Définition de la manière dont les nœuds sont groupés dans un réseau o Répartition des nœuds entre baies et data centers o Défini dans le fichier de configuration cassandra.yaml 45 Cassandra - Réplication CREATE KEYSPACE MonEspaceDeCle WITH REPLICATION = { 'class' : 'SimpleStrategy', 'replication_factor' : 3 }; USE MonEspaceDeCle; CREATE COLUMNFAMILY MesColonnes (id, Nom, Prenom, PRIMARY KEY (id)); INSERT INTO MesColonnes (id, Nom, Prenom) VALUES ('1', 'Doe', 'John'); SELECT * FROM MesColonnes; 46 Cassandra - Consistance Sur Cassandra l’écriture de données se fait : o Dans un premier temps dans un journal de commit ; o Puis dans une structure en mémoire appelée Memtable. o Les données sont écrites de façon périodique sur le disque dans une structure appelée SSTable . => Moins d’entrées/sorties disque au moment de l’écriture  Cassandra est optimisée pour permettre une écriture rapide et hautement disponible des données avec un débit élevé. 47 Cassandra - Consistance Consistance : à quel point est-ce qu’une donnée est à jour et synchronisée sur toutes ses répliques. Extension du concept de consistance éventuelle à une consistance ajustable. Choix possible entre une consistance forte ou éventuelle selon les besoins Ce choix est fait par opération , ce n’est pas une stratégie globale pour la base de données (ex, pour changer la stratégie de lecture en quorum) SELECT - FROM users USING CONSISTENCY QUORUM WHERE state=‘TX’; 48 Cassandra–Stratégies d’écriture Niveau de consistance : combien de répliques doivent être écrites avec succès avant de retourner un acquittement au client. 49 Niveau de consistance Description Any Une écriture doit être faite sur au moins un nœud même si c’est un hinted handoff . ~~Offre la plus haute disponibilité, mais la plus basse consistan~~ce One (défaut dans CQL) Une écriture doit réussir sur le commit log et la memtable d’au moins une réplique. Quorum Une écriture doit réussir sur un certain pourcentage de répliques (pourcentage = (facteur de réplication/2)+1) Meilleure alternative en terme de consistance et de disponibilité Local-Quorum Une écriture doit réussir sur un certain pourcentage de nœuds répliques sur le même data center que le nœud coordinateur Each-Quorum une écriture doit réussir sur un certain pourcentage de nœuds répliques sur tous les data centers. All une écriture doit réussir sur tous les nœuds répliques d’une colonne. Offre la plus haute consistance, mais la plus basse disponibilité 50 Cassandra–Stratégies d’écriture Hinted Handoff : cette fonctionnalité permet de synchroniser un nœud qui est indisponible pour une petite période de temps. Une écriture est toujours envoyée à tous les réplicas. Si un réplica n’est pas disponible, les autres réplicas gardent une information indiquant qu’une écriture est en attente pour ce nœud et lorsqu’il est de nouveau disponible ils lanceront l’écriture. 51 Cassandra-Stratégies de lecture Niveau de consistance : combien de répliques doivent répondre avant de retourner le résultat. 52 Col1 Col2 One (défaut dans CQL) : Obtention d’une réponse à partir de la réplique la plus proche selon le SNITCH. ~~Offre la plus faible consistance, mais la plus haute disponibilit~~é Quorum Obtention du résultat le plus récent à partir d’un certain pourcentage de nœuds répliques (pourcentage = (facteur de réplication /2)+1) Meilleure alternative en terme de consistance et de disponibilité Local-Quorum Obtention du résultat le plus récent à partir d’un certain pourcentage de nœuds répliques sur le même datacenter que le nœud coordinateur Évite la latence due à la communication inter-datacenters Each-Quorum Obtention du résultat le plus récent à partir d’un certain pourcentage de nœuds répliques sur tous les datacenters All Obtention du résultat le plus récent à partir de tous les nœuds répliques Offre la plus haute consistance, mais la plus basse disponibilité 53 Cassandra-Stratégies de lecture Read Repair Cassandra assure que les données fréquemment lues soient consistantes. À la lecture d’une donnée, le nœud coordinateur compare toutes ses répliques en arrière plan. Si ces données ne sont pas consistantes, il envoie une demande d’écriture aux nœuds réplicas pour mettre à jour leur donnée et afficher la donnée la plus récente. Read Repair peut être configuré par famille de colonnes et est activé par défaut. 54 Cassandra Deux interfaces pour gérer les objets/données : Cassandra CLI (Command Line Interface) Interface originelle conçue pour créer des objets, entrées et manipuler les données. CQL (Cassandra Query Language) Utilisée pour créer/manipuler des données en utilisant un langage proche de SQL 55 Cassandra Les objets tels que les keyspaces, les familles de colonnes et les index sont créés, modifiés et supprimés avec les commandes usuelles : CREATE, ALTER et DROP Données insérées, modifiées et supprimées avec INSERT, UPDATE et DELETE Données lues avec SELECT Utiliser la clause USING CONSISTENCY pour déterminer le type de consistance forte pour chaque opération de lecture et l’écriture (Any, One, Quorum…). 56 Cassandra - Récapitulation Grande Scalabilité Pas de SPOF Réplication et distribution des données facile à travers les data centers Consistance des données ajustable Possibilité de choisir pour chaque opération si une donnée est fortement consistante (tous les nœuds sont similaires à tout moment) ou éventuellement consistante. Schéma de données flexible Langage CQL très proche de SQL 57 MongoDB SGBD NOSQL orienté documents, à schéma flexible et distribuable. MongoDB (de Humongous, qui veut dire énorme) Écrit en C++ Distribué sous licence AGPL ( GNU Affero General Public License ) Développé en 2007 par la firme MongoDB 58 MongoDB Compagnie fondée en 2007 par les anciens de 10gen dont l’objectif était de construire une offre PAAS (cloud). Ils n’ont pas trouvé un SGBD suffisamment élastique pour l’intégrer à leur offre ; ils ont développé MongoDB MongoDB était tellement populaire qu’ils ont abandonné leur offre Cloud au profit de celui-ci. Changement de nom : 10gen est devenue MongoDB 59 MongoDB Un des SGBD les plus utilisés. Exemples d’utilisateurs : eBay Foursquare SourceForge.net Viacom Pagesjaunes New York Times 60 MongoDB MongoDB est livré avec des liaisons pour les principaux langages de programmation : C , C++, Dart, Erlang, Go, Haskell, Java, JavaScript, .NET (C# F#, PowerShell,…), Perl, PHP, Python, Ruby, Scala. MongoDB possède un outil qui peut être utilisé en ligne de commande. Cet outil permet de manipuler la base de données à travers son langage : Javascript. 61 MongoDB Table Acteur Dans le modèle relationnel : Id Nom Prénom 1 Johansson Scarlett 2 Phoenix Joaquim Table Film Table jointure Acteur_Film Acteur_id Film_id 1 10 1 20 2 10 62 Id titre 10 Her 20 Avengers MongoDB Dans MongoDB : Les films peuvent être modélisés selon des documents comme suit : { _id : "Her", Document acteurs : [{nom:"Johansson", prenom:"Scarlett"}, {nom:"Phoenix", prenom:"Joaquim"}]} Duplication de l’acteur : inacceptable en relationnel mais tout à fait possible en NOSQL dans l’objectif d’améliorer les performances { _id : "Avengers", acteurs : [{nom:"Johansson", prenom:"Scarlett"}]} 63 MongoDB Dans un document , des champs peuvent être ajoutés, supprimés, modifiés et renommés à tout moment. La structure d'un document est très simple et se compose de paires clef/valeur, la clef est le nom Nom du champ du champ, la valeur son contenu. {_id: "Avengers", acteurs : [{nom:"Johansson", prenom:"Scarlett"}]} Valeur Les deux sont séparés d'un signe deux-points ":". Une "valeur" peut être un nombre, du texte, une donnée binaire (comme une image) ou une collection d'autres paires clefs/valeurs. 64 MongoDB : document Le champ _id :  Seul champ obligatoire , utilisé comme clef primaire dans une collection  Peut-être de tout type autre que Tableau Les noms des champs ne peuvent pas : commencer par un $, contenir le caractère « . » ou le caractère « null ». 65 MongoDB Structure de données JSON-like, composée de paires clef/valeur. Stocké sur le disque sous forme de document BSON : Documents BSON (Binary JSON) : représentation binaire sérialisées d’un document JSON ; Supporte plus de types de données que JSON ; La partie valeur peut avoir n’importe quel type supporté par JSON, dont d’autres documents, des tableaux, et des tableaux de documents. 66 MongoDB : document La structure du document n’est pas fixée à sa création mais en général, les documents d’une même collection ont une structure similaire (homogénéité). Les documents sont organisés sous forme de collections : groupe de documents reliés par des indexes en commun. 67 MongoDB Col2 Terminologie SQL Terminologie MongoDB Base de données Base de données Table Collection Ligne Document Colonne Champ Index Index Jointure Imbrication ou Référence Clef Primaire (peut être multiple) Clef Primaire (une seule, et représentée par le champ _id) 68 Exemple MongoDB Deux manières d’exprimer les relations entre les données : Références et Données Imbriquées Références Inclusion de liens ou références d’un document à un autre C’est à l’application de résoudre ces références pour accéder aux données associées On dit qu’on utilise des Modèles de Données Normalisés 70 MongoDB 71 MongoDB Données Imbriquées (Embedded Data) Sauvegarde des données associées dans la même structure de documents Il est possible d’inclure des documents dans un champ ou un tableau Permet aux applications d’extraire et manipuler plusieurs niveaux de hiérarchie en une seule instruction Ce sont les Modèles de Données Dénormalisés 72 MongoDB 73 MongoDB Comment choisir entre Références et Données Imbriquées? On choisit les références quand : L’imbrication va produire des données dupliquées sans grands avantages en terme de performance de lecture On veut représenter des relations many-to-many complexes On veut modéliser de larges ensembles de données hiérarchiques 74 MongoDB On choisit les données imbriquées quand : On a des relations contains entre les éléments (modèles one-to-one) Exemple: personne et adresse On a des relations one-to-many, où les documents fils (many) apparaissent toujours dans le contexte des documents parents (one) Exemple : personne et plusieurs emails 75 MongoDB : lecture Lecture : Cible une collection unique de documents ; Se base sur un critère ou des conditions spécifiques, pour identifier le document à retourner ; Peut inclure une projection sur les champs du document à retourner ; Peut définir des modificateurs pour imposer des limites, un ordre, un filtre… 76 MongoDB : lecture 77 MongoDB : lecture La méthode db. collection.find() : Permet l’extraction de données en se basant sur des critères ; Accepte les projections ; Retourne un curseur vers les documents correspondants. La méthode db. collection.findOne() se comporte de la même manière que la méthode find mais elle retourne un seul document 78 MongoDB : lecture 79 MongoDB : lecture Projections : Deuxième argument de la méthode find() Peuvent spécifier la liste des champs à afficher ou à exclure A part le champ _id (qui est affiché par défaut), il est interdit de mixer les projections inclusives et exclusives des différents champs 80 MongoDB : lecture 81 MongoDB : écriture Création, mise à jour ou suppression de document ; Ciblent une seule collection ; Se basent sur un ou plusieurs critères pour sélectionner les documents à modifier ou supprimer. 82 MongoDB : écriture Insertion d’un document Si on ne définit pas le champ 83 MongoDB : écriture Mise à jour de documents Méthode update peut accepter des critères de sélection des documents à modifier, et des options qui affectent son comportement. L’opération update : Par défaut, modifie un seul document Plusieurs documents si l’option multi est à true 84 MongoDB : écriture 85 MongoDB : écriture La méthode remove supprime des documents d’une collection Accepte des critères de sélection des documents à supprimer Supprime par défaut tous les documents correspondants aux critères de sélection (sauf indication du contraire dans un flag approprié) 86 MongoDB : écriture Les opérations d’écriture sont atomiques au niveau d’un document. L’utilisation des données imbriquées facilite l’écriture. La normalisation des données (référence vers données dans d’autres collections) implique plusieurs opérations d’écriture qui ne sont pas atomiques. 87 MongoDB : écriture Certaines modifications (un push dans des tableaux, ou bien un ajout d’un champ) augmentent la taille des documents. Pour le moteur de stockage MMAPv1, si la taille d’un document dépasse la taille autorisée pour ce document, MongoDB le réalloue sur le disque. Si l’application en question nécessite plusieurs modifications qui augmentent la taille des documents, il vaut mieux opter pour l’utilisation des références. 88 MongoDB : load balancing MongoDB utilise le sharding pour stocker ses données dans le cluster. Le sharding est utilisé pour faire du scaling horizontal . Il s’agit de créer un cluster MongoDB (appelé sharded cluster) composé de plusieurs machines sur lesquelles les données contenues dans notre base vont être réparties. L’atout principal d’un sharded cluster est le load balancing (répartition de charge) :  Données réparties sur un grand nombre de nœuds différents ;  Requêtes se feront sur de plus petits jeux de données et pourront être parallélisées => temps de réponse plus rapides 89 MongoDB Scaling vertical vs scaling horizontal https://www.supinfo.com/articles/single/4761-mongodb-sharding 90 MongoDB Trois types de composants dans un cluster MongoDB : Le serveur de configuration :  Stocke les métadonnées et les paramètres de configuration du cluster.  Permet de localiser les données sur les shards. Les shards :  Stockent les données. Peuvent être ajoutés pour agrandir la capacité de stockage et la puissance de calcul. Un ou plusieurs routeurs :  Communique avec le serveur de configuration pour connaître la répartition des données et donc choisir le bon shard => assure le routage des requêtes.  Assure l’équilibrage de charge.  Joue le rôle d’interface entre l’application cliente et le sharded cluster. 91 MongoDB MongoDB propose un mécanisme de réplication basé sur le « replica set » afin de se prémunir de la perte de données et assurer la continuité des services. Un « replica set » : est un groupe d’instances qui maintiennent le même ensemble de données. Il se compose d’un nœud primaire et de nœuds secondaires . Les opérations ont lieu sur le nœud primaire , puis elles sont reproduites sur les nœuds secondaires. Dans le cas où le nœud primaire ne répond pas pendant 10 secondes , un nœud secondaire est élu comme nouveau nœud primaire. Ce processus est rapide (environ une minute), automatique et complètement transparent pour l’utilisateur. 92 MongoDB Election d’un nouveau primaire https://www.supinfo.com/articles/single/4761-mongodb-sharding 93 MongoDB Pour qu’un nœud soit élu primaire, il doit obtenir une majorité qualifiée. Exp : Dans un réplica composé de 3 nœuds, pour être élu il faut au moins 2 votes. Si 2 serveurs tombent en panne, le nœud restant n’aura qu’un seul vote, il ne pourra donc pas être élu => les données ne seront plus accessibles. Quand on choisit le nombre de nœuds du réplica il faut s’assurer qu’en cas de panne, un nouveau nœud primaire pourra être élu. 94 MongoDB Pour éviter les situations d’élection impossible , il faut ajouter un arbitre au réplica set. Un arbitre est un nœud qui ne contient pas de données et qui consomme très peu de ram. Il sert uniquement à s’assurer qu’un des nœuds aura la majorité qualifiée lors de l’élection. L’arbitre ne doit pas être sur le même serveur que les autres membres du réplica set. Pour savoir si une élection peut avoir lieu : si on appelle N le nombre de nœuds, pour qu’un nœud soit élu il doit avoir un nombre de votes strictement supérieur à N/2 . L’arbitre permet d’ajouter un vote, sans changer la valeur de N (il ne compte pas comme un nœud). 95 MongoDB Pour profiter pleinement du scaling horizontal, le routeur de MongoDB répartit uniformément les données sur les différents shards. Ce partitionnement se fait au niveau des collections et s'appuie sur une clé de sharding . MongoDB définit un intervalle de valeurs sur cette clé pour chaque shard. Il faut choisir un champ présent dans tous les documents de la collection. 96 MongoDB Ainsi, les opérations (requêtes portant sur la clé de sharding, ajout de document) porteront uniquement sur le shard concerné donc sur un sousensemble de données => Temps de réponse beaucoup plus court . Si la requête s’applique sur plusieurs shards => elle s’effectue en parallèle. Le choix de la clé est très important puisqu’il impacte l’efficacité des requêtes et la possibilité d’agrandir le cluster (possibilité d’ajouter des machines, scalabilité). 97 Conclusion Quand utilise-t-on MongoDB ? Données semi-structurées Peu de relations Besoin d’élasticité Besoin de programmer aisément Licence libre 98 Conclusion Le scaling horizontal, permet de faire face à plusieurs limites techniques et assure de vraies économies. Mais il implique un plus grand risque de panne. Le sharding est un mécanisme proposé par MongoDB pour créer un cluster hautement disponible : sharded cluster. Le « replica set » est un mécanisme de réplication qui rend le cluster tolérant aux pannes en le prémunissant contre la perte partielle de données. Un sharded cluster permet d’équilibrer la charge entre les différentes machines (load balancing). 99