Les BD NoSQL

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

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

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
BD NoSQL Clé/Valeur (Key/Value Store)
BD NoSQL orientées Colonnes
BD NoSQL orientées documents
BD NoSQL orientées graphes
Prise en charge de l’extensibilité
Partitionnement dans les systèmes NoSQL
Compromis sur la Cohérence
Consultation de données : MapReduce

Mouvement NoSQL 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).

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

Mouvement NoSQL 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.

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).

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.

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

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

Potential des BD NoSQL dans l’entreprise
http ://www.pwc.com/us/en/advisory/business-digital-technology-trends-nosql-databases.html

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.

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).

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.

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.

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

Mouvement 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.

Taxonomie des bases NoSQL
1 Mouvement 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,....

Paysage des SGBD NoSQL

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

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 eﬀectuées.

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

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.

Taxonomie des bases NoSQL 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.
- 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.

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

Colonne / Super-Colonne/Famille de Colonnes

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

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.

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

Taxonomie des bases NoSQL 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’eﬀec-
tuer des requêtes (plus complexe que l’interface CRUD des BD clés/valeurs).
- MongoDB.
- CouchDB (fondation Apache).
- RavenDB (pour plate-formes .NET/Windows - LINQ), ....

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

http ://www.stechfrites.com/book/export/html/2
http ://changeaas.com/2014/09/14/nosql-databases-2/

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...

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).

Taxonomie des bases NoSQL 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.
- Neo4J.
- OrientDB (fondation Apache), ...
I Elles utilisent :
- Un moteur de stockage pour les objets (similaire à une base documentaire, chaque
entité de cette base étant nommée nœud).
- Un mécanisme de description d’arcs (relations entre les objets), arcs orientés et avec
propriétés (nom, date, ...)
I Elles sont bien plus eﬃcaces que les BDR pour traiter les problématiques liées aux réseaux
(cartographie, relations entre personnes, ...).
I Sont adaptées à la manipulation d’objets complexes organisés en réseaux : cartographie,
réseaux sociaux,...

Exemples

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

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,...

Technologies communément utilisées dans les bases NoSQL
1 Mouvement NoSQL

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

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é.

Distribution de données : Consistent hashing
I Consistent hashing : Mécanisme de partitionnement (horizontal) dans lequel
les objet-données sont stockés sur des nœuds-serveurs diﬀérents en utilisant la
même fonction de hachage à la fois pour le hachage des objets et le hachage
des nœuds :
Nœuds et objets sont associés par une même 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.

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.

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).

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

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

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

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 remplaçant par une fraction contenant les données
modifiées.
- Mais en marquant les anciennes données comme obsolètes et en ajoutant
une nouvelle version contenant les nouvelles données.
- Il existe ainsi plusieurs versions enregistrées, une seule est la plus récente.
I Nécessite généralement un balayage périodique pour supprimer les don-
nées obsolètes.

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.

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

Avantages / Inconvénients des bases NoSQL
1 Mouvement NoSQL

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.

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’oﬀrir.

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

Structure de données

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

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

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

Les documents

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.

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.

Structure de documents
I Comment choisir entre références et données imbriquées ?
I On choisit les références quand :
- L’imbrication va produire des données dupliquées sans grands avantages en terme
de performance de lecture.
- On veut représenter des relations many-to-many complexes.
- On veut modéliser de larges ensembles de données hiérarchiques.
I On choisit les données imbriquées quand :
- On a des relations contains entre les éléments (modèles one-to-one). Exemple :
personne et adresse.
- On a des relations one-to-many, où les documents ﬁls (many) apparaissent toujours
dans le contexte des documents parents (one). Exemple : personne et plusieurs
emails.

L’invite interactive de MongoDB

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.

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.

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 )

L’invite interactive de MongoDB Déﬁnition 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() ;

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

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’}])

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...).

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”) })
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

Recherche
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.

Recherche
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).

Recherche
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,...]}}

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

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’ } )
> db.etudiants.remove({ id : ObjectId(”532d40c72d150b4635b8cfc9”) })
> db.etudiants.find({prenom : ’Camille’})

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 :

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

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() ;

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

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.

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

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.

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.

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

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

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)
...

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.

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.

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

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

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

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 :
- Évite d’avoir des chunks trop larges.
- Quand la taille d’un chunk augmente au delà d’une valeur prédéfinie
(chunk size), MongoDB divise cet ensemble de données en deux sur le
même shard.
- Les insertions et les modifications déclenchent les splits.
- Un split change les méta-données, mais ne fait pas migrer les données
ni n’affecte le contenu des shards.

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

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.

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

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 ...

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..

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

MongoDB et MapReduce

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

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.

Exemple
I Le traitement et son résultat : (lui-même stocké dans un champs or-
der totals)

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.

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/

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

Découverte de Cassandra

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

Partitionnement dans Cassandra

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

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.

Replication dans Cassandra

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

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.

Consistance dans Cassandra

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

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.

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.
- Oﬀre la plus haute disponibilité,
mais la plus basse consistance.
I One (défaut dans CQL) : une écriture doit
réussir sur le commit log et la memtable
d’au moins une réplique.
I Quorum : une écriture doit réussir sur un certain pourcentage de répliques (pourcentage
=(facteur de replication/2)+1).
I Local-Quorum : une écriture doit réussir sur un certain pourcentage de nœuds répliqués
sur le même Data-Center que le nœud coordinateur.
I Each-Quorum : une écriture doit réussir sur un certain pourcentage de nœuds répliqués
sur tous les Data-Centers.
I All : une écriture doit réussir sur tous les nœuds répliqués d’une colonne.
- Oﬀre la plus haute consistance, mais la plus basse disponibilité.

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

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é.

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

Gestion de données et des objets dans Cassandra

Les BD NoSQL

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (20)

Similar a Les BD NoSQL

Similar a Les BD NoSQL (20)

Les BD NoSQL