SlideShare une entreprise Scribd logo
1  sur  85
Télécharger pour lire hors ligne
Chp4 – Bases de Données NOSQL
Types, Architectures et Exemples (Cassandra, MongoDB)
Big Data
GL4 (Option Management des Systèmes d'Information) - 2016
Dr. Lilia SFAXI
www.liliasfaxi.wix.com/liliasfaxi
Slide 1
Bases de Données NOSQL
• Bases de données NOSQL (Not Only SQL) :
§ Ce n’est pas (comme son nom le laisse supposer) No SQL (pas de SQL)
§ Privilégier donc NOSQL plutôt que NoSQL
• Bases de données non-relationnelles et largement distribuées
• Permet une analyse et une organisation rapides et ad-hoc des données de
très grands volumes et de types de données disparates
• Appelées également
§ Cloud Databases
§ Non-Relational Databases
§ Big Data Databases
§ …
• Développées en réponse à l’augmentation exponentielle des données
générées, enregistrées et analysées par les utilisateurs modernes et leurs
applications
2
Définition
Bases de Données NOSQL
• Principaux atouts
§ Évolutivité
§ Disponibilité
§ Tolérance aux fautes
• Caractéristiques
§ Modèle de données sans schéma
§ Architecture distribuée
§ Utilisation de langages et interfaces qui ne sont pas uniquement du SQL
3
Atouts
Bases de Données NOSQL
• De point de vue métier, utiliser un environnement BigData et NOSQL
fournit un avantage compétitif certain
• Importance des données :
§ « Si vos données ne croissent pas, alors votre entreprise ne le fait pas non
plus »
4
NOSQL et Big Data
Bases de Données NOSQL
• Types des bases de données NOSQL
§ Clef/valeur
§ Orientées colonnes
§ Orientées documents
§ Orientées graphes
• Propriétés des BDR
§ ACID : Atomicity, Consistency, Isolation and Durability
§ Utilisation de SQL
5
Types
Id Nom Humeur Date_naissance Couleur	
12 Stella Heureuse 2007-04-01 NULL
13 Wimma Faim NULL Noire
9 Ninja NULL NULL NULL
Types de Bases de Données NOSQL
• L’un des types les plus simples, sorte de Hashmap distribuée
• Conçues pour sauvegarder les données sans définir de schéma
• Toutes les données sont sous forme de clef/valeur
§ La valeur peut être une chaîne de caractères, un objet sérialisé, blob…
§ La donnée est opaque au système: il n’est pas possible d’y accéder sans passer
par la clef
• Absence de typage a un impact sur le requêtage: toute l’intelligence portée
avant par les requêtes devra être portée par l’applicatif qui interroge la BD
• Communications se résumant surtout aux opérations PUT, GET et DELETE
• Objectif: fournir un accès rapide aux informations, conserver la session d’un
site web…
• Exemple : DynamoDB (Amazon), Azure Table Storage (ATS), Redis,
BerkeleyDB, Voldemort (LinkedIn)
6
1. Clef/Valeur (Key/Value Store)
Types de Bases de Données NOSQL
7
1. Clef/Valeur (Key/Value Store)
Id Nom Humeur Date_naissance Couleur	
12 Stella Heureuse 2007-04-01 NULL
13 Wimma Faim NULL Noire
9 Ninja NULL NULL NULL
Chien_12
Nom_$#_Stella~~Humeur_$#_Heureuse
~~Date_naissance_$#_2007-04-01…
Clef
Valeur
Types de Bases de Données NOSQL
• Étendent le paradigme clef/valeur, avec des « documents » plus complexes à
la place des données simples, et une clef unique pour chacun d’eux
• Documents de type JSON ou XML
• Chaque document est un objet, contient un ou plusieurs champs, et chaque
champs contient une valeur typée (string, date, binary ou array)
• Permettent de stocker, extraire et gérer les informations orientées
documents (données semi-structurées)
• Avantage : pouvoir récupérer, via une seule clef, un ensemble d’informations
structurées de manière hiérarchique
§ Dans les bases relationnelles, cela impliquerait plusieurs jointures
• Exemples : Mongo DB (SourceForge), Couch DB (Apache), RavenDB (destiné
aux plateformes .Net/Windows, interrogation via LINQ)
8
2. Orientée Documents (Document Database)
Types de Bases de Données NOSQL
9
2. Orientée Documents (Document Database)
Id Nom Humeur Date_naissance Couleur	
12 Stella Heureuse 2007-04-01 NULL
13 Wimma Faim NULL Noire
9 Ninja NULL NULL NULL
Chien_12
{
type	:	« Chien »,
nom	: « Stella »,
humeur	: « Heureuse»,
date_naissance:	2007-04-01
}
Clef
Document	(V1)
{
type	:	 « Chien »,
nom	: « Stella »,
humeur	: « Heureuse»,
date_naissance:	2007-04-01
aboiement	:	[
{	texte	:	« j’ai	mangé	de	la	pâtée»
commentaires	:	[
{	id_chien :	« chien_4 »,
texte	:	« on	s’en	fout!»
}
]
}
]
}
Document	(V2)
Types de Bases de Données NOSQL
• Évolution de la BD clef/valeur
• Ressemble aux SGBDR, mais avec un nombre de colonnes dynamique,
différent d’un enregistrement à un autre (pas de colonnes portant les
valeurs NULL)
• Offrent de très hautes performances et une architecture hautement
évolutive
• Exemples: Hbase (Hadoop), Cassandra (Facebook, Twitter), BigTable
(Google)
10
3. Orientées Colonnes (Column Store)
A B C D E
1 Foo Bar Hello
2 Tom
3 Java Scala Cobol	
1
2
3
A Foo B Bar C Hello
B Tom
C Java D Scala E Cobol
Types de Bases de Données NOSQL
11
3. Orientées Colonnes (Column Store)
Id Nom Humeur Date_naissance Couleur	
12 Stella Heureuse 2007-04-01 NULL
13 Wimma Faim NULL Noire
9 Ninja NULL NULL NULL
Chien_12
Clef
Chien Date_naissance 15
Chien Humeur 11
Chien Humeur 45
Chien Nom 25
Chien Couleur 34
Colonnes
Aboiement Text 11
2007-04-01
En	Colère
Heureuse
Stella
Noire
J’ai	mangé	de	la	pâtée
Famille	 Titre Temps	
Valeur
Requête:	 clef/famille:titre[/time]
Exp:		"chien_12"/"Chien":"Nom"	è Stella
Types de Bases de Données NOSQL
12
3. Orientées Colonnes (Column Store)
Exemple	Cassandra	:	Colonne	/	Super	Colonne	/	Famille	de	Colonnes
Types de Bases de Données NOSQL
• Basées sur les théories des graphes
• S’appuie sur les notions de nœuds, de relations et des propriétés qui
leur sont rattachées
• Conçues pour les données dont les relations sont représentées comme
graphes, et ayant des éléments interconnectés, avec un nombre
indéterminé de relations entre elles
• Adapté aux traitements des données des réseaux sociaux
• Exemples : Neo4J et InfiniteGraph, OrientDB
13
4. Orienté Graphes (Graph Database)
Types de Bases de Données NOSQL
14
4. Orienté Graphes (Graph Database)
Id Nom Humeur Date_naissance Couleur	
12 Stella Heureuse 2007-04-01 NULL
13 Wimma Faim NULL Noire
9 Ninja NULL NULL NULL
Chien_12
Chien
Stella
Heureuse
2007-04-01
Aboiement_5
9
Commentaire_
83
Chien_4
«	On	s’en	
fout! »
«	J’ai	mangé	de	la	
pâtée! »
type
nom
humeur
date_naissance
aboiements
Commentaire_à
texte
commente
texte
Types de Bases de Données NOSQL
Modèle Performance Évolutivité Flexibilité Complexité Fonctionnalités
Clef/Valeur Variable
Orienté Colonnes Minimale
Orienté Document Variable
Orienté Graphes
Théorie des
Graphes
15
Comparaison
NOSQL VS. BDR
Chp4 – Bases de Données NOSQL
16
NOSQL et BDR
• Choix de NOSQL en opposition aux bases de données relationnelles conduits
par les contraintes du marché et les besoins techniques
• BigData
§ Adaptation des BD NOSQL au BigData
o Vitesse (Velocity) : beaucoup de données qui arrivent rapidement, à partir de
plusieurs sources
o Variété (Variety) : données structurées, semi-structurées ou non-structurées
o Volume (Volume) : données très nombreuses (To et Po)
o Complexité (Complexity) : données stockées et gérées à plusieurs endroits et data
centers.
• Disponibilité continue des données
§ Le manque de disponibilité peut être fatal pour une entreprise
§ BD NOSQL utilisent une architecture hautement distribuée : pas de SPOF
§ Redondance des données et traitements : tolérance aux fautes
§ D’où : disponibilité continue à travers les data centers, et le cloud
§ Toute mise à jour ou modification est faite sans déconnecter la base
17
Comparaison (1/3)
NOSQL et BDR
• Indépendance de l’emplacement
§ Possibilité de consulter et modifier une BD sans savoir où est-ce que ces
opérations ont réellement lieu
§ Toute fonctionnalité d’écriture propagée à partir d’un emplacement, pour être
disponible aux utilisateurs à partir d’autres sites
§ Difficile à appliquer aux BDR, surtout pour l’écriture
• Modèles de données flexibles
§ Une des raisons majeures
§ Dans le modèle relationnel, les relations entre les tables sont prédéfinies, fixes
et organisées dans un schéma strict et uniforme
o Problèmes d’évolutivité et de performance en gérant de grands volumes de données
§ Les BD NOSQL peuvent accepter tout type de données (structurées, semi-
structurées ou non-structurées) plus facilement
§ Dans les BDR, les performances posent problème, surtout quand des lignes
« larges » sont utilisées et les actions de modification sont nombreuses
18
Comparaison (1/3)
NOSQL et BDR
• Business Intelligence et Analyse
§ Capacité des bases NOSQL à exploiter les données collectées pour dériver
des idées
§ Extraction d’informations décisionnelles à partir d’un grand volume de
données, difficile à obtenir avec des bases relationnelles
§ Bases NoSQL permettent le stockage et la gestion des données des
applications métier, et fournissent une possibilité de comprendre les
données complexes, et de prendre des décisions
• Capacités transactionnelles modernes
§ Nouvelles définition du principe de transaction
§ Utilisation des propriétés BASE au lieu des propriétés ACID
19
Comparaison (3/3)
NOSQL et BDR
• Propriétés ACID : Atomicité, Consistance, Isolation et Durabilité
§ Propriétés des transactions des BDR
§ Atomicité : Soit toutes les instructions sont exécutées, soit aucune
§ Consistance : toute transaction amène la BD d’un état valide à un autre è
renforcée par les contraintes d’intégrité et les clefs étrangères
§ Isolation : Même si plusieurs transactions peuvent être exécutées par un
ou plusieurs utilisateurs simultanément, une transaction ne devrait pas
voir les effets des autres transactions concurrentes
§ Durabilité : Une fois la transaction enregistrée dans la base (commit), ces
changements sont persistants.
• Toutes les BDR supportent les transactions ACID
• Mais :
§ Données de plus en plus volumineuses + Besoin de systèmes évolutifs
§ Besoin de BD distribuées sur le réseau, pour une évolutivité horizontale
20
Propriétés ACID
NOSQL et BDR
• Destiné à évaluer les systèmes de stockage
distribués
• Théorème CAP : « Il est impossible de satisfaire les
trois propriétés CAP en même temps »
• Propriétés CAP : Consistency, Availability, Partition
tolerance
§ Consistance: Si j’écris une donnée dans un nœud et
que je la lis à partir d’un autre nœud dans un
système distribué, je retrouve ce que j’ai écris sur le
premier.
§ Haute disponibilité : à tout moment, pour chaque
requête, la réponse est garantie. Même en cas de
panne, les données restent accessibles
§ Tolérance au partitionnement : les données peuvent
être partitionnées sur différents supports sans
souci de localisation. Les activités continuent sans
interruption lors de la modification du système (en
cas d’ajout ou suppression de nœuds) et en cas de
chute du réseau
21
Théorème CAP
NOSQL et BDR
• Pourquoi est-il impossible de satisfaire les 3 propriétés CAP en même
temps?
• Soit un système distribué. On est entrain de modifier une donnée sur le
nœud N1 et d’essayer de la lire à partir du nœud N2
§ N2 peut retourner la dernière bonne valeur dont il dispose, ce qui viole la
Consistance
§ N2 attend que la nouvelle valeur lui parvienne. Comme c’est un système
distribué, les chances d’un échec de transmission sont assez importantes, ce
qui provoquera une attente infinie de N2. D’où une violation de la Disponibilité
§ Si on veut satisfaire à la fois la consistance et la disponibilité, le système de
stockage ne doit pas être partitionné. D’où violation de la Tolérance au
partitionnement.
• Pour les BD NOSQL, il n’y a plus de jointures
§ è La propriété de consistance n’est plus assurée de la même manière
• Consistance dans NOSQL: consistance immédiate et éventuelle des données
à travers les nœuds de la base distribuée
22
Théorème CAP
NOSQL et BDR
• BASE : Basically Available, Soft-state, Eventual consistency
• Basically Available
§ Le système garantit la disponibilité, comme définie dans le théorème CAP
• Soft-State
§ L’état du système peut changer dans le temps, même sans nouvelles
entrées, et ce à cause du principe de consistance éventuelle
• Eventual Consistency
§ Les modification arriveront éventuellement à tous les serveurs, si on leur
donne suffisamment de temps
• BASE est plus flexible que ACID, accepte certaines erreurs, dont
l’occurrence est assez rare
23
Propriétés BASE
NOSQL et BDR
24
Récapitulatif
BRD NOSQL
Consistance forte vs Consistance éventuelle
Grande quantité de données vs Enormequantité de données
Évolutivité possible vs Evolutivité facile
SQL vs Map-Reduce
Bonne disponibilité vs Trèshaute disponibilité
NOSQL et BDR
• Bases de données NOSQL
§ Performances sur de gros volumes de données
§ Performances sur des données non structurées
§ Evolutivité très importante, même pour de faibles volumes
• Cependant:
§ Technologie assez jeune è Manque d’outils la supportant
§ Encore en évolution, pas de standards
§ Pas de langage de requêtage commun comme SQL, mais divers:
o Requêtes spécifiques au langage (Java, Python…)
o Requêtes spéciale pour la base (Cassandra Query Language)
o API basée sur Map Reduce, ou sur graphes d’objets
§ On doit faire plus de travail au niveau du code, ce qui peut influer sur la
performance
25
Synthèse
NOSQL et BDR
• Si l’évolutivité est une préoccupation
§ Mais attention, ce n’est pas toujours un MUST : Flickr et Wikipedia utilisent des
RDBMS
• Si l’absence de schéma est une préoccupation
• Si être IN et FASHION est une préoccupation
§ Pour un nombre important de personnes, l’utilisation d’un nouveau paradigme ou
technologie est un MUST!
26
Quand utiliser NOSQL?
CASSANDRA
Chp4 – Bases de Données NOSQL
27
Cassandra
• Base de données :
§ Distribuée
§ À haute performance
§ Extrêmement évolutive
§ Tolérante aux fautes (pas de SPOF)
§ Non-relationnelle
• Peut être utilisée à la fois comme :
§ Base de données temps réel
§ Base de données pour une lecture intensive pour les systèmes décisionnels
• À la base, c’est une combinaison de BigTable de Google et DynamoDB de
Amazon, incubée dans Facebook, et hébergée comme solution open
source dans Apache.
28
Présentation
Cassandra
• Système distribué, P2P
• Composés de plusieurs nœuds identiques
§ Pas de notion de NameNode ou nœud maître…
• Les données sont partitionnées par défaut à travers
les différents nœuds du cluster
• Les données sont répliquées pour assurer une
tolérance aux fautes maximale
§ L’utilisateur contrôle le nombre de répliques qu’il
désire avoir pour ses données
• Lecture et écriture à partir de n’importe quel nœud,
indépendamment de l’emplacement des données
• Utilisation du protocole Gossip pour la
communication entre les différents nœuds du
cluster
§ Échange de données entre les nœuds chaque
seconde
29
Architecture (1/2)
Cassandra
• Structure orientée colonnes, à l’image de
BigTable
• Vocabulaire:
§ Keyspace (équivalent de database)
§ Column Family (équivalent de table)
o Dans la nouvelle version du langage CQL,
appelée Table
o Schéma plus flexible et dynamique qu’une
table
§ Colonne (équivalent à enregistrement)
o Indexée par une clef
o D’autres champs peuvent être également
indexés, mais à la demande
30
Architecture (2/2)
Keyspace:	Portfolio
Column Family :	Client
ID Nom Adresse Tel
Cassandra
• Partitionnement facile des données à
travers les différents nœuds participants du
cluster
• Chaque nœud est responsable d’une partie
de la base de données
• Les données sont insérées par l’utilisateur
dans une famille de colonnes
• Elles sont ensuite placées sur un nœud,
selon sa clef de colonne
31
Partitionnement (1/2)
Keyspace :	Portfolio
Column Family :	Client
ID Nom Adresse Tel
1
2
34
5
Donnée
Cassandra
• Stratégies de partitionnement
§ Partitionnement aléatoire
o Par défaut, recommandé
o Données partitionnée le plus équitablement
possible à travers les différents nœuds
o Utilisation de MD5 (ou Murmur3) pour le hachage
de chaque clef de famille de colonnes
§ Partitionnement ordonné
o Sauvegarde les clefs de familles de colonnes par
ordre à travers les nœuds d’un cluster
o Peut provoquer des problèmes, surtout pour la
répartition des charges (des nœuds avec des
données plus volumineuses que d’autres)
• Stratégie spécifiée dans un fichier de
configuration cassandra.yaml
• Si la stratégie d’une base est modifiée, il faut
recharger toutes les données
32
Partitionnement (2/2)
Keyspace :	Portfolio
Column Family :	Client
ID Nom Adresse Tel
1
2
34
5
Donnée
Cassandra
• Pour assurer la tolérance aux fautes et pas
de SPOF, il est possible de créer une ou
plusieurs copie(s) de chaque colonne à
travers les nœuds participants
• L’utilisateur spécifie le facteur de réplication
désiré à la création du keyspace
• Les données sont insérées par l’utilisateur
dans une famille de colonnes
• La colonne est répliquée dans les nœuds du
cluster selon le facteur de réplication
33
Réplication (1/3)
Facteur	de	réplication	=	2
Keyspace :	Portfolio
Column Family :	Client
ID Nom Adresse Tel
1
2
34
5
Donnée
Copie	de	la	
Donnée
Cassandra
• Stratégies de réplication
§ Stratégie Simple :
o La colonne originelle est placée sur un nœud
déterminé par le partitionneur
o La réplique est placée sur le nœud suivant de
l’anneau (clockwise)
o Pas de considération pour l’emplacement dans
un data-center ou dans une baie (approprié
pour les déploiement sur un seul datacenter)
§ Stratégie par topologie du réseau
o Plus sophistiquée
o Plus de contrôle sur l’emplacement des
répliques de colonnes
o Parcourt le cluster (clockwise) à la recherche
d’un nœud dans une baie différente. Si
introuvable, stocker la colonne dans un nœud
de la même baie
o Un groupe de réplication est spécifié, pour
distinguer entre plusieurs datacenters
34
Réplication (2/3)
1
2
34
5 Donnée
Copie	de	la	
Donnée
1
2
34
5
1
2
34
5
Donnée
Copie	de	la	
Donnée
Copie	de	la	
Donnée
Baie1
Baie2
Cassandra
• Mécanisme de réplication
§ Utilisation de SNITCH:
o Définition de la manière dont les nœuds sont groupés dans un réseau
o Répartition des nœuds entre baies et datacenters
§ Plusieurs types de SNITCH
o Simple SNITCH : utilise la stratégie simple
o Rack-Inferring SNITCH : détermine la topologie du réseau en analysant les
adresses IP:
1. Second octet de l’adresse IP: Data Center
2. Troisième octet de l’adresse IP: Baie
o Property File SNITCH : se base sur une description de l’utilisateur pour
déterminer l’emplacement des nœuds (cassandra-topology.properties)
o EC2 SNITCH : pour déploiement dans Amazon EC2. Utilise l’API AWS pour
déterminer la topologie
§ Défini dans le fichier de configuration cassandra.yaml
35
Réplication (3/3)
Cassandra
• Architecture Read and Write Anywhere
• L’utilisateur peut se connecter à n’importe quel nœud, dans n’importe
quel datacenter, et lire/écrire les données qu’il veut
• Les données sont automatiquement partitionnées et répliquées à
travers le cluster
36
Consistance
Cassandra
• Écriture :
§ 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
o Soit toutes les colonnes sont modifiées, soit aucune ne l’est
• Cassandra est la base de données NOSQL la plus rapide en écriture
37
Consistance
Cassandra
• Consistance : à quel point est-ce qu’une donnée est à jour et synchronisée
sur toutes ses répliques.
• Extension du concept de consistance éventuelle à une consistance ajustable
• Choix possible entre une consistance forte ou éventuelle selon les besoins
• Ce choix est fait par opération, ce n’est pas une stratégie globale pour la
base de données (ex, pour changer la stratégie de lecture en quorum)
§ SELECT * FROM users USING CONSISTENCY QUORUM WHERE state=‘TX’;
• Consistance gérée à travers plusieurs data centers.
38
Consistance
Cassandra
• Niveau de consistance : combien de répliques doivent être écrites avec
succès avant de retourner un acquittement au client
§ Any : une écriture doit réussir sur n’importe quel nœud, au moins un.
o Offre la plus haute disponibilité, mais la plus basse consistance
§ One (défaut dans CQL) : une écriture doit réussir sur le commit log et la
memtable d’au moins une réplique
§ Quorum : une écriture doit réussir sur un certain pourcentage de répliques
(pourcentage = (facteur de réplication/2)+1)
o Meilleure alternative en terme de consistance et de disponibilité
§ Local-Quorum : une écriture doit réussir sur un certain pourcentage de
nœuds répliques sur le même datacenter que le nœud coordinateur
§ Each-Quorum : une écriture doit réussir sur un certain pourcentage de
nœuds répliques sur tous les datacenters.
§ All : une écriture doit réussir sur tous les nœuds répliques d’une colonne
o Offre la plus haute consistance, mais la plus basse disponibilité
39
Stratégies d’Écriture
Cassandra
§ Cassandra utilise les Hinted Handoffs
§ Elle tente de modifier une colonne sur toutes les répliques
§ 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épliques en panne une fois disponibles
§ 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.
40
Stratégies d’Écriture
Cassandra
• Niveau de consistance : combien de répliques doivent répondre avant de
retourner le résultat à l’application cliente
• 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)
§ One (défaut dans CQL) : obtention d’une réponse à partir de la réplique la plus
proche selon le SNITCH
o Offre la plus faible consistance, mais la plus haute disponibilité
§ Quorum : obtention du résultat le plus récent à partir d’un certain pourcentage
de nœuds répliques (pourcentage = (facteur de réplication/2)+1)
o Meilleure alternative en terme de consistance et de disponibilité
§ Local-Quorum : obtention du résultat le plus récent à partir d’un certain
pourcentage de nœuds répliques sur le même datacenter que le nœud
coordinateur
o Évite la latence due à la communication inter-datacenters
§ Each-Quorum : : obtention du résultat le plus récent à partir d’un certain
pourcentage de nœuds répliques sur tous les datacenters.
§ All : obtention du résultat le plus récent à partir de tous les nœuds répliques
o Offre la plus haute consistance, mais la plus basse disponibilité
41
Stratégies de Lecture
Cassandra
• Read Repair
§ Cassandra assure que les données fréquemment lues soient consistantes
§ À la lecture d’une donnée, le nœud coordinateur compare toutes ses
répliques en arrière plan.
§ Si ces données ne sont pas consistantes, 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.
42
Stratégies de Lecture
1
2
34
5 Réplique1	
Réplique2	Réplique3
Cassandra
• Deux interfaces pour gérer les objets/données
§ Cassandra CLI (Command Line Interface)
§ CQL (Cassandra Query Language)
• CLI
§ Interface originelle conçue pour créer des objets, entrées et manipuler les
données
• CQL
§ Utilisée pour créer/manipuler des données en utilisant un langage proche
de SQL
43
Gestion des Données et Objets
Cassandra
• CQL
§ Objets tels que les keyspaces, familles de colonnes et index sont créés,
modifiés et supprimés avec les requêtes usuelles: CREATE, ALTER et DROP
§ Données insérées, modifiées et supprimées avec INSERT, UPDATE et DELETE
§ Données lues avec SELECT
§ Mais
o Ne supporte pas des opérations telles que GROUP BY, ORDER BY (sauf pour les
clefs composées, et ordonnées seulement selon la deuxième clef primaire)…
§ Utiliser la clause USING CONSISTENCY pour déterminer le type de consistance
forte pour chaque opération de lecture et l’écriture (Any, One, Quorum…)
44
Gestion des Données et Objets
Cassandra
• Grande Scalabilité (Gigaoctet/Petaoctet) è Appropriée aux Big Data
§ Gain de performances linéaire grâce à l’ajout des nœuds
• Pas de SPOF (Single Point of Failure)
• Réplication et distribution des données facile à travers les data-
centers
• Pas besoin de couche de cache séparée
§ Utilisation des mémoires vives de l’ensemble des nœuds
• Consistance des données ajustable
§ Possibilité de choisir pour chaque opération si une donnée est fortement
consistante (tous les nœuds sont similaires à tout moment) ou
éventuellement consistante
• Schéma de données flexible
45
Récapitulatif (1/2)
Cassandra
• Compression des données
§ Utilisation de l’algorithme de compression Snappy de Google
§ Compression des données pour chaque famille de colonnes
§ Pas de pénalité pour la performance, et même une amélioration notable,
grâce à la diminution du nombre de I/O physique
• Langage CQL très proche de SQL
• Support des langages et plateformes clef
• Pas besoin de matériel ou de logiciel particulier
46
Récapitulatif (2/2)
MONGODB
Chp4 – Bases de Données NOSQL
47
MongoDB
• MongoDB (de Humongous, qui veut dire énorme)
• SGBD NOSQL orienté documents, à schéma flexible et distribuable
• Écrit en C++
• Distribué sous licence AGPL
• Développé en 2007 par la firme MongoDB
48
Introduction
MongoDB
• Données représentées dans un schéma flexible
• Données stockées sous forme de documents (paires clef/valeur) JSON-
like
• La structure du document n’est pas fixée à sa création
§ Mais en général, les documents d’une même collection ont une structure
similaire (homogénéité)
• Les documents sont organisés sous forme de collections
§ Groupe de documents reliés par des indexes en commun
49
Structure de Données
MongoDB
50
Terminologie
Terminologie SQL Terminologie MongoDB
Base de données Base de données
Table Collection
Ligne Document
Colonne Champ
Index Index
Jointure Imbrication ou Référence
Clef Primaire (peutêtre multiple) Clef Primaire (une seule, etreprésentée par le champ_id)
MongoDB
• Structure de données JSON-like, composée de paires clef/valeur
• Stocké sur le disque sous forme de document BSON
§ Documents BSON (Binary JSON) : représentation binaire sérialisées d’une
document JSON
§ 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
51
Document
MongoDB
• Le champ _id
§ Seul champ obligatoire, utilisé comme clef primaire dans une collection
§ Peut être de tout type autre que Tableau
• Les champs indexés ont une taille limite (1Mo)
• Les noms des champs ne peuvent pas commencer par un $, contenir le
caractère « . » ou le caractère « null »
52
Document
MongoDB
• Limites
§ Taille max d’un document : 16Mo
o Utilisation de l’API GridFS pour stocker des documents plus larges que la taille
autorisée
o GridFS permet de diviser les documents en chunks de même taille, et les stocke
sous forme de documents séparés
§ MongoDB préserve l’ordre des champs du document, comme défini à leur création,
sauf:
o Que le champs _id doit toujours figurer en premier
o 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
§ Champs _id
o Création d’un index unique à la création d’une collection
o Utilisation conseillée d’un ObjectId: objets petits (12o), uniques et rapides à
générer
53
Document
MongoDB
• Deux manières des relations entre les données: Références et Données
Imbriquées
• Références
§ Inclusion de liens ou références d’un document à un autre
§ C’est à l’application de résoudre ces références pour accéder aux données
associées
§ On dit qu’on utilise des Modèles de Données Normalisés
54
Structure de Documents
MongoDB
• Données Imbriquées (Embedded Data)
§ Sauvegarde des données associées dans la même structure de documents
§ Il est possible d’inclure des documents dans un champ ou un tableau
§ Permet aux applications d’extraire et manipuler plusieurs niveaux de
hiérarchie en une seule instruction
§ Ce sont les Modèles de Données Dénormalisés
55
Structure de Documents
MongoDB
• Comment choisir entre Références et Données Imbriquées?
• On choisit les références quand:
§ L’imbrication va produire des données dupliquées sans grands avantages en
terme de performance de lecture
§ On veut représenter des relations many-to-many complexes
§ On veut modéliser de larges ensembles de données hiérarchiques
• On choisit les données imbriquées quand:
§ On a des relations contains entre les éléments (modèles one-to-one)
o 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)
o Exemple : personne et plusieurs emails
56
Structure de Documents
MongoDB
• Lecture
§ Cible une unique collection spécifique de documents
§ Cible un critère ou des conditions spécifiques, pour identifier le document à
retourner
§ Peut inclure une projection sur les champs du document à retourner
§ Peut définir des Modificateurs pour imposer des limites, un ordre, un filtre…
57
Opération de Lecture
MongoDB
• MongoDB fournit une méthode db.collection.find() pour l’extraction de
données
§ Accepte les critères de la requête, ainsi que les projections
§ Retourne un curseur vers les documents correspondants
• Fournit également une méthode db.collection.findOne() retournant un
seul document
58
Opération de Lecture
Équivalent	SQL
MongoDB
• Projections
§ Deuxième argument de la méthode find()
§ Peuvent spécifier la liste des champs à afficher ou à exclure
§ Mis à part pour exclure le champ _id (qui est affiché par défaut), il est
interdit de mixer les projections inclusives et exclusives
59
Opération de Lecture
MongoDB
• Modification
§ Création, mise à jour ou suppression de données
§ Ces opérations modifient les données d’une seule collection
§ Définition de critères pour sélectionner les documents à modifier ou
supprimer
60
Opération d’Ecriture
MongoDB
• Insertion de document
§ Si vous ajoutez un document sans champ _id, le système l’ajoute lui-même
en générant un champ de type ObjectId
61
Opération d’Ecriture
MongoDB
• Mise à jour de documents
§ Méthode update peut accepter des critères de sélection des documents à
modifier, et des options qui affectent son comportement.
§ Une opération update modifie un seul document par défaut (plusieurs docs
si multi:true)
§ Existence de l’option upsert: si true, et que le document à modifier n’existe
pas dans la collection, il est automatiquement inséré
62
Opération d’Ecriture
MongoDB
• Suppression de documents
§ La méthode remove supprime des documents d’une collection
§ Accepte des critères de sélection des documents à supprimer
§ Supprime par défaut tous les documents correspondant aux critères de
sélection (sauf indication du contraire dans un flag approprié)
63
Opération d’Ecriture
MongoDB
• Les opérations d’écriture sont atomiques au niveau d’un document
§ Aucune opération d’écriture ne peut affecter atomiquement plus qu’un seul
document ou collection
§ L’utilisation des données imbriquées facilite l’écriture
§ La normalisation des données (référence vers données dans d’autres
collections) implique plusieurs opérations d’écriture qui ne sont pas
atomiques.
• Certaines modifications (un push dans des tableaux, ou bien un ajout
d’un champ) augmentent la taille des documents
§ Pour le moteur de stockage MMAPv1, si la taille d’un document dépasse la
taille autorisée pour ce document, MongoDB le réalloue sur le disque
§ Si votre application nécessite plusieurs modifications qui augmentent la
taille des documents, considérer plutôt l’utilisation des références
64
Opération d’Ecriture
MongoDB
• MongoDB utilise la notion de Sharding (ou horizontal scaling ou scale
out) pour stocker ses données dans le cluster
§ Division des données et leur distribution entre plusieurs serveurs ou
shards
§ Chaque shard est une base indépendante, et mis ensemble, forment une
seule base de données logique
• Réduction du nombre d’opérations que chaque machine gère
§ Chaque machine gère les données qui y sont stockées
• Réduction de la quantité de données que le serveur a besoin de
stocker
§ Plus le cluster grandit, moins un serveur contient de données
65
Architecture: Sharding
MongoDB
• Shards
§ Stockent les données
§ Les données sont distribuées et
répliquées sur les shards
• 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
• 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
66
Architecture: Sharding
MongoDB
• Partitionnement des données au niveau des collections, via la
shard key
§ Champ simple ou composé indexé qui existe dans chaque document de la
collection
• MongoDB divise les valeurs de la clef en morceaux (chunks)
et les distribuent de manière équitable entre les shards
• La répartition des clefs suit l’une de ces deux méthodes de
partitionnement:
§ Basée sur le rang
§ Basée sur le Hash
§ Basée sur les tags
67
Partitionnement des Données
MongoDB
• Paritionnement basé sur le rang
§ Définition d’intervalles qui ne se chevauchent pas, dans lesquelles les
valeurs de la shard key peuvent se trouver
§ Permet aux documents avec des clefs proches de se trouver dans le même
shard
§ Plus facile de retrouver le shard pour une donnée
§ Risque de distribution non équitable des données (par exemple si la clef
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é)
68
Partitionnement des Données
MongoDB
• Paritionnement basé sur le hash
§ Calcul de la valeur du hash d’un champ, puis utilise ces hash pour créer des
parittions
§ Deux documents ayant des clefs proches ont peu de chance de se trouver
dans le même shard
§ Distribution aléatoire d’une collection dans le cluster, d’où une distribution
plus équitable
§ Moins efficace, car le temps de recherche de la donnée est plus grand
§ 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
69
Partitionnement des Données
MongoDB
• Paritionnement basé sur les tags
§ Les administrateurs peuvent définir des tags, qu’ils associent à des
intervalles de clef
§ Ils associent ces tags aux différents shards en essayant de respecter la
distribution équitable des données
§ Un balancer migre les données taggées vers les shards adéquats
§ Le meilleur moyen pour assurer une bonne répartition des données
70
Partitionnement des Données
MongoDB
• L’ajout de nouvelles données ou nouveaux serveurs peut rendre la
distribution des données déséquilibrée
• 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 divisie 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
71
Maintien d’une Distribution Équitable
MongoDB
• 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
o Le shard destination reçoit tous les documents du chunk à migrer
o Le shard destination applique tous les changements faits aux données durant le
processus de migration
o Finalement, les métadonnées concernant l’emplacement du chunk sur le config
server sont modifiées
72
Maintien d’une Distribution Équitable
MongoDB
• 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é
• 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
73
Ajout ou Suppression de Shards
MongoDB
• Définition d’un Replicat Set: groupe de processus mongod qui fournit la
redondance et la haute disponibilité
• Types de membres dans un replicat set:
§ Primaire: Reçoit toutes les opérations d’écriture
§ Secondaire: réplication des opération 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
74
Stratégies de Réplication
MongoDB
• Primaire
§ Seul membre qui reçoit les opérations d’écriture
§ MongoDB applique les opérations d’écriture sur le
primaire, puis les enregistre dans son log
(oplog)
§ Les membres secondaires dupliquent ce log et
appliquent les opérations sur leurs données
§ Tous les membres d’un replicat set peuvent
accepter une opération de lecture
o Par défaut, une application dirige ces opérations
vers le primaire
§ Un replicat set a au plus un primaire
§ Si le primaire tombe en panne, une élection a lieu
pour en choisir un autre
75
Stratégies de Réplication
MongoDB
• Secondaires
§ Maintiennent une copie des données du primaire
§ 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
§ Un replicat set peut avoir un ou plusieurs secondaires
§ Même si les clients ne peuvent pas écrire des données sur les secondaires, ils
peuvent en lire
§ Un secondaire peut devenir un primaire, suite à une élection
§ Il est possible de configurer un secondaire :
o L’empêcher d’être élu pour devenir primaire, lui permettant de rester toujours comme
un backup
o Empêcher les applications de lire à partir de lui, lui permettant ainsi de se consacrer
à certaines applications nécessitant un trafic séparé
o Exécuter des snapshots périodiques pour garder un historique
76
Stratégies de Réplication
MongoDB
• 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
• É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
o L’élection choisit le membre ayant la plus haute priorité comme
primaire
o Par défaut, tous les membres ont la même priorité (1)
o 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
77
Stratégies de Réplication
MongoDB
• Représente la garantie que MongoDB fournit en déclarant qu’une
opération d’écriture a été réalisée avec succès
• Si les insertions, modifications et suppressions ont un write concern
faible
§ Les opérations retournent rapidement
§ En cas d’échec, les données peuvent ne pas être persistées
• Si l’écriture a un write concern plus fort, les clients doivent attendre
après chaque opération d’écriture que MongoDB la confirme
• Depuis la version 2.6, le write concern peut être intégré avec
l’opération d’écriture
§ Au lieu d’être dans une commande séparée (getLastError)
78
Write Concern
MongoDB
• Unacknowledged
§ Similaire à « Errors Ignored »
§ MongoDB n’envoie pas d’acquittement après une opération d’écriture
§ Le driver tentera de gérer les erreurs réseau tant que possible, selon la
configuration du système
§ Avant, c’était le niveau par défaut
79
Write Concern : Niveaux (1/4)
MongoDB
• Acknowledged
§ Niveau par défaut
§ Mongod confirme la réception de l’opération d’écriture et applique les
changements à la vue in-memory des données
§ Permet aux clients de détecter les erreurs dues au réseau, aux clefs
dupliquées…
§ Elle ne confirme pas que les données
§ sont correctement écrites sur le disque !
80
Write Concern : Niveaux (2/4)
MongoDB
• Journaled
§ MongoDB valide les opérations d’écriture uniquement après avoir réalisé l’opération
d’écriture sur le Journal (Log permettant de sauvegarder les transactions et
évènements)
§ MongoDB peut ainsi récupérer les données à la suite d’un shutdown ou d’une panne
électrique
§ Le Journaling doit être activé pour utiliser cette option
§ Pour réduire la latence de ces opérations,
§ MongoDB augmente la fréquence des commit
§ La journalisation est requise uniquement pour la donnée
§ primaire (pas les répliques)
81
Write Concern : Niveaux (3/4)
MongoDB
• Replica Acknowledged
§ Garantit que l’opération d’écriture
s’est propagée à un nombre spécifié
de répliques
§ Exemple:
o La méthode retourne seulement si
l’écriture se propage à la donnée
primaire et au moins à une réplique
o sinon la méthode lance un timeout
au bout de 5s.
82
Write Concern : Niveaux (4/4)
MongoDB
• MongoDB permet aux clients de lire des documents insérés ou
modifiés avant qu’ils ne soient écrits sur le disque, indépendamment
du write concern défini ou de la configuration de journalisation
• Comme résultat, les applications peuvent observer deux classes de
comportement
§ Pour les systèmes avec des lecteurs et écrivains concurrents, MongoDB
autorise les résultats de lecture avant que l’opération d’écriture ne
retourne
§ Si Mongod termine avant que la journalisation ne soit faite, et même si une
opération d’écriture a retourné avec succès, le client peut avoir lu des
données qui n’existeront plus quand mongod redémarrera
83
Read Isolation
MongoDB
• Décrit comment les clients MongoDB routent les opérations de lecture vers
les répliques
• Par défaut, une application oriente ses opérations de lecture vers la donnée
primaire
§ Donne une garantie de fraicheur, car les opérations d’écriture par défaut
opèrent sur la donnée primaire
• Pour une application qui ne nécessite pas des données de toute fraîcheur, il
est possible d’améliorer la latence de lecture en distribuant certaines
opérations de lecture vers les répliques
84
Read Preference
• Sites (consultés en février 2014)
§ Planet Cassandra : www.planetcassandra.org
§ NOSQL : 5 minutes pour comprendre : http://blog.neoxia.com/nosql-5-minutes-pour-
comprendre/ NEOXIA
§ NOSQL Europe : Bases de données orientées colonnes et Cassandra
http://blog.xebia.fr/2010/05/04/nosql-europe-bases-de-donnees-orientees-colonnes-et-
cassandra/ XEBIA
§ Une base NOSQL, Cassandra : http://www-igm.univ-mlv.fr/~dr/XPOSE2010/Cassandra IGM
§ Why NOSQL – Part 1 – CAP Theorem : http://bigdatanerd.wordpress.com/2011/12/08/why-
nosql-part-1-cap-theorem/ DATANERD
§ DataStax Cassandra Tutorials : http://www.datastax.com/resources/tutorials/cassandra-
overview DataStax
§ Documentation officielle MongoDB : http://docs.mongodb.org/ MongoDB
• Présentations
§ Harri Kauhanen, « NOSQL Databases », Futurice, Septembre 2010
• Rapports
§ Mouna Laroussi, « Etude et mise en place de la technologie Big Data pour la
télécommunication », Projet de fin d’études, INSAT, 2013
• Livres Blancs
§ Top 5 Considerations when evaluating NOSQL Databases, MongoDB White Paper, Juin 2013
85
Sources

Contenu connexe

Tendances

Projet BI - 2 - Conception base de données
Projet BI - 2 - Conception base de donnéesProjet BI - 2 - Conception base de données
Projet BI - 2 - Conception base de données
Jean-Marc Dupont
 

Tendances (20)

Cours Big Data Chap1
Cours Big Data Chap1Cours Big Data Chap1
Cours Big Data Chap1
 
BigData_TP3 : Spark
BigData_TP3 : SparkBigData_TP3 : Spark
BigData_TP3 : Spark
 
Les BD NoSQL
Les BD NoSQLLes BD NoSQL
Les BD NoSQL
 
Cours Big Data Chap5
Cours Big Data Chap5Cours Big Data Chap5
Cours Big Data Chap5
 
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
 
Chp1 - Introduction à l'Informatique Décisionnelle
Chp1 - Introduction à l'Informatique DécisionnelleChp1 - Introduction à l'Informatique Décisionnelle
Chp1 - Introduction à l'Informatique Décisionnelle
 
Technologies pour le Big Data
Technologies pour le Big DataTechnologies pour le Big Data
Technologies pour le Big Data
 
Cours HBase et Base de Données Orientées Colonnes (HBase, Column Oriented Dat...
Cours HBase et Base de Données Orientées Colonnes (HBase, Column Oriented Dat...Cours HBase et Base de Données Orientées Colonnes (HBase, Column Oriented Dat...
Cours HBase et Base de Données Orientées Colonnes (HBase, Column Oriented Dat...
 
Chp2 - Les Entrepôts de Données
Chp2 - Les Entrepôts de DonnéesChp2 - Les Entrepôts de Données
Chp2 - Les Entrepôts de Données
 
DataWarehouse
DataWarehouseDataWarehouse
DataWarehouse
 
Big Data, Hadoop & Spark
Big Data, Hadoop & SparkBig Data, Hadoop & Spark
Big Data, Hadoop & Spark
 
BigData_TP2: Design Patterns dans Hadoop
BigData_TP2: Design Patterns dans HadoopBigData_TP2: Design Patterns dans Hadoop
BigData_TP2: Design Patterns dans Hadoop
 
Chapitre 2 hadoop
Chapitre 2 hadoopChapitre 2 hadoop
Chapitre 2 hadoop
 
Hadoop Hbase - Introduction
Hadoop Hbase - IntroductionHadoop Hbase - Introduction
Hadoop Hbase - Introduction
 
BigData_TP5 : Neo4J
BigData_TP5 : Neo4JBigData_TP5 : Neo4J
BigData_TP5 : Neo4J
 
Intégration des données avec Talend ETL
Intégration des données avec Talend ETLIntégration des données avec Talend ETL
Intégration des données avec Talend ETL
 
Installation hadoopv2.7.4-amal abid
Installation hadoopv2.7.4-amal abidInstallation hadoopv2.7.4-amal abid
Installation hadoopv2.7.4-amal abid
 
BigData_TP1: Initiation à Hadoop et Map-Reduce
BigData_TP1: Initiation à Hadoop et Map-ReduceBigData_TP1: Initiation à Hadoop et Map-Reduce
BigData_TP1: Initiation à Hadoop et Map-Reduce
 
Cours Big Data Chap4 - Spark
Cours Big Data Chap4 - SparkCours Big Data Chap4 - Spark
Cours Big Data Chap4 - Spark
 
Projet BI - 2 - Conception base de données
Projet BI - 2 - Conception base de donnéesProjet BI - 2 - Conception base de données
Projet BI - 2 - Conception base de données
 

En vedette

En vedette (20)

Thinking BIG
Thinking BIGThinking BIG
Thinking BIG
 
Business Intelligence
Business IntelligenceBusiness Intelligence
Business Intelligence
 
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
 
Testing Angular
Testing AngularTesting Angular
Testing Angular
 
Core JavaScript
Core JavaScriptCore JavaScript
Core JavaScript
 
Introduction au Web
Introduction au WebIntroduction au Web
Introduction au Web
 
Angular
AngularAngular
Angular
 
Client-side JavaScript
Client-side JavaScriptClient-side JavaScript
Client-side JavaScript
 
Javascript Design Patterns
Javascript Design PatternsJavascript Design Patterns
Javascript Design Patterns
 
Server-side JS with NodeJS
Server-side JS with NodeJSServer-side JS with NodeJS
Server-side JS with NodeJS
 
Mobile developement
Mobile developementMobile developement
Mobile developement
 
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
 
Big Data Analytics for connected home
Big Data Analytics for connected homeBig Data Analytics for connected home
Big Data Analytics for connected home
 
Bases de données NoSQL
Bases de données NoSQLBases de données NoSQL
Bases de données NoSQL
 
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
 
Une introduction à MapReduce
Une introduction à MapReduceUne introduction à MapReduce
Une introduction à MapReduce
 
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
 
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
 
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
 
Hadopp Vue d'ensemble
Hadopp Vue d'ensembleHadopp Vue d'ensemble
Hadopp Vue d'ensemble
 

Similaire à BigData_Chp4: NOSQL

Similaire à BigData_Chp4: NOSQL (20)

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
 
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
 
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
 
NoSQL panorama - Jean Seiler Softeam
NoSQL panorama - Jean Seiler SofteamNoSQL panorama - Jean Seiler Softeam
NoSQL panorama - Jean Seiler Softeam
 
Introduction nosql
Introduction nosqlIntroduction nosql
Introduction nosql
 
Discovery Session France: Atelier découverte de la Data Virtualization
Discovery Session France: Atelier découverte de la Data VirtualizationDiscovery Session France: Atelier découverte de la Data Virtualization
Discovery Session France: Atelier découverte de la Data Virtualization
 
Discovery Session France: Atelier découverte de la Data Virtualization
Discovery Session France: Atelier découverte de la Data VirtualizationDiscovery Session France: Atelier découverte de la Data Virtualization
Discovery Session France: Atelier découverte de la Data Virtualization
 
NoSQL MeetUp
NoSQL MeetUpNoSQL MeetUp
NoSQL MeetUp
 
Les Base de Données NOSQL
Les Base de Données NOSQLLes Base de Données NOSQL
Les Base de Données NOSQL
 
Base de données graphe, Noe4j concepts et mise en oeuvre
Base de données graphe, Noe4j concepts et mise en oeuvreBase de données graphe, Noe4j concepts et mise en oeuvre
Base de données graphe, Noe4j concepts et mise en oeuvre
 
No Sql - Olivier Mallassi - September 2010
No Sql - Olivier Mallassi - September 2010No Sql - Olivier Mallassi - September 2010
No Sql - Olivier Mallassi - September 2010
 
Relational databases & NoSQL databases
Relational databases & NoSQL databasesRelational databases & NoSQL databases
Relational databases & NoSQL databases
 
Valtech - NoSQL, solution alternative ou complémentaire aux bases de données ...
Valtech - NoSQL, solution alternative ou complémentaire aux bases de données ...Valtech - NoSQL, solution alternative ou complémentaire aux bases de données ...
Valtech - NoSQL, solution alternative ou complémentaire aux bases de données ...
 
MariaDB une base de donnees NewSQL
MariaDB une base de donnees NewSQLMariaDB une base de donnees NewSQL
MariaDB une base de donnees NewSQL
 
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
 
Base de données NoSQL
Base de données NoSQLBase de données NoSQL
Base de données NoSQL
 
Webinar Degetel DataStax
Webinar Degetel DataStaxWebinar Degetel DataStax
Webinar Degetel DataStax
 
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
 
Base de données graphe et Neo4j
Base de données graphe et Neo4jBase de données graphe et Neo4j
Base de données graphe et Neo4j
 
MySQL Innovation & Cloud Day - Document Store avec MySQL HeatWave Database Se...
MySQL Innovation & Cloud Day - Document Store avec MySQL HeatWave Database Se...MySQL Innovation & Cloud Day - Document Store avec MySQL HeatWave Database Se...
MySQL Innovation & Cloud Day - Document Store avec MySQL HeatWave Database Se...
 

Plus de Lilia Sfaxi

Plus de Lilia Sfaxi (20)

chp1-Intro à l'urbanisation des SI.pdf
chp1-Intro à l'urbanisation des SI.pdfchp1-Intro à l'urbanisation des SI.pdf
chp1-Intro à l'urbanisation des SI.pdf
 
Plan d'études_INSAT_2022_2023.pdf
Plan d'études_INSAT_2022_2023.pdfPlan d'études_INSAT_2022_2023.pdf
Plan d'études_INSAT_2022_2023.pdf
 
Lab3-DB_Neo4j
Lab3-DB_Neo4jLab3-DB_Neo4j
Lab3-DB_Neo4j
 
Lab2-DB-Mongodb
Lab2-DB-MongodbLab2-DB-Mongodb
Lab2-DB-Mongodb
 
Lab1-DB-Cassandra
Lab1-DB-CassandraLab1-DB-Cassandra
Lab1-DB-Cassandra
 
TP2-UML-Correction
TP2-UML-CorrectionTP2-UML-Correction
TP2-UML-Correction
 
TP1-UML-Correction
TP1-UML-CorrectionTP1-UML-Correction
TP1-UML-Correction
 
TP0-UML-Correction
TP0-UML-CorrectionTP0-UML-Correction
TP0-UML-Correction
 
TD4-UML
TD4-UMLTD4-UML
TD4-UML
 
TD4-UML-Correction
TD4-UML-CorrectionTD4-UML-Correction
TD4-UML-Correction
 
TD3-UML-Séquences
TD3-UML-SéquencesTD3-UML-Séquences
TD3-UML-Séquences
 
TD3-UML-Correction
TD3-UML-CorrectionTD3-UML-Correction
TD3-UML-Correction
 
TD2 - UML - Correction
TD2 - UML - CorrectionTD2 - UML - Correction
TD2 - UML - Correction
 
TD1 - UML - DCU
TD1 - UML - DCUTD1 - UML - DCU
TD1 - UML - DCU
 
TD1-UML-correction
TD1-UML-correctionTD1-UML-correction
TD1-UML-correction
 
Android - Tp1 - installation et démarrage
Android - Tp1 -   installation et démarrageAndroid - Tp1 -   installation et démarrage
Android - Tp1 - installation et démarrage
 
Android - Tp2 - Elements graphiques
Android - Tp2 - Elements graphiques Android - Tp2 - Elements graphiques
Android - Tp2 - Elements graphiques
 
Android - Tp3 - intents
Android - Tp3 -  intentsAndroid - Tp3 -  intents
Android - Tp3 - intents
 
Android - TPBonus - web services
Android - TPBonus - web servicesAndroid - TPBonus - web services
Android - TPBonus - web services
 
Android - Tp4 - graphiques avancés
Android - Tp4 - graphiques avancésAndroid - Tp4 - graphiques avancés
Android - Tp4 - graphiques avancés
 

BigData_Chp4: NOSQL

  • 1. Chp4 – Bases de Données NOSQL Types, Architectures et Exemples (Cassandra, MongoDB) Big Data GL4 (Option Management des Systèmes d'Information) - 2016 Dr. Lilia SFAXI www.liliasfaxi.wix.com/liliasfaxi Slide 1
  • 2. Bases de Données NOSQL • Bases de données NOSQL (Not Only SQL) : § Ce n’est pas (comme son nom le laisse supposer) No SQL (pas de SQL) § Privilégier donc NOSQL plutôt que NoSQL • Bases de données non-relationnelles et largement distribuées • Permet une analyse et une organisation rapides et ad-hoc des données de très grands volumes et de types de données disparates • Appelées également § Cloud Databases § Non-Relational Databases § Big Data Databases § … • Développées en réponse à l’augmentation exponentielle des données générées, enregistrées et analysées par les utilisateurs modernes et leurs applications 2 Définition
  • 3. Bases de Données NOSQL • Principaux atouts § Évolutivité § Disponibilité § Tolérance aux fautes • Caractéristiques § Modèle de données sans schéma § Architecture distribuée § Utilisation de langages et interfaces qui ne sont pas uniquement du SQL 3 Atouts
  • 4. Bases de Données NOSQL • De point de vue métier, utiliser un environnement BigData et NOSQL fournit un avantage compétitif certain • Importance des données : § « Si vos données ne croissent pas, alors votre entreprise ne le fait pas non plus » 4 NOSQL et Big Data
  • 5. Bases de Données NOSQL • Types des bases de données NOSQL § Clef/valeur § Orientées colonnes § Orientées documents § Orientées graphes • Propriétés des BDR § ACID : Atomicity, Consistency, Isolation and Durability § Utilisation de SQL 5 Types Id Nom Humeur Date_naissance Couleur 12 Stella Heureuse 2007-04-01 NULL 13 Wimma Faim NULL Noire 9 Ninja NULL NULL NULL
  • 6. Types de Bases de Données NOSQL • L’un des types les plus simples, sorte de Hashmap distribuée • Conçues pour sauvegarder les données sans définir de schéma • Toutes les données sont sous forme de clef/valeur § La valeur peut être une chaîne de caractères, un objet sérialisé, blob… § La donnée est opaque au système: il n’est pas possible d’y accéder sans passer par la clef • Absence de typage a un impact sur le requêtage: toute l’intelligence portée avant par les requêtes devra être portée par l’applicatif qui interroge la BD • Communications se résumant surtout aux opérations PUT, GET et DELETE • Objectif: fournir un accès rapide aux informations, conserver la session d’un site web… • Exemple : DynamoDB (Amazon), Azure Table Storage (ATS), Redis, BerkeleyDB, Voldemort (LinkedIn) 6 1. Clef/Valeur (Key/Value Store)
  • 7. Types de Bases de Données NOSQL 7 1. Clef/Valeur (Key/Value Store) Id Nom Humeur Date_naissance Couleur 12 Stella Heureuse 2007-04-01 NULL 13 Wimma Faim NULL Noire 9 Ninja NULL NULL NULL Chien_12 Nom_$#_Stella~~Humeur_$#_Heureuse ~~Date_naissance_$#_2007-04-01… Clef Valeur
  • 8. Types de Bases de Données NOSQL • Étendent le paradigme clef/valeur, avec des « documents » plus complexes à la place des données simples, et une clef unique pour chacun d’eux • Documents de type JSON ou XML • Chaque document est un objet, contient un ou plusieurs champs, et chaque champs contient une valeur typée (string, date, binary ou array) • Permettent de stocker, extraire et gérer les informations orientées documents (données semi-structurées) • Avantage : pouvoir récupérer, via une seule clef, un ensemble d’informations structurées de manière hiérarchique § Dans les bases relationnelles, cela impliquerait plusieurs jointures • Exemples : Mongo DB (SourceForge), Couch DB (Apache), RavenDB (destiné aux plateformes .Net/Windows, interrogation via LINQ) 8 2. Orientée Documents (Document Database)
  • 9. Types de Bases de Données NOSQL 9 2. Orientée Documents (Document Database) Id Nom Humeur Date_naissance Couleur 12 Stella Heureuse 2007-04-01 NULL 13 Wimma Faim NULL Noire 9 Ninja NULL NULL NULL Chien_12 { type : « Chien », nom : « Stella », humeur : « Heureuse», date_naissance: 2007-04-01 } Clef Document (V1) { type : « Chien », nom : « Stella », humeur : « Heureuse», date_naissance: 2007-04-01 aboiement : [ { texte : « j’ai mangé de la pâtée» commentaires : [ { id_chien : « chien_4 », texte : « on s’en fout!» } ] } ] } Document (V2)
  • 10. Types de Bases de Données NOSQL • Évolution de la BD clef/valeur • Ressemble aux SGBDR, mais avec un nombre de colonnes dynamique, différent d’un enregistrement à un autre (pas de colonnes portant les valeurs NULL) • Offrent de très hautes performances et une architecture hautement évolutive • Exemples: Hbase (Hadoop), Cassandra (Facebook, Twitter), BigTable (Google) 10 3. Orientées Colonnes (Column Store) A B C D E 1 Foo Bar Hello 2 Tom 3 Java Scala Cobol 1 2 3 A Foo B Bar C Hello B Tom C Java D Scala E Cobol
  • 11. Types de Bases de Données NOSQL 11 3. Orientées Colonnes (Column Store) Id Nom Humeur Date_naissance Couleur 12 Stella Heureuse 2007-04-01 NULL 13 Wimma Faim NULL Noire 9 Ninja NULL NULL NULL Chien_12 Clef Chien Date_naissance 15 Chien Humeur 11 Chien Humeur 45 Chien Nom 25 Chien Couleur 34 Colonnes Aboiement Text 11 2007-04-01 En Colère Heureuse Stella Noire J’ai mangé de la pâtée Famille Titre Temps Valeur Requête: clef/famille:titre[/time] Exp: "chien_12"/"Chien":"Nom" è Stella
  • 12. Types de Bases de Données NOSQL 12 3. Orientées Colonnes (Column Store) Exemple Cassandra : Colonne / Super Colonne / Famille de Colonnes
  • 13. Types de Bases de Données NOSQL • Basées sur les théories des graphes • S’appuie sur les notions de nœuds, de relations et des propriétés qui leur sont rattachées • Conçues pour les données dont les relations sont représentées comme graphes, et ayant des éléments interconnectés, avec un nombre indéterminé de relations entre elles • Adapté aux traitements des données des réseaux sociaux • Exemples : Neo4J et InfiniteGraph, OrientDB 13 4. Orienté Graphes (Graph Database)
  • 14. Types de Bases de Données NOSQL 14 4. Orienté Graphes (Graph Database) Id Nom Humeur Date_naissance Couleur 12 Stella Heureuse 2007-04-01 NULL 13 Wimma Faim NULL Noire 9 Ninja NULL NULL NULL Chien_12 Chien Stella Heureuse 2007-04-01 Aboiement_5 9 Commentaire_ 83 Chien_4 « On s’en fout! » « J’ai mangé de la pâtée! » type nom humeur date_naissance aboiements Commentaire_à texte commente texte
  • 15. Types de Bases de Données NOSQL Modèle Performance Évolutivité Flexibilité Complexité Fonctionnalités Clef/Valeur Variable Orienté Colonnes Minimale Orienté Document Variable Orienté Graphes Théorie des Graphes 15 Comparaison
  • 16. NOSQL VS. BDR Chp4 – Bases de Données NOSQL 16
  • 17. NOSQL et BDR • Choix de NOSQL en opposition aux bases de données relationnelles conduits par les contraintes du marché et les besoins techniques • BigData § Adaptation des BD NOSQL au BigData o Vitesse (Velocity) : beaucoup de données qui arrivent rapidement, à partir de plusieurs sources o Variété (Variety) : données structurées, semi-structurées ou non-structurées o Volume (Volume) : données très nombreuses (To et Po) o Complexité (Complexity) : données stockées et gérées à plusieurs endroits et data centers. • Disponibilité continue des données § Le manque de disponibilité peut être fatal pour une entreprise § BD NOSQL utilisent une architecture hautement distribuée : pas de SPOF § Redondance des données et traitements : tolérance aux fautes § D’où : disponibilité continue à travers les data centers, et le cloud § Toute mise à jour ou modification est faite sans déconnecter la base 17 Comparaison (1/3)
  • 18. NOSQL et BDR • Indépendance de l’emplacement § Possibilité de consulter et modifier une BD sans savoir où est-ce que ces opérations ont réellement lieu § Toute fonctionnalité d’écriture propagée à partir d’un emplacement, pour être disponible aux utilisateurs à partir d’autres sites § Difficile à appliquer aux BDR, surtout pour l’écriture • Modèles de données flexibles § Une des raisons majeures § Dans le modèle relationnel, les relations entre les tables sont prédéfinies, fixes et organisées dans un schéma strict et uniforme o Problèmes d’évolutivité et de performance en gérant de grands volumes de données § Les BD NOSQL peuvent accepter tout type de données (structurées, semi- structurées ou non-structurées) plus facilement § Dans les BDR, les performances posent problème, surtout quand des lignes « larges » sont utilisées et les actions de modification sont nombreuses 18 Comparaison (1/3)
  • 19. NOSQL et BDR • Business Intelligence et Analyse § Capacité des bases NOSQL à exploiter les données collectées pour dériver des idées § Extraction d’informations décisionnelles à partir d’un grand volume de données, difficile à obtenir avec des bases relationnelles § Bases NoSQL permettent le stockage et la gestion des données des applications métier, et fournissent une possibilité de comprendre les données complexes, et de prendre des décisions • Capacités transactionnelles modernes § Nouvelles définition du principe de transaction § Utilisation des propriétés BASE au lieu des propriétés ACID 19 Comparaison (3/3)
  • 20. NOSQL et BDR • Propriétés ACID : Atomicité, Consistance, Isolation et Durabilité § Propriétés des transactions des BDR § Atomicité : Soit toutes les instructions sont exécutées, soit aucune § Consistance : toute transaction amène la BD d’un état valide à un autre è renforcée par les contraintes d’intégrité et les clefs étrangères § Isolation : Même si plusieurs transactions peuvent être exécutées par un ou plusieurs utilisateurs simultanément, une transaction ne devrait pas voir les effets des autres transactions concurrentes § Durabilité : Une fois la transaction enregistrée dans la base (commit), ces changements sont persistants. • Toutes les BDR supportent les transactions ACID • Mais : § Données de plus en plus volumineuses + Besoin de systèmes évolutifs § Besoin de BD distribuées sur le réseau, pour une évolutivité horizontale 20 Propriétés ACID
  • 21. NOSQL et BDR • Destiné à évaluer les systèmes de stockage distribués • Théorème CAP : « Il est impossible de satisfaire les trois propriétés CAP en même temps » • Propriétés CAP : Consistency, Availability, Partition tolerance § Consistance: Si j’écris une donnée dans un nœud et que je la lis à partir d’un autre nœud dans un système distribué, je retrouve ce que j’ai écris sur le premier. § Haute disponibilité : à tout moment, pour chaque requête, la réponse est garantie. Même en cas de panne, les données restent accessibles § Tolérance au partitionnement : les données peuvent être partitionnées sur différents supports sans souci de localisation. Les activités continuent sans interruption lors de la modification du système (en cas d’ajout ou suppression de nœuds) et en cas de chute du réseau 21 Théorème CAP
  • 22. NOSQL et BDR • Pourquoi est-il impossible de satisfaire les 3 propriétés CAP en même temps? • Soit un système distribué. On est entrain de modifier une donnée sur le nœud N1 et d’essayer de la lire à partir du nœud N2 § N2 peut retourner la dernière bonne valeur dont il dispose, ce qui viole la Consistance § N2 attend que la nouvelle valeur lui parvienne. Comme c’est un système distribué, les chances d’un échec de transmission sont assez importantes, ce qui provoquera une attente infinie de N2. D’où une violation de la Disponibilité § Si on veut satisfaire à la fois la consistance et la disponibilité, le système de stockage ne doit pas être partitionné. D’où violation de la Tolérance au partitionnement. • Pour les BD NOSQL, il n’y a plus de jointures § è La propriété de consistance n’est plus assurée de la même manière • Consistance dans NOSQL: consistance immédiate et éventuelle des données à travers les nœuds de la base distribuée 22 Théorème CAP
  • 23. NOSQL et BDR • BASE : Basically Available, Soft-state, Eventual consistency • Basically Available § Le système garantit la disponibilité, comme définie dans le théorème CAP • Soft-State § L’état du système peut changer dans le temps, même sans nouvelles entrées, et ce à cause du principe de consistance éventuelle • Eventual Consistency § Les modification arriveront éventuellement à tous les serveurs, si on leur donne suffisamment de temps • BASE est plus flexible que ACID, accepte certaines erreurs, dont l’occurrence est assez rare 23 Propriétés BASE
  • 24. NOSQL et BDR 24 Récapitulatif BRD NOSQL Consistance forte vs Consistance éventuelle Grande quantité de données vs Enormequantité de données Évolutivité possible vs Evolutivité facile SQL vs Map-Reduce Bonne disponibilité vs Trèshaute disponibilité
  • 25. NOSQL et BDR • Bases de données NOSQL § Performances sur de gros volumes de données § Performances sur des données non structurées § Evolutivité très importante, même pour de faibles volumes • Cependant: § Technologie assez jeune è Manque d’outils la supportant § Encore en évolution, pas de standards § Pas de langage de requêtage commun comme SQL, mais divers: o Requêtes spécifiques au langage (Java, Python…) o Requêtes spéciale pour la base (Cassandra Query Language) o API basée sur Map Reduce, ou sur graphes d’objets § On doit faire plus de travail au niveau du code, ce qui peut influer sur la performance 25 Synthèse
  • 26. NOSQL et BDR • Si l’évolutivité est une préoccupation § Mais attention, ce n’est pas toujours un MUST : Flickr et Wikipedia utilisent des RDBMS • Si l’absence de schéma est une préoccupation • Si être IN et FASHION est une préoccupation § Pour un nombre important de personnes, l’utilisation d’un nouveau paradigme ou technologie est un MUST! 26 Quand utiliser NOSQL?
  • 27. CASSANDRA Chp4 – Bases de Données NOSQL 27
  • 28. Cassandra • Base de données : § Distribuée § À haute performance § Extrêmement évolutive § Tolérante aux fautes (pas de SPOF) § Non-relationnelle • Peut être utilisée à la fois comme : § Base de données temps réel § Base de données pour une lecture intensive pour les systèmes décisionnels • À la base, c’est une combinaison de BigTable de Google et DynamoDB de Amazon, incubée dans Facebook, et hébergée comme solution open source dans Apache. 28 Présentation
  • 29. Cassandra • Système distribué, P2P • Composés de plusieurs nœuds identiques § Pas de notion de NameNode ou nœud maître… • Les données sont partitionnées par défaut à travers les différents nœuds du cluster • Les données sont répliquées pour assurer une tolérance aux fautes maximale § L’utilisateur contrôle le nombre de répliques qu’il désire avoir pour ses données • Lecture et écriture à partir de n’importe quel nœud, indépendamment de l’emplacement des données • Utilisation du protocole Gossip pour la communication entre les différents nœuds du cluster § Échange de données entre les nœuds chaque seconde 29 Architecture (1/2)
  • 30. Cassandra • Structure orientée colonnes, à l’image de BigTable • Vocabulaire: § Keyspace (équivalent de database) § Column Family (équivalent de table) o Dans la nouvelle version du langage CQL, appelée Table o Schéma plus flexible et dynamique qu’une table § Colonne (équivalent à enregistrement) o Indexée par une clef o D’autres champs peuvent être également indexés, mais à la demande 30 Architecture (2/2) Keyspace: Portfolio Column Family : Client ID Nom Adresse Tel
  • 31. Cassandra • Partitionnement facile des données à travers les différents nœuds participants du cluster • Chaque nœud est responsable d’une partie de la base de données • Les données sont insérées par l’utilisateur dans une famille de colonnes • Elles sont ensuite placées sur un nœud, selon sa clef de colonne 31 Partitionnement (1/2) Keyspace : Portfolio Column Family : Client ID Nom Adresse Tel 1 2 34 5 Donnée
  • 32. Cassandra • Stratégies de partitionnement § Partitionnement aléatoire o Par défaut, recommandé o Données partitionnée le plus équitablement possible à travers les différents nœuds o Utilisation de MD5 (ou Murmur3) pour le hachage de chaque clef de famille de colonnes § Partitionnement ordonné o Sauvegarde les clefs de familles de colonnes par ordre à travers les nœuds d’un cluster o Peut provoquer des problèmes, surtout pour la répartition des charges (des nœuds avec des données plus volumineuses que d’autres) • Stratégie spécifiée dans un fichier de configuration cassandra.yaml • Si la stratégie d’une base est modifiée, il faut recharger toutes les données 32 Partitionnement (2/2) Keyspace : Portfolio Column Family : Client ID Nom Adresse Tel 1 2 34 5 Donnée
  • 33. Cassandra • Pour assurer la tolérance aux fautes et pas de SPOF, il est possible de créer une ou plusieurs copie(s) de chaque colonne à travers les nœuds participants • L’utilisateur spécifie le facteur de réplication désiré à la création du keyspace • Les données sont insérées par l’utilisateur dans une famille de colonnes • La colonne est répliquée dans les nœuds du cluster selon le facteur de réplication 33 Réplication (1/3) Facteur de réplication = 2 Keyspace : Portfolio Column Family : Client ID Nom Adresse Tel 1 2 34 5 Donnée Copie de la Donnée
  • 34. Cassandra • Stratégies de réplication § Stratégie Simple : o La colonne originelle est placée sur un nœud déterminé par le partitionneur o La réplique est placée sur le nœud suivant de l’anneau (clockwise) o Pas de considération pour l’emplacement dans un data-center ou dans une baie (approprié pour les déploiement sur un seul datacenter) § Stratégie par topologie du réseau o Plus sophistiquée o Plus de contrôle sur l’emplacement des répliques de colonnes o Parcourt le cluster (clockwise) à la recherche d’un nœud dans une baie différente. Si introuvable, stocker la colonne dans un nœud de la même baie o Un groupe de réplication est spécifié, pour distinguer entre plusieurs datacenters 34 Réplication (2/3) 1 2 34 5 Donnée Copie de la Donnée 1 2 34 5 1 2 34 5 Donnée Copie de la Donnée Copie de la Donnée Baie1 Baie2
  • 35. Cassandra • Mécanisme de réplication § Utilisation de SNITCH: o Définition de la manière dont les nœuds sont groupés dans un réseau o Répartition des nœuds entre baies et datacenters § Plusieurs types de SNITCH o Simple SNITCH : utilise la stratégie simple o Rack-Inferring SNITCH : détermine la topologie du réseau en analysant les adresses IP: 1. Second octet de l’adresse IP: Data Center 2. Troisième octet de l’adresse IP: Baie o Property File SNITCH : se base sur une description de l’utilisateur pour déterminer l’emplacement des nœuds (cassandra-topology.properties) o EC2 SNITCH : pour déploiement dans Amazon EC2. Utilise l’API AWS pour déterminer la topologie § Défini dans le fichier de configuration cassandra.yaml 35 Réplication (3/3)
  • 36. Cassandra • Architecture Read and Write Anywhere • L’utilisateur peut se connecter à n’importe quel nœud, dans n’importe quel datacenter, et lire/écrire les données qu’il veut • Les données sont automatiquement partitionnées et répliquées à travers le cluster 36 Consistance
  • 37. Cassandra • Écriture : § 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 o Soit toutes les colonnes sont modifiées, soit aucune ne l’est • Cassandra est la base de données NOSQL la plus rapide en écriture 37 Consistance
  • 38. Cassandra • Consistance : à quel point est-ce qu’une donnée est à jour et synchronisée sur toutes ses répliques. • Extension du concept de consistance éventuelle à une consistance ajustable • Choix possible entre une consistance forte ou éventuelle selon les besoins • Ce choix est fait par opération, ce n’est pas une stratégie globale pour la base de données (ex, pour changer la stratégie de lecture en quorum) § SELECT * FROM users USING CONSISTENCY QUORUM WHERE state=‘TX’; • Consistance gérée à travers plusieurs data centers. 38 Consistance
  • 39. Cassandra • Niveau de consistance : combien de répliques doivent être écrites avec succès avant de retourner un acquittement au client § Any : une écriture doit réussir sur n’importe quel nœud, au moins un. o Offre la plus haute disponibilité, mais la plus basse consistance § One (défaut dans CQL) : une écriture doit réussir sur le commit log et la memtable d’au moins une réplique § Quorum : une écriture doit réussir sur un certain pourcentage de répliques (pourcentage = (facteur de réplication/2)+1) o Meilleure alternative en terme de consistance et de disponibilité § Local-Quorum : une écriture doit réussir sur un certain pourcentage de nœuds répliques sur le même datacenter que le nœud coordinateur § Each-Quorum : une écriture doit réussir sur un certain pourcentage de nœuds répliques sur tous les datacenters. § All : une écriture doit réussir sur tous les nœuds répliques d’une colonne o Offre la plus haute consistance, mais la plus basse disponibilité 39 Stratégies d’Écriture
  • 40. Cassandra § Cassandra utilise les Hinted Handoffs § Elle tente de modifier une colonne sur toutes les répliques § 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épliques en panne une fois disponibles § 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. 40 Stratégies d’Écriture
  • 41. Cassandra • Niveau de consistance : combien de répliques doivent répondre avant de retourner le résultat à l’application cliente • 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) § One (défaut dans CQL) : obtention d’une réponse à partir de la réplique la plus proche selon le SNITCH o Offre la plus faible consistance, mais la plus haute disponibilité § Quorum : obtention du résultat le plus récent à partir d’un certain pourcentage de nœuds répliques (pourcentage = (facteur de réplication/2)+1) o Meilleure alternative en terme de consistance et de disponibilité § Local-Quorum : obtention du résultat le plus récent à partir d’un certain pourcentage de nœuds répliques sur le même datacenter que le nœud coordinateur o Évite la latence due à la communication inter-datacenters § Each-Quorum : : obtention du résultat le plus récent à partir d’un certain pourcentage de nœuds répliques sur tous les datacenters. § All : obtention du résultat le plus récent à partir de tous les nœuds répliques o Offre la plus haute consistance, mais la plus basse disponibilité 41 Stratégies de Lecture
  • 42. Cassandra • Read Repair § Cassandra assure que les données fréquemment lues soient consistantes § À la lecture d’une donnée, le nœud coordinateur compare toutes ses répliques en arrière plan. § Si ces données ne sont pas consistantes, 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. 42 Stratégies de Lecture 1 2 34 5 Réplique1 Réplique2 Réplique3
  • 43. Cassandra • Deux interfaces pour gérer les objets/données § Cassandra CLI (Command Line Interface) § CQL (Cassandra Query Language) • CLI § Interface originelle conçue pour créer des objets, entrées et manipuler les données • CQL § Utilisée pour créer/manipuler des données en utilisant un langage proche de SQL 43 Gestion des Données et Objets
  • 44. Cassandra • CQL § Objets tels que les keyspaces, familles de colonnes et index sont créés, modifiés et supprimés avec les requêtes usuelles: CREATE, ALTER et DROP § Données insérées, modifiées et supprimées avec INSERT, UPDATE et DELETE § Données lues avec SELECT § Mais o Ne supporte pas des opérations telles que GROUP BY, ORDER BY (sauf pour les clefs composées, et ordonnées seulement selon la deuxième clef primaire)… § Utiliser la clause USING CONSISTENCY pour déterminer le type de consistance forte pour chaque opération de lecture et l’écriture (Any, One, Quorum…) 44 Gestion des Données et Objets
  • 45. Cassandra • Grande Scalabilité (Gigaoctet/Petaoctet) è Appropriée aux Big Data § Gain de performances linéaire grâce à l’ajout des nœuds • Pas de SPOF (Single Point of Failure) • Réplication et distribution des données facile à travers les data- centers • Pas besoin de couche de cache séparée § Utilisation des mémoires vives de l’ensemble des nœuds • Consistance des données ajustable § Possibilité de choisir pour chaque opération si une donnée est fortement consistante (tous les nœuds sont similaires à tout moment) ou éventuellement consistante • Schéma de données flexible 45 Récapitulatif (1/2)
  • 46. Cassandra • Compression des données § Utilisation de l’algorithme de compression Snappy de Google § Compression des données pour chaque famille de colonnes § Pas de pénalité pour la performance, et même une amélioration notable, grâce à la diminution du nombre de I/O physique • Langage CQL très proche de SQL • Support des langages et plateformes clef • Pas besoin de matériel ou de logiciel particulier 46 Récapitulatif (2/2)
  • 47. MONGODB Chp4 – Bases de Données NOSQL 47
  • 48. MongoDB • MongoDB (de Humongous, qui veut dire énorme) • SGBD NOSQL orienté documents, à schéma flexible et distribuable • Écrit en C++ • Distribué sous licence AGPL • Développé en 2007 par la firme MongoDB 48 Introduction
  • 49. MongoDB • Données représentées dans un schéma flexible • Données stockées sous forme de documents (paires clef/valeur) JSON- like • La structure du document n’est pas fixée à sa création § Mais en général, les documents d’une même collection ont une structure similaire (homogénéité) • Les documents sont organisés sous forme de collections § Groupe de documents reliés par des indexes en commun 49 Structure de Données
  • 50. MongoDB 50 Terminologie Terminologie SQL Terminologie MongoDB Base de données Base de données Table Collection Ligne Document Colonne Champ Index Index Jointure Imbrication ou Référence Clef Primaire (peutêtre multiple) Clef Primaire (une seule, etreprésentée par le champ_id)
  • 51. MongoDB • Structure de données JSON-like, composée de paires clef/valeur • Stocké sur le disque sous forme de document BSON § Documents BSON (Binary JSON) : représentation binaire sérialisées d’une document JSON § 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 51 Document
  • 52. MongoDB • Le champ _id § Seul champ obligatoire, utilisé comme clef primaire dans une collection § Peut être de tout type autre que Tableau • Les champs indexés ont une taille limite (1Mo) • Les noms des champs ne peuvent pas commencer par un $, contenir le caractère « . » ou le caractère « null » 52 Document
  • 53. MongoDB • Limites § Taille max d’un document : 16Mo o Utilisation de l’API GridFS pour stocker des documents plus larges que la taille autorisée o GridFS permet de diviser les documents en chunks de même taille, et les stocke sous forme de documents séparés § MongoDB préserve l’ordre des champs du document, comme défini à leur création, sauf: o Que le champs _id doit toujours figurer en premier o 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 § Champs _id o Création d’un index unique à la création d’une collection o Utilisation conseillée d’un ObjectId: objets petits (12o), uniques et rapides à générer 53 Document
  • 54. MongoDB • Deux manières des relations entre les données: Références et Données Imbriquées • Références § Inclusion de liens ou références d’un document à un autre § C’est à l’application de résoudre ces références pour accéder aux données associées § On dit qu’on utilise des Modèles de Données Normalisés 54 Structure de Documents
  • 55. MongoDB • Données Imbriquées (Embedded Data) § Sauvegarde des données associées dans la même structure de documents § Il est possible d’inclure des documents dans un champ ou un tableau § Permet aux applications d’extraire et manipuler plusieurs niveaux de hiérarchie en une seule instruction § Ce sont les Modèles de Données Dénormalisés 55 Structure de Documents
  • 56. MongoDB • Comment choisir entre Références et Données Imbriquées? • On choisit les références quand: § L’imbrication va produire des données dupliquées sans grands avantages en terme de performance de lecture § On veut représenter des relations many-to-many complexes § On veut modéliser de larges ensembles de données hiérarchiques • On choisit les données imbriquées quand: § On a des relations contains entre les éléments (modèles one-to-one) o 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) o Exemple : personne et plusieurs emails 56 Structure de Documents
  • 57. MongoDB • Lecture § Cible une unique collection spécifique de documents § Cible un critère ou des conditions spécifiques, pour identifier le document à retourner § Peut inclure une projection sur les champs du document à retourner § Peut définir des Modificateurs pour imposer des limites, un ordre, un filtre… 57 Opération de Lecture
  • 58. MongoDB • MongoDB fournit une méthode db.collection.find() pour l’extraction de données § Accepte les critères de la requête, ainsi que les projections § Retourne un curseur vers les documents correspondants • Fournit également une méthode db.collection.findOne() retournant un seul document 58 Opération de Lecture Équivalent SQL
  • 59. MongoDB • Projections § Deuxième argument de la méthode find() § Peuvent spécifier la liste des champs à afficher ou à exclure § Mis à part pour exclure le champ _id (qui est affiché par défaut), il est interdit de mixer les projections inclusives et exclusives 59 Opération de Lecture
  • 60. MongoDB • Modification § Création, mise à jour ou suppression de données § Ces opérations modifient les données d’une seule collection § Définition de critères pour sélectionner les documents à modifier ou supprimer 60 Opération d’Ecriture
  • 61. MongoDB • Insertion de document § Si vous ajoutez un document sans champ _id, le système l’ajoute lui-même en générant un champ de type ObjectId 61 Opération d’Ecriture
  • 62. MongoDB • Mise à jour de documents § Méthode update peut accepter des critères de sélection des documents à modifier, et des options qui affectent son comportement. § Une opération update modifie un seul document par défaut (plusieurs docs si multi:true) § Existence de l’option upsert: si true, et que le document à modifier n’existe pas dans la collection, il est automatiquement inséré 62 Opération d’Ecriture
  • 63. MongoDB • Suppression de documents § La méthode remove supprime des documents d’une collection § Accepte des critères de sélection des documents à supprimer § Supprime par défaut tous les documents correspondant aux critères de sélection (sauf indication du contraire dans un flag approprié) 63 Opération d’Ecriture
  • 64. MongoDB • Les opérations d’écriture sont atomiques au niveau d’un document § Aucune opération d’écriture ne peut affecter atomiquement plus qu’un seul document ou collection § L’utilisation des données imbriquées facilite l’écriture § La normalisation des données (référence vers données dans d’autres collections) implique plusieurs opérations d’écriture qui ne sont pas atomiques. • Certaines modifications (un push dans des tableaux, ou bien un ajout d’un champ) augmentent la taille des documents § Pour le moteur de stockage MMAPv1, si la taille d’un document dépasse la taille autorisée pour ce document, MongoDB le réalloue sur le disque § Si votre application nécessite plusieurs modifications qui augmentent la taille des documents, considérer plutôt l’utilisation des références 64 Opération d’Ecriture
  • 65. MongoDB • MongoDB utilise la notion de Sharding (ou horizontal scaling ou scale out) pour stocker ses données dans le cluster § Division des données et leur distribution entre plusieurs serveurs ou shards § Chaque shard est une base indépendante, et mis ensemble, forment une seule base de données logique • Réduction du nombre d’opérations que chaque machine gère § Chaque machine gère les données qui y sont stockées • Réduction de la quantité de données que le serveur a besoin de stocker § Plus le cluster grandit, moins un serveur contient de données 65 Architecture: Sharding
  • 66. MongoDB • Shards § Stockent les données § Les données sont distribuées et répliquées sur les shards • 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 • 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 66 Architecture: Sharding
  • 67. MongoDB • Partitionnement des données au niveau des collections, via la shard key § Champ simple ou composé indexé qui existe dans chaque document de la collection • MongoDB divise les valeurs de la clef en morceaux (chunks) et les distribuent de manière équitable entre les shards • La répartition des clefs suit l’une de ces deux méthodes de partitionnement: § Basée sur le rang § Basée sur le Hash § Basée sur les tags 67 Partitionnement des Données
  • 68. MongoDB • Paritionnement basé sur le rang § Définition d’intervalles qui ne se chevauchent pas, dans lesquelles les valeurs de la shard key peuvent se trouver § Permet aux documents avec des clefs proches de se trouver dans le même shard § Plus facile de retrouver le shard pour une donnée § Risque de distribution non équitable des données (par exemple si la clef 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é) 68 Partitionnement des Données
  • 69. MongoDB • Paritionnement basé sur le hash § Calcul de la valeur du hash d’un champ, puis utilise ces hash pour créer des parittions § Deux documents ayant des clefs proches ont peu de chance de se trouver dans le même shard § Distribution aléatoire d’une collection dans le cluster, d’où une distribution plus équitable § Moins efficace, car le temps de recherche de la donnée est plus grand § 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 69 Partitionnement des Données
  • 70. MongoDB • Paritionnement basé sur les tags § Les administrateurs peuvent définir des tags, qu’ils associent à des intervalles de clef § Ils associent ces tags aux différents shards en essayant de respecter la distribution équitable des données § Un balancer migre les données taggées vers les shards adéquats § Le meilleur moyen pour assurer une bonne répartition des données 70 Partitionnement des Données
  • 71. MongoDB • L’ajout de nouvelles données ou nouveaux serveurs peut rendre la distribution des données déséquilibrée • 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 divisie 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 71 Maintien d’une Distribution Équitable
  • 72. MongoDB • 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 o Le shard destination reçoit tous les documents du chunk à migrer o Le shard destination applique tous les changements faits aux données durant le processus de migration o Finalement, les métadonnées concernant l’emplacement du chunk sur le config server sont modifiées 72 Maintien d’une Distribution Équitable
  • 73. MongoDB • 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é • 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 73 Ajout ou Suppression de Shards
  • 74. MongoDB • Définition d’un Replicat Set: groupe de processus mongod qui fournit la redondance et la haute disponibilité • Types de membres dans un replicat set: § Primaire: Reçoit toutes les opérations d’écriture § Secondaire: réplication des opération 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 74 Stratégies de Réplication
  • 75. MongoDB • Primaire § Seul membre qui reçoit les opérations d’écriture § MongoDB applique les opérations d’écriture sur le primaire, puis les enregistre dans son log (oplog) § Les membres secondaires dupliquent ce log et appliquent les opérations sur leurs données § Tous les membres d’un replicat set peuvent accepter une opération de lecture o Par défaut, une application dirige ces opérations vers le primaire § Un replicat set a au plus un primaire § Si le primaire tombe en panne, une élection a lieu pour en choisir un autre 75 Stratégies de Réplication
  • 76. MongoDB • Secondaires § Maintiennent une copie des données du primaire § 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 § Un replicat set peut avoir un ou plusieurs secondaires § Même si les clients ne peuvent pas écrire des données sur les secondaires, ils peuvent en lire § Un secondaire peut devenir un primaire, suite à une élection § Il est possible de configurer un secondaire : o L’empêcher d’être élu pour devenir primaire, lui permettant de rester toujours comme un backup o Empêcher les applications de lire à partir de lui, lui permettant ainsi de se consacrer à certaines applications nécessitant un trafic séparé o Exécuter des snapshots périodiques pour garder un historique 76 Stratégies de Réplication
  • 77. MongoDB • 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 • É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 o L’élection choisit le membre ayant la plus haute priorité comme primaire o Par défaut, tous les membres ont la même priorité (1) o 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 77 Stratégies de Réplication
  • 78. MongoDB • Représente la garantie que MongoDB fournit en déclarant qu’une opération d’écriture a été réalisée avec succès • Si les insertions, modifications et suppressions ont un write concern faible § Les opérations retournent rapidement § En cas d’échec, les données peuvent ne pas être persistées • Si l’écriture a un write concern plus fort, les clients doivent attendre après chaque opération d’écriture que MongoDB la confirme • Depuis la version 2.6, le write concern peut être intégré avec l’opération d’écriture § Au lieu d’être dans une commande séparée (getLastError) 78 Write Concern
  • 79. MongoDB • Unacknowledged § Similaire à « Errors Ignored » § MongoDB n’envoie pas d’acquittement après une opération d’écriture § Le driver tentera de gérer les erreurs réseau tant que possible, selon la configuration du système § Avant, c’était le niveau par défaut 79 Write Concern : Niveaux (1/4)
  • 80. MongoDB • Acknowledged § Niveau par défaut § Mongod confirme la réception de l’opération d’écriture et applique les changements à la vue in-memory des données § Permet aux clients de détecter les erreurs dues au réseau, aux clefs dupliquées… § Elle ne confirme pas que les données § sont correctement écrites sur le disque ! 80 Write Concern : Niveaux (2/4)
  • 81. MongoDB • Journaled § MongoDB valide les opérations d’écriture uniquement après avoir réalisé l’opération d’écriture sur le Journal (Log permettant de sauvegarder les transactions et évènements) § MongoDB peut ainsi récupérer les données à la suite d’un shutdown ou d’une panne électrique § Le Journaling doit être activé pour utiliser cette option § Pour réduire la latence de ces opérations, § MongoDB augmente la fréquence des commit § La journalisation est requise uniquement pour la donnée § primaire (pas les répliques) 81 Write Concern : Niveaux (3/4)
  • 82. MongoDB • Replica Acknowledged § Garantit que l’opération d’écriture s’est propagée à un nombre spécifié de répliques § Exemple: o La méthode retourne seulement si l’écriture se propage à la donnée primaire et au moins à une réplique o sinon la méthode lance un timeout au bout de 5s. 82 Write Concern : Niveaux (4/4)
  • 83. MongoDB • MongoDB permet aux clients de lire des documents insérés ou modifiés avant qu’ils ne soient écrits sur le disque, indépendamment du write concern défini ou de la configuration de journalisation • Comme résultat, les applications peuvent observer deux classes de comportement § Pour les systèmes avec des lecteurs et écrivains concurrents, MongoDB autorise les résultats de lecture avant que l’opération d’écriture ne retourne § Si Mongod termine avant que la journalisation ne soit faite, et même si une opération d’écriture a retourné avec succès, le client peut avoir lu des données qui n’existeront plus quand mongod redémarrera 83 Read Isolation
  • 84. MongoDB • Décrit comment les clients MongoDB routent les opérations de lecture vers les répliques • Par défaut, une application oriente ses opérations de lecture vers la donnée primaire § Donne une garantie de fraicheur, car les opérations d’écriture par défaut opèrent sur la donnée primaire • Pour une application qui ne nécessite pas des données de toute fraîcheur, il est possible d’améliorer la latence de lecture en distribuant certaines opérations de lecture vers les répliques 84 Read Preference
  • 85. • Sites (consultés en février 2014) § Planet Cassandra : www.planetcassandra.org § NOSQL : 5 minutes pour comprendre : http://blog.neoxia.com/nosql-5-minutes-pour- comprendre/ NEOXIA § NOSQL Europe : Bases de données orientées colonnes et Cassandra http://blog.xebia.fr/2010/05/04/nosql-europe-bases-de-donnees-orientees-colonnes-et- cassandra/ XEBIA § Une base NOSQL, Cassandra : http://www-igm.univ-mlv.fr/~dr/XPOSE2010/Cassandra IGM § Why NOSQL – Part 1 – CAP Theorem : http://bigdatanerd.wordpress.com/2011/12/08/why- nosql-part-1-cap-theorem/ DATANERD § DataStax Cassandra Tutorials : http://www.datastax.com/resources/tutorials/cassandra- overview DataStax § Documentation officielle MongoDB : http://docs.mongodb.org/ MongoDB • Présentations § Harri Kauhanen, « NOSQL Databases », Futurice, Septembre 2010 • Rapports § Mouna Laroussi, « Etude et mise en place de la technologie Big Data pour la télécommunication », Projet de fin d’études, INSAT, 2013 • Livres Blancs § Top 5 Considerations when evaluating NOSQL Databases, MongoDB White Paper, Juin 2013 85 Sources