Bases de données NOSQL

Ninja

Humeur

Date_naissance

Couleur

Heureuse

2007-04-01

Faim

NULL

NULL

NULL

NULL

Noire

NULL

Chien

type

Stella

nom

Heureuse

humeur

Chien_12

date_naissance

2007-04-01

Commentaire_ 83

Commentaire_à

texte

aboiements

Aboiement_5 9

texte

« J’ai mangéde la pâtée! »

Chien_4

commente

« Ons’en fout! »

19

NOSQL vs BDR Le choix de NOSQL plutôt que les bases de données relationnelles est conduit par les contraintes du marché et les besoins techniques suivants :

 Big Data Adaptation des BD NOSQL aux Big Data o Vitesse (Velocity)

: beaucoup de données qui arrivent

rapidement, à partir de plusieurs sources

o Variété (Variety) : données structurées, semi-structurées ou

non-structurées

o Volume (Volume) : données massives (To et Po)

20

NOSQL vs BDR  Modèles de données flexibles

o Une des raisons majeures o Dans le modèle relationnel :

 Les relations entre les tables sont prédéfinies, fixes et organisées dans

un schéma strict et uniforme

 Problèmes d’évolutivité et de performance en gérant de grands

volumes de données.

o Les BD NOSQL peuvent accepter tout type de données semi-structurées ou non-structurées) plus

(structurées, facilement.

o Dans les BDR, les performances posent problème, surtout quand des lignes « larges » sont utilisées et les actions de modification sont nombreuses.

21

NOSQL vs BDR  Disponibilité continue des données

◦ Le manque de disponibilité peut être fatal pour une

entreprise.

◦ BD NOSQL utilisent une architecture hautement distribuée

: pas de SPOF

◦ Redondance des données et traitements : tolérance aux

fautes

◦ Toute mise à jour ou modification est faite sans déconnecter

la base

22

NOSQL vs BDR  Indépendance de l’emplacement

o Possibilité de consulter et modifier une BD sans savoir où

est-ce que ces opérations ont réellement lieu.

o Toute fonctionnalité d’écriture est propagée à partir d’un emplacement, pour être disponible aux utilisateurs à partir d’autres sites.

23

NOSQL vs BDR

 Capacité des bases NOSQL à exploiter les données collectées pour dériver des idées o Extraction d’informations décisionnelles à partir d’un grand volume de données : difficile à obtenir avec des bases relationnelles.

o Bases NOSQL permettent le stockage et la gestion des données des fournissent une possibilité de comprendre les données complexes, et de prendre des décisions.

applications métier,

et

24

NOSQL vs BDR

 Capacités transactionnelles modernes

o Nouvelles définitions du principe de transaction

o Utilisation des propriétés BASE au lieu des propriétés ACID

25

NOSQL vs BDR

Toutes les BDR supportent les transactions ACID. Mais :

◦ Données de plus en plus volumineuses + Besoin de

systèmes évolutifs.

◦ Besoin de BD distribuées sur le réseau, pour une évolutivité

horizontale.

26

NOSQL vs BDR Théorème CAP : Dans les systèmes distribués, satisfaire les trois propriétés CAP en même temps.

il est impossible de

CAP = Consistency, Availability, Partition Tolerance

27

NOSQL vs BDR Pourquoi est-il impossible de satisfaire les 3 propriétés CAP en même temps? Soit un système distribué. On est entrain de modifier une donnée sur le nœud N1 et d’essayer de la lire à partir du nœud N2 : N2 peut retourner la dernière bonne valeur dont il dispose, ce qui viole la Consistance. N2 attend que la nouvelle valeur lui parvienne. Comme c’est un système distribué, les risques d’un échec de transmission sont assez importantes, ce qui provoquera une attente infinie de N2. D’où une violation de la Disponibilité. Si on veut satisfaire à la fois la consistance et la disponibilité, le système de stockage ne doit pas être partitionné. D’où violation de la Tolérance au partitionnement.

28

NOSQL vs BDR BASE Basically Available Le système garantit la disponibilité, comme définie dans le théorème CAP Soft-State L’état du système peut changer dans le temps, même sans nouvelles entrées, et ce à cause du principe de consistance éventuelle. Eventual Consistency Les modifications arriveront éventuellement à tous les serveurs, si on leur donne suffisamment de temps.

29

NOSQL vs BDR - Synthèse Bases de données NOSQL : o Performances sur de gros volumes de données o Performances sur des données non structurées o Evolutivité très importante, même pour de faibles volumes

Cependant :

 Technologie assez jeune => Manque d’outils la supportant

 Encore en évolution, pas de standards

 Pas de langage de requête commun comme SQL, mais divers :

o Requêtes spécifiques au langage (Java, Python…) o Requêtes spéciales pour la base (Cassandra Query Language) o API basée sur Map Reduce…

30

NOSQL vs BDR Quand utiliser NOSQL?

 Si l’évolutivité est une préoccupation

Mais attention, ce n’est pas toujours un MUST : Flickr et Wikipédia utilisent des SGBDR

 Si l’absence de schéma est une préoccupation  Si être IN et FASHION est une préoccupation

Pour un nombre important de personnes, paradigme ou technologie est nécessaire !

l’utilisation d’un nouveau

31

Cassandra Base de données : Distribuée À haute performance Extrêmement évolutive Tolérante aux fautes (pas de SPOF) Non-relationnelle

Peut être utilisée à la fois comme : Base de données temps réel Base de données pour une lecture intensive pour les

systèmes décisionnels

32

Cassandra - Architecture

 Inspirée de Big Table

 Cassandra est développée par Facebook en 2007

 En 2008, le projet est cédé à la fondation Apache et devient "top-level-project" à partir de 2010.

 Indépendante de Hadoop

33

Cassandra - Architecture

Lecture et écriture à partir de n’importe quel nœud, indépendamment de l’emplacement des données.

la Utilisation communication entre les différents nœuds du cluster.

protocole Gossip

pour

du

34

Cassandra - Architecture Structure orientée colonnes

Vocabulaire :

• Keyspace

• Column

• Row

• Column Family

35

Cassandra - Architecture

Colonne (Column) : une colonne est composée d'un nom, d'une valeur et d'un timestamp (instant de création).

Ligne (Row) : les colonnes sont regroupées en Rows. Une Row est représentée par une clé et une valeur. Il existe deux types de rows : les « wide row » permettant de stocker énormément de données, avec beaucoup de colonnes et les « skinny row » permettant de stocker peu de données.

36

Cassandra - Architecture Une famille de colonnes (Column family) : c'est l'objet principal de données et peut être assimilé à une table dans le monde des bases de données relationnelles. Toutes les rows sont regroupées dans les column family. Une famille de colonnes regroupe un ensemble de colonnes destinées à être consultées ensemble pour satisfaire les requêtes spécifiques à l'application.

Keyspace : c'est l'équivalent d'une base de données dans le monde du relationnel. À noter qu'il est possible d'avoir plusieurs « Keyspaces » sur un même serveur.

37

Cassandra - Architecture Il y a deux types de familles de colonnes :

Les familles de colonnes statiques : elles utilisent un ensemble statique de noms de colonne et sont très similaires à une table d'une base de données relationnelle même si toutes les colonnes n'ont pas à être obligatoirement renseignées.

Les familles de colonnes dynamiques : elles permettent, par exemple, de précalculer un ensemble de résultats et de les stocker dans une même ligne afin de pouvoir y accéder plus tard. Chaque ligne correspond donc à un snapshot de données correspondant à une requête donnée.

38

Partitionnement

 Partitionnement différents nœuds participants du cluster

facile des données

à

travers

les

 Chaque nœud accueille une partie de la base de données

 Les données sont famille de colonnes

insérées par l’utilisateur dans une

39

Partitionnement Stratégies de partitionnement

Partitionnement aléatoire o Par défaut, recommandé

o Données partitionnées le plus équitablement possible à

travers les différents nœuds

o Utilisation de MD5 (ou Murmur3) pour le hachage de

chaque clef de ligne

40

Partitionnement Partitionnement ordonné

o Sauvegarde les clefs des lignes par ordre à travers les

nœuds d’un cluster

o Peut provoquer des problèmes, surtout pour la répartition avec des données plus

(des nœuds

charges

des volumineuses que d’autres)

 Stratégie cassandra.yaml

spécifiée dans

un fichier de

configuration

 Si la stratégie d’une base est modifiée, il faut recharger toutes les données

41

Cassandra - Réplication  Pour assurer la tolérance aux pannes, il est possible de créer une ou plusieurs copie(s) de chaque colonne à travers les nœuds participants.

 L’utilisateur spécifie le facteur de réplication désiré à la création du keyspace.

 Les données sont insérées par l’utilisateur dans une famille de colonnes.

 La colonne est répliquée dans les nœuds du cluster selon le facteur de réplication.

42

Cassandra - Réplication Stratégies de réplication

Stratégie Simple :

o La colonne originelle est placée sur un nœud déterminé par le partitionneur.

o La réplique est placée sur le nœud suivant de l’anneau (clockwise).

o Pas de considération de l’emplacement dans un data center ou dans une baie (approprié pour les déploiements sur un seul data center)

43

Cassandra - Réplication Stratégie par topologie du réseau :

o Plus sophistiquée

o Plus de contrôle sur l’emplacement des répliques de colonnes

o Parcourt le cluster (clockwise) à la recherche d’un nœud dans une baie différente.

o Si introuvable, stocker la colonne dans un nœud de la même baie

o Un groupe de réplication est spécifié, pour distinguer entre plusieurs data centers.

44

Cassandra - Réplication Mécanisme de réplication

 Utilisation de SNITCH :

o Définition de la manière dont les nœuds sont groupés dans

un réseau

o Répartition des nœuds entre baies et data centers o Défini dans le fichier de configuration cassandra.yaml

45

Cassandra - Réplication

CREATE KEYSPACE MonEspaceDeCle WITH REPLICATION =

{ 'class' : 'SimpleStrategy', 'replication_factor' : 3 };

USE MonEspaceDeCle;

CREATE COLUMNFAMILY MesColonnes (id , Nom , Prenom , PRIMARY KEY(id));

INSERT INTO MesColonnes (id, Nom, Prenom) VALUES ('1', 'Doe', 'John');

SELECT * FROM MesColonnes;

46

Cassandra - Consistance Sur Cassandra l’écriture de données se fait : o Dans un premier temps dans un journal de commit ; o Puis dans une structure en mémoire appelée Memtable. o Les données sont écrites de façon périodique sur le disque dans une structure appelée SSTable.

=> Moins d’entrées/sorties disque au moment de l’écriture  Cassandra est optimisée pour permettre une écriture rapide et hautement disponible des données avec un débit élevé.

47

Cassandra - Consistance Consistance : à quel point est-ce qu’une donnée est à jour et synchronisée sur toutes ses répliques. Extension du concept de consistance éventuelle à une consistance ajustable. Choix possible entre une consistance forte ou éventuelle selon les besoins Ce choix est fait par opération, ce n’est pas une stratégie globale pour la base de données (ex, pour changer la stratégie de lecture en quorum)

SELECT * QUORUM WHERE state=‘TX’;

FROM users USING CONSISTENCY

48

Cassandra–Stratégies d’écriture Niveau de consistance : combien de répliques doivent être écrites avec succès avant de retourner un acquittement au client.

49

Niveau de consistance Any

One (défaut dans CQL)

Description

Une écriture doit être faite sur au moins un nœud même si c’est un hinted handoff. Offre la plus haute disponibilité, mais la plus basse consistance

Une écriture doit réussir sur le commit log et la memtable d’au moins une réplique.

Quorum

Une écriture doit réussir sur un certain pourcentage de répliques (pourcentage = (facteur de réplication/2)+1) Meilleure alternative en terme de consistance et de disponibilité Local-Quorum Une écriture doit réussir sur un certain pourcentage de nœuds

répliques sur le même data center que le nœud coordinateur

Each-Quorum une écriture doit réussir sur un certain pourcentage de

nœuds répliques sur tous les data centers.

All

une écriture doit réussir sur tous les nœuds répliques d’une colonne. Offre la plus haute consistance, mais la plus basse disponibilité

50

Cassandra–Stratégies d’écriture de permet cette Hinted Handoff synchroniser un nœud qui est indisponible pour une petite période de temps.

fonctionnalité

:

Une écriture est toujours envoyée à tous les réplicas.

Si un réplica n’est pas disponible, les autres réplicas gardent une information indiquant qu’une écriture est en attente pour ce nœud et lorsqu’il est de nouveau disponible ils lanceront l’écriture.

51

Cassandra-Stratégies de lecture Niveau de consistance : combien de répliques doivent répondre avant de retourner le résultat.

52

One (défaut dans CQL) :

Obtention d’une réponse à partir de la réplique la plus proche selon le SNITCH. Offre la plus faible consistance, mais la plus haute disponibilité

Quorum

le plus récent à partir d’un certain Obtention du résultat pourcentage de nœuds répliques (pourcentage = (facteur de réplication /2)+1) Meilleure alternative en terme de consistance et de disponibilité

Local-Quorum Obtention du résultat

le plus récent à partir d’un certain pourcentage de nœuds répliques sur le même datacenter que le nœud coordinateur Évite la latence due à la communication inter-datacenters

Each-Quorum Obtention du résultat

le plus récent à partir d’un certain

pourcentage de nœuds répliques sur tous les datacenters

All

Obtention du résultat le plus récent à partir de tous les nœuds répliques Offre la plus haute consistance, mais la plus basse disponibilité

53

Cassandra-Stratégies de lecture Read Repair

 Cassandra assure que les données fréquemment lues soient consistantes.

 À la lecture d’une donnée, toutes ses répliques en arrière plan.

le nœud coordinateur compare

 Si ces données ne sont pas consistantes, il envoie une demande d’écriture aux nœuds réplicas pour mettre à jour leur donnée et afficher la donnée la plus récente.

 Read Repair peut être configuré par famille de colonnes et est activé par défaut.

54

Cassandra Deux interfaces pour gérer les objets/données :

 Cassandra CLI (Command Line Interface)

Interface originelle conçue pour créer des objets, entrées et manipuler les données.

 CQL (Cassandra Query Language)

Utilisée pour créer/manipuler des données en utilisant un langage proche de SQL

55

Cassandra

Les objets tels que les keyspaces, les familles de colonnes et les index sont créés, modifiés et supprimés avec les commandes usuelles : CREATE, ALTER et DROP

Données insérées, modifiées et supprimées avec INSERT, UPDATE et DELETE

Données lues avec SELECT

Utiliser la clause USING CONSISTENCY pour déterminer le type de consistance forte pour chaque opération de lecture et l’écriture (Any, One, Quorum…).

56

Cassandra - Récapitulation  Grande Scalabilité

 Pas de SPOF

 Réplication et distribution des données facile à travers les data centers

 Consistance des données ajustable

Possibilité de choisir pour chaque opération si une donnée est fortement consistante (tous les nœuds sont similaires à tout moment) ou éventuellement consistante.

 Schéma de données flexible

 Langage CQL très proche de SQL

57

MongoDB

 SGBD NOSQL orienté documents, à schéma flexible et distribuable.

 MongoDB (de Humongous, qui veut dire énorme)

 Écrit en C++

 Distribué sous licence AGPL (GNU Affero General Public License)

 Développé en 2007 par la firme MongoDB

58

MongoDB  Compagnie fondée en 2007 par les anciens de 10gen dont l’objectif était de construire une offre PAAS (cloud).

 Ils n’ont pas trouvé un SGBD suffisamment élastique pour l’intégrer à leur offre ; ils ont développé MongoDB

 MongoDB était tellement populaire qu’ils ont abandonné leur offre Cloud au profit de celui-ci.

 Changement de nom : 10gen est devenue MongoDB

59

MongoDB Un des SGBD les plus utilisés.

Exemples d’utilisateurs :

eBay Foursquare SourceForge.net Viacom Pagesjaunes New York Times

60

MongoDB des livré MongoDB principaux langages de programmation :

avec

est

liaisons

pour

les

C , C++, Dart, Erlang, Go, Haskell, JavaScript, .NET (C# F#, PowerShell,…), Perl, PHP, Python, Ruby, Scala.

Java,

MongoDB possède un outil qui peut être utilisé en ligne de commande.

Cet outil permet de manipuler la base de données à travers son langage : Javascript.

61

MongoDB

Dans le modèle relationnel :

Table Acteur Id Nom

Prénom

1

2

Johansson

Scarlett

Phoenix

Joaquim

Table Film Id titre

10

20

Her

Avengers

Table jointure Acteur_Film Acteur_id Film_id

1

1

2

10

20

10

62

MongoDB

Dans MongoDB : Les films peuvent être modélisés selon des documents comme suit :

{_id: "Her",

Document

acteurs : [{nom:"Johansson",

prenom:"Scarlett"}, {nom:"Phoenix", prenom:"Joaquim"}]}

Duplication de l’acteur : inacceptable en relationnel mais tout à fait possible en NOSQL dans l’objectif d’améliorer les performances

{_id: "Avengers", acteurs : [{nom:"Johansson", prenom:"Scarlett"}]}

63

MongoDB Dans un document, des champs peuvent être ajoutés, supprimés, modifiés et renommés à tout moment.

La structure d'un document est compose de paires clef/valeur, du champ, la valeur son contenu.

Nom du champ

très simple et se le nom

est

la clef

{_id: "Avengers", acteurs : [{nom:"Johansson", prenom:"Scarlett"}]}

Les deux sont séparés d'un signe deux-points ":".

Valeur

Une "valeur" peut être un nombre, du texte, une donnée binaire (comme une image) ou une collection d'autres paires clefs/valeurs.

64

MongoDB : document

 Le champ _id :

 Seul champ obligatoire, utilisé comme clef primaire

dans une collection

 Peut-être de tout type autre que Tableau

 Les noms des champs ne peuvent pas : commencer par un $, contenir le caractère « . » ou le caractère « null ».

65

MongoDB Structure de données JSON-like, composée de paires clef/valeur.

Stocké sur le disque sous forme de document BSON : ◦ Documents BSON (Binary JSON) : représentation binaire

sérialisées d’un document JSON ;

◦ Supporte plus de types de données que JSON ;

◦ La partie valeur peut avoir n’importe quel type supporté par JSON, dont d’autres documents, des tableaux, et des tableaux de documents.

66

MongoDB : document

La structure du document n’est pas fixée à sa création mais en général, les documents d’une même collection ont une structure similaire (homogénéité).

forme de sont organisés Les documents collections : groupe de documents reliés par des indexes en commun.

sous

67

MongoDB

Terminologie SQL

Terminologie MongoDB

Base de données Table

Ligne

Colonne Index

Base de données Collection

Document

Champ Index

Jointure Clef Primaire (peut être multiple)

Imbrication ou Référence Clef Primaire (une seule, et représentée par le champ _id)

68

Exemple

{ "_id": ObjectId("4efa8d2b7d284dad101e4bc7"),

"Nom": "DUMOND",

"Prénom": "Jean",

"Âge": 43

},

Changement de schéma

{"_id": ObjectId("4efa8d2b7d284dad101e4bc8"),

"Nom": "PELLERIN",

"Prénom": "Franck",

"Adresse": "1 chemin des Loges",

"Ville": "VERSAILLES"

},

69

MongoDB Deux manières d’exprimer données : Références et Données Imbriquées

les relations entre les

Références

 Inclusion de liens ou références d’un document à un

autre

 C’est à l’application de résoudre ces références pour

accéder aux données associées

 On dit qu’on utilise des Modèles de Données

Normalisés

70

MongoDB

71

MongoDB Données Imbriquées (Embedded Data)

 Sauvegarde des données associées dans la même

structure de documents

 Il est possible d’inclure des documents dans un champ

ou un tableau

 Permet

aux applications d’extraire

plusieurs niveaux de hiérarchie instruction

et manipuler seule

en une

 Ce sont les Modèles de Données Dénormalisés

72

MongoDB

73

MongoDB Comment choisir entre Références et Données Imbriquées?

On choisit les références quand :

 L’imbrication va produire des données dupliquées sans grands avantages en terme de performance de lecture

 On veut complexes

représenter des relations many-to-many

 On veut modéliser de larges ensembles de données

hiérarchiques

74

MongoDB On choisit les données imbriquées quand :

 On a des relations contains entre les éléments

(modèles one-to-one)

 Exemple: personne et adresse

 On a des relations one-to-many, où les documents fils toujours dans le contexte des

(many) apparaissent documents parents (one)

 Exemple : personne et plusieurs emails

75

MongoDB : lecture Lecture :  Cible une collection unique de documents ;  Se base spécifiques, pour identifier le document à retourner ;  Peut document à retourner ;  Peut définir des modificateurs pour imposer des limites, un ordre, un filtre…

inclure une projection sur les champs du

sur un critère ou des conditions

76

MongoDB : lecture

77

MongoDB : lecture La méthode db. collection.find() : Permet l’extraction de données en se basant sur des critères ; Accepte les projections ; Retourne curseur un correspondants.

documents

vers

les

La méthode db. collection.findOne() se comporte de la même manière que la méthode find mais elle retourne un seul document

78

MongoDB : lecture

79

MongoDB : lecture Projections :

Deuxième argument de la méthode find()

Peuvent spécifier la liste des champs à afficher ou à

exclure

A part le champ _id (qui est affiché par défaut), il est interdit de mixer les projections inclusives et exclusives des différents champs

80

MongoDB : lecture

81

MongoDB : écriture

 Création, mise à jour ou suppression de document ;

 Ciblent une seule collection ;

 Se basent sur un ou plusieurs sélectionner les documents à modifier ou supprimer.

critères pour

82

MongoDB : écriture

Insertion d’un document

Si on ne définit pas le champ _id, le système l’ajoute tout seul

83

MongoDB : écriture Mise à jour de documents

Méthode update peut accepter des critères de sélection des documents à modifier, et des options qui affectent son comportement.

L’opération update :

 Par défaut, modifie un seul document

 Plusieurs documents si l’option multi est à true

84

MongoDB : écriture

85

MongoDB : écriture La méthode remove supprime des documents d’une collection  Accepte des critères de sélection des documents à supprimer  Supprime par défaut tous les documents correspondants aux critères de sélection (sauf indication du contraire dans un flag approprié)

86

MongoDB : écriture

 Les opérations d’écriture sont atomiques au niveau d’un document.

 L’utilisation des données imbriquées facilite l’écriture.

 La normalisation des données (référence vers données dans d’autres collections) implique plusieurs opérations d’écriture qui ne sont pas atomiques.

87

MongoDB : écriture Certaines modifications (un push dans des tableaux, ou bien un ajout d’un champ) augmentent la taille des documents.

le moteur de stockage MMAPv1, si

la taille d’un Pour document dépasse la taille autorisée pour ce document, MongoDB le réalloue sur le disque.

Si l’application en question nécessite plusieurs modifications qui augmentent la taille des documents, il vaut mieux opter pour l’utilisation des références.

88

MongoDB : load balancing  MongoDB utilise le sharding pour stocker ses données dans le cluster.

 Le sharding est utilisé pour faire du scaling horizontal.

 Il s’agit de créer un cluster MongoDB (appelé sharded cluster) composé de plusieurs machines sur lesquelles les données contenues dans notre base vont être réparties.

 L’atout principal d’un sharded cluster est le load balancing (répartition de charge) :  Données réparties sur un grand nombre de nœuds différents ;  Requêtes se feront sur de plus petits jeux de données et pourront

être parallélisées => temps de réponse plus rapides

89

MongoDB

Scaling vertical vs scaling horizontal https://www.supinfo.com/articles/single/4761-mongodb-sharding

90

MongoDB Trois types de composants dans un cluster MongoDB :  Le serveur de configuration :

Stocke les métadonnées et les paramètres de configuration du cluster. Permet de localiser les données sur les shards.

 Les shards :

Stockent les données. Peuvent être ajoutés pour agrandir la capacité de

stockage et la puissance de calcul.  Un ou plusieurs routeurs :

Communique avec le serveur de configuration pour connaître la répartition des données et donc choisir le bon shard => assure le routage des requêtes.

Assure l’équilibrage de charge. Joue le rôle d’interface entre l’application cliente et le sharded cluster.

91

MongoDB

MongoDB propose un mécanisme de réplication basé sur le « replica set » afin de se prémunir de la perte de données et assurer la continuité des services.

Un « replica set » : est un groupe d’instances qui maintiennent le même ensemble de données.

Il se compose d’un nœud primaire et de nœuds secondaires.

Les opérations ont lieu sur le nœud primaire, puis elles sont reproduites sur les nœuds secondaires.

Dans le cas où le nœud primaire ne répond pas pendant 10 secondes, un nœud secondaire est élu comme nouveau nœud primaire.

Ce processus complètement transparent pour l’utilisateur.

est

rapide (environ une minute), automatique et

92

MongoDB

Election d’un nouveau primaire https://www.supinfo.com/articles/single/4761-mongodb-sharding

93

MongoDB

Pour qu’un nœud soit élu primaire, il doit obtenir une majorité qualifiée.

Exp : Dans un réplica composé de 3 nœuds, pour être élu il faut au moins 2 votes. Si 2 serveurs tombent en panne, le nœud restant n’aura qu’un seul vote, il ne pourra donc pas être élu => les données ne seront plus accessibles.

Quand on choisit le nombre de nœuds du réplica il faut s’assurer qu’en cas de panne, un nouveau nœud primaire pourra être élu.

94

MongoDB

Pour éviter les situations d’élection impossible, il faut ajouter un arbitre au réplica set.

Un arbitre est un nœud qui ne contient pas de données et qui consomme très peu de ram. Il sert uniquement à s’assurer qu’un des nœuds aura la majorité qualifiée lors de l’élection.

L’arbitre ne doit pas être sur le même serveur que les autres membres du réplica set.

Pour savoir si une élection peut avoir lieu : si on appelle N le nombre de nœuds, pour qu’un nœud soit élu il doit avoir un nombre de votes strictement supérieur à N/2. L’arbitre permet d’ajouter un vote, sans changer la valeur de N (il ne compte pas comme un nœud).

95

MongoDB

Pour profiter pleinement du scaling horizontal, le routeur de MongoDB répartit uniformément les données sur les différents shards.

Ce partitionnement se fait au niveau des collections et s'appuie sur une clé de sharding. MongoDB définit un intervalle de valeurs sur cette clé pour chaque shard.

Il faut choisir un champ présent dans tous les documents de la collection.

96

MongoDB

Ainsi, les opérations (requêtes portant sur la clé de sharding, ajout de document) porteront uniquement sur le shard concerné donc sur un sous- ensemble de données => Temps de réponse beaucoup plus court.

Si la requête s’applique sur plusieurs shards => elle s’effectue en parallèle.

Le choix de la clé est très important puisqu’il impacte l’efficacité des requêtes et la possibilité d’agrandir le cluster (possibilité d’ajouter des machines, scalabilité).

97

Conclusion Quand utilise-t-on MongoDB ?

 Données semi-structurées  Peu de relations  Besoin d’élasticité  Besoin de programmer aisément  Licence libre

98

Conclusion  Le scaling horizontal, permet de faire face à plusieurs limites techniques et assure de vraies économies. Mais il implique un plus grand risque de panne.

Le sharding est un mécanisme proposé par MongoDB pour créer un cluster hautement disponible : sharded cluster.

Le « replica set » est un mécanisme de réplication qui rend le cluster tolérant aux pannes en le prémunissant contre la perte partielle de données.

Un sharded cluster permet d’équilibrer la charge entre les différentes machines (load balancing).

99