SlideShare une entreprise Scribd logo
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
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
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
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
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 or-
dinateurs. 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
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 diffé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
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
Mouvement NoSQL Limites des systèmes SGBD classiques
Limites des systèmes SGBD classiques
I SGBD Relationnels sont généralement transactionnels ⇒ Gestion de tran-
sactions 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
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
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 différents serveurs.
I Difficile 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
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écification 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
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
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 à fonc-
tionner.
I Partition-tolerance ou Résistance au partitionne-
ment : 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
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 partitionne-
ment) ou AP (Dispo-
nible et Résistant au
partitionnement).
Minyar Sassi Hidri Les BDs NoSQL 14 / 194
Mouvement NoSQL Racines et concepts fondateurs
Théorème de CAP
Consistance (Coherence)
I Exemple 1 : Une instance de la BD est automa-
tiquement 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 environne-
ment 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
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 co-
pies des données (répliques) augmente direc-
tement 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
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 diffé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, afin 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
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 solu-
tions 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 nom-
breux 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
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
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
Taxonomie des bases NoSQL
Paysage des SGBD NoSQL
Minyar Sassi Hidri Les BDs NoSQL 21 / 194
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 identifié par une clé
unique, seule fac¸on de le requêter.
Minyar Sassi Hidri Les BDs NoSQL 22 / 194
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 couram-
ment 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 effectuées.
Minyar Sassi Hidri Les BDs NoSQL 23 / 194
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 significative).
I Les profils, 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
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
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
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
Taxonomie des bases NoSQL BD NoSQL orientées Colonnes
Colonne / Super-Colonne/Famille de Colonnes
Minyar Sassi Hidri Les BDs NoSQL 28 / 194
Taxonomie des bases NoSQL BD NoSQL orientées Colonnes
BD NoSQL orientées Colonnes
Minyar Sassi Hidri Les BDs NoSQL 29 / 194
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
- `a n’importe quelle ligne
- d’une famille de colonnes, colonnes ou super-colonne à tout instant.
Minyar Sassi Hidri Les BDs NoSQL 30 / 194
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
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 Netflix 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
Taxonomie des bases NoSQL BD NoSQL orientées documents
BD NoSQL orientées documents
I Elles stockent une collection de do-
cuments.
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’effec-
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
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éfinir 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’effectuer 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
Taxonomie des bases NoSQL BD NoSQL orientées documents
BD NoSQL orientées documents
Minyar Sassi Hidri Les BDs NoSQL 35 / 194
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
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
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
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 efficaces 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
Taxonomie des bases NoSQL BD NoSQL orientées graphes
BD NoSQL orientées graphes
Minyar Sassi Hidri Les BDs NoSQL 40 / 194
Taxonomie des bases NoSQL BD NoSQL orientées graphes
Exemples
Minyar Sassi Hidri Les BDs NoSQL 41 / 194
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 diffé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
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
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
Technologies communément utilisées dans les bases NoSQL Prise en charge de l’extensibilité
Prise en charge de l’extensibilité
Il existe plusieurs fac¸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 rec¸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 fac¸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
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
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 diffé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 fonc-
tion 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
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
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
Technologies communément utilisées dans les bases NoSQL Partitionnement dans les systèmes NoSQL
Tolérance au partitionnement (2)
I Hinted Handoff :
- 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
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 (fin 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
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 suffisant pour garantir
une cohérence éventuelle.
Minyar Sassi Hidri Les BDs NoSQL 52 / 194
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 mo-
dification et en la remplac¸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
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 vec-
teur d’horloge représentant son état et ce-
lui 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 hor-
loge locale de nœud, du numéro de ver-
sion/révision, etc.
Minyar Sassi Hidri Les BDs NoSQL 54 / 194
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 finaux.
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
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
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
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 appli-
cations nécessitant d’être très performante et travaillant sur de gros volumes
que seules de grosses compagnies peuvent s’offrir.
Minyar Sassi Hidri Les BDs NoSQL 58 / 194
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
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
Structure de données Caractéristiques
Caractéristiques
I ´Ecrit 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
Structure de données Caractéristiques
Structure de données
I Données représentées dans un schéma flexible.
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éfixe 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
Structure de données Caractéristiques
Définition 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
Structure de données Caractéristiques
Définition d’un schéma de données avec MongoDB
Les documents
Minyar Sassi Hidri Les BDs NoSQL 64 / 194
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
Structure de données Caractéristiques
Définition 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 docu-
ment à 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
Structure de données Caractéristiques
Définition 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 fils (many) apparaissent toujours
dans le contexte des documents parents (one). Exemple : personne et plusieurs
emails.
Minyar Sassi Hidri Les BDs NoSQL 67 / 194
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
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
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
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
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 ?
- ´Equivalent 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
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
- 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
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
L’invite interactive de MongoDB Lecture/´Ecriture
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
L’invite interactive de MongoDB Lecture/´Ecriture
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
L’invite interactive de MongoDB Lecture/´Ecriture
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
L’invite interactive de MongoDB Lecture/´Ecriture
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
L’invite interactive de MongoDB Lecture/´Ecriture
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
L’invite interactive de MongoDB Lecture/´Ecriture
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
L’invite interactive de MongoDB Lecture/´Ecriture
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
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
L’invite interactive de MongoDB Exemple
Exemple
Insertion des données dans MongoDB (2)
I Nous commenc¸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
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
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 offre 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.find({”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
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
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 ser-
veurs.
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
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, rec¸oit toutes les opérations de lecture et
écriture.
- Les autres instances mongod, les répliques secondaires, appliquent les instructions
rec¸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 fac¸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
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 es-
claves pour élire le
nouveau maître.
Minyar Sassi Hidri Les BDs NoSQL 89 / 194
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
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 configurer 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 trafic séparé.
- Exécuter des snapshots périodiques
pour garder un historique.
Minyar Sassi Hidri Les BDs NoSQL 91 / 194
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éfini 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 modifier 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
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
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
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
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
Le sharding dans MongoDB
Partitionnement de données
Partitionnement basé sur le rang
I Définition 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 différence selon les
heures de grande ou de faible activité).
Minyar Sassi Hidri Les BDs NoSQL 97 / 194
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 efficace, 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éfini, le système doit parcourir plusieurs shards.
Minyar Sassi Hidri Les BDs NoSQL 98 / 194
Le sharding dans MongoDB
Partitionnement de données
Partitionnement basé sur les tags
I Les administrateurs peuvent définir des tags, qu’ils associent à des
intervalles de clé.
I Ils associent ces tags aux diffé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
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 dis-
tribution des données déséquilibrée.
I Splitting :
- ´Evite 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
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
config server sont modifiées.
Minyar Sassi Hidri Les BDs NoSQL 101 / 194
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
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éfinir une clé de partitionnement pour le sharding :
db.runCommand({shardcollection : ”<namespace>”, key :{” :<nom champ>” :1}}) ;
I Afficher les informations sur le sharding :
db.printShardingStatus() ;
db.<collection>.stats() ;
Minyar Sassi Hidri Les BDs NoSQL 103 / 194
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
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
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
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
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
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 effectuer sur les données), mais peut avoir son utilité.
I Syntaxe :
Minyar Sassi Hidri Les BDs NoSQL 109 / 194
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
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
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
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
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
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
Découverte de Cassandra
Présentation
I SGBD NoSQL orienté colonnes.
I Initié par Facebook.
I ´Ecrit en Java.
I Distribué.
I Haute disponibilité : no SPOF.
I Massivement parallèle.
I Scalabilité linéaire.
I ´Ecrit plus rapidement qu’il ne lit.
⇒ `A 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.
- ´Echange 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
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
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 diffé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
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
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
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 fac¸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
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
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
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éfinit 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
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
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’im-
porte quel nœud, au moins un.
- Offre 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.
- Offre la plus haute consistance, mais la plus basse disponibilité.
Minyar Sassi Hidri Les BDs NoSQL 126 / 194
Consistance dans Cassandra
Consistance dans Cassandra
Stratégies d’écriture
I Cassandra utilise les Hinted Handoffs.
I Elle tente de modifier 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
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
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.
- `A la lecture d’une donnée, le nœud coor-
dinateur 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
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
Les BD NoSQL
Les BD NoSQL
Les BD NoSQL
Les BD NoSQL
Les BD NoSQL
Les BD NoSQL
Les BD NoSQL
Les BD NoSQL
Les BD NoSQL
Les BD NoSQL
Les BD NoSQL
Les BD NoSQL
Les BD NoSQL
Les BD NoSQL
Les BD NoSQL
Les BD NoSQL
Les BD NoSQL
Les BD NoSQL
Les BD NoSQL
Les BD NoSQL
Les BD NoSQL
Les BD NoSQL
Les BD NoSQL
Les BD NoSQL
Les BD NoSQL
Les BD NoSQL
Les BD NoSQL
Les BD NoSQL
Les BD NoSQL
Les BD NoSQL
Les BD NoSQL
Les BD NoSQL
Les BD NoSQL
Les BD NoSQL
Les BD NoSQL
Les BD NoSQL
Les BD NoSQL
Les BD NoSQL
Les BD NoSQL
Les BD NoSQL
Les BD NoSQL
Les BD NoSQL
Les BD NoSQL
Les BD NoSQL
Les BD NoSQL
Les BD NoSQL
Les BD NoSQL
Les BD NoSQL
Les BD NoSQL
Les BD NoSQL
Les BD NoSQL
Les BD NoSQL
Les BD NoSQL
Les BD NoSQL
Les BD NoSQL
Les BD NoSQL
Les BD NoSQL
Les BD NoSQL
Les BD NoSQL
Les BD NoSQL
Les BD NoSQL
Les BD NoSQL
Les BD NoSQL

Contenu connexe

Tendances

Cours Big Data Chap6
Cours Big Data Chap6Cours Big Data Chap6
Cours Big Data Chap6
Amal Abid
 
Bases de Données non relationnelles, NoSQL (Introduction) 1er cours
Bases de Données non relationnelles, NoSQL (Introduction) 1er coursBases de Données non relationnelles, NoSQL (Introduction) 1er cours
Bases de Données non relationnelles, NoSQL (Introduction) 1er cours
Hatim CHAHDI
 
BigData_Chp1: Introduction à la Big Data
BigData_Chp1: Introduction à la Big DataBigData_Chp1: Introduction à la Big Data
BigData_Chp1: Introduction à la Big Data
Lilia Sfaxi
 
BigData_TP4 : Cassandra
BigData_TP4 : CassandraBigData_TP4 : Cassandra
BigData_TP4 : Cassandra
Lilia Sfaxi
 
Introduction aux bases de données NoSQL
Introduction aux bases de données NoSQLIntroduction aux bases de données NoSQL
Introduction aux bases de données NoSQL
Antoine Augusti
 
Big data
Big dataBig data
Big data
Yosra ADDALI
 
Cours Big Data Chap3
Cours Big Data Chap3Cours Big Data Chap3
Cours Big Data Chap3
Amal Abid
 
BigData_Chp3: Data Processing
BigData_Chp3: Data ProcessingBigData_Chp3: Data Processing
BigData_Chp3: Data Processing
Lilia Sfaxi
 
BigData_Chp5: Putting it all together
BigData_Chp5: Putting it all togetherBigData_Chp5: Putting it all together
BigData_Chp5: Putting it all together
Lilia Sfaxi
 
Introduction au big data
Introduction au big dataIntroduction au big data
Introduction au big data
Abdelghani Azri
 
Cours Big Data Chap1
Cours Big Data Chap1Cours Big Data Chap1
Cours Big Data Chap1
Amal Abid
 
Les modèles NoSQL
Les modèles NoSQLLes modèles NoSQL
Les modèles NoSQL
ebiznext
 
Alphorm.com-Formation MongoDB Administration
Alphorm.com-Formation MongoDB AdministrationAlphorm.com-Formation MongoDB Administration
Alphorm.com-Formation MongoDB Administration
Alphorm
 
Chapitre 2 hadoop
Chapitre 2 hadoopChapitre 2 hadoop
Chapitre 2 hadoop
Mouna Torjmen
 
Hadoop et son écosystème
Hadoop et son écosystèmeHadoop et son écosystème
Hadoop et son écosystème
Khanh Maudoux
 
TP1 Big Data - MapReduce
TP1 Big Data - MapReduceTP1 Big Data - MapReduce
TP1 Big Data - MapReduce
Amal Abid
 
BigData_TP2: Design Patterns dans Hadoop
BigData_TP2: Design Patterns dans HadoopBigData_TP2: Design Patterns dans Hadoop
BigData_TP2: Design Patterns dans Hadoop
Lilia Sfaxi
 
Thinking Big - Big data: principes et architecture
Thinking Big - Big data: principes et architecture Thinking Big - Big data: principes et architecture
Thinking Big - Big data: principes et architecture
Lilia Sfaxi
 
Modélisation de données pour MongoDB
Modélisation de données pour MongoDBModélisation de données pour MongoDB
Modélisation de données pour MongoDB
MongoDB
 
Big Data, Hadoop & Spark
Big Data, Hadoop & SparkBig Data, Hadoop & Spark
Big Data, Hadoop & Spark
Alexia Audevart
 

Tendances (20)

Cours Big Data Chap6
Cours Big Data Chap6Cours Big Data Chap6
Cours Big Data Chap6
 
Bases de Données non relationnelles, NoSQL (Introduction) 1er cours
Bases de Données non relationnelles, NoSQL (Introduction) 1er coursBases de Données non relationnelles, NoSQL (Introduction) 1er cours
Bases de Données non relationnelles, NoSQL (Introduction) 1er cours
 
BigData_Chp1: Introduction à la Big Data
BigData_Chp1: Introduction à la Big DataBigData_Chp1: Introduction à la Big Data
BigData_Chp1: Introduction à la Big Data
 
BigData_TP4 : Cassandra
BigData_TP4 : CassandraBigData_TP4 : Cassandra
BigData_TP4 : Cassandra
 
Introduction aux bases de données NoSQL
Introduction aux bases de données NoSQLIntroduction aux bases de données NoSQL
Introduction aux bases de données NoSQL
 
Big data
Big dataBig data
Big data
 
Cours Big Data Chap3
Cours Big Data Chap3Cours Big Data Chap3
Cours Big Data Chap3
 
BigData_Chp3: Data Processing
BigData_Chp3: Data ProcessingBigData_Chp3: Data Processing
BigData_Chp3: Data Processing
 
BigData_Chp5: Putting it all together
BigData_Chp5: Putting it all togetherBigData_Chp5: Putting it all together
BigData_Chp5: Putting it all together
 
Introduction au big data
Introduction au big dataIntroduction au big data
Introduction au big data
 
Cours Big Data Chap1
Cours Big Data Chap1Cours Big Data Chap1
Cours Big Data Chap1
 
Les modèles NoSQL
Les modèles NoSQLLes modèles NoSQL
Les modèles NoSQL
 
Alphorm.com-Formation MongoDB Administration
Alphorm.com-Formation MongoDB AdministrationAlphorm.com-Formation MongoDB Administration
Alphorm.com-Formation MongoDB Administration
 
Chapitre 2 hadoop
Chapitre 2 hadoopChapitre 2 hadoop
Chapitre 2 hadoop
 
Hadoop et son écosystème
Hadoop et son écosystèmeHadoop et son écosystème
Hadoop et son écosystème
 
TP1 Big Data - MapReduce
TP1 Big Data - MapReduceTP1 Big Data - MapReduce
TP1 Big Data - MapReduce
 
BigData_TP2: Design Patterns dans Hadoop
BigData_TP2: Design Patterns dans HadoopBigData_TP2: Design Patterns dans Hadoop
BigData_TP2: Design Patterns dans Hadoop
 
Thinking Big - Big data: principes et architecture
Thinking Big - Big data: principes et architecture Thinking Big - Big data: principes et architecture
Thinking Big - Big data: principes et architecture
 
Modélisation de données pour MongoDB
Modélisation de données pour MongoDBModélisation de données pour MongoDB
Modélisation de données pour MongoDB
 
Big Data, Hadoop & Spark
Big Data, Hadoop & SparkBig Data, Hadoop & Spark
Big Data, Hadoop & Spark
 

En vedette

المكتبة الزيتونية سمير باني
المكتبة الزيتونية سمير بانيالمكتبة الزيتونية سمير باني
المكتبة الزيتونية سمير باني
Minyar Sassi Hidri
 
Installation hadoopv2.7.4-amal abid
Installation hadoopv2.7.4-amal abidInstallation hadoopv2.7.4-amal abid
Installation hadoopv2.7.4-amal abid
Amal Abid
 
Big Data: Hadoop Map / Reduce sur Windows et Windows Azure
Big Data: Hadoop Map / Reduce sur Windows et Windows AzureBig Data: Hadoop Map / Reduce sur Windows et Windows Azure
Big Data: Hadoop Map / Reduce sur Windows et Windows Azure
Microsoft
 
Introduction to Cassandra (June 2010)
Introduction to Cassandra (June 2010)Introduction to Cassandra (June 2010)
Introduction to Cassandra (June 2010)
gdusbabek
 
NoSQL et Big Data
NoSQL et Big DataNoSQL et Big Data
NoSQL et Big Data
acogoluegnes
 
NoSQL: Introducción a las Bases de Datos no estructuradas
NoSQL: Introducción a las Bases de Datos no estructuradasNoSQL: Introducción a las Bases de Datos no estructuradas
NoSQL: Introducción a las Bases de Datos no estructuradas
Diego López-de-Ipiña González-de-Artaza
 
Techday Arrow Group: Hadoop & le Big Data
Techday Arrow Group: Hadoop & le Big DataTechday Arrow Group: Hadoop & le Big Data
Techday Arrow Group: Hadoop & le Big Data
Arrow Group
 
Presentation Hadoop Québec
Presentation Hadoop QuébecPresentation Hadoop Québec
Presentation Hadoop Québec
Mathieu Dumoulin
 
TP2 Big Data HBase
TP2 Big Data HBaseTP2 Big Data HBase
TP2 Big Data HBase
Amal Abid
 
NoSQL databases
NoSQL databasesNoSQL databases
NoSQL databases
Marin Dimitrov
 
Présentation Big Data et REX Hadoop
Présentation Big Data et REX HadoopPrésentation Big Data et REX Hadoop
Présentation Big Data et REX Hadoop
Joseph Glorieux
 
Casablanca Hadoop & Big Data Meetup - Introduction à Hadoop
Casablanca Hadoop & Big Data Meetup - Introduction à HadoopCasablanca Hadoop & Big Data Meetup - Introduction à Hadoop
Casablanca Hadoop & Big Data Meetup - Introduction à Hadoop
Benoît de CHATEAUVIEUX
 
Plateforme bigdata orientée BI avec Hortoworks Data Platform et Apache Spark
Plateforme bigdata orientée BI avec Hortoworks Data Platform et Apache SparkPlateforme bigdata orientée BI avec Hortoworks Data Platform et Apache Spark
Plateforme bigdata orientée BI avec Hortoworks Data Platform et Apache Spark
ALTIC Altic
 
NoSql : conception des schémas, requêtage, et optimisation
NoSql : conception des schémas, requêtage, et optimisationNoSql : conception des schémas, requêtage, et optimisation
NoSql : conception des schémas, requêtage, et optimisation
Microsoft Technet France
 
Bases de données NoSQL
Bases de données NoSQLBases de données NoSQL
Bases de données NoSQL
Samy Dindane
 
Enquête RegionsJob : emploi et réseaux sociaux, deuxième édition
Enquête RegionsJob : emploi et réseaux sociaux, deuxième éditionEnquête RegionsJob : emploi et réseaux sociaux, deuxième édition
Enquête RegionsJob : emploi et réseaux sociaux, deuxième édition
HelloWork
 
Une introduction à MapReduce
Une introduction à MapReduceUne introduction à MapReduce
Une introduction à MapReduce
Modern Data Stack France
 
Big Data Analytics for connected home
Big Data Analytics for connected homeBig Data Analytics for connected home
Big Data Analytics for connected home
Héloïse Nonne
 
Hadopp Vue d'ensemble
Hadopp Vue d'ensembleHadopp Vue d'ensemble
Hadopp Vue d'ensemble
Modern Data Stack France
 
Hadoop Hbase - Introduction
Hadoop Hbase - IntroductionHadoop Hbase - Introduction
Hadoop Hbase - Introduction
Blandine Larbret
 

En vedette (20)

المكتبة الزيتونية سمير باني
المكتبة الزيتونية سمير بانيالمكتبة الزيتونية سمير باني
المكتبة الزيتونية سمير باني
 
Installation hadoopv2.7.4-amal abid
Installation hadoopv2.7.4-amal abidInstallation hadoopv2.7.4-amal abid
Installation hadoopv2.7.4-amal abid
 
Big Data: Hadoop Map / Reduce sur Windows et Windows Azure
Big Data: Hadoop Map / Reduce sur Windows et Windows AzureBig Data: Hadoop Map / Reduce sur Windows et Windows Azure
Big Data: Hadoop Map / Reduce sur Windows et Windows Azure
 
Introduction to Cassandra (June 2010)
Introduction to Cassandra (June 2010)Introduction to Cassandra (June 2010)
Introduction to Cassandra (June 2010)
 
NoSQL et Big Data
NoSQL et Big DataNoSQL et Big Data
NoSQL et Big Data
 
NoSQL: Introducción a las Bases de Datos no estructuradas
NoSQL: Introducción a las Bases de Datos no estructuradasNoSQL: Introducción a las Bases de Datos no estructuradas
NoSQL: Introducción a las Bases de Datos no estructuradas
 
Techday Arrow Group: Hadoop & le Big Data
Techday Arrow Group: Hadoop & le Big DataTechday Arrow Group: Hadoop & le Big Data
Techday Arrow Group: Hadoop & le Big Data
 
Presentation Hadoop Québec
Presentation Hadoop QuébecPresentation Hadoop Québec
Presentation Hadoop Québec
 
TP2 Big Data HBase
TP2 Big Data HBaseTP2 Big Data HBase
TP2 Big Data HBase
 
NoSQL databases
NoSQL databasesNoSQL databases
NoSQL databases
 
Présentation Big Data et REX Hadoop
Présentation Big Data et REX HadoopPrésentation Big Data et REX Hadoop
Présentation Big Data et REX Hadoop
 
Casablanca Hadoop & Big Data Meetup - Introduction à Hadoop
Casablanca Hadoop & Big Data Meetup - Introduction à HadoopCasablanca Hadoop & Big Data Meetup - Introduction à Hadoop
Casablanca Hadoop & Big Data Meetup - Introduction à Hadoop
 
Plateforme bigdata orientée BI avec Hortoworks Data Platform et Apache Spark
Plateforme bigdata orientée BI avec Hortoworks Data Platform et Apache SparkPlateforme bigdata orientée BI avec Hortoworks Data Platform et Apache Spark
Plateforme bigdata orientée BI avec Hortoworks Data Platform et Apache Spark
 
NoSql : conception des schémas, requêtage, et optimisation
NoSql : conception des schémas, requêtage, et optimisationNoSql : conception des schémas, requêtage, et optimisation
NoSql : conception des schémas, requêtage, et optimisation
 
Bases de données NoSQL
Bases de données NoSQLBases de données NoSQL
Bases de données NoSQL
 
Enquête RegionsJob : emploi et réseaux sociaux, deuxième édition
Enquête RegionsJob : emploi et réseaux sociaux, deuxième éditionEnquête RegionsJob : emploi et réseaux sociaux, deuxième édition
Enquête RegionsJob : emploi et réseaux sociaux, deuxième édition
 
Une introduction à MapReduce
Une introduction à MapReduceUne introduction à MapReduce
Une introduction à MapReduce
 
Big Data Analytics for connected home
Big Data Analytics for connected homeBig Data Analytics for connected home
Big Data Analytics for connected home
 
Hadopp Vue d'ensemble
Hadopp Vue d'ensembleHadopp Vue d'ensemble
Hadopp Vue d'ensemble
 
Hadoop Hbase - Introduction
Hadoop Hbase - IntroductionHadoop Hbase - Introduction
Hadoop Hbase - Introduction
 

Similaire à Les BD NoSQL

Big data: NoSQL comme solution
Big data: NoSQL comme solutionBig data: NoSQL comme solution
Big data: NoSQL comme solution
JEMLI Fathi
 
Cours de base de données et Langage UML.pptx
Cours de base de données et Langage UML.pptxCours de base de données et Langage UML.pptx
Cours de base de données et Langage UML.pptx
baaab6100
 
NoSQL: Quoi, quand et pour qui par Orlando Cassano du CETIC
NoSQL: Quoi, quand et pour qui par Orlando Cassano du CETICNoSQL: Quoi, quand et pour qui par Orlando Cassano du CETIC
NoSQL: Quoi, quand et pour qui par Orlando Cassano du CETIC
La FeWeb
 
Introduction nosql
Introduction nosqlIntroduction nosql
Introduction nosql
Ines Slimene
 
No Sql - Olivier Mallassi - September 2010
No Sql - Olivier Mallassi - September 2010No Sql - Olivier Mallassi - September 2010
No Sql - Olivier Mallassi - September 2010
JUG Lausanne
 
Benchmarking NoSQL DataBase dans le cadre d'un projet IoT
Benchmarking NoSQL DataBase dans le cadre d'un projet IoTBenchmarking NoSQL DataBase dans le cadre d'un projet IoT
Benchmarking NoSQL DataBase dans le cadre d'un projet IoT
CHAKER ALLAOUI
 
SGBDR vs NoSQL, Différences et Uses Cases. Focus sur ArangoDB
SGBDR vs NoSQL, Différences et Uses Cases. Focus sur ArangoDBSGBDR vs NoSQL, Différences et Uses Cases. Focus sur ArangoDB
SGBDR vs NoSQL, Différences et Uses Cases. Focus sur ArangoDB
Romain Cambien
 
Traitement distribue en BIg Data - KAFKA Broker and Kafka Streams
Traitement distribue en BIg Data - KAFKA Broker and Kafka StreamsTraitement distribue en BIg Data - KAFKA Broker and Kafka Streams
Traitement distribue en BIg Data - KAFKA Broker and Kafka Streams
ENSET, Université Hassan II Casablanca
 
Les bases de donnees nosql
Les bases de donnees nosqlLes bases de donnees nosql
Les bases de donnees nosql
zied kallel
 
cours06-nosql.pdf
cours06-nosql.pdfcours06-nosql.pdf
cours06-nosql.pdf
hbadir
 
Database/ Bases de données
Database/ Bases de donnéesDatabase/ Bases de données
Database/ Bases de données
zied kallel
 
Bases de données no sql.pdf
Bases de données no sql.pdfBases de données no sql.pdf
Bases de données no sql.pdf
ZkSadrati
 
DataStax Enterprise - La plateforme de base de données pour le Cloud
DataStax Enterprise - La plateforme de base de données pour le CloudDataStax Enterprise - La plateforme de base de données pour le Cloud
DataStax Enterprise - La plateforme de base de données pour le Cloud
Victor Coustenoble
 
ch2-hadoop-L3-2023-4p (1).pdf
ch2-hadoop-L3-2023-4p (1).pdfch2-hadoop-L3-2023-4p (1).pdf
ch2-hadoop-L3-2023-4p (1).pdf
salmanakbi
 
Livre blanc data-lakes converteo 2018
Livre blanc data-lakes converteo 2018Livre blanc data-lakes converteo 2018
Livre blanc data-lakes converteo 2018
Converteo
 
Les clés de succès pour moderniser votre architecture de données en 2022
Les clés de succès pour moderniser votre architecture de données en 2022Les clés de succès pour moderniser votre architecture de données en 2022
Les clés de succès pour moderniser votre architecture de données en 2022
Denodo
 
dbh.pdf
dbh.pdfdbh.pdf
dbh.pdf
DOUA9
 
Big_Data_Cours.pdf
Big_Data_Cours.pdfBig_Data_Cours.pdf
Big_Data_Cours.pdf
GonnaBe1
 
NOTES DE BIG DATA L 3 INFO DUS 2024.pptx
NOTES DE BIG DATA L 3 INFO DUS 2024.pptxNOTES DE BIG DATA L 3 INFO DUS 2024.pptx
NOTES DE BIG DATA L 3 INFO DUS 2024.pptx
EddySHANGA
 

Similaire à Les BD NoSQL (20)

Big data: NoSQL comme solution
Big data: NoSQL comme solutionBig data: NoSQL comme solution
Big data: NoSQL comme solution
 
Cours de base de données et Langage UML.pptx
Cours de base de données et Langage UML.pptxCours de base de données et Langage UML.pptx
Cours de base de données et Langage UML.pptx
 
NoSQL: Quoi, quand et pour qui par Orlando Cassano du CETIC
NoSQL: Quoi, quand et pour qui par Orlando Cassano du CETICNoSQL: Quoi, quand et pour qui par Orlando Cassano du CETIC
NoSQL: Quoi, quand et pour qui par Orlando Cassano du CETIC
 
Introduction nosql
Introduction nosqlIntroduction nosql
Introduction nosql
 
No Sql - Olivier Mallassi - September 2010
No Sql - Olivier Mallassi - September 2010No Sql - Olivier Mallassi - September 2010
No Sql - Olivier Mallassi - September 2010
 
Benchmarking NoSQL DataBase dans le cadre d'un projet IoT
Benchmarking NoSQL DataBase dans le cadre d'un projet IoTBenchmarking NoSQL DataBase dans le cadre d'un projet IoT
Benchmarking NoSQL DataBase dans le cadre d'un projet IoT
 
SGBDR vs NoSQL, Différences et Uses Cases. Focus sur ArangoDB
SGBDR vs NoSQL, Différences et Uses Cases. Focus sur ArangoDBSGBDR vs NoSQL, Différences et Uses Cases. Focus sur ArangoDB
SGBDR vs NoSQL, Différences et Uses Cases. Focus sur ArangoDB
 
Traitement distribue en BIg Data - KAFKA Broker and Kafka Streams
Traitement distribue en BIg Data - KAFKA Broker and Kafka StreamsTraitement distribue en BIg Data - KAFKA Broker and Kafka Streams
Traitement distribue en BIg Data - KAFKA Broker and Kafka Streams
 
Les bases de donnees nosql
Les bases de donnees nosqlLes bases de donnees nosql
Les bases de donnees nosql
 
cours06-nosql.pdf
cours06-nosql.pdfcours06-nosql.pdf
cours06-nosql.pdf
 
Database/ Bases de données
Database/ Bases de donnéesDatabase/ Bases de données
Database/ Bases de données
 
Bases de données no sql.pdf
Bases de données no sql.pdfBases de données no sql.pdf
Bases de données no sql.pdf
 
DataStax Enterprise - La plateforme de base de données pour le Cloud
DataStax Enterprise - La plateforme de base de données pour le CloudDataStax Enterprise - La plateforme de base de données pour le Cloud
DataStax Enterprise - La plateforme de base de données pour le Cloud
 
ch2-hadoop-L3-2023-4p (1).pdf
ch2-hadoop-L3-2023-4p (1).pdfch2-hadoop-L3-2023-4p (1).pdf
ch2-hadoop-L3-2023-4p (1).pdf
 
Livre blanc data-lakes converteo 2018
Livre blanc data-lakes converteo 2018Livre blanc data-lakes converteo 2018
Livre blanc data-lakes converteo 2018
 
Les clés de succès pour moderniser votre architecture de données en 2022
Les clés de succès pour moderniser votre architecture de données en 2022Les clés de succès pour moderniser votre architecture de données en 2022
Les clés de succès pour moderniser votre architecture de données en 2022
 
dbh.pdf
dbh.pdfdbh.pdf
dbh.pdf
 
Big_Data_Cours.pdf
Big_Data_Cours.pdfBig_Data_Cours.pdf
Big_Data_Cours.pdf
 
Base donnes my_sql
Base donnes my_sqlBase donnes my_sql
Base donnes my_sql
 
NOTES DE BIG DATA L 3 INFO DUS 2024.pptx
NOTES DE BIG DATA L 3 INFO DUS 2024.pptxNOTES DE BIG DATA L 3 INFO DUS 2024.pptx
NOTES DE BIG DATA L 3 INFO DUS 2024.pptx
 

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 or- dinateurs. 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 diffé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 tran- sactions 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 différents serveurs. I Difficile 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écification 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 à fonc- tionner. I Partition-tolerance ou Résistance au partitionne- ment : 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 partitionne- ment) 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 automa- tiquement 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 environne- ment 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 co- pies des données (répliques) augmente direc- tement 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 diffé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, afin 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 solu- tions 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 nom- breux 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 identifié 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 couram- ment 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 effectué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 significative). I Les profils, 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 - `a 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 Netflix 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 do- cuments. 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’effec- 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éfinir 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’effectuer 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 efficaces 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 diffé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 fac¸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 rec¸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 fac¸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 diffé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 fonc- tion 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 Handoff : - 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 (fin 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 suffisant 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 mo- dification et en la remplac¸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 vec- teur d’horloge représentant son état et ce- lui 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 hor- loge locale de nœud, du numéro de ver- sion/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 finaux. 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 appli- cations nécessitant d’être très performante et travaillant sur de gros volumes que seules de grosses compagnies peuvent s’offrir. 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 ´Ecrit 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 flexible. 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éfixe 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éfinition 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éfinition 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éfinition 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 docu- ment à 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éfinition 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 fils (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 ? - ´Equivalent 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éfinition d’un schéma de données avec MongoDB Définition 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/´Ecriture 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/´Ecriture 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/´Ecriture 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/´Ecriture 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/´Ecriture 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/´Ecriture 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/´Ecriture 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 commenc¸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 offre 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.find({”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 ser- veurs. 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, rec¸oit toutes les opérations de lecture et écriture. - Les autres instances mongod, les répliques secondaires, appliquent les instructions rec¸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 fac¸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 es- claves 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 configurer 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 trafic 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éfini 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 modifier 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éfinition 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 diffé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 efficace, 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éfini, 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éfinir des tags, qu’ils associent à des intervalles de clé. I Ils associent ces tags aux diffé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 dis- tribution des données déséquilibrée. I Splitting : - ´Evite 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 config server sont modifié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éfinir une clé de partitionnement pour le sharding : db.runCommand({shardcollection : ”<namespace>”, key :{” :<nom champ>” :1}}) ; I Afficher 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 effectuer 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 ´Ecrit en Java. I Distribué. I Haute disponibilité : no SPOF. I Massivement parallèle. I Scalabilité linéaire. I ´Ecrit plus rapidement qu’il ne lit. ⇒ `A 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. - ´Echange 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 diffé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 fac¸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éfinit 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’im- porte quel nœud, au moins un. - Offre 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. - Offre 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 Handoffs. I Elle tente de modifier 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. - `A la lecture d’une donnée, le nœud coor- dinateur 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