Les BD NoSQL

1. Les bases de données NoSQL par Minyar Sassi Hidri Département Technologies de l’Information et de la Communication Ecole Nationale d’Ingénieurs de Tunis Novembre 2016 Minyar Sassi Hidri Les BDs NoSQL 1 / 194

2. Plan 1 Chapitre 1 : Big Data et NoSQL 2 Chapitre 2 : MongoDB 3 Chapitre 3 : Cassandra 4 Chapitre 4 : Les autres BDs de la mouvance NoSQL 5 Chapitre 5 : Mise en œuvre d’une base NoSQL Minyar Sassi Hidri Les BDs NoSQL 2 / 194

3. Chapitre 1 - Big Data et NoSQL 1 Mouvement NoSQL 2 Taxonomie des bases NoSQL 3 Technologies communément utilisées dans les bases NoSQL 4 Avantages / Inconvénients des bases NoSQL Minyar Sassi Hidri Les BDs NoSQL 3 / 194

4. Mouvement NoSQL 1 Mouvement NoSQL Nouveaux besoins en gestion de données Limites des systèmes SGBD classiques Racines et concepts fondateurs Caractéristiques générales des BD NoSQL 2 Taxonomie des bases NoSQL BD NoSQL Clé/Valeur (Key/Value Store) BD NoSQL orientées Colonnes BD NoSQL orientées documents BD NoSQL orientées graphes 3 Technologies communément utilisées dans les bases NoSQL Prise en charge de l’extensibilité Partitionnement dans les systèmes NoSQL Compromis sur la Cohérence Consultation de données : MapReduce 4 Avantages / Inconvénients des bases NoSQL Minyar Sassi Hidri Les BDs NoSQL 4 / 194

5. Mouvement NoSQL Nouveaux besoins en gestion de données Nouveaux besoins en gestion de données Système distribué I Système distribué = système logiciel qui permet de coordonner plusieurs ordinateurs. Généralement, cette coordination se fait par envoi de messages via un réseau auquel sont reliés ces ordinateurs. I Pourquoi ? parce qu’on manipule un très grand volume de données. Sans distribution, on n’a pas d’application scalable. I 2 scénarios de traitement des données : 1. Par distribution des traitements (scaling des traitements) : - On distribue les traitements sur un nombre de machines important afin d’ab- sorber des charges très importantes. - On envoie les données aux endroits appropriés, et on enchaîne les exécutions distantes (scénario type Workflow implémentable avec des Web services). 2. Par distribution des données (scaling des données) : - On distribue les données sur un nombre important de serveurs afin de stocker de très grands volumes de données. - On pousse les programmes vers ces serveurs (plus efficace de transférer un petit programme sur le réseau plutôt qu’un grand volume de données - Ex : algorithme MapReduce). Minyar Sassi Hidri Les BDs NoSQL 5 / 194

6. Mouvement NoSQL Nouveaux besoins en gestion de données Système distribué Exemple : Data Centers I Utilise des LANs (Local Area Networks). On distingue 3 niveaux de communication : 1. Les serveurs sont regroupés en racks. Liaison réseau rapide, environ 1Go/sec. 2. Un data center consiste en un grand nombre de racks, interconnectés par des routeurs (switches). Liaison à 100 Mo/sec. 3. Entre diﬀérents data centers, il y a aussi une possibilité de communication mais par liaison assez lente (internet - 2-3 Mo/sec). I Les serveurs communiquent par envoi de messages, ils ne partagent pas de disque ni de ressources de traitement ⇒ Architecture shared nothing. I Début 2010 : 1 data center Google contient entre 100 et 200 racks, chacun contenant 40 serveurs. Environ 5000 serveurs par data-center pour un total de 1 millions de serveurs (estimation d’après la consommation électrique). I Data center de Facebook (2010) : 2500 CPU (serveurs), 1 PetaByte d’espace disque (= milleTerabytes = 1 million de Gigabytes), plus de 250 Gigabytes données compressées (plus de 2 Terabytes non compressés). Minyar Sassi Hidri Les BDs NoSQL 6 / 194

7. Mouvement NoSQL Limites des systèmes SGBD classiques Limites des systèmes SGBD classiques SGBD Relationnels offrent : I Un système de jointure entre les tables permettant de construire des requêtes complexes impliquant plusieurs entités. I Un système d’intégrité référentielle permettant de s’assurer que les liens entre les entités sont valides. Contexte fortement distribué : Ces mécanismes ont un coût considérable : I Avec la plupart des SGBD relationnels, les données d’une BD liées entre elles sont placées sur le même nœud du serveur. I Si le nombre de liens important, il est de plus en plus difficile de placer les données sur des nœuds différents. Minyar Sassi Hidri Les BDs NoSQL 7 / 194

8. Mouvement NoSQL Limites des systèmes SGBD classiques Limites des systèmes SGBD classiques I SGBD Relationnels sont généralement transactionnels ⇒ Gestion de transactions respectant les contraintes ACID (Atomicity, Consistency, Isolation, Durability). I Le modèle ACID est un des plus anciens et des plus importants concepts à l’origine des SGBD actuels. Il définit quatre principes que toute BDR doit atteindre : - Atomicité : Tout ou rien. - Cohérence : Les transactions qui modifient l’état de la base font en sorte que les contraintes d’intégrité référentielle sont respectées. - Isolation : Une transaction ne peut pas accéder aux données mise à jour par une autre transaction avant qu’elle ne soit validée par son propriétaire. - Durabilité : Toute transaction validée (commitée) est assurée d’être prise en compte quelque soit la panne (transaction logs permettant de rejouer les modifications en cas de restauration). Minyar Sassi Hidri Les BDs NoSQL 8 / 194

9. Mouvement NoSQL Limites des systèmes SGBD classiques Limites des systèmes SGBD classiques Constat : I Essor des très grandes plate-formes et applications Web (Google, Facebook, Twitter, LinkedIn, Amazon,...). I Volume considérable de données à gérer par ces applications nécessitant une distribution des données et leur traitement sur de nombreux serveurs. I Ces données sont souvent associées à des objets complexes et hétérogènes. ⇒ Limites des SGBD traditionnels (relationnels et transactionnels) basés sur SQL. ⇒ D’où, nouvelles approches de stockage et de gestion des données : I Permettant une meilleure scalabilité dans des contextes fortement distribués. I Permettant une gestion d’objets complexes et hétérogènes sans avoir à déclarer au préalable l’ensemble des champs représentant un objet. I Regroupées derrière le terme NoSQL (Not Only SQL), proposé par Carl Strozzi, ne se substituant pas aux SGBD Relationnels mais les complètant en comblant leurs faiblesses. Minyar Sassi Hidri Les BDs NoSQL 9 / 194

10. Mouvement NoSQL Limites des systèmes SGBD classiques Limites des systèmes SGBD classiques I Nécessaire de distribuer les traitements de données entre diﬀérents serveurs. I Diﬃcile de maintenir les contraintes ACID à l’échelle du système distribué entier tout en maintenant des performances correctes. ⇒ La plupart des SGBD NoSQL relâchent les contraintes ACID, ou même ne proposent pas de gestion de transactions. I BDs NoSQL : - Ce n’est pas (comme son nom le laisse supposer) NoSQL (pas de SQL). - Privilégier donc NOSQL plutôt que NoSQL. I BDsnon-relationnelles et largement distribuées. I Permet une analyse et une organisation rapides des données de très grands volumes et de types de données disparates. I Appelées également : - Cloud Databases. - Non-Relational Databases. - Big Data Databases... Minyar Sassi Hidri Les BDs NoSQL 10 / 194

11. Mouvement NoSQL Racines et concepts fondateurs Genèse du NoSQL I 1988 : Le terme à été inventé par Carlo Strozzi qui présentait le NoSQL comme un modèle de BD plus léger et sans interface SQL. I Juin 2009 - Meetup NoSQL de San Francisco : Le mouvement NoSQL à prit un essor important. Plus de 100 développeurs de logiciels ont assisté à des présentations de solutions telles que Project Voldemort, Cassandra Project, Dynomite, HBase, Hypertable, CouchDB et MongoDB. I 2011 : Un travail de spéciﬁcation pour un langage de manipulation standar- disé a débuté sous le nom de UnQL (Unstructured Query Language). Il se propose de formaliser la fac¸on dont les bases NoSQL requêtent les collections (équivalent des tables pour les BDR). ⇒ Le NoSQL est issu du travail des grands acteurs d’Internet (Google, Amazon, Facebook, LinkedIn,...) en écho aux nouvelles architectures (Cloud, Grille de calcul, etc.). Minyar Sassi Hidri Les BDs NoSQL 11 / 194

12. Mouvement NoSQL Racines et concepts fondateurs Potential des BD NoSQL dans l’entreprise http ://www.pwc.com/us/en/advisory/business-digital-technology-trends-nosql-databases.html Minyar Sassi Hidri Les BDs NoSQL 12 / 194

13. Mouvement NoSQL Racines et concepts fondateurs Théorème de CAP (Brewer, 2000) I L’émergence du NoSQL est liée au théorème de CAP (Coherence (Cohérence), Availibility (Disponibilité), Partition-Tolerance (Résistance au morcellement). I Cohérence ou Consistance : Tous les nœuds du système voient exactement les mêmes données au même moment. I Availability ou Disponibilité : L’échec d’un nœud n’empêche pas les survivants de continuer à fonctionner. I Partition-tolerance ou Résistance au partitionnement : Le système étant partitionné, aucune panne moins importante qu’une coupure totale du réseau ne doit l’empêcher de répondre correctement (en cas de partitionnement en sous-réseaux, chacun doit pouvoir fonctionner de manière autonome). ⇒ Dans un système distribué, il est impossible d’obtenir ces 3 propriétés en même temps, il faut en choisir 2 parmi les 3. Minyar Sassi Hidri Les BDs NoSQL 13 / 194

14. Mouvement NoSQL Racines et concepts fondateurs Théorème de CAP I Les SGBDR assurent les propriétés de Consistance et de Disponibilité (Avai- lability) ⇒ Système AC. I Les SGBD NoSQL sont des systèmes CP (Cohérent et Résis- tant au partitionnement) ou AP (Dispo- nible et Résistant au partitionnement). Minyar Sassi Hidri Les BDs NoSQL 14 / 194

15. Mouvement NoSQL Racines et concepts fondateurs Théorème de CAP Consistance (Coherence) I Exemple 1 : Une instance de la BD est automatiquement pleinement consistante puisqu’il n’y a qu’un seul nœud qui maintient l’état. I Exemple 2 : Si 2 serveurs de BD sont impliqués, et si le système est conc¸u de telle sorte que toutes les clés de A à M sont conservées sur le serveur 1, et les clés N à Z sont conservées sur le serveur 2, alors le système peut encore facilement garantir la cohérence. I Exemple 3 : Supposons 2 BD avec des répliques. Si une des BD fait une opération d’insertion de ligne, cette opération doit être aussi faite (commi- ted) dans la seconde BD avant que l’opération soit considérée comme complète. - Pour avoir une cohérence de 100% dans un tel environnement répliqué, les nœuds doivent communiquer. - Plus le nombre de répliques est grand plus les performances d’un tel système sont mauvaises. Minyar Sassi Hidri Les BDs NoSQL 15 / 194

16. Mouvement NoSQL Racines et concepts fondateurs Théorème de CAP Disponibilité (Availability) Les BD dans Exemple 1 ou Exemple 2 ne sont pas fortement disponibles : I Exemple 1 : Si le nœud tombe en panne, on perd 100% des données. I Exemple 2 : Si le nœud tombe en panne, on perd 50% des données. I Exemple 3 : Une simple réplication de la BD sur un autre serveur assure une disponibilité de 100%. - Augmenter le nombre de nœuds avec des copies des données (répliques) augmente directement la disponibilité du système, en le pro- tégeant contre les défaillances matérielles. - Les répliques aident à équilibrer la charge d’opérations concurrences, notamment en lecture. Minyar Sassi Hidri Les BDs NoSQL 16 / 194

17. Mouvement NoSQL Racines et concepts fondateurs Théorème de CAP Résistance au partitionnement (Partition-tolerance) I Supposons que soit assuré par réplication consistance et disponibilité, dans le cas de l’exemple 3, supposons 2 serveurs de BD dans 2 Data-Centers diﬀérents, et que l’on perde la connexion réseau entre les 2 Data-Centers, faisant que les 2 BD sont incapables de synchroniser leurs états. I Si vous parvenez à gérer les opérations de lecture/écriture sur ces 2 BD, il peut être prouvé que les 2 serveurs ne seront plus consistants. I Une application bancaire gardant à tout moment l’état de votre compte est l’exemple parfait du problème des enregistrements inconsistants : Si un client retire 1000 euros à Marseille, cela doit être immédiatement répercuté à Paris, aﬁn que le système sache exactement combien il peut retirer à tout . Si le système ne parvient pas à le faire, cela pourrait mécontenter de nombreux clients. I Si les banques décident que la consistance est très importante, et désactivent les opérations d’écriture lors de la panne, alors la disponibilité du cluster sera perdu puisque tous les comptes bancaires dans les 2 villes seront désormais gelés jusqu’à ce que le réseau soit de nouveau opérationnel. Minyar Sassi Hidri Les BDs NoSQL 17 / 194

18. Mouvement NoSQL Caractéristiques générales des BD NoSQL Caractéristiques générales des BD NoSQL I Adoptent une représentation non relationnelle de données. I Ne remplacent pas les BDR mais sont une alternative, un complémentapportant des solutions plus intéressantes dans certains contextes. I Apportent une plus grande performancedans le contexte des applications Web avec des volumétries de données exponentielle. I Utilisent une très forte distributionde ces données et des traitements associés sur de nombreux serveurs. I Pas de schémapour les données ou schéma dynamique. I Données de structures complexesou imbriquées. I Données distribuées : partitionnement horizontal des données sur plusieurs nœuds (serveurs) généralement par utilisation d’algorithmes MapReduce. I Réplication des donnéessur plusieurs nœuds. I Privilégient la Disponibilité à la Cohérence (théorème de CAP) : AP (Disponible + Résistant au partitionnement) plutôt que CP (Cohérent + Résistant au partitionnement). ⇒ N’ont en général pas de gestion de transactions. I Mode d’utilisation : Peu d’écritures, beaucoup de lectures. Minyar Sassi Hidri Les BDs NoSQL 18 / 194

19. Taxonomie des bases NoSQL 1 Mouvement NoSQL Nouveaux besoins en gestion de données Limites des systèmes SGBD classiques Racines et concepts fondateurs Caractéristiques générales des BD NoSQL 2 Taxonomie des bases NoSQL BD NoSQL Clé/Valeur (Key/Value Store) BD NoSQL orientées Colonnes BD NoSQL orientées documents BD NoSQL orientées graphes 3 Technologies communément utilisées dans les bases NoSQL Prise en charge de l’extensibilité Partitionnement dans les systèmes NoSQL Compromis sur la Cohérence Consultation de données : MapReduce 4 Avantages / Inconvénients des bases NoSQL Minyar Sassi Hidri Les BDs NoSQL 19 / 194

20. Taxonomie des bases NoSQL Taxonomie des bases NoSQL I Clé/Valeur (Key/value) : basique, chaque objet est identifié par une clé unique constituant la seule manière de le requêter. - Voldemort, Redis, Riak,.... I Orientées colonnes (Column Store) : permet de disposer d’un très grand nombre de valeurs sur une même ligne, de stocker des relations one-to-many, d’effectuer des requêtes par clé (adaptés au stockage de listes : messages, posts, commentaires, ...). - HBase, Cassandra, Hypertable,.... I Orientées documents (Document Databases) : pour la gestion de collections de documents, composés chacun de champs et de valeurs associées, valeurs pouvant être requêtées (adaptées au stockage de profils utilisateur). - MongoDB, CouchDB, Couchbase,.... I Orientées graphes (Graph Databases) : pour gérer des relations multiples entre les objets (adaptés au données issues de réseaux sociaux,...). - Neo4j, OrientDB,.... Minyar Sassi Hidri Les BDs NoSQL 20 / 194

21. Taxonomie des bases NoSQL Paysage des SGBD NoSQL Minyar Sassi Hidri Les BDs NoSQL 21 / 194

22. Taxonomie des bases NoSQL BD NoSQL Clé/Valeur (Key/Value Store) Key/Value Store I Elles fonctionnent comme un grand tableau associatif et retourne une valeur dont elle ne connaît pas la structure. I Leur modèle peut être assimilé à une table de hachage (hashmap) distribuée. I Les données sont simplement représentées par un couple clé/valeur. I La valeur peut être une simple chaîne de caractères, ou un objet sérialisé. I Cette absence de structure ou de typage ont un impact important sur le requêtage : toute l’intelligence portée auparavant par les requêtes SQL devra être portée par l’applicatif qui interroge la BD. I Implémentations les plus connues : - Amazon Dynamo (Riak en est l’implémentation open source). - Redis (projet sponsorisé par VMWare). - Voldemort (développé par Linkedln en interne puis passage en open source). I Chaque objet est identiﬁé par une clé unique, seule fac¸on de le requêter. Minyar Sassi Hidri Les BDs NoSQL 22 / 194

23. Taxonomie des bases NoSQL BD NoSQL Clé/Valeur (Key/Value Store) Key/Value Store I Leur exploitation est basée sur 4 opéra- tions (CRUD) : - Create : créer un nouvel objet avec sa clé : create(key, value). - Read : lit un objet à partir de sa clé : read(key). - Update : met à jour la valeur d’un objet à partir de sa clé : update(key, value). - Delete : supprime un objet à partir de sa clé : delete(key). + Auxquelles on retrouve couramment associée la fonction rechercher (Search ou LookUp). I Elles disposent généralement d’une simple interface de requêtage HTTP REST accessible depuis n’importe quel langage de développement. I Ont des performances très élevées en lecture et en écriture et une scalabilité horizontale considérable. I Le besoin en scalabilité verticale est faible du fait de la simplicité des opérations eﬀectuées. Minyar Sassi Hidri Les BDs NoSQL 23 / 194

24. Taxonomie des bases NoSQL BD NoSQL Clé/Valeur (Key/Value Store) Key/Value Store Utilisations principales I Dépôt de données avec besoins de requêtage très simples. I Système de stockage de cache ou d’information de sessions distribuées (quand l’intégrité relationnelle des données est non signiﬁcative). I Les proﬁls, préférences d’utilisateur. I Les données de panier d’achat. I Les données de capteurs. I Les logs de données. I .... Minyar Sassi Hidri Les BDs NoSQL 24 / 194

25. Taxonomie des bases NoSQL BD NoSQL Clé/Valeur (Key/Value Store) Key/Value Store Forces et faiblesses Forces : I Modèle de données simple . I Bonne mise à l’échelle horizontale pour les lectures et écritures : - ´Evolutivité (scalable). - Disponibilité. - Pas de maintenances requises lors d’ajout/suppression de colonnes. Faiblesses : I Modèle de données TROP simple : - Pauvre pour les données complexes. - Interrogation seulement sur clé. - Déporte une grande partie de la complexité de l’application sur la couche application elle-même. Minyar Sassi Hidri Les BDs NoSQL 25 / 194

26. Taxonomie des bases NoSQL BD NoSQL orientées Colonnes BD NoSQL orientées Colonnes I Les données sont stockées par colonne, non par ligne. I On peut facilement ajouter des colonnes aux tables, par contre l’insertion d’une ligne est plus coûteuse. I Quand les données d’une colonne se ressemblent, on peut facilement compresser la colonne. I Modèle proche d’une table dans un SGBDR mais ici le nombre de colonnes : - est dynamique. - peut varier d’un enregistrement à un autre ce qui évite de retrouver des colonnes ayant des valeurs NULL. I Implémentations les plus connues : - HBase (Open Source de BigTable de Google utilisé pour l’indexation des pages Web, Google Earth, Google analytics, ...). - Cassandra (fondation Apache qui respecte l’architecture distribuée de Dynamo d’Amazon, projet né de chez Facebook). - SimpleDB de Amazon. Minyar Sassi Hidri Les BDs NoSQL 26 / 194

27. Taxonomie des bases NoSQL BD NoSQL orientées Colonnes BD NoSQL orientées Colonnes Principaux concepts associés aux BD NoSQL orientées colonnes I Colonne : - Objet de plus bas niveau, il est composé d’une clé (le nom de la colonne), d’une valeur et d’un timestamp. Les timestamps des colonnes sont utilisés pour résoudre les conflits entre plusieurs nœuds de l’infrastructure, pour savoir si un nœud à une version plus récente. Il est donc important que tous les nœuds de l’infrastructure soient synchronisés sur la même horloge. - Une colonne contenant d’autres colonnes est nommée super-colonne. I Super-colonnes : - Situées dans les familles de colonnes. Elle représente une colonne dont les valeurs sont d’autres colonnes. - Si on veut faire le parallèle avec une base SQL cela représente une ligne. On retrouve cette correspondance clé-valeur, la clé permet d’identifier la super-colonne tandis que la valeur est la liste des colonnes qui la compose. I Famille de colonnes : - Permettent de regrouper plusieurs colonnes (ou super-colonnes). - Les colonnes sont regroupées par ligne. - Chaque ligne est identifiée par un identifiant unique (assimilées aux tables dans le modèle relationnel) et sont identifiées par un nom unique. - Les familles de colonnes sont ce qui ressemble le plus aux tables en SQL. http ://www-igm.univ-mlv.fr/ dr/XPOSE2010/Cassandra/modele.html Minyar Sassi Hidri Les BDs NoSQL 27 / 194

28. Taxonomie des bases NoSQL BD NoSQL orientées Colonnes Colonne / Super-Colonne/Famille de Colonnes Minyar Sassi Hidri Les BDs NoSQL 28 / 194

29. Taxonomie des bases NoSQL BD NoSQL orientées Colonnes BD NoSQL orientées Colonnes Minyar Sassi Hidri Les BDs NoSQL 29 / 194

30. Taxonomie des bases NoSQL BD NoSQL orientées Colonnes BD NoSQL orientées Colonnes I Elles sont les plus complexes à appréhender des BD NoSQL, même si au final on a un schéma assez proche des bases documentaires. I Elles sont très utilisées pour les traitements d’analyse de données et dans les traitements massifs (notamment via des opérations de type MapReduce). I Elles offrent plus de flexibilité que les BDR : - il est possible d’ajouter une colonne ou - une super colonne - à n’importe quelle ligne - d’une famille de colonnes, colonnes ou super-colonne à tout instant. Minyar Sassi Hidri Les BDs NoSQL 30 / 194

31. Taxonomie des bases NoSQL BD NoSQL orientées Colonnes BD NoSQL orienté Colonnes Forces et faiblesses des BD NoSQL orientées Colonnes Forces : I Modèle de données supportant des données semi-structurées. I Naturellement indexé (colonnes). I Bonne mise à l’échelle à l’horizontale. I MapReduce souvent utilisé en scaling horizontal. Faiblesses : I Modèle de données TROP simple : `a éviter pour des données interconnectés : si les relations entre les données sont aussi importantes que les données elles- mêmes (comme la distance ou calculs de la trajectoire). I `A éviter pour les lectures de données complexes. I Exige de la maintenance - lors de l’ajout / suppression de colonnes et leur regroupements. Minyar Sassi Hidri Les BDs NoSQL 31 / 194

32. Taxonomie des bases NoSQL BD NoSQL orientées Colonnes BD NoSQL orientées colonnes Utilisations principales des BD NoSQL orientées colonnes Les BD NoSQL orientées colonnes sont principalement utilisées pour : I Netﬂix l’utilise notamment pour le logging et l’analyse de sa clientèle. I Ebay l’utilise pour l’optimisation de la recherche. I Adobe l’utilise pour le traitement des données structurées et de Business Intelligence (BI). I Des sociétés de TV l’utilisent pour cerner leur audience et gérer le vote des spectateurs (nombre élevé d’écritures rapides et analyse de base en temps réel (Cassandra). I Peuvent être de bons magasins d’analyse des données semi-structurées. Minyar Sassi Hidri Les BDs NoSQL 32 / 194

33. Taxonomie des bases NoSQL BD NoSQL orientées documents BD NoSQL orientées documents I Elles stockent une collection de documents. I Elles sont basées sur le modèle clé/valeur mais la valeur est un document en format semi-structuré hiérarchique de type JSON (JavaS- cript Object Notation) ou XML. I Les documents n’ont pas de schéma, mais une structure arborescente : ils contiennent une liste de champs, un champ a une valeur qui peut être une liste de champs, ... I Elles ont généralement une interface d’accès HTTP REST permettant d’eﬀec- tuer des requêtes (plus complexe que l’interface CRUD des BD clés/valeurs). I Implémentations les plus connues : - MongoDB. - CouchDB (fondation Apache). - RavenDB (pour plate-formes .NET/Windows - LINQ), .... Minyar Sassi Hidri Les BDs NoSQL 33 / 194

34. Taxonomie des bases NoSQL BD NoSQL orientées documents BD NoSQL orientées documents I Un document est composé de champs et des valeurs associées. I Ces valeurs : - peuvent être requêtées. - sont soit d’un type simple (entier, chaîne de caractères, date, ...) - soit elles-mêmes composées de plusieurs couples clé/valeur. I Bien que les documents soient structurés, ces BD sont dites schemaless : il n’est pas nécessaire de déﬁnir au préalable les champs utilisés dans un document. I Les documents peuvent être très hétérogènes au sein de la BD. I Permettent d’eﬀectuer des requêtes sur le contenu des documents/objets : pas possible avec les BD clés/valeurs simples. I Elles sont principalement utilisées dans le développement de CMS (Content Management System - outils de gestion de contenus). Minyar Sassi Hidri Les BDs NoSQL 34 / 194

35. Taxonomie des bases NoSQL BD NoSQL orientées documents BD NoSQL orientées documents Minyar Sassi Hidri Les BDs NoSQL 35 / 194

36. Taxonomie des bases NoSQL BD NoSQL orientées documents BD NoSQL orientées documents http ://www.stechfrites.com/book/export/html/2 http ://changeaas.com/2014/09/14/nosql-databases-2/ Minyar Sassi Hidri Les BDs NoSQL 36 / 194

37. Taxonomie des bases NoSQL BD NoSQL orientées documents BD NoSQL orientées documents Avantages du format JSON : I Format abstrait pour une représentation simplifiée dans les différents langages. I Indépendant du langage de programmation. I Simple et complet pour la représentation des objets. I Utilise des types de données connus et simples à décrire. I Une bonne lisibilité de la syntaxe. I Temps de traitement très proche de celui des fichiers XML. I Moins volumineux en terme de stockage. I Pour JavaScript, un document JSON représente un objet. Utilisations principales des BD NoSQL orientées Documents : I Enregistrement d’événements. I Systèmes de gestion de contenu. I Web analytique ou analytique temps-réel. I Catalogue de produits. I Systèmes d’exploitation... Minyar Sassi Hidri Les BDs NoSQL 37 / 194

38. Taxonomie des bases NoSQL BD NoSQL orientées documents BD NoSQL orientées documents Forces et faiblesses des BD NoSQL orientées Documents Forces : I Modèle de données simple mais puissant (expressions de structures imbri- quées). I Bonne mise à l’échelle. I Pas de maintenance de la BD requise pour ajouter/supprimer des colonnes. I Forte expressivité de requêtage (requêtes assez complexes sur des structures imbriquées). Faiblesses : I Inadaptée pour les données interconnectées. I Modèle de requête limitée à des clés (et indexes). I Peut alors être lent pour les grandes requêtes (avec MapReduce). Minyar Sassi Hidri Les BDs NoSQL 38 / 194

39. Taxonomie des bases NoSQL BD NoSQL orientées graphes BD NoSQL orientées graphes I Elles permettent la modélisation, le stockage et la manipulation de données complexes liées par des relations non-triviales ou variables. I Modèle de représentation des données basé sur la théorie des graphes. I S’appuie sur les notions de nœuds, de relations et de propriétés qui leur sont rattachées. I Implémentations les plus connues : - Neo4J. - OrientDB (fondation Apache), ... I Elles utilisent : - Un moteur de stockage pour les objets (similaire à une base documentaire, chaque entité de cette base étant nommée nœud). - Un mécanisme de description d’arcs (relations entre les objets), arcs orientés et avec propriétés (nom, date, ...) I Elles sont bien plus eﬃcaces que les BDR pour traiter les problématiques liées aux réseaux (cartographie, relations entre personnes, ...). I Sont adaptées à la manipulation d’objets complexes organisés en réseaux : cartographie, réseaux sociaux,... Minyar Sassi Hidri Les BDs NoSQL 39 / 194

40. Taxonomie des bases NoSQL BD NoSQL orientées graphes BD NoSQL orientées graphes Minyar Sassi Hidri Les BDs NoSQL 40 / 194

41. Taxonomie des bases NoSQL BD NoSQL orientées graphes Exemples Minyar Sassi Hidri Les BDs NoSQL 41 / 194

42. Taxonomie des bases NoSQL BD NoSQL orientées graphes BD NoSQL orientées graphes Forces et faiblesses des BD NoSQL orientées graphes Forces : I Modèle de données puissant. I Rapide pour les données liées, bien plus rapide que SGBDR. I Modèles d’interrogation bien établis et performants : Tinkerpop pile (fournit un ensemble commun d’interfaces permettant aux diﬀérentes technologies informatiques graphiques de travailler ensemble, que le développeur utilise en cas de besoin), SparQL et Cypher. Faiblesses : I Fragmentation (sharding) : - Même si elles peuvent évoluer assez bien. - Pour certains domaines, on peut aussi fractionner. Minyar Sassi Hidri Les BDs NoSQL 42 / 194

43. Taxonomie des bases NoSQL BD NoSQL orientées graphes BD NoSQL orientées Graphes Utilisations principales des BD NoSQL orientées graphes Les BD NoSQL type orientées graphes sont principalement utilisées pour : I Moteurs de recommandation. I Business Intelligence (BI). I Semantic Web. I Social computing. I Données géospatiales. I Généalogie. I Web of things. I Catalogue des produits. I Sciences de la Vie et calcul scientifique (bio-informatique). I Données liées, données hiérarchiques. I Services de routage, d’expédition et de géolocalisation. I Services financiers : chaîne de financement, dépendances, gestion des risques, détection des fraudes,... Minyar Sassi Hidri Les BDs NoSQL 43 / 194

44. Technologies communément utilisées dans les bases NoSQL 1 Mouvement NoSQL Nouveaux besoins en gestion de données Limites des systèmes SGBD classiques Racines et concepts fondateurs Caractéristiques générales des BD NoSQL 2 Taxonomie des bases NoSQL BD NoSQL Clé/Valeur (Key/Value Store) BD NoSQL orientées Colonnes BD NoSQL orientées documents BD NoSQL orientées graphes 3 Technologies communément utilisées dans les bases NoSQL Prise en charge de l’extensibilité Partitionnement dans les systèmes NoSQL Compromis sur la Cohérence Consultation de données : MapReduce 4 Avantages / Inconvénients des bases NoSQL Minyar Sassi Hidri Les BDs NoSQL 44 / 194

45. Technologies communément utilisées dans les bases NoSQL Prise en charge de l’extensibilité Prise en charge de l’extensibilité Il existe plusieurs façons de mettre en œuvre l’extensibilité : I Par réplication, on duplique sur plusieurs nœuds les données. Deux modes : - Maitre-Esclave : le maître reçoit les requêtes en écriture et réplique les modifications sur les esclaves. Les esclaves servent les requêtes en lecture. Ce mode est limité par la capacité du Maître à traiter les requêtes en écriture. - Maître-Maître : tous les nœuds servent à la fois en lecture et en écriture et contiennent une copie des données. Il se pose alors les problèmes de gestion de la concurrence et de la cohérence. I Sharding ou distribution de données : décrit un ensemble de techniques qui permet de répartir les données sur plusieurs machines pour assurer la scalabilité de l’architecture. I 2 façons de partitionner (sharder) la donnée : verticalement ou horizontalement : - Le partitionnement vertical est le plus communément utilisé : il s’agit d’isoler, de séparer des concepts métier. Par exemple, on décidera de stocker les clients sur une base et leur contrat sur une autre. - La notion de partitionnement horizontal renvoie à l’idée de répartir l’ensemble des enregistrements d’une table (au sens d’une BD) sur plusieurs machines. Ainsi, on choisira par exemple de stocker les clients de A à M sur une machine #1 et les clients de N à Z sur une autre machine #2. Le sharding horizontal nécessite une clé de répartition - la première lettre du nom dans l’exemple. Minyar Sassi Hidri Les BDs NoSQL 45 / 194

46. Technologies communément utilisées dans les bases NoSQL Partitionnement dans les systèmes NoSQL Distribution de données : Sharding I Les données peuvent être aussi partitionnées afin que : - Les données accédées ou mises à jour en même temps, résident sur le même nœud. - La charge soit uniformément répartie entre les nœuds. I Tables distribuées par partitionnement simple : Pour pallier à la problématique de montée en charge et en volume, une solution simple est de partitionner la table, divisant ainsi le volume et la charge entre toutes les instances. - Cette approche simple peut entraîner une répartition inégale des données entre les instances, il a donc été nécessaire de trouver des solutions pour palier à ce problème de déséquilibre. I Sharding : Mécanisme de partitionnement des données dans lequel les données sont stockées sur des nœuds serveurs différents en fonction d’une clé (ex : fonction de hachage) : - L’accès à une clé se fait en transformant à l’aide d’une fonction la clé en une valeur de hachage. La table des clés est répartie sur des nœuds et la fonction de hachage permet de répartir les clés sur les différents nœuds puis ensuite de retrouver le nœud sur lequel se trouve une clé. Minyar Sassi Hidri Les BDs NoSQL 46 / 194

47. Technologies communément utilisées dans les bases NoSQL Partitionnement dans les systèmes NoSQL Distribution de données : Consistent hashing I Consistent hashing : Mécanisme de partitionnement (horizontal) dans lequel les objet-données sont stockés sur des nœuds-serveurs diﬀérents en utilisant la même fonction de hachage à la fois pour le hachage des objets et le hachage des nœuds : Nœuds et objets sont associés par une même fonction de hachage, et imaginés être placés sur un anneau (rack/cluster de serveurs) Exemple : A, B, C sont des nœuds (serveurs) et 1, 2, 3, 4 sont des objets. Un objet est associé au premier nœud serveur dans le sens horaire : Exemple : Les objets 4 et 1 sont associés au œud A. 2 à B. 3 à C. D’après Strauch. Minyar Sassi Hidri Les BDs NoSQL 47 / 194

48. Technologies communément utilisées dans les bases NoSQL Partitionnement dans les systèmes NoSQL Distribution de données : Consistent hashing Quand un nœud quitte l’anneau, les données qui lui sont liées sont alors associées à leur nœud adjacent dans le sens horaire : Exemple : Le nœud C quitte l’anneau, 3 est alors associé avec 4 et 1 au nœud A. Quand un nœud entre dans l’anneau, il est placé (haché) sur l’anneau et des données lui seront as- sociées selon sa place dans l’anneau : Exemple : Le nœud D entre dans l’anneau, les données 3 et 4 lui sont associées. D’après Strauch. Minyar Sassi Hidri Les BDs NoSQL 48 / 194

49. Technologies communément utilisées dans les bases NoSQL Partitionnement dans les systèmes NoSQL Tolérance au partitionnement (1) I Protocole de communication Gossip : Le protocole Gossip (commérage) est un protocole de communication inspiré par la manière dont les commérages ou rumeurs sont propagées à travers un réseau sociale ou dans la vie réelle. Le protocole Gossip implique des interactions périodiques par paire de nœuds. I De manière périodique, chaque nœud envoi à un autre nœud (choisi de manière aléatoire) un message. Ce message contient son état. Le nœud qui rec¸oit le message envoi un accusé de réception et éventuellement une information sur un autre nœud que celui-ci n’arrive pas à joindre (pas rec¸u d’accusé de réception). I Avant de considérer qu’un autre nœud est réellement indisponible, un mécanisme de quorum peut être mise en œuvre pour évaluer la rumeur (Cassandra implémente ce mode de communication). Minyar Sassi Hidri Les BDs NoSQL 49 / 194

50. Technologies communément utilisées dans les bases NoSQL Partitionnement dans les systèmes NoSQL Tolérance au partitionnement (2) I Hinted Handoﬀ : - Lors d’une écriture, si un nœud contenant un répliqua de la ligne est connu pour être indisponible (par exemple à travers le protocole Gossip), le système écrira la donnée sur un autre nœud contenant un répliqua en indiquant que l’écriture devra être rejouée plus tard sur le nœud indisponible. - Si tous les nœuds contenant un répliqua sont indisponibles, un nœud de coordination va prendre en charge l’écriture (alors que normalement il ne doit contenir cette donnée). - Une fois qu’un nœud découvre qu’un autre nœud pour lequel il détient une écriture en instance est à nouveau disponible (par exemple à travers le protocole Gossip), il lui renvoi la ligne de données correspondante. ⇒ On améliore fortement la tolérance au partitionnement et la disponi- bilité en écriture mais on augmente le risque d’incohérence . Minyar Sassi Hidri Les BDs NoSQL 50 / 194

51. Technologies communément utilisées dans les bases NoSQL Compromis sur la Cohérence Evaluation du niveau de cohérence Soient : I N : le nombre de nœuds qui contiennent une copie des données. I W : quorum en écriture, c’est le nombre de copies qui doivent accuser réception d’une mise à jour avant qu’une mise à jour soit considérer comme complète (ﬁn de la transaction). I R : quorum en lecture, c’est le nombre de copies qui doivent être consultés lorsqu’une donnée est accédée lors d’une lecture. Alors : I Si W +R > N alors on a une cohérence Forte. Il y a toujours chevauchement entre les nœuds sur lesquels on écrit et ceux sur lesquels on lit (lors de la lecture, au moins un des nœuds aura toujours la dernière version de la valeur). I Si W + R <= N alors on a une cohérence éventuelle. Minyar Sassi Hidri Les BDs NoSQL 51 / 194

52. Technologies communément utilisées dans les bases NoSQL Compromis sur la Cohérence ´Evaluation du niveau de cohérence Cas particuliers : I Si R = N et W = N, c’est le cas extrême, dans ce cas R + W = 2N, le système garantie une cohérence forte (tous les nœuds disposent de la même version), et il peut alors fournir une garantie ACID. I Si R = 1 et W = N, la cohérence est forte. On peut le mettre en place dans le cas où on a un beaucoup plus grand volume en lecture qu’en écriture, la charge en lecture n’est traitée que par un nœud alors que l’écriture nécessite tous les nœuds. Mais si un des nœuds est indisponible ou injoignable, alors tout le système devient indisponible en écriture. I Si R = N et W = 1, c’est le cas inverse, mais les risques d’incohérence sont forts. Avec un R = N, on s’assure d’au moins lire sur le nœud qui a la dernière version. Cependant si un nœud est indisponible ou injoignable, la lecture n’est plus possible. I Si R = W alors R = W = (N + 1)/2, on a quorum suﬃsant pour garantir une cohérence éventuelle. Minyar Sassi Hidri Les BDs NoSQL 52 / 194

53. Technologies communément utilisées dans les bases NoSQL Compromis sur la Cohérence Gestion de la concurrence Contrôle de concurrence Multi-Version (MVCC) I Méthode de contrôle de concurrence couramment utilisée par les SGBD pour gérer des accès simultanés à la base de données avec mises à jour. I Dans une BD NoSQL, la gestion des mises à jour est faite : - Non pas en supprimant une fraction contenant les données avant modification et en la remplaçant par une fraction contenant les données modifiées. - Mais en marquant les anciennes données comme obsolètes et en ajoutant une nouvelle version contenant les nouvelles données. - Il existe ainsi plusieurs versions enregistrées, une seule est la plus récente. I Nécessite généralement un balayage périodique pour supprimer les don- nées obsolètes. Minyar Sassi Hidri Les BDs NoSQL 53 / 194

54. Technologies communément utilisées dans les bases NoSQL Compromis sur la Cohérence Gestion de la cohérence Horloges Vectorielle (Vector Clocks) I Les ensembles de données répartis sur nœuds peuvent être lus et modifiés sur chaque nœud et aucune cohérence stricte est assurée par des protocoles de transactions distribuées. Problème : Comment faire des modifications concurrentes ? I Une solution : les horloges vectorielles : I Un vecteur d’horloge est défini comme un n-uplet V [0], V [1], ..., V[n] des valeurs d’horloge à partir de chaque nœud. I À tout instant le nœud i maintient un vecteur d’horloge représentant son état et celui des autres nœuds répliques : (Vi [0] = valeur de l’horloge du premier nœud, Vi [1] = valeur de l’horloge du deuxième nœud, ... Vi [i] = sa propre valeur d’horloge, ... Vi [n] = valeur de l’horloge du dernier nœud). I Les valeurs d’horloge peuvent être de réelles timestamps dérivées d’une horloge locale de nœud, du numéro de version/révision, etc. Minyar Sassi Hidri Les BDs NoSQL 54 / 194

55. Technologies communément utilisées dans les bases NoSQL Consultation de données : MapReduce MapReduce I Appliqué à la BD, MapReduce traite un ensemble de clés en appliquant les fonctions Map et Reduce aux nœuds de stockage qui appliquent localement la fonction Map aux clés qui doivent être traitées et qu’ils possèdent. I Les résultats intermédiaires peuvent être hachés comme des données ordinaires et traitées par les nœuds suivants dans le sens horaire, qui appliquent la fonction Reduce aux résultats intermédiaires et produisent les résultats ﬁnaux. I Du fait du hachage des résultats intermédiaires, aucun coordinateur est utilisé pour diriger les nœuds de traitement vers ces résultats. Minyar Sassi Hidri Les BDs NoSQL 55 / 194

56. Avantages / Inconvénients des bases NoSQL 1 Mouvement NoSQL Nouveaux besoins en gestion de données Limites des systèmes SGBD classiques Racines et concepts fondateurs Caractéristiques générales des BD NoSQL 2 Taxonomie des bases NoSQL BD NoSQL Clé/Valeur (Key/Value Store) BD NoSQL orientées Colonnes BD NoSQL orientées documents BD NoSQL orientées graphes 3 Technologies communément utilisées dans les bases NoSQL Prise en charge de l’extensibilité Partitionnement dans les systèmes NoSQL Compromis sur la Cohérence Consultation de données : MapReduce 4 Avantages / Inconvénients des bases NoSQL Minyar Sassi Hidri Les BDs NoSQL 56 / 194

57. Avantages / Inconvénients des bases NoSQL Avantages Avantages I Leurs performances ne s’écroulent jamais quel que soit le volume traité. Leur temps de réponse est proportionnel au volume. I Elles se migrent facilement. En effet, contrairement aux SGBDR classiques, il n’est pas nécessaire de procéder à une interruption de service pour effectuer le déploiement d’une fonctionnalité impactant les modèle de données. I Sharding automatique : Aussi appelé élasticité, une base NoSQL peut se ré- partir sur plusieurs serveurs sans l’aide de l’application. De plus des serveurs peuvent être ajoutés ou retirés à la volée. I Elles sont consistantes de manière pratique (pour l’utilisateur, une requête aura toujours la même réponse quel que soit le nœud du cluster). I Elles s’intègrent facilement aux SI déployés dans les Clouds du marché. I Les schémas de la base ne sont pas figés : les données sont dorénavant bien plus flexibles car la structure et le type des données peuvent changer à tout moment sans forcément impacter l’application. Minyar Sassi Hidri Les BDs NoSQL 57 / 194

58. Avantages / Inconvénients des bases NoSQL Inconvénients Inconvénients I `A première vue, le principal désavantage du NoSQL est sa jeunesse. I Les outils de supervision ne sont pas très développés pour le moment et cela peut constituer un frein à une mise en production sur des applications critiques. I Le NoSQL a aussi une image de système à déployer uniquement sur des applications nécessitant d’être très performante et travaillant sur de gros volumes que seules de grosses compagnies peuvent s’oﬀrir. Minyar Sassi Hidri Les BDs NoSQL 58 / 194

59. Chapitre 2 - MongoDB 1 Structure de données 2 L’invite interactive de MongoDB 3 Réplication dans MongoDB 4 Le sharding dans MongoDB 5 Programmation client 6 MongoDB et MapReduce Minyar Sassi Hidri Les BDs NoSQL 59 / 194

60. Structure de données 1 Structure de données 2 L’invite interactive de MongoDB 3 Réplication dans MongoDB 4 Le sharding dans MongoDB 5 Programmation client 6 MongoDB et MapReduce Minyar Sassi Hidri Les BDs NoSQL 60 / 194

61. Structure de données Caractéristiques Caractéristiques I Écrit en C++. I Orienté documents à schéma flexible et distribuable. I Interprète les requêtes Javascript (coté serveur). I Distribué sous licence AGPL (Licence publique générale Affero). I Une table vide occupe environs 200Mo. I La taille maximale d’un objet est 4Mo. Pour pouvoir stocker les objets volumineux MongoDB implémente son propre système de découpage GridFS). ⇒ Il est utilisé dans le cas où on recherche des performances élevées sur des bases de grande taille. http ://www.mongodb.org/ http ://www.php.net/manual/en/class.mongo.php Minyar Sassi Hidri Les BDs NoSQL 61 / 194

62. Structure de données Caractéristiques Structure de données I Données représentées dans un schéma ﬂexible. I Données stockées sous forme de documents (paires clé/valeur) JSON-like (un format de données textuel dérivé de la syntaxe d’expression des objets en JavaScript). I Pour l’utilisateur, la structure visible est du JSON. I Ce document sera stocké par MongoDB dans un format plus compact, plus pratique pour le stockage et les traitements, le BSON (Binary JSON) : repré- sentation binaire sérialisées d’une document JSON. I Les documents sont contenus dans des collections, qui correspondent plus ou moins aux tables des SGBDR. I Les documents d’une même collection ont une structure similaire (homogé- néité). I Les collections peuvent être regroupées dans des espaces de noms, et sont stockées dans des BDs (databases). Un espace de noms est simplement un préﬁxe ajouté aux collections (et séparé de celles-ci par un point), qui permet de les regrouper, un peu comme le concept de schémas de la norme SQL. I Une BD peut être considérée comme une collection de collections. Minyar Sassi Hidri Les BDs NoSQL 62 / 194

63. Structure de données Caractéristiques Déﬁnition d’un schéma de données avec MongoDB Les documents I Un document c’est quoi ? - ´Equivalent d’un enregistrement (tuple) en relationnel. - Trois modes d’insertion : - En utilisant la commande db.<nom collection>.insert() du schell. - En utilisant la commande db.<nom collection>.save () du schell. - En utilisant un driver : PHP, Ruby, Java et Python. - Chaque document crée contient le champ id : - Sa valeur peut être fournie ou générée automatiquement. - Type primary key. - Indexé. - Structure de données JSON-like, composée de paires clef/valeur. - Stocké sur le disque sous forme de document BSON. - Supporte plus de types de données que JSON. - La partie valeur peut avoir n’importe quel type supporté par BSON, dont d’autres documents, des tableaux, et des tableaux de documents. Minyar Sassi Hidri Les BDs NoSQL 63 / 194

64. Structure de données Caractéristiques Déﬁnition d’un schéma de données avec MongoDB Les documents Minyar Sassi Hidri Les BDs NoSQL 64 / 194

65. Structure de données Caractéristiques Définition d’un schéma de données avec MongoDB Les documents I Le champ id - Seul champ obligatoire, utilisé comme clé primaire dans une collection. De type nommé ObjectId, d’une taille de 96 octets. Sa valeur est créée par un algorithme qui garantit une très faible probabilité de collision. I Les champs indexés ont une taille limite (1Mo). I Les noms des champs ne peuvent pas commencer par un $, contenir le caractère <<.>> ou le caractère <<null>>. I Limites : - Taille max d’un document : 16Mo - Utilisation de l’API GridFS pour stocker des documents plus larges que la taille autorisée. - GridFS permet de diviser les documents en chunks de même taille, et les stockent sous forme de documents séparés. - Les métadonnées des fichiers sont conservées dans une autre collection, nom- mée files. - MongoDB préserve l’ordre des champs du document, comme défini à leur création, sauf : - Que le champs id doit toujours figurer en premier. - Les opérations de update qui incluent le renommage d’un champs peut entraîner le changement de l’ordre des champs dans le document. Minyar Sassi Hidri Les BDs NoSQL 65 / 194

66. Structure de données Caractéristiques Déﬁnition d’un schéma de données avec MongoDB Structure de documents I Deux manières des relations entre les données : références et données Imbriquées. I 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. I 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 mani- puler plusieurs niveaux de hiérarchie en une seule instruction. - Ce sont les Modèles de Données Dénormali- sés. Minyar Sassi Hidri Les BDs NoSQL 66 / 194

67. Structure de données Caractéristiques Déﬁnition d’un schéma de données avec MongoDB Structure de documents I Comment choisir entre références et données imbriquées ? I 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. I 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 ﬁls (many) apparaissent toujours dans le contexte des documents parents (one). Exemple : personne et plusieurs emails. Minyar Sassi Hidri Les BDs NoSQL 67 / 194

68. L’invite interactive de MongoDB 1 Structure de données 2 L’invite interactive de MongoDB 3 Réplication dans MongoDB 4 Le sharding dans MongoDB 5 Programmation client 6 MongoDB et MapReduce Minyar Sassi Hidri Les BDs NoSQL 68 / 194

69. L’invite interactive de MongoDB Installation Instance MongoDB I Installation : https ://docs.mongodb.com/manual/installation/ I Caractéristiques d’une instance MongoDB : - Un port d’écoute (par défaut 27017). - Un processus serveur. - Un répertoire racine de stockage. - Un fichier de log. - Un fichier de configuration : mongod.conf. I Les outils et commandes MongoDB : mongod : le moteur de base. - mongo : le shell Javascript. - mongos : le contrôleur de Sharding (partitionnement). - Les outils d’import/export : mongoimport, mongoexport, mongodump, mongores- tore, bsondump. - mongofiles : l’utilitaire GridFS. - mongostat : visualisation des stats d’une instance mongoDB. - mongosniff : le tcpdump de mongo. Minyar Sassi Hidri Les BDs NoSQL 69 / 194

70. L’invite interactive de MongoDB Création de la base et mise en œuvre du schéma Les bases de données (1) I La distribution de MongoDB inclue un outil en ligne de commande (MongoDB interactive shell). Cet utilitaire permet d’envoyer des commandes au serveur à partir de la ligne de la commande. Il permet aussi d’exécuter des fichiers JavaScript pour exécuter des scripts d’administration. Ce shell permet de : - Consulter le contenu de la base. - Tester des requêtes de consultation. - Créer des indexes. - Exécuter des scripts de maintenance. - Administrer la base. I Affichage de la base en cours : > db I Affichage de la liste des bases : > show dbs I Mongo créé par défaut deux bases : - local : une base qui a la particularité de n’être jamais dupliqué et qui peut servir à stocker des documents qui n’ont d’utilité que sur une machine. - test : base vide sans particularité. - Il peut aussi contenir une base admin permettant à ses utilisateurs d’utiliser des commandes d’administration (comme l’arrêt du serveur) qui ne sont pas disponibles avec les autres bases et config qui est utilisée en mode partitionnement pour stocker des informations sur les nœuds. Minyar Sassi Hidri Les BDs NoSQL 70 / 194

71. L’invite interactive de MongoDB Création de la base et mise en œuvre du schéma Les bases de données (2) I Création / Suppression - Démarrage de l’outil en ligne de commande : mongo - Création de bases de données : >use <db name> - Suppression de bases de données : > use <db name> ; > db.runCommand({dropDatabase : 1}) ; > db.dropDatabase() ; I Pour chaque base : - Initialisation de deux fichiers <db name>.0 et <db name>.1 - La taille de chaque fichier est le double de la taille du précédent (64, 128, 256, etc.). - Taille maximale d’un fichier = 2Gb. - Le fichier <nom fichier>.ns stocke les namespaces de la base (16 Mb par défaut, modifiable via l’option -nssize, avec pour taille maximale 2Gb). I Il est possible d’exécuter des commandes écrites dans un fichier au moyen de la fonction load : load( test.js ) Minyar Sassi Hidri Les BDs NoSQL 71 / 194

72. L’invite interactive de MongoDB Définition d’un schéma de données avec MongoDB Définition d’un schéma de données avec MongoDB Les collections I Un schéma de données orienté documents possède deux éléments de base : Documents et collections. I Une collection c’est quoi ? - Équivalent de la table en relationnel. Deux modes de création. - Automatiquement lors d’une insertion de document (tuple). - En exécutant la commande db.createCollection(”<nom collection>”). I Les opérations sur les collections : - Créer : - > db.createCollection(’gens’). - Supprimer : - >db.collection.drop(). - Lister : - > show collections. - > db.getCollections(). - Insérer un document : - > show collections. - > db.<collection name>.insert({var1 : ”valeur”, var2 : ”valeur”, var3 : ”valeur”,}) ; - Supprimer : - > db.<nom collection>.drop() ; Minyar Sassi Hidri Les BDs NoSQL 72 / 194

73. L’invite interactive de MongoDB Déﬁnition d’un schéma de données avec MongoDB Déﬁnition d’un schéma de données avec MongoDB - Lister les bases créées > show dbs - Création de la base > use bibliotheque > show collections - Création des collections > db.createCollection(”livres”); > db.createCollection(”Editeurs”); > show collections - Renommer une Collection > db.Editeurs.renameCollection(”editeurs”); > show collections - Exemple complet : https ://docs.mongodb.org/ Minyar Sassi Hidri Les BDs NoSQL 73 / 194

74. L’invite interactive de MongoDB Lecture/´Ecriture Insertion de documents I Pour insérer un document dans une collection (que la collection existe ou non) : >db.collection.insert(document) >db.collection.insert(documents) - document est un tableau clefs / valeurs. - documents est une liste de tableaux clefs / valeurs. - collection est le nom de la collection à laquelle on souhaite ajouter le(s) document(s). Si la collection n’existait pas au préalable, elle est créée (c’est de cette manière qu’on crée les collections). >db.etudiants.insert({’prenom’ : ’Camille’,’nom’ : ’Simon’}) >db.etudiants.insert({ ’prenom’ : ’Thomas’ }) >db.etudiants.insert([ { ’prenom’ : ’Jordan’ }, { ’prenom’ : ’Mélanie’} ] ) >db.etudiants.insert([ {’prenom’ : ’Camille’,’nom’ : ’Alberti’}, {’prenom’ : ’Laura’,’nom’ : ’Seban’}]) >db.cours.insert([{ ’code’ : ’IO2’, ’intitulé’ : ’Internet et outils’ }, { ’code’ : ’TO2’, ’intitulé’ : ’Types de données et objets’}]) Minyar Sassi Hidri Les BDs NoSQL 74 / 194

75. L’invite interactive de MongoDB Lecture/Écriture Recherche I Recherche standard : MongoDB propose deux fonctions de recherche simples : - findOne() : recherche et retourne un document. - find() : retourne une liste de documents, avec un curseur permettant de se déplacer à l’intérieur de la liste. I Cible une unique collection spécifique de documents. I Cible un critère ou des conditions spécifiques, pour identifier le document à retourner. I Peut inclure une projection sur les champs du document à retourner. I Peut définir des modificateurs pour imposer des limites, un ordre, un filtre... I Pour consulter des documents dans une collection : >db.collection.find() >db.collection.find(requête) >db.collection.find(requête, projection) - Sans paramètre, tous les documents sont renvoyés. - requête est un tableau clefs / valeurs spécifiant des opérateurs sur les champs des documents recherchés. - projection est un tableau permettant de limiter les champs que l’on souhaite consulter dans les documents recherchés (suite...). Minyar Sassi Hidri Les BDs NoSQL 75 / 194

76. L’invite interactive de MongoDB Lecture/Écriture Recherche Fonction find() (1) I Exemple : >db.etudiants.find() >db.etudiants.find({ ’prenom’ : ’Camille’}) I Résultat : > db.etudiants.find( { ’prenom’ : ’Camille’ } ) { ” id” : ObjectId(”532d40c72d150b4635b8cfc9”), ”prenom” : ”Camille”, ”nom” : ”Simon” } { ” id” : ObjectId(”532d40c72d150b4635b8cfcd”), ”prenom” : ”Camille”, ”nom” : ”Alberti” } - Le champ id a été ajouté par le système au moment de l’opération insert. On peut ensuite l’utiliser pour désigner un document précis : > db.etudiants.find({ id : ObjectId(”532d40c72d150b4635b8cfc9”) }) { ” id” : ObjectId(”532d40c72d150b4635b8cfc9”), ”prenom” : ”Camille”, ”nom” : ”Simon” } I Le résultat renvoyé par find est un curseur, un objet qui permet d’itérer sur les documents. Considérons un exemple d’utilisation simple, comme un tableau : > var c = db.etudiants.find({’prenom’ : ’Camille’}) > c[0] { ” id” : ObjectId(”532d40c72d150b4635b8cfc9”),”prenom” : ”Camille”,”nom” : ”Simon”} > c[0].nom Simon Minyar Sassi Hidri Les BDs NoSQL 76 / 194

77. L’invite interactive de MongoDB Lecture/Écriture Recherche Fonction find() (2) I On peut également utiliser l’opérateur $or pour indiquer un OU logique, sur le modèle : >db.collection.find({$or : [ {field1 : value1},{field2 :value2}]}) I Plutôt que d’indiquer une valeur fixe dans ces instructions conditionnelles, on peut également utiliser des opérateurs tel que supérieur à, inférieur à, etc.. ils respectent la syntaxe suivante : {field : {operator :value}} I Et on dispose des opérateurs suivantes : - $gt : plus grand que. - $gte : plus grand ou égal a. - $lt : plus petit que. - $lte : plus petit ou égal a. - $ne : different de. Minyar Sassi Hidri Les BDs NoSQL 77 / 194

78. L’invite interactive de MongoDB Lecture/Écriture Recherche Fonction find() (3) I On peut également indiquer, par le biais d’un second argument à find(), quels champs on souhaite sélectionner. Si ce second argument n’est pas spécifié, tous les champs du document sont renvoyés. .find({...},{field1 :[0|1],field2 :[0|1],...}) I Pour sélectionner tous les élèves mais sans extraire leurs noms et prénoms : >db.eleves.find({}, {prenom :0,nom :0}) I On peut également appliquer un équivalent de l’opérateur limit par le biais des fonctions limit() et skip() à appliquer respectivement à find() et à limit(). - pour sélectionner les N premiers documents : .find(...).limit(N). - pour sélectionner les N premier documents à partir du Mième document : .find(...).limit(N).skip(M). Minyar Sassi Hidri Les BDs NoSQL 78 / 194

79. L’invite interactive de MongoDB Lecture/Écriture Recherche Fonction find() (4) I On peut également trier les documents résultant de notre recherche. Pour ce faire, on va utiliser la fonction .sort() à appliquer à find(). .find(...).sort({field1 :[1|-1], filed2 :[1|-1],...) ...où 1 désigne un ordre ascendant et -1 un ordre descendant. I Un autre opérateur utilisable au sein des instructions conditionnelles est l’opérateur in. {filed : {in : [value1, value2, value3,...]}} Minyar Sassi Hidri Les BDs NoSQL 79 / 194

80. L’invite interactive de MongoDB Lecture/Écriture Recherche Fonction findOne() I La fonction findOne fait la même chose que find mais sans s’embarrasser d’un curseur, lorsqu’on souhaite récupérer un document unique (par son identifiant, par exemple). I Si la requête désigne plusieurs documents, le premier trouvé est renvoyé. > var camille = db.etudiants.findOne({’ id’ : ObjectId(’532d40c72d150b4635b8cfc9’)}) > camille {” id” : ObjectId(”532d40c72d150b4635b8cfc9”), ”prenom” : ”Camille”,”nom” : ”Simon”} > camille.nom Simon Minyar Sassi Hidri Les BDs NoSQL 80 / 194

81. L’invite interactive de MongoDB Lecture/Écriture Modification/Suppression Fonction Update/ Fonction Remove I Pour modifier un ou des documents existant : >db.collection.update(requête, modifications) - requête est de la même forme que pour find. - modification est un tableau clefs / valeurs définissant des opérations sur les champs. - Exemple : L’opérateur set pour ajouter un champ : >db.users.update({’prenom’ : ’Thomas’}, {’$set’ : {nom : ’Hummel’}}) I Pour supprimer un ou plusieurs documents : >db.collection.remove() >db.collection.remove(requête) - sans paramètre, tous les documents sont supprimés (attention, donc). - requête est de la même forme que pour find, elle désigne les documents qui seront supprimés. > db.etudiants.find( { ’prenom’ : ’Camille’ } ) { ” id” : ObjectId(”532d40c72d150b4635b8cfc9”), ”prenom” : ”Camille”, ”nom” : ”Simon” } { ” id” : ObjectId(”532d40c72d150b4635b8cfcd”), ”prenom” : ”Camille”, ”nom” : ”Alberti” } > db.etudiants.remove({ id : ObjectId(”532d40c72d150b4635b8cfc9”) }) > db.etudiants.find({prenom : ’Camille’}) { ” id” : ObjectId(”532d40c72d150b4635b8cfcd”), ”prenom” : ”Camille”, ”nom” : ”Alberti” } Minyar Sassi Hidri Les BDs NoSQL 81 / 194

82. L’invite interactive de MongoDB Exemple Exemple Insertion des données dans MongoDB (1) I Nous insérons trois documents (livres, auteur, editeur) dans notre base, ils reprennent notre structure mais ont chacun des champs supplémentaires : Minyar Sassi Hidri Les BDs NoSQL 82 / 194

83. L’invite interactive de MongoDB Exemple Exemple Insertion des données dans MongoDB (2) I Nous commençons par ajouter les éditeurs : >show dbs >use bibliotheque >db.editeurs.insert({ nom : ”Hachette”}) ; >db.editeurs.insert({ nom : ”Hatier”}) ; >db.editeurs.insert({ nom : ”O’Reilly”}) ; I Consultons le contenu de la collection editeurs : > db.editeurs.find({}) I On a bien ajouté trois documents dans la collection editeurs. On remarque que MongoDB a automatiquement ajouté un identifiant. On peut maintenant ajouter les documents livres en reprenant les Id des éditeurs. > db.livres.insert({type : ”livre”, titre : ”Aubonheurdesdames”, annee : 2010, editeur : new DBRef ( editeurs , ObjectId(”4fa40cbe9ff 7ba90f 5d13eed”)), ISBN : ”2012814557”, auteurs : [{nom : ”Zola”, prenom : ”Emile”}]}); > db.livres.insert({type : ”livre”, titre : ”Germinal”, annee : 1995, editeur : newDBRef ( editeurs , ObjectId(”4fa40d359ff 7ba90f 5d13eee”)), format : ”Poche”, auteurs : [{nom : ”Zola”, prenom : ”Emile”}]}); > db.livres.insert({type : ”livre”, titre : ”TheDefinitiveGuidetoMongodb”, annee : 2003, editeur : newDBRef ( Editeurs , ObjectId(”4fa40dfb7b071ce946d6dc34”)), ISBN : ”1449381561”, pages : 206, langue : ”Anglais”, auteurs : [{nom : ”Dirolf ”, prenom : ”Michael”}, {nom : ”Dirolf ”, prenom : ”Kristina”}]}); I Vérification du nombre de livres en base : >db.livres.count() Minyar Sassi Hidri Les BDs NoSQL 83 / 194

84. L’invite interactive de MongoDB Exemple Exemple Consultation des données avec MongoDB (1) I Recherche standard : MongoDB propose deux fonctions de recherche simples : - findOne() : recherche et retourne un document. - find() : retourne une liste de documents, avec un curseur permettant de se déplacer à l’intérieur de la liste. - Rechercher un document suivant la clé titre : > db.livres.findOne({titre : ”Germinal”}) ; - Rechercher uniquement les titres des documents ayant pour nom d’auteur Zola : > db.livres.find({”auteurs.nom” : ”Zola”}, {titre : 1}) ; - Rechercher uniquement les titres des documents ayant pour nom d’auteur Dirolf : > db.livres.find({”auteurs.nom” : ”Dirolf ”}, {titre : 1}) ; - Rechercher uniquement les titres des documents publiés après 2000 : > db.livres.find({”annee” : {$gt : 2000}}, {titre : 1}) ; - Requête composée regroupant les deux précédentes recherches (année > 2000 et nom auteur = Zola : > db.livres.find({”annee” : {$gt : 2000}, ”auteurs.nom” : ”Zola”}, {titre : 1}); - Retrouver les livres qui ne possèdent pas la clé ISBN : > db.livres.find({ISBN : { $exists : false}}, {titre : 1}) ; - Retrouver l’éditeur d’un livre dont la langue est en Anglais : > db.livres.findOne({”langue” : ”Anglais”}).editeur.fetch() ; Minyar Sassi Hidri Les BDs NoSQL 84 / 194

85. L’invite interactive de MongoDB Exemple Exemple Consultation des données avec MongoDB (2) I Requêtes agrégées : MongoDB dans la version V2.2 oﬀre la possibilité d’exécuter des requêtes agrégées. On retrouve alors une partie des fonction- nalités d’agrégation des SGBDR. Les fonctionnalités sont : - Count : calcul le nombre de documents qui correspondent à un critère. - Distinct : retourne les valeurs distinctes d’un champs dans une collections (les dou- blons ne sont pas retournés). - Group : permet de retourner un résultat agrégé sur un ou plusieurs critères. Par exemple on pourrait retourner le nombre d’oeuvres publiées par un éditeur par années. I Indexation : - Pour déterminer la pertinence d’un index pour optimiser une requête, MongoDB permet d’obtenir le plan d’exécution à l’aide de la commande Explain. > db.livres.ﬁnd({”auteurs.nom” : ”Dirolf ”}, {titre : 1}).sort({annee : −1}).explain(); - Pour connaître l’espace consommé en RAM pour une collection. > db.livres.totalIndexSize(); Minyar Sassi Hidri Les BDs NoSQL 85 / 194

86. Réplication dans MongoDB 1 Structure de données 2 L’invite interactive de MongoDB 3 Réplication dans MongoDB 4 Le sharding dans MongoDB 5 Programmation client 6 MongoDB et MapReduce Minyar Sassi Hidri Les BDs NoSQL 86 / 194

87. Réplication dans MongoDB Réplication dans MongoDB Réplication dans MongoDB Les Replica Sets I Réplication : permet d’assurer la redondance et la haute disponibilité. I Processus de synchronisation d’un ensemble de données sur de multiples serveurs. I Fournit la haute disponibilité : si un serveur MongoDB crash, un autre prendra la relève. I Qu’est-ce que le Replica Set ? - Permet d’assurer la redondance et la haute disponibilité. - Permet aux données d’être dupliquées de manière transparente. - Utilise la notion de groupe de serveurs appelé set : chaque set possède : - un nœud principal (primaire) : lecture/écriture. - n serveurs de backup (secondaire) : lecture uniquement. - Concrètement : les Replica Set permettent de répliquer les données entre des instances MongoDB. Minyar Sassi Hidri Les BDs NoSQL 87 / 194

88. Réplication dans MongoDB Réplication dans MongoDB Réplication dans MongoDB I Replica Set : correspond à un ensemble de processus mongod qui hébergent le même ensemble de données : - Le premier mongod, le mongod primaire, reçoit toutes les opérations de lecture et écriture. - Les autres instances mongod, les répliques secondaires, appliquent les instructions reçues par le membre primaire afin d’avoir exactement le même ensemble de données. - Un replica set ne peut avoir qu’un seul membre primaire uniquement qui accepte les opérations d’écriture. - Afin de supporter la réplication, le membre primaire enregistre tous les changements réalisés sur son ensemble de données dans son oplog (globalement on peut le qualifier de journal enregistrant toutes les opérations d’écritures du membre). - De cette façon, les membres secondaires vont pouvoir s’appuyer sur cet oplog afin de répliquer les mêmes opérations sur leur propre ensemble de données. Minyar Sassi Hidri Les BDs NoSQL 88 / 194

89. Réplication dans MongoDB Réplication dans MongoDB Réplication dans MongoDB I Types de membres dans un replicat set : - Primaire : reçoit toutes les opérations d’écriture/lecture. - Secondaire : réplication des opérations du primaire pour maintenir des répliques identiques à l’original. - Arbitre : ne conserve pas de copie de la donnée, mais joue un rôle dans les élections qui sélectionnent un membre primaire, si le primaire actuel est indisponible. - Il faut au minimum 3 nœuds pour fonctionner : - 1 maître - 2 esclaves. - En cas de crash du maître, une élection se produit entre les esclaves pour élire le nouveau maître. Minyar Sassi Hidri Les BDs NoSQL 89 / 194

90. Réplication dans MongoDB Réplication dans MongoDB Stratégies de réplication Primaire I Seul membre qui reçoit les opérations d’écriture. I MongoDB applique les opérations d’écriture sur le primaire, puis les enregistre dans son log (oplog). I Les membres secondaires dupliquent ce log et appliquent les opérations sur leurs données. I Tous les membres d’un replicat set peuvent accepter une opération de lecture. I Par défaut, une application dirige ces opérations vers le primaire. I Un replicat set a au plus un primaire. I Si le primaire tombe en panne, une élection a lieu pour en choisir un autre. Minyar Sassi Hidri Les BDs NoSQL 90 / 194

91. Réplication dans MongoDB Réplication dans MongoDB Stratégies de Réplication Secondaires I Maintiennent une copie des données du primaire. I Pour répliquer les données, un secondaire applique les opérations du oplog du primaire sur ses propres données, de manière asynchrone. I Un replicat set peut avoir un ou plusieurs secondaires. I Même si les clients ne peuvent pas écrire des données sur les secondaires, ils peuvent en lire. I Un secondaire peut devenir un primaire, suite à une élection. I Il est possible de conﬁgurer un secondaire : - L’empêcher d’être élu pour devenir primaire, lui permettant de rester toujours comme un backup. - Empêcher les applications de lire à partir de lui, lui permettant ainsi de se consacrer à certaines applications nécessitant un traﬁc séparé. - Exécuter des snapshots périodiques pour garder un historique. Minyar Sassi Hidri Les BDs NoSQL 91 / 194

92. Réplication dans MongoDB Réplication dans MongoDB Stratégies de réplication Arbitre I Arbitre - N’a pas de copie des données et ne peut pas devenir un primaire. - Permet de voter pour un primaire. - Doit être déﬁni pour les replicat sets avec un nombre pair de membres. I Élections - Ont lieu à la création d’un replicat set, ou bien quand un primaire devient indisponible. - Processus qui prend du temps, et qui rend le replicat set en readonly. - Chaque membre a une priorité déterminant son éligibilité à devenir primaire. - L’élection choisit le membre ayant la plus haute priorité comme primaire. - Par défaut, tous les membres ont la même priorité (1). - Il est possible de modiﬁer la priorité d’un membre ou groupe, selon leur position géographique par exemple. - Chaque membre a la possibilité de voter pour un seul autre membre. - Le membre recevant le plus grand nombre de votes devient primaire. Minyar Sassi Hidri Les BDs NoSQL 92 / 194

93. Réplication dans MongoDB Réplication dans MongoDB Réplication dans MongoDB Principales commandes I Démarrage d’un serveur dans un Replica Set : mongod –replSet (indique à quel Replica Set appartient l’instance) –shardsvr (active le partitionnement horizontal) ... I Ajout d’un nœud dans un Replica Set sur le serveur maître : PRIMARY> rs.add(”host :port”) ; I Sortir un nœud d’un Replica Set sur le serveur maître : PRIMARY> rs.remove(”host :port”) ; I Les principales commandes d’exploitation : rs.initiate(cfg) ; (permet d’initialiser la configuration d’un Replica Set) db.isMaster() ; (permet de vérifier qui est le maître) rs.status() ; (permet de vérifier l’état du Replica Set) rs.slaveOk() ; (permet d’activer les lectures sur les serveurs esclaves) rs.syncFrom(”host :port”) ; (permet de forcer la synchronisation) ... Minyar Sassi Hidri Les BDs NoSQL 93 / 194

94. Le sharding dans MongoDB 1 Structure de données 2 L’invite interactive de MongoDB 3 Réplication dans MongoDB 4 Le sharding dans MongoDB 5 Programmation client 6 MongoDB et MapReduce Minyar Sassi Hidri Les BDs NoSQL 94 / 194

95. Le sharding dans MongoDB Le sharding dans MongoDB Architecture I Pré-requis : mise en place des Replica Set. I Permet une scalabilité horizontale. I Distribution du stockage des données sur différentes instances MongoDB. I Chaque machine stocke un sous ensemble des données (chunk). I Utilise une clé de sharding pour répartir le stockage. I Shards : - Stockent les données. - Les données sont distribuées et répliquées sur les shards. I Query Routers - Instances mongos. - Interfaçage avec les applications clientes. - Redirige les opérations vers le shard approprié et retourne le résultat au client. - Plusieurs QR pour la répartition des tâches. I Config Servers - Stockent les méta-données du cluster. - Définissent le mapping entre les data et les shards. - Dans les env. de prod., 3 CS doivent être définis. Minyar Sassi Hidri Les BDs NoSQL 95 / 194

96. Le sharding dans MongoDB MongoDB Partitionnement de données I Partitionnement des données au niveau des collections, via la shard key. I Shard key : champs simple ou composé, indexé qui existe dans chaque document de la collection. I MongoDB divise les valeurs de la clé en morceaux (chunks) et les distribuent de manière équitable entre les shards. I La répartition des clés suit l’une de ces deux méthodes de partitionnement : 1. Basée sur le rang. 2. Basée sur le Hash. 3. Basée sur les tags. Minyar Sassi Hidri Les BDs NoSQL 96 / 194

97. Le sharding dans MongoDB Partitionnement de données Partitionnement basé sur le rang I Déﬁnition d’intervalles qui ne se chevauchent pas, dans lesquelles les valeurs de la shard key peuvent se trouver. I Permet aux documents avec des clés proches de se trouver dans le même shard. I Plus facile de retrouver le shard pour une donnée. I Risque de distribution non équitable des données (par exemple si la clé est le temps, alors toutes les requêtes dans un même intervalle de temps sont sur le même serveur, d’où une grande diﬀérence selon les heures de grande ou de faible activité). Minyar Sassi Hidri Les BDs NoSQL 97 / 194

98. Le sharding dans MongoDB Partitionnement de données Partitionnement basé sur le hash I Calcul de la valeur du hash d’un champ, puis utilise ces hash pour créer des partitions. I Deux documents ayant des clés proches ont peu de chance de se trouver dans le même shard. I Distribution aléatoire d’une collection dans le cluster, d’où une distribution plus équitable. I Moins eﬃcace, car le temps de recherche de la donnée est plus grand. I Dans le cas d’une requête portant sur des données se trouvant dans un intervalle déﬁni, le système doit parcourir plusieurs shards. Minyar Sassi Hidri Les BDs NoSQL 98 / 194

99. Le sharding dans MongoDB Partitionnement de données Partitionnement basé sur les tags I Les administrateurs peuvent déﬁnir des tags, qu’ils associent à des intervalles de clé. I Ils associent ces tags aux diﬀérents shards en essayant de respecter la distribution équitable des données. I Un balancer migre les données taggées vers les shards adéquats. I Le meilleur moyen pour assurer une bonne répartition des données. Minyar Sassi Hidri Les BDs NoSQL 99 / 194

100. Le sharding dans MongoDB Partitionnement de données Maintien d’une distribution équitable I L’ajout de nouvelles données ou nouveaux serveurs peut rendre la distribution des données déséquilibrée. I Splitting : - Évite d’avoir des chunks trop larges. - Quand la taille d’un chunk augmente au delà d’une valeur prédéfinie (chunk size), MongoDB divise cet ensemble de données en deux sur le même shard. - Les insertions et les modifications déclenchent les splits. - Un split change les méta-données, mais ne fait pas migrer les données ni n’affecte le contenu des shards. Minyar Sassi Hidri Les BDs NoSQL 100 / 194

101. Le sharding dans MongoDB Partitionnement de données Maintien d’une distribution équitable I Balancing : - Balancer : processus en arrière plan, gérant les migrations de chunks. - Peut être lancé à partir de n’importe quel query router. - Quand la distribution des données est déséquilibrée, le balancer fait migrer des chunks du shard ayant le plus de chunks vers celui qui en a le moins, jusqu’à ce que la collection devienne équitablement répartie. - Étapes : - Le shard destination reçoit tous les documents du chunk à migrer. - Le shard destination applique tous les changements faits aux données durant le processus de migration. - Finalement, les métadonnées concernant l’emplacement du chunk sur le conﬁg server sont modiﬁées. Minyar Sassi Hidri Les BDs NoSQL 101 / 194

102. Le sharding dans MongoDB Partitionnement de données Ajout ou suppression de shards I Dans le cas d’un ajout de shard : - Un dé-séquilibre est créé entre les shards du cluster, car le nouveau shard n’a pas de chunks. - MongoDB peut commencer le processus de migration immédiatement, mais cela risque de prendre du temps avant que le cluster ne soit équilibré. I Dans le cas d’une suppression de shard : - Le balancer migre tous les chunks de ce shard vers les autres shards. - Une fois toutes les données migrées et les méta-données mises à jour, la suppression peut avoir lieu. Minyar Sassi Hidri Les BDs NoSQL 102 / 194

103. Le sharding dans MongoDB Le sharding dans MongoDB Principales commandes I Ajouter des nœuds au sharding : db.runCommand({addshard : ”<nom Replica Set/host1 :port,host2 :port,hostN :port”}) ; I Activer le sharding pour une base de données : db.runCommand({enablesharding : ”<nom base>”}) ; I Déﬁnir une clé de partitionnement pour le sharding : db.runCommand({shardcollection : ”<namespace>”, key :{” :<nom champ>” :1}}) ; I Aﬃcher les informations sur le sharding : db.printShardingStatus() ; db.<collection>.stats() ; Minyar Sassi Hidri Les BDs NoSQL 103 / 194

104. Le sharding dans MongoDB Les principaux paramètres Renseignés dans le fichier mongod.conf. I dbpath : emplacement des données d’une instance I logpath : emplacement des logs I logappend : continu à écrire des anciens logs ou créer un nouveau fichier I nojournal = true : désactive ou pas la journalisation I noprealloc = true : désactive la pré-allocation des fichiers data I nssize = <size> : taille du fichier d’espace de nom I port = 27017 : port utilisé par une instance I auth = true : active l’authentification sous MongoDB I fork = true : démarrage de mongod en tâche de fond I objcheck = true : inspection des documents avant insertion ( utf-8 ,type ect .. ) I nohttpinterface = true : active ou désactive l’interface Web de monitoring (Defaults to localhost :27018). I ... Minyar Sassi Hidri Les BDs NoSQL 104 / 194

105. Programmation client 1 Structure de données 2 L’invite interactive de MongoDB 3 Réplication dans MongoDB 4 Le sharding dans MongoDB 5 Programmation client 6 MongoDB et MapReduce Minyar Sassi Hidri Les BDs NoSQL 105 / 194

106. Programmation client Programmation client Programmation client I MongoDB développe des bibliothèques pour de nombreux langages, appelés pilotes (drivers). I Celui pour Python se nomme PyMongo . I Avant de l’installer, nous nous assurons que le paquet python-dev est installé sur la machine. sudo apt-get install python-dev I Nous installons ensuite le pilote pymongo avec pip. I Exemple d’utilisation, dans un fichier source Python, en créant d’abord un dictionnaire Python qui contient le document que nous allons stocker. I Nous avons ici effectué notre écriture avec l’instruction db.articles.insert(article, safe=True), ce qui signifie : dans la BD db ouverte, dans la collection articles, insérer le dictionnaire article. I L’objet sera automatiquement transformé en document JSON par PyMongo. Si la collection articles n’existe pas, elle sera créée.. Minyar Sassi Hidri Les BDs NoSQL 106 / 194

107. Programmation client Programmation client Programmation client I Le paramètre safe=True indique d’effectuer l’insertion en mode synchrone. I Le pilote PyMongo effectue l’insertion en mode asynchrone par défaut, ce qui est pour le moins une option dangereuse pour une application sérieuse : une erreur resterait silencieuse. I Une autre option permet de s’assurer que l’écriture est bien effectuée sur un nombre défini de nœuds dans une configuration en replica set : db.articles.insert(article, w=2) I Ici, nous indiquons que l’écriture doit avoir été réellement effectuée sur deux nœuds avant de redonner la main. I Cette option implique bien sûr le mode synchrone, il est donc inutile de spé- cifier safe=True. I Il nous suffit donc d’exécuter notre fichier Python dans notre environnement : ∼/python env/bin/python ∼/insertion.py Minyar Sassi Hidri Les BDs NoSQL 107 / 194

108. MongoDB et MapReduce 1 Structure de données 2 L’invite interactive de MongoDB 3 Réplication dans MongoDB 4 Le sharding dans MongoDB 5 Programmation client 6 MongoDB et MapReduce Minyar Sassi Hidri Les BDs NoSQL 108 / 194

109. MongoDB et MapReduce Parallélisation : MapReduce Parallélisation : MapReduce I MongoDB possède également une fonction mapreduce() interne. I Elle est relativement limitée (essentiellement par le type de traitement qu’on peut eﬀectuer sur les données), mais peut avoir son utilité. I Syntaxe : Minyar Sassi Hidri Les BDs NoSQL 109 / 194

110. MongoDB et MapReduce Parallélisation : MapReduce Exemple I Imaginons qu’on ait par exemple une collection orders ; contenant les documents suivants : I On va exécuter la commande suivante : ...afin d’appliquer un traitement MapReduce aux documents dont le champs status vaut A ; on générera des couples (clef ;valeur) contenant l’identifiant client et le total de la commande dans Map, et on renverra la somme de tous les totaux obtenus après shuffle pour chaque clef distincte dans Reduce. Minyar Sassi Hidri Les BDs NoSQL 110 / 194

111. MongoDB et MapReduce Parallélisation : MapReduce Exemple I Le traitement et son résultat : (lui-même stocké dans un champs or- der totals) Minyar Sassi Hidri Les BDs NoSQL 111 / 194

112. MongoDB et MapReduce Connecteur Hadoop Connecteur Hadoop I MongoDB dispose d’un connecteur Hadoop. Ce connecteur vise à permettre à des programmes MapReduce Hadoop de directement adresser MongoDB comme source des données d’entrée du programme ou comme destination des données de sorties. I Ce connecteur est lui-aussi Open Source (licence AGPLv3). Il n’est en revanche pas inclus par défaut dans la distribution de MongoDB. I URL du repository du projet : https ://github.com/mongodb/mongo-hadoop I Ce connecteur est disponible au sein d’une librairie Java .jar, et téléchargeable depuis le dépôt Github. I Il a par ailleurs pour dépendance la librairie fournissant l’API Java de connexion à MongoDB. I Le connecteur fonctionne en mettant à disposition du développeur des formats Hadoop supplémentaires d’entrée et de sortie, permettant de directement lire et écrire au sein de bases/collections MongoDB plutôt que depuis/sur HDFS. I L’inclusion de la librairie (et de sa dependance) sera donc nécessaire au sein du projet Java MapReduce si on souhaite s’en servir. I Le connecteur va par ailleurs nous permettre, si on lit/écrit via MongoDB plutôt que HDFS, de passer des objets contenant directement les données BSON dans les classes map et/ou reduce, à la place des types Hadoop standards comme IntWritable ou Text. Minyar Sassi Hidri Les BDs NoSQL 112 / 194

113. MongoDB et MapReduce Connecteur Hadoop Liens utiles I MongoDB en pratique : https ://mongoteam.gitbooks.io/ http ://blog.xebia.fr/2010/12/15/mongodb-en-pratique/ I Opérations de lecture / écriture https ://docs.mongodb.org/manual/core/read-operations-introduction/ I Documentation MongoDB : https ://www.mongodb.org I Livres : http ://www.mongodb.org/books (en Anglais) I Blog : http ://blog.mongodb.org/ I MongoDB Management Service (un service gratuit en cloud pour la surveillance et backup des déploiement de mongodb) : http ://mms.mongodb.com/ Minyar Sassi Hidri Les BDs NoSQL 113 / 194

114. Chapitre 3 - Cassandra 1 Découverte de Cassandra 2 Partitionnement dans Cassandra 3 Replication dans Cassandra 4 Consistance dans Cassandra 5 Gestion de données et des objets dans Cassandra Minyar Sassi Hidri Les BDs NoSQL 114 / 194

115. Découverte de Cassandra 1 Découverte de Cassandra 2 Partitionnement dans Cassandra 3 Replication dans Cassandra 4 Consistance dans Cassandra 5 Gestion de données et des objets dans Cassandra Minyar Sassi Hidri Les BDs NoSQL 115 / 194

116. Découverte de Cassandra Présentation I SGBD NoSQL orienté colonnes. I Initié par Facebook. I Écrit en Java. I Distribué. I Haute disponibilité : no SPOF. I Massivement parallèle. I Scalabilité linéaire. I Écrit plus rapidement qu’il ne lit. ⇒ À utiliser dans le cas ou on doit surtout stocker (écrire) des données plus que les lire. Il peut aussi être utile si l’architecture complète doit être en Java. I Composés de plusieurs nœuds identiques : - Pas de notion de NameNode ou nœud maître. I Les données sont partitionnées par défaut à travers les différents nœuds du cluster. - L’utilisateur contrôle le nombre de répliques qu’il désire avoir pour ses données. I Lecture et écriture à partir de n’importe quel nœud, indépendamment de l’emplacement des données. I Utilisation du protocole Gossip pour la communication entre les différents nœuds du cluster. - Échange de données entre les nœuds chaque seconde. I Comparatif des NoSQL : http ://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis http ://www-igm.univ-mlv.fr/ dr/XPOSE2010/Cassandra/nosql.html Minyar Sassi Hidri Les BDs NoSQL 116 / 194

117. Partitionnement dans Cassandra 1 Découverte de Cassandra 2 Partitionnement dans Cassandra 3 Replication dans Cassandra 4 Consistance dans Cassandra 5 Gestion de données et des objets dans Cassandra Minyar Sassi Hidri Les BDs NoSQL 117 / 194

118. Partitionnement dans Cassandra Partitionnement dans Cassandra I Le partitionnement permet de répartir les lignes sur les nœuds du cluster (à partir de la clé). I Partitionnement facile des don- nées à travers les diﬀérents nœuds participants du cluster. I Chaque nœud est responsable d’une partie de la base de don- nées. I Les données sont insérées par l’utilisateur dans une famille de colonnes. I Elles sont ensuite placées sur un nœud, selon sa clé de colonne. Minyar Sassi Hidri Les BDs NoSQL 118 / 194

119. Partitionnement dans Cassandra Partitionnement dans Cassandra I Partitionnement aléatoire (RandomPartitioner) : - Par défaut, recommandé. - Données partitionnées le plus équitablement possible à travers les différents nœuds. - Un token est défini au niveau de chaque nœud (un BigInteger entre 0 et 2∗∗127). - Chaque nœud est responsable des clés qui sont dans l’intervalle qu’il gère (intervalle entre le token du nœud précédent et le token du nœud). - Un hash (M5 ou Murmur3) de la clé est effectué et définit un token. La ligne est envoyée sur le nœud qui gère l’intervalle concerné. I Partitionnement ordonné (ByteOrderedPartitioner) : - Sauvegarde les clés de familles de colonnes par ordre à travers les nœuds d’un cluster. - Peut provoquer des problèmes, surtout pour la répartition des charges (des nœuds avec des données plus volumineuses que d’autres). I Stratégie spécifiée dans un fichier de configuration cassandra.yaml . I Si la stratégie d’une base est modifiée, il faut recharger toutes les données. Minyar Sassi Hidri Les BDs NoSQL 119 / 194

120. Replication dans Cassandra 1 Découverte de Cassandra 2 Partitionnement dans Cassandra 3 Replication dans Cassandra 4 Consistance dans Cassandra 5 Gestion de données et des objets dans Cassandra Minyar Sassi Hidri Les BDs NoSQL 120 / 194

121. Replication dans Cassandra Replication dans Cassandra I La réplication est gérée au niveau d’un keyspace par le replication factor . I Le replication factor définit le nombre de copies globales sur le cluster d’une ligne. I La façon dont sont placés les replicas dé- pend de la stratégie choisie. I Stratégie Simple (SimpleStrategy) : - La colonne originelle est placée sur un nœud determiné par le partitionneur (partitio- ner). - La réplique est placée sur le nœud suivant de l’anneau (clockwise). - Pas de considération pour l’emplacement dans un Data-Center ou dans une rack (baie) - approprié pour les déploiement sur un seul Data-Center). I Stratégie par topologie du réseau (NetworkTopologyStrategy) : - Les réplicas peuvent être placés dans un autre rack, un autre Data-Center. - Il faut définir la topology du cluster : Snitch. Minyar Sassi Hidri Les BDs NoSQL 121 / 194

122. Replication dans Cassandra Replication dans Cassandra I Utilisation de Snitch : - Définition de la manière dont les nœuds sont groupés dans un réseau. - Répartition des nœuds entre baies et Data- Centers. I Plusieurs types de Snitch : - Simple Snitch : utilise la stratégie simple. - Rack-Inferring Snitch : détermine la topologie du réseau en analysant les adresses IP : Second octet de l’adresse IP : Data-Center, Troisième octet de l’adresse IP : Baie. - Property File Snitch : se base sur une description de l’utilisateur pour determiner l’emplacement des nœuds (cassandra-topology.properties). - EC2 (Elastic Compute Cloud) Snitch : pour déploiement dans Amazon EC2. Utilise l’API AWS (Amazon Web Services) pour déterminer la topologie. I Définit dans le fichier de configuration cassandra.yaml. Minyar Sassi Hidri Les BDs NoSQL 122 / 194

123. Consistance dans Cassandra 1 Découverte de Cassandra 2 Partitionnement dans Cassandra 3 Replication dans Cassandra 4 Consistance dans Cassandra 5 Gestion de données et des objets dans Cassandra Minyar Sassi Hidri Les BDs NoSQL 123 / 194

124. Consistance dans Cassandra Consistance dans Cassandra I P2P ⇒ on contacte n’importe quel nœud. I Nœud contacté = coordinateur ; I Le coordinateur contacte les répliques. I Le client peut se connecter à n’importe quel nœud, dans n’importe quel Data- Center, et lire/écrire les données qu’il veut. I Le consistency level est lié au replication factor. Il déﬁnit le nombre de nœuds devant se synchroniser avant de répondre à une opération. I ´Ecriture : - Données écrites d’abord dans un commit log pour la durabilité. - Ensuite, écriture en mémoire dans une MemTable. - Une fois la MemTable pleine, les données sont sauvegardées dans le disque, dans une SSTable (Sorted Strings Table). - Même si les transactions relationnelles (commits et rollbacks) ne sont pas supportées, les écritures sont atomiques au niveau des colonnes. Minyar Sassi Hidri Les BDs NoSQL 124 / 194

125. Consistance dans Cassandra Consistance dans Cassandra I Niveau de consistance : combien de répliques doivent être écrites avec succès avant de retourner acquittement au client. I Consistance : à quel point est-ce qu’une donnée est à jour et synchronisée sur toutes ses répliques. I Cassandra est la BD NoSQL la plus rapide en écriture. I Extension du concept de consistance éventuelle à une consistance ajustable. I Choix possible entre une consistance forte ou éventuelle selon les besoins. I 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). I Consistance gérée à travers plusieurs data centers. Minyar Sassi Hidri Les BDs NoSQL 125 / 194

126. Consistance dans Cassandra Consistance dans Cassandra Stratégies d’écriture Niveau de consistance : Combien de répliques doivent être écrites avec succès avant de retourner acquittement au client. I Any : une écriture doit réussir sur n’importe quel nœud, au moins un. - Oﬀre la plus haute disponibilité, mais la plus basse consistance. I One (défaut dans CQL) : une écriture doit réussir sur le commit log et la memtable d’au moins une réplique. I Quorum : une écriture doit réussir sur un certain pourcentage de répliques (pourcentage =(facteur de replication/2)+1). I Local-Quorum : une écriture doit réussir sur un certain pourcentage de nœuds répliqués sur le même Data-Center que le nœud coordinateur. I Each-Quorum : une écriture doit réussir sur un certain pourcentage de nœuds répliqués sur tous les Data-Centers. I All : une écriture doit réussir sur tous les nœuds répliqués d’une colonne. - Oﬀre la plus haute consistance, mais la plus basse disponibilité. Minyar Sassi Hidri Les BDs NoSQL 126 / 194

127. Consistance dans Cassandra Consistance dans Cassandra Stratégies d’écriture I Cassandra utilise les Hinted Handoﬀs. I Elle tente de modiﬁer une colonne sur toutes les répliques. I Si certains des nœuds répliques ne sont pas disponibles, un indice (hint) est sauvegardé sur l’un des nœuds répliques en marche, pour mettre à jour tous les nœuds répliqués en panne une fois disponibles. I Si aucun nœud réplique n’est disponible, l’utilisation de la stratégie Any permettra au nœud coordinateur de stocker cet indice. Mais la donnée ne sera lisible que quand l’un des nœuds est disponible de nouveau. Minyar Sassi Hidri Les BDs NoSQL 127 / 194

128. Consistance dans Cassandra Consistance dans Cassandra Stratégies de lecture I Niveau de consistance : combien de répliques doivent répondre avant de retourner le résultat à l’application cliente. I Cassandra vérifie le nombre de répliques pour la donnée la plus récente pour satisfaire une demande de lecture (basée sur le temps). I 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é. I 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é. I 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-Data-Centers. I Each-Quorum : obtention du résultat le plus récent à partir d’un certain pourcentage de nœuds répliques sur tous les Data-Centers. I 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é. Minyar Sassi Hidri Les BDs NoSQL 128 / 194

129. Consistance dans Cassandra Consistance dans Cassandra Stratégies de lecture I Pour réparer de l’inconsistance quand elle se produit (perte d’un nœud,...) : - Hintend handoff : Quand un nœud n’est pas disponible, les insertions sont envoyées à un autre nœud qui lui renverra quand le nœud redeviendra disponible. - Read repair : En lecture, si les valeurs différents, les nœuds désynchronisés sont réparés en insérant les nouvelles valeurs (basé sur le Timestamp). - Cassandra assure que les données fréquem- ment 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, 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. Minyar Sassi Hidri Les BDs NoSQL 129 / 194

130. Gestion de données et des objets dans Cassandra 1 Découverte de Cassandra 2 Partitionnement dans Cassandra 3 Replication dans Cassandra 4 Consistance dans Cassandra 5 Gestion de données et des objets dans Cassandra Minyar Sassi Hidri Les BDs NoSQL 130 / 194

Les BD NoSQL

Vous êtes en train de lire un aperçu.

Consultez-les par la suite

Les BD NoSQL

Plus De Contenu Connexe

Diaporamas pour vous (20)

Les utilisateurs ont également aimé (20)

Similaire à Les BD NoSQL (20)

Plus récents (20)

Les BD NoSQL

Les BD NoSQL

Vous êtes en train de lire un aperçu.

Les BD NoSQL

Suggestions

Plus De Contenu Connexe

Diaporamas pour vous (20)

Les utilisateurs ont également aimé (20)

Similaire à Les BD NoSQL (20)

Plus récents (20)

Les BD NoSQL