![Technologies communément utilisées dans les bases NoSQL Compromis sur la Cohérence
Gestion de la cohérence
Horloges Vectorielle (Vector Clocks)
I Les ensembles de données répartis sur nœuds peuvent être lus et modifiés sur chaque
nœud et aucune cohérence stricte est assurée par des protocoles de transactions
distribuées.
Problème : Comment faire des modifications concurrentes ?
I Une solution : les horloges vectorielles : I Un vecteur d’horloge est défini comme un
n-uplet V [0], V [1], ..., V[n] des valeurs
d’horloge à partir de chaque nœud.
I À tout instant le nœud i maintient un vec-
teur d’horloge représentant son état et ce-
lui des autres nœuds répliques : (Vi [0] =
valeur de l’horloge du premier nœud, Vi [1]
= valeur de l’horloge du deuxième nœud,
... Vi [i] = sa propre valeur d’horloge, ... Vi
[n] = valeur de l’horloge du dernier nœud).
I Les valeurs d’horloge peuvent être de
réelles timestamps dérivées d’une hor-
loge locale de nœud, du numéro de ver-
sion/révision, etc.
Minyar Sassi Hidri Les BDs NoSQL 54 / 194](https://image.slidesharecdn.com/nosql-161213143036/85/Les-BD-NoSQL-54-320.jpg)
![L’invite interactive de MongoDB Lecture/´Ecriture
Insertion de documents
I Pour insérer un document dans une collection (que la collection existe ou non) :
>db.collection.insert(document)
>db.collection.insert(documents)
- document est un tableau clefs / valeurs.
- documents est une liste de tableaux clefs / valeurs.
- collection est le nom de la collection à laquelle on souhaite ajouter le(s) document(s). Si la collection n’existait
pas au préalable, elle est créée (c’est de cette manière qu’on crée les collections).
>db.etudiants.insert({’prenom’ : ’Camille’,’nom’ : ’Simon’})
>db.etudiants.insert({ ’prenom’ : ’Thomas’ })
>db.etudiants.insert([ { ’prenom’ : ’Jordan’ },
{ ’prenom’ : ’Mélanie’} ] )
>db.etudiants.insert([ {’prenom’ : ’Camille’,’nom’ : ’Alberti’},
{’prenom’ : ’Laura’,’nom’ : ’Seban’}])
>db.cours.insert([{ ’code’ : ’IO2’, ’intitulé’ : ’Internet et outils’ },
{ ’code’ : ’TO2’, ’intitulé’ : ’Types de données et objets’}])
Minyar Sassi Hidri Les BDs NoSQL 74 / 194](https://image.slidesharecdn.com/nosql-161213143036/85/Les-BD-NoSQL-74-320.jpg)
![L’invite interactive de MongoDB Lecture/´Ecriture
Recherche
Fonction find() (1)
I Exemple :
>db.etudiants.find()
>db.etudiants.find({ ’prenom’ : ’Camille’})
I Résultat :
> db.etudiants.find( { ’prenom’ : ’Camille’ } )
{ ” id” : ObjectId(”532d40c72d150b4635b8cfc9”), ”prenom” : ”Camille”, ”nom” : ”Simon” }
{ ” id” : ObjectId(”532d40c72d150b4635b8cfcd”), ”prenom” : ”Camille”, ”nom” : ”Alberti” }
- Le champ id a été ajouté par le système au moment de l’opération insert. On peut ensuite l’utiliser pour
désigner un document précis :
> db.etudiants.find({ id : ObjectId(”532d40c72d150b4635b8cfc9”) })
{ ” id” : ObjectId(”532d40c72d150b4635b8cfc9”), ”prenom” : ”Camille”, ”nom” : ”Simon” }
I Le résultat renvoyé par find est un curseur, un objet qui permet d’itérer sur les documents.
Considérons un exemple d’utilisation simple, comme un tableau :
> var c = db.etudiants.find({’prenom’ : ’Camille’})
> c[0]
{
” id” : ObjectId(”532d40c72d150b4635b8cfc9”),”prenom” : ”Camille”,”nom” : ”Simon”}
> c[0].nom
Simon
Minyar Sassi Hidri Les BDs NoSQL 76 / 194](https://image.slidesharecdn.com/nosql-161213143036/85/Les-BD-NoSQL-76-320.jpg)
![L’invite interactive de MongoDB Lecture/´Ecriture
Recherche
Fonction find() (2)
I On peut également utiliser l’opérateur $or pour indiquer un OU logique, sur le modèle :
>db.collection.find({$or : [ {field1 : value1},{field2 :value2}]})
I Plutôt que d’indiquer une valeur fixe dans ces instructions conditionnelles, on peut
également utiliser des opérateurs tel que supérieur à, inférieur à, etc.. ils respectent la
syntaxe suivante :
{field : {operator :value}}
I Et on dispose des opérateurs suivantes :
- $gt : plus grand que.
- $gte : plus grand ou égal a.
- $lt : plus petit que.
- $lte : plus petit ou égal a.
- $ne : different de.
Minyar Sassi Hidri Les BDs NoSQL 77 / 194](https://image.slidesharecdn.com/nosql-161213143036/85/Les-BD-NoSQL-77-320.jpg)
![L’invite interactive de MongoDB Lecture/´Ecriture
Recherche
Fonction find() (3)
I On peut également indiquer, par le biais d’un second argument à find(),
quels champs on souhaite sélectionner. Si ce second argument n’est pas
spécifié, tous les champs du document sont renvoyés.
.find({...},{field1 :[0|1],field2 :[0|1],...})
I Pour sélectionner tous les élèves mais sans extraire leurs noms et prénoms :
>db.eleves.find({}, {prenom :0,nom :0})
I On peut également appliquer un équivalent de l’opérateur limit par le biais
des fonctions limit() et skip() à appliquer respectivement à find() et à
limit().
- pour sélectionner les N premiers documents : .find(...).limit(N).
- pour sélectionner les N premier documents à partir du Mième document :
.find(...).limit(N).skip(M).
Minyar Sassi Hidri Les BDs NoSQL 78 / 194](https://image.slidesharecdn.com/nosql-161213143036/85/Les-BD-NoSQL-78-320.jpg)
![L’invite interactive de MongoDB Lecture/´Ecriture
Recherche
Fonction find() (4)
I On peut également trier les documents résultant de notre recherche. Pour ce
faire, on va utiliser la fonction .sort() à appliquer à find().
.find(...).sort({field1 :[1|-1], filed2 :[1|-1],...)
...où 1 désigne un ordre ascendant et -1 un ordre descendant.
I Un autre opérateur utilisable au sein des instructions conditionnelles est
l’opérateur in.
{filed : {in : [value1, value2, value3,...]}}
Minyar Sassi Hidri Les BDs NoSQL 79 / 194](https://image.slidesharecdn.com/nosql-161213143036/85/Les-BD-NoSQL-79-320.jpg)
![L’invite interactive de MongoDB Exemple
Exemple
Insertion des données dans MongoDB (2)
I Nous commenc¸ons par ajouter les éditeurs :
>show dbs
>use bibliotheque
>db.editeurs.insert({ nom : ”Hachette”}) ;
>db.editeurs.insert({ nom : ”Hatier”}) ;
>db.editeurs.insert({ nom : ”O’Reilly”}) ;
I Consultons le contenu de la collection editeurs :
> db.editeurs.find({})
I On a bien ajouté trois documents dans la collection editeurs. On remarque que MongoDB
a automatiquement ajouté un identifiant. On peut maintenant ajouter les documents livres
en reprenant les Id des éditeurs.
> db.livres.insert({type : ”livre”, titre : ”Aubonheurdesdames”, annee : 2010, editeur :
new DBRef ( editeurs , ObjectId(”4fa40cbe9ff 7ba90f 5d13eed”)), ISBN : ”2012814557”,
auteurs : [{nom : ”Zola”, prenom : ”Emile”}]});
> db.livres.insert({type : ”livre”, titre : ”Germinal”, annee : 1995, editeur : newDBRef ( editeurs ,
ObjectId(”4fa40d359ff 7ba90f 5d13eee”)),
format : ”Poche”, auteurs : [{nom : ”Zola”, prenom : ”Emile”}]});
> db.livres.insert({type : ”livre”, titre : ”TheDefinitiveGuidetoMongodb”, annee : 2003,
editeur : newDBRef ( Editeurs , ObjectId(”4fa40dfb7b071ce946d6dc34”)),
ISBN : ”1449381561”, pages : 206, langue : ”Anglais”,
auteurs : [{nom : ”Dirolf ”, prenom : ”Michael”}, {nom : ”Dirolf ”, prenom : ”Kristina”}]});
I Vérification du nombre de livres en base :
>db.livres.count()
Minyar Sassi Hidri Les BDs NoSQL 83 / 194](https://image.slidesharecdn.com/nosql-161213143036/85/Les-BD-NoSQL-83-320.jpg)
![HBase Recherche de n-uplets
Recherche de n-uplets
I La commande scan affiche les n-uplets sélectionnés par les conditions. La difficulté, c’est
d’écrire les conditions en Ruby.
Scan ’NOMTABLE’, {CONDITIONS}
I Conditions :
- COLUMNS=>[’FAMILIY COLUMN :COLONNE’,...] pour sélectionner certaines co-
lonnes.
- STARTROW=>’CLE1’, STOPROW=>’CLE2’ pour sélectionner les n-uplets entre
CLE1 et CLE2.
- VERSIONS=>NB affiche NB versions des valeurs.
- FILTER=>”ValueFilter(OP, ’binary :CONSTANTE’)” permet de comparer les valeurs
à une constante, mettre <, <=, =, ! =, >, >= pour OP. Il existe quelques autres
filtres.
- ....
Scan ’table 1’, {FILTER => ”ColumnPrefixFilter (’d11’)”}
I Voici comment compter les n-uplets d’une table, en configurant le cache pour en prendre
1000 à la fois :
Count ’NOMTABLE’, CACHE => 1000
I HBase n’est qu’un stockage de mégadonnées. Il n’a pas de dispositif d’interrogations so-
phistiqué.
Minyar Sassi Hidri Les BDs NoSQL 149 / 194](https://image.slidesharecdn.com/nosql-161213143036/85/Les-BD-NoSQL-149-320.jpg)
![HBase API de HBase
Création/ Suppression d’une table
I Voici une fonction qui crée une table :
void CreerTable(String nomtable, String[] familles)
{
Configuration config = HBaseConfiguration.create() ;
HBaseAdmin admin = new HBaseAdmin(config) ;
try {TableName tn = TableName.valueOf(nomtable) ;
HTableDescriptor htd = new HTableDescriptor(tn) ;
for (String famille : familles) {
htd.addFamily(new HColumnDescriptor(famille)) ;
}
admin.createTable(tabledescriptor) ;
} finally {
admin.close() ;
}
}
I Voici comment on supprime une table, en vérifiant au préalable si elle existe :
void SupprimerTable(String nomtable)
{
Configuration conf = HBaseConfiguration.create() ;
HBaseAdmin admin = new HBaseAdmin(conf) ;
try {TableName tn = TableName.valueOf(nomtable) ;
if (admin.tableExists(tn)) {
admin.disableTable(tn) ;
admin.deleteTable(tn) ;
}
}finally {
admin.close() ;
}
}
Minyar Sassi Hidri Les BDs NoSQL 151 / 194](https://image.slidesharecdn.com/nosql-161213143036/85/Les-BD-NoSQL-151-320.jpg)
![HBase API de HBase
Insertion d’une valeur
Transformation en tableaux d’octets
I L’insertion d’une valeur consiste à créer une instance de la classe Put. Cet
objet spécifie la valeur à insérer :
- identifiant du n-uplet auquel elle appartient
- nom de la famille
- nom de la colonne
- valeur
- en option, le timestamp à lui affecter.
I Toutes les données concernées doivent être converties en tableaux d’octets.
I Transformation en tableaux d’octets :
- HBase stocke des données binaires quelconques : chaînes, nombres, images jpg, etc.
Il faut seulement les convertir en byte[].
- Convertir une donnée en octets se fait quelque soit son type par :
final byte[] octets = Bytes.toBytes(donnée) ;
Minyar Sassi Hidri Les BDs NoSQL 153 / 194](https://image.slidesharecdn.com/nosql-161213143036/85/Les-BD-NoSQL-153-320.jpg)
![HBase API de HBase
Insertion d’une valeur (fonction)
void AjouterValeur(String nomtable, String id, String fam, String col, String val)
{
Configuration config = HBaseConfiguration.create() ;
HTable table = new HTable(config, nomtable) ;
// Construire un Put
final byte[] rawid = Bytes.toBytes(id) ;
Put action = new Put(rawid) ;
final byte[] rawfam = Bytes.toBytes(fam) ;
final byte[] rawcol = Bytes.toBytes(col) ;
final byte[] rawval = Bytes.toBytes(val) ;
action.add(rawfam, rawcol, rawval) ;
// Effectuer l’ajout dans la table
table.put(action) ;
}
Minyar Sassi Hidri Les BDs NoSQL 155 / 194](https://image.slidesharecdn.com/nosql-161213143036/85/Les-BD-NoSQL-155-320.jpg)
![HBase API de HBase
Extraction d’une valeur
I La récupération d’une cellule fait appel à un Get.
I Il se construit avec l’identifiant du n-uplet voulu.
I Ensuite, on applique ce Get à la table. Elle retourne un Result conte-
nant les cellules du n-uplet.
static void AfficherNuplet(String nomTable, String id)
{
final byte[] rawid = Bytes.toBytes(id) ;
Get action = new Get(rawid) ;
// appliquer le get à la table
Configuration config = HBaseConfiguration.create() ;
HTable table = new HTable(config, nomTable) ;
Result result = table.get(action) ;
AfficherResult(result) ;
}
Minyar Sassi Hidri Les BDs NoSQL 156 / 194](https://image.slidesharecdn.com/nosql-161213143036/85/Les-BD-NoSQL-156-320.jpg)
![HBase API de HBase
Extraction d’une valeur
Résultat d’un Get
I Un Result est une sorte de dictionnaire (famille, colonne) → valeur.
- Sa méthode getValue(famille, colonne) retourne les octets de la valeur
désignée, s’il y en a une :
byte[] octets = result.getValue(rawfam, rawcol) ;
- On peut parcourir toutes les cellules par une boucle :
void AfficherResult(Result result)
{
for (Cell cell : result.listCells())
{
AfficherCell(cell) ;
}
}
Minyar Sassi Hidri Les BDs NoSQL 157 / 194](https://image.slidesharecdn.com/nosql-161213143036/85/Les-BD-NoSQL-157-320.jpg)
![HBase API de HBase
Parcours des n-uplets d’une table
I Réaliser un Scan par programme n’est pas très compliqué.
I Il faut fournir la clé de départ et celle d’arrêt (ou alors le scan se fait
sur toute la table). On reçoit une énumération de Result.
void ParcourirTable(String nomtable, String start, String stop)
{
final byte[] rawstart = Bytes.toBytes(start) ;
final byte[] rawstop = Bytes.toBytes(stop) ;
Scan action = new Scan(rawstart, rawstop) ;
Configuration config = HBaseConfiguration.create() ;
HTable table = new HTable(config, nomTable) ;
ResultScanner results = table.getScanner(action) ;
for (Result result : results) {
AfficherResult(result) ;
}
}
Minyar Sassi Hidri Les BDs NoSQL 159 / 194](https://image.slidesharecdn.com/nosql-161213143036/85/Les-BD-NoSQL-159-320.jpg)
![Neo4j
Neo4j : Exemple (1)
I Tout d’abord, nous créons un nœud :
CREATE n = {nom : ’Milou’, ville : ’Paris’} ;
I Affichage :
START n=node(1) RETURN n ;
I Résultat :
==> +-−-−-−-−-−-−-−-−-−-−-−-−-−-−-−-−-−-−+
==> | n |
==> +-−-−-−-−-−-−-−-−-−-−-−-−-−-−-−-−-−-−+
==> | Node[1]{nom : Milou ,ville : Paris } |
==> +-−-−-−-−-−-−-−-−-−-−-−-−-−-−-−-−-−-−+
==> 1 row
==> 0 ms
Minyar Sassi Hidri Les BDs NoSQL 163 / 194](https://image.slidesharecdn.com/nosql-161213143036/85/Les-BD-NoSQL-163-320.jpg)
![Neo4j
Neo4j : Exemple (2)
I Nous allons maintenant ajouter un deuxième nœud et une relation dans
la même commande :
START Milou = node(1)
CREATE
Tintin = { nom : ’Tintin’, ville : ’Paris’ },
Milou-[r :AMI]->Tintin
RETURN
Tintin ;
I Ce qui retourne :
==> +-−-−-−-−-−-−-−-−-−-−-−-−-−-−-−-−-−-−+
==> | Tintin |
==> +————————————-+
==> | Node[2]{nom : Tintin ,ville : Paris } |
==> +-−-−-−-−-−-−-−-−-−-−-−-−-−-−-−-−-−-−+
==> 1 row
==> Nodes created : 1
==> Relationships created : 1
==> Properties set : 2
==> 42 ms
==>
Minyar Sassi Hidri Les BDs NoSQL 164 / 194](https://image.slidesharecdn.com/nosql-161213143036/85/Les-BD-NoSQL-164-320.jpg)
![Neo4j
Neo4j : Exemple (3)
I `A l’aide de la commande START, nous avons indiqué le point de départ de notre pattern, c’est-à-dire de notre instruction.
I Nous avons ensuite créé un nœud et une relation que nous avons nommée AMI.
I Ajoutons encore quelques nœuds :
START Milou = node(1), Tintin = node(2)
CREATE
Haddock = { nom : ’Capitain Haddock’, ville : ’Moulinsart’},
Castafiore = { nom : ’Castafiore’, ville : ’Pesaro’},
Tintin-[r :AMI]->Haddock,
Haddock -[r :AMI]->Castafiore ;
I Les relations, comme les nœuds, sont numérotées. Nous pouvons maintenant appliquer toutes sortes de requêtes pour
traverser l’arbre et chercher les relations.
I Exemple : la requête suivante cherche s’il y a une relation de type AMI entre Milou et la Castafiore :
START Milou=node(1), Castafiore=node(4)
MATCH Milou[r :AMI*]->Castafiore
RETURN r ;
I La requête peut se lire ainsi : pour Milou et la Castafiore, s’il y a une relation de type AMI qui va de Milou à la Castafiore
en passant par un nombre indéfini (*) de relations intermédiaires, retourne-moi cette relation. Le résultat est :
==> +-−-−-−-−-−-−-−-−-−-−-−-−-−-−-−-−-−-−+
==> | r |
==> +-−-−-−-−-−-−-−-−-−-−-−-−-−-−-−-−-−-−+
==> | [ :AMI[2] {}, :AMI[1] {}, :AMI[0] {}] |
==> +-−-−-−-−-−-−-−-−-−-−-−-−-−-−-−-−-−-−+
==> 1 row
==> 4 ms
I Bibliothèques clientes pour différents langages.
I Le client pour Python s’appelle py2neo.
Minyar Sassi Hidri Les BDs NoSQL 165 / 194](https://image.slidesharecdn.com/nosql-161213143036/85/Les-BD-NoSQL-165-320.jpg)
Téléchargé parMinyar Sassi Hidri
Les BD NoSQL
Le document traite des bases de données NoSQL, en expliquant leur émergence face aux limitations des systèmes de gestion de bases de données relationnelles classiques dans le contexte du Big Data. Il présente différents types de bases NoSQL, comme celles orientées clés/valeurs, colonnes, documents et graphes, tout en abordant leurs avantages et inconvénients, ainsi que les principes du théorème de CAP. Enfin, il souligne l'importance de ces bases pour la scalabilité et la gestion de données complexes dans des systèmes distribués.
Les BD NoSQL
- 1. Les bases dedonnées NoSQL par Minyar Sassi Hidri Département Technologies de l’Information et de la Communication Ecole Nationale d’Ingénieurs de Tunis Novembre 2016 Minyar Sassi Hidri Les BDs NoSQL 1 / 194
- 2. Plan 1 Chapitre 1: Big Data et NoSQL 2 Chapitre 2 : MongoDB 3 Chapitre 3 : Cassandra 4 Chapitre 4 : Les autres BDs de la mouvance NoSQL 5 Chapitre 5 : Mise en œuvre d’une base NoSQL Minyar Sassi Hidri Les BDs NoSQL 2 / 194
- 3. Chapitre 1 -Big Data et NoSQL 1 Mouvement NoSQL 2 Taxonomie des bases NoSQL 3 Technologies communément utilisées dans les bases NoSQL 4 Avantages / Inconvénients des bases NoSQL Minyar Sassi Hidri Les BDs NoSQL 3 / 194
- 4. Mouvement NoSQL 1 MouvementNoSQL Nouveaux besoins en gestion de données Limites des systèmes SGBD classiques Racines et concepts fondateurs Caractéristiques générales des BD NoSQL 2 Taxonomie des bases NoSQL BD NoSQL Clé/Valeur (Key/Value Store) BD NoSQL orientées Colonnes BD NoSQL orientées documents BD NoSQL orientées graphes 3 Technologies communément utilisées dans les bases NoSQL Prise en charge de l’extensibilité Partitionnement dans les systèmes NoSQL Compromis sur la Cohérence Consultation de données : MapReduce 4 Avantages / Inconvénients des bases NoSQL Minyar Sassi Hidri Les BDs NoSQL 4 / 194
- 5. Mouvement NoSQL Nouveauxbesoins en gestion de données Nouveaux besoins en gestion de données Système distribué I Système distribué = système logiciel qui permet de coordonner plusieurs or- dinateurs. Généralement, cette coordination se fait par envoi de messages via un réseau auquel sont reliés ces ordinateurs. I Pourquoi ? parce qu’on manipule un très grand volume de données. Sans distribution, on n’a pas d’application scalable. I 2 scénarios de traitement des données : 1. Par distribution des traitements (scaling des traitements) : - On distribue les traitements sur un nombre de machines important afin d’ab- sorber des charges très importantes. - On envoie les données aux endroits appropriés, et on enchaîne les exécutions distantes (scénario type Workflow implémentable avec des Web services). 2. Par distribution des données (scaling des données) : - On distribue les données sur un nombre important de serveurs afin de stocker de très grands volumes de données. - On pousse les programmes vers ces serveurs (plus efficace de transférer un petit programme sur le réseau plutôt qu’un grand volume de données - Ex : algorithme MapReduce). Minyar Sassi Hidri Les BDs NoSQL 5 / 194
- 6. Mouvement NoSQL Nouveauxbesoins en gestion de données Système distribué Exemple : Data Centers I Utilise des LANs (Local Area Networks). On distingue 3 niveaux de communication : 1. Les serveurs sont regroupés en racks. Liaison réseau rapide, environ 1Go/sec. 2. Un data center consiste en un grand nombre de racks, interconnectés par des routeurs (switches). Liaison à 100 Mo/sec. 3. Entre différents data centers, il y a aussi une possibilité de communication mais par liaison assez lente (internet - 2-3 Mo/sec). I Les serveurs communiquent par envoi de messages, ils ne partagent pas de disque ni de ressources de traitement ⇒ Architecture shared nothing. I Début 2010 : 1 data center Google contient entre 100 et 200 racks, chacun contenant 40 serveurs. Environ 5000 serveurs par data-center pour un total de 1 millions de serveurs (estimation d’après la consommation électrique). I Data center de Facebook (2010) : 2500 CPU (serveurs), 1 PetaByte d’espace disque (= milleTerabytes = 1 million de Gigabytes), plus de 250 Gigabytes données compressées (plus de 2 Terabytes non compressés). Minyar Sassi Hidri Les BDs NoSQL 6 / 194
- 7. Mouvement NoSQL Limitesdes systèmes SGBD classiques Limites des systèmes SGBD classiques SGBD Relationnels offrent : I Un système de jointure entre les tables permettant de construire des requêtes complexes impliquant plusieurs entités. I Un système d’intégrité référentielle permettant de s’assurer que les liens entre les entités sont valides. Contexte fortement distribué : Ces mécanismes ont un coût considérable : I Avec la plupart des SGBD relationnels, les données d’une BD liées entre elles sont placées sur le même nœud du serveur. I Si le nombre de liens important, il est de plus en plus difficile de placer les données sur des nœuds différents. Minyar Sassi Hidri Les BDs NoSQL 7 / 194
- 8. Mouvement NoSQL Limitesdes systèmes SGBD classiques Limites des systèmes SGBD classiques I SGBD Relationnels sont généralement transactionnels ⇒ Gestion de tran- sactions respectant les contraintes ACID (Atomicity, Consistency, Isolation, Durability). I Le modèle ACID est un des plus anciens et des plus importants concepts à l’origine des SGBD actuels. Il définit quatre principes que toute BDR doit atteindre : - Atomicité : Tout ou rien. - Cohérence : Les transactions qui modifient l’état de la base font en sorte que les contraintes d’intégrité référentielle sont respectées. - Isolation : Une transaction ne peut pas accéder aux données mise à jour par une autre transaction avant qu’elle ne soit validée par son propriétaire. - Durabilité : Toute transaction validée (commitée) est assurée d’être prise en compte quelque soit la panne (transaction logs permettant de rejouer les modifications en cas de restauration). Minyar Sassi Hidri Les BDs NoSQL 8 / 194
- 9. Mouvement NoSQL Limitesdes systèmes SGBD classiques Limites des systèmes SGBD classiques Constat : I Essor des très grandes plate-formes et applications Web (Google, Facebook, Twitter, LinkedIn, Amazon,...). I Volume considérable de données à gérer par ces applications nécessitant une distribution des données et leur traitement sur de nombreux serveurs. I Ces données sont souvent associées à des objets complexes et hétérogènes. ⇒ Limites des SGBD traditionnels (relationnels et transactionnels) basés sur SQL. ⇒ D’où, nouvelles approches de stockage et de gestion des données : I Permettant une meilleure scalabilité dans des contextes fortement distribués. I Permettant une gestion d’objets complexes et hétérogènes sans avoir à déclarer au préalable l’ensemble des champs représentant un objet. I Regroupées derrière le terme NoSQL (Not Only SQL), proposé par Carl Strozzi, ne se substituant pas aux SGBD Relationnels mais les complètant en comblant leurs faiblesses. Minyar Sassi Hidri Les BDs NoSQL 9 / 194
- 10. Mouvement NoSQL Limitesdes systèmes SGBD classiques Limites des systèmes SGBD classiques I Nécessaire de distribuer les traitements de données entre différents serveurs. I Difficile de maintenir les contraintes ACID à l’échelle du système distribué entier tout en maintenant des performances correctes. ⇒ La plupart des SGBD NoSQL relâchent les contraintes ACID, ou même ne proposent pas de gestion de transactions. I BDs NoSQL : - Ce n’est pas (comme son nom le laisse supposer) NoSQL (pas de SQL). - Privilégier donc NOSQL plutôt que NoSQL. I BDsnon-relationnelles et largement distribuées. I Permet une analyse et une organisation rapides des données de très grands volumes et de types de données disparates. I Appelées également : - Cloud Databases. - Non-Relational Databases. - Big Data Databases... Minyar Sassi Hidri Les BDs NoSQL 10 / 194
- 11. Mouvement NoSQL Racineset concepts fondateurs Genèse du NoSQL I 1988 : Le terme à été inventé par Carlo Strozzi qui présentait le NoSQL comme un modèle de BD plus léger et sans interface SQL. I Juin 2009 - Meetup NoSQL de San Francisco : Le mouvement NoSQL à prit un essor important. Plus de 100 développeurs de logiciels ont assisté à des présentations de solutions telles que Project Voldemort, Cassandra Project, Dynomite, HBase, Hypertable, CouchDB et MongoDB. I 2011 : Un travail de spécification pour un langage de manipulation standar- disé a débuté sous le nom de UnQL (Unstructured Query Language). Il se propose de formaliser la fac¸on dont les bases NoSQL requêtent les collections (équivalent des tables pour les BDR). ⇒ Le NoSQL est issu du travail des grands acteurs d’Internet (Google, Amazon, Facebook, LinkedIn,...) en écho aux nouvelles architectures (Cloud, Grille de calcul, etc.). Minyar Sassi Hidri Les BDs NoSQL 11 / 194
- 12. Mouvement NoSQL Racineset concepts fondateurs Potential des BD NoSQL dans l’entreprise http ://www.pwc.com/us/en/advisory/business-digital-technology-trends-nosql-databases.html Minyar Sassi Hidri Les BDs NoSQL 12 / 194
- 13. Mouvement NoSQL Racineset concepts fondateurs Théorème de CAP (Brewer, 2000) I L’émergence du NoSQL est liée au théorème de CAP (Coherence (Cohérence), Availibility (Disponibilité), Partition-Tolerance (Résistance au morcellement). I Cohérence ou Consistance : Tous les nœuds du système voient exactement les mêmes données au même moment. I Availability ou Disponibilité : L’échec d’un nœud n’empêche pas les survivants de continuer à fonc- tionner. I Partition-tolerance ou Résistance au partitionne- ment : Le système étant partitionné, aucune panne moins importante qu’une coupure totale du réseau ne doit l’empêcher de répondre correctement (en cas de partitionnement en sous-réseaux, chacun doit pouvoir fonctionner de manière autonome). ⇒ Dans un système distribué, il est impossible d’obtenir ces 3 propriétés en même temps, il faut en choisir 2 parmi les 3. Minyar Sassi Hidri Les BDs NoSQL 13 / 194
- 14. Mouvement NoSQL Racineset concepts fondateurs Théorème de CAP I Les SGBDR assurent les propriétés de Consistance et de Disponibilité (Avai- lability) ⇒ Système AC. I Les SGBD NoSQL sont des systèmes CP (Cohérent et Résis- tant au partitionne- ment) ou AP (Dispo- nible et Résistant au partitionnement). Minyar Sassi Hidri Les BDs NoSQL 14 / 194
- 15. Mouvement NoSQL Racineset concepts fondateurs Théorème de CAP Consistance (Coherence) I Exemple 1 : Une instance de la BD est automa- tiquement pleinement consistante puisqu’il n’y a qu’un seul nœud qui maintient l’état. I Exemple 2 : Si 2 serveurs de BD sont impliqués, et si le système est conc¸u de telle sorte que toutes les clés de A à M sont conservées sur le serveur 1, et les clés N à Z sont conservées sur le serveur 2, alors le système peut encore facilement garantir la cohérence. I Exemple 3 : Supposons 2 BD avec des répliques. Si une des BD fait une opération d’insertion de ligne, cette opération doit être aussi faite (commi- ted) dans la seconde BD avant que l’opération soit considérée comme complète. - Pour avoir une cohérence de 100% dans un tel environne- ment répliqué, les nœuds doivent communiquer. - Plus le nombre de répliques est grand plus les performances d’un tel système sont mauvaises. Minyar Sassi Hidri Les BDs NoSQL 15 / 194
- 16. Mouvement NoSQL Racineset concepts fondateurs Théorème de CAP Disponibilité (Availability) Les BD dans Exemple 1 ou Exemple 2 ne sont pas fortement disponibles : I Exemple 1 : Si le nœud tombe en panne, on perd 100% des données. I Exemple 2 : Si le nœud tombe en panne, on perd 50% des données. I Exemple 3 : Une simple réplication de la BD sur un autre serveur assure une disponibilité de 100%. - Augmenter le nombre de nœuds avec des co- pies des données (répliques) augmente direc- tement la disponibilité du système, en le pro- tégeant contre les défaillances matérielles. - Les répliques aident à équilibrer la charge d’opérations concurrences, notamment en lecture. Minyar Sassi Hidri Les BDs NoSQL 16 / 194
- 17. Mouvement NoSQL Racineset concepts fondateurs Théorème de CAP Résistance au partitionnement (Partition-tolerance) I Supposons que soit assuré par réplication consistance et disponibilité, dans le cas de l’exemple 3, supposons 2 serveurs de BD dans 2 Data-Centers différents, et que l’on perde la connexion réseau entre les 2 Data-Centers, faisant que les 2 BD sont incapables de synchroniser leurs états. I Si vous parvenez à gérer les opérations de lecture/écriture sur ces 2 BD, il peut être prouvé que les 2 serveurs ne seront plus consistants. I Une application bancaire gardant à tout moment l’état de votre compte est l’exemple parfait du problème des enregistrements inconsistants : Si un client retire 1000 euros à Marseille, cela doit être immédiatement répercuté à Paris, afin que le système sache exactement combien il peut retirer à tout . Si le système ne parvient pas à le faire, cela pourrait mécontenter de nombreux clients. I Si les banques décident que la consistance est très importante, et désactivent les opérations d’écriture lors de la panne, alors la disponibilité du cluster sera perdu puisque tous les comptes bancaires dans les 2 villes seront désormais gelés jusqu’à ce que le réseau soit de nouveau opérationnel. Minyar Sassi Hidri Les BDs NoSQL 17 / 194
- 18. Mouvement NoSQL Caractéristiquesgénérales des BD NoSQL Caractéristiques générales des BD NoSQL I Adoptent une représentation non relationnelle de données. I Ne remplacent pas les BDR mais sont une alternative, un complémentapportant des solu- tions plus intéressantes dans certains contextes. I Apportent une plus grande performancedans le contexte des applications Web avec des volumétries de données exponentielle. I Utilisent une très forte distributionde ces données et des traitements associés sur de nom- breux serveurs. I Pas de schémapour les données ou schéma dynamique. I Données de structures complexesou imbriquées. I Données distribuées : partitionnement horizontal des données sur plusieurs nœuds (serveurs) généralement par utilisation d’algorithmes MapReduce. I Réplication des donnéessur plusieurs nœuds. I Privilégient la Disponibilité à la Cohérence (théorème de CAP) : AP (Disponible + Résistant au partitionnement) plutôt que CP (Cohérent + Résistant au partitionnement). ⇒ N’ont en général pas de gestion de transactions. I Mode d’utilisation : Peu d’écritures, beaucoup de lectures. Minyar Sassi Hidri Les BDs NoSQL 18 / 194
- 19. Taxonomie des basesNoSQL 1 Mouvement NoSQL Nouveaux besoins en gestion de données Limites des systèmes SGBD classiques Racines et concepts fondateurs Caractéristiques générales des BD NoSQL 2 Taxonomie des bases NoSQL BD NoSQL Clé/Valeur (Key/Value Store) BD NoSQL orientées Colonnes BD NoSQL orientées documents BD NoSQL orientées graphes 3 Technologies communément utilisées dans les bases NoSQL Prise en charge de l’extensibilité Partitionnement dans les systèmes NoSQL Compromis sur la Cohérence Consultation de données : MapReduce 4 Avantages / Inconvénients des bases NoSQL Minyar Sassi Hidri Les BDs NoSQL 19 / 194
- 20. Taxonomie des basesNoSQL Taxonomie des bases NoSQL I Clé/Valeur (Key/value) : basique, chaque objet est identifié par une clé unique constituant la seule manière de le requêter. - Voldemort, Redis, Riak,.... I Orientées colonnes (Column Store) : permet de disposer d’un très grand nombre de valeurs sur une même ligne, de stocker des relations one-to-many, d’effectuer des requêtes par clé (adaptés au stockage de listes : messages, posts, commentaires, ...). - HBase, Cassandra, Hypertable,.... I Orientées documents (Document Databases) : pour la gestion de collections de documents, composés chacun de champs et de valeurs associées, valeurs pouvant être requêtées (adaptées au stockage de profils utilisateur). - MongoDB, CouchDB, Couchbase,.... I Orientées graphes (Graph Databases) : pour gérer des relations multiples entre les objets (adaptés au données issues de réseaux sociaux,...). - Neo4j, OrientDB,.... Minyar Sassi Hidri Les BDs NoSQL 20 / 194
- 21. Taxonomie des basesNoSQL Paysage des SGBD NoSQL Minyar Sassi Hidri Les BDs NoSQL 21 / 194
- 22. Taxonomie des basesNoSQL BD NoSQL Clé/Valeur (Key/Value Store) Key/Value Store I Elles fonctionnent comme un grand tableau associatif et retourne une valeur dont elle ne connaît pas la structure. I Leur modèle peut être assimilé à une table de hachage (hashmap) distribuée. I Les données sont simplement représentées par un couple clé/valeur. I La valeur peut être une simple chaîne de caractères, ou un objet sérialisé. I Cette absence de structure ou de typage ont un impact important sur le requêtage : toute l’intelligence portée auparavant par les requêtes SQL devra être portée par l’applicatif qui interroge la BD. I Implémentations les plus connues : - Amazon Dynamo (Riak en est l’implémentation open source). - Redis (projet sponsorisé par VMWare). - Voldemort (développé par Linkedln en interne puis passage en open source). I Chaque objet est identifié par une clé unique, seule fac¸on de le requêter. Minyar Sassi Hidri Les BDs NoSQL 22 / 194
- 23. Taxonomie des basesNoSQL BD NoSQL Clé/Valeur (Key/Value Store) Key/Value Store I Leur exploitation est basée sur 4 opéra- tions (CRUD) : - Create : créer un nouvel objet avec sa clé : create(key, value). - Read : lit un objet à partir de sa clé : read(key). - Update : met à jour la valeur d’un objet à partir de sa clé : update(key, value). - Delete : supprime un objet à partir de sa clé : delete(key). + Auxquelles on retrouve couram- ment associée la fonction rechercher (Search ou LookUp). I Elles disposent généralement d’une simple interface de requêtage HTTP REST accessible depuis n’importe quel langage de développement. I Ont des performances très élevées en lecture et en écriture et une scalabilité horizontale considérable. I Le besoin en scalabilité verticale est faible du fait de la simplicité des opérations effectuées. Minyar Sassi Hidri Les BDs NoSQL 23 / 194
- 24. Taxonomie des basesNoSQL BD NoSQL Clé/Valeur (Key/Value Store) Key/Value Store Utilisations principales I Dépôt de données avec besoins de requêtage très simples. I Système de stockage de cache ou d’information de sessions distribuées (quand l’intégrité relationnelle des données est non significative). I Les profils, préférences d’utilisateur. I Les données de panier d’achat. I Les données de capteurs. I Les logs de données. I .... Minyar Sassi Hidri Les BDs NoSQL 24 / 194
- 25. Taxonomie des basesNoSQL BD NoSQL Clé/Valeur (Key/Value Store) Key/Value Store Forces et faiblesses Forces : I Modèle de données simple . I Bonne mise à l’échelle horizontale pour les lectures et écritures : - ´Evolutivité (scalable). - Disponibilité. - Pas de maintenances requises lors d’ajout/suppression de colonnes. Faiblesses : I Modèle de données TROP simple : - Pauvre pour les données complexes. - Interrogation seulement sur clé. - Déporte une grande partie de la complexité de l’application sur la couche application elle-même. Minyar Sassi Hidri Les BDs NoSQL 25 / 194
- 26. Taxonomie des basesNoSQL BD NoSQL orientées Colonnes BD NoSQL orientées Colonnes I Les données sont stockées par colonne, non par ligne. I On peut facilement ajouter des colonnes aux tables, par contre l’insertion d’une ligne est plus coûteuse. I Quand les données d’une colonne se ressemblent, on peut facilement compresser la colonne. I Modèle proche d’une table dans un SGBDR mais ici le nombre de colonnes : - est dynamique. - peut varier d’un enregistrement à un autre ce qui évite de retrouver des colonnes ayant des valeurs NULL. I Implémentations les plus connues : - HBase (Open Source de BigTable de Google utilisé pour l’indexation des pages Web, Google Earth, Google analytics, ...). - Cassandra (fondation Apache qui respecte l’architecture distribuée de Dynamo d’Amazon, projet né de chez Facebook). - SimpleDB de Amazon. Minyar Sassi Hidri Les BDs NoSQL 26 / 194
- 27. Taxonomie des basesNoSQL BD NoSQL orientées Colonnes BD NoSQL orientées Colonnes Principaux concepts associés aux BD NoSQL orientées colonnes I Colonne : - Objet de plus bas niveau, il est composé d’une clé (le nom de la colonne), d’une valeur et d’un timestamp. Les timestamps des colonnes sont utilisés pour résoudre les conflits entre plusieurs nœuds de l’infrastructure, pour savoir si un nœud à une version plus récente. Il est donc important que tous les nœuds de l’infrastructure soient synchronisés sur la même horloge. - Une colonne contenant d’autres colonnes est nommée super-colonne. I Super-colonnes : - Situées dans les familles de colonnes. Elle représente une colonne dont les valeurs sont d’autres colonnes. - Si on veut faire le parallèle avec une base SQL cela représente une ligne. On retrouve cette correspondance clé-valeur, la clé permet d’identifier la super-colonne tandis que la valeur est la liste des colonnes qui la compose. I Famille de colonnes : - Permettent de regrouper plusieurs colonnes (ou super-colonnes). - Les colonnes sont regroupées par ligne. - Chaque ligne est identifiée par un identifiant unique (assimilées aux tables dans le modèle relationnel) et sont identifiées par un nom unique. - Les familles de colonnes sont ce qui ressemble le plus aux tables en SQL. http ://www-igm.univ-mlv.fr/ dr/XPOSE2010/Cassandra/modele.html Minyar Sassi Hidri Les BDs NoSQL 27 / 194
- 28. Taxonomie des basesNoSQL BD NoSQL orientées Colonnes Colonne / Super-Colonne/Famille de Colonnes Minyar Sassi Hidri Les BDs NoSQL 28 / 194
- 29. Taxonomie des basesNoSQL BD NoSQL orientées Colonnes BD NoSQL orientées Colonnes Minyar Sassi Hidri Les BDs NoSQL 29 / 194
- 30. Taxonomie des basesNoSQL BD NoSQL orientées Colonnes BD NoSQL orientées Colonnes I Elles sont les plus complexes à appréhender des BD NoSQL, même si au final on a un schéma assez proche des bases documentaires. I Elles sont très utilisées pour les traitements d’analyse de données et dans les traitements massifs (notamment via des opérations de type MapReduce). I Elles offrent plus de flexibilité que les BDR : - il est possible d’ajouter une colonne ou - une super colonne - `a n’importe quelle ligne - d’une famille de colonnes, colonnes ou super-colonne à tout instant. Minyar Sassi Hidri Les BDs NoSQL 30 / 194
- 31. Taxonomie des basesNoSQL BD NoSQL orientées Colonnes BD NoSQL orienté Colonnes Forces et faiblesses des BD NoSQL orientées Colonnes Forces : I Modèle de données supportant des données semi-structurées. I Naturellement indexé (colonnes). I Bonne mise à l’échelle à l’horizontale. I MapReduce souvent utilisé en scaling horizontal. Faiblesses : I Modèle de données TROP simple : `a éviter pour des données interconnectés : si les relations entre les données sont aussi importantes que les données elles- mêmes (comme la distance ou calculs de la trajectoire). I `A éviter pour les lectures de données complexes. I Exige de la maintenance - lors de l’ajout / suppression de colonnes et leur regroupements. Minyar Sassi Hidri Les BDs NoSQL 31 / 194
- 32. Taxonomie des basesNoSQL BD NoSQL orientées Colonnes BD NoSQL orientées colonnes Utilisations principales des BD NoSQL orientées colonnes Les BD NoSQL orientées colonnes sont principalement utilisées pour : I Netflix l’utilise notamment pour le logging et l’analyse de sa clientèle. I Ebay l’utilise pour l’optimisation de la recherche. I Adobe l’utilise pour le traitement des données structurées et de Business Intelligence (BI). I Des sociétés de TV l’utilisent pour cerner leur audience et gérer le vote des spectateurs (nombre élevé d’écritures rapides et analyse de base en temps réel (Cassandra). I Peuvent être de bons magasins d’analyse des données semi-structurées. Minyar Sassi Hidri Les BDs NoSQL 32 / 194
- 33. Taxonomie des basesNoSQL BD NoSQL orientées documents BD NoSQL orientées documents I Elles stockent une collection de do- cuments. I Elles sont basées sur le modèle clé/valeur mais la valeur est un document en format semi-structuré hiérarchique de type JSON (JavaS- cript Object Notation) ou XML. I Les documents n’ont pas de schéma, mais une structure arborescente : ils contiennent une liste de champs, un champ a une valeur qui peut être une liste de champs, ... I Elles ont généralement une interface d’accès HTTP REST permettant d’effec- tuer des requêtes (plus complexe que l’interface CRUD des BD clés/valeurs). I Implémentations les plus connues : - MongoDB. - CouchDB (fondation Apache). - RavenDB (pour plate-formes .NET/Windows - LINQ), .... Minyar Sassi Hidri Les BDs NoSQL 33 / 194
- 34. Taxonomie des basesNoSQL BD NoSQL orientées documents BD NoSQL orientées documents I Un document est composé de champs et des valeurs associées. I Ces valeurs : - peuvent être requêtées. - sont soit d’un type simple (entier, chaîne de caractères, date, ...) - soit elles-mêmes composées de plusieurs couples clé/valeur. I Bien que les documents soient structurés, ces BD sont dites schemaless : il n’est pas nécessaire de définir au préalable les champs utilisés dans un document. I Les documents peuvent être très hétérogènes au sein de la BD. I Permettent d’effectuer des requêtes sur le contenu des documents/objets : pas possible avec les BD clés/valeurs simples. I Elles sont principalement utilisées dans le développement de CMS (Content Management System - outils de gestion de contenus). Minyar Sassi Hidri Les BDs NoSQL 34 / 194
- 35. Taxonomie des basesNoSQL BD NoSQL orientées documents BD NoSQL orientées documents Minyar Sassi Hidri Les BDs NoSQL 35 / 194
- 36. Taxonomie des basesNoSQL BD NoSQL orientées documents BD NoSQL orientées documents http ://www.stechfrites.com/book/export/html/2 http ://changeaas.com/2014/09/14/nosql-databases-2/ Minyar Sassi Hidri Les BDs NoSQL 36 / 194
- 37. Taxonomie des basesNoSQL BD NoSQL orientées documents BD NoSQL orientées documents Avantages du format JSON : I Format abstrait pour une représentation simplifiée dans les différents langages. I Indépendant du langage de programmation. I Simple et complet pour la représentation des objets. I Utilise des types de données connus et simples à décrire. I Une bonne lisibilité de la syntaxe. I Temps de traitement très proche de celui des fichiers XML. I Moins volumineux en terme de stockage. I Pour JavaScript, un document JSON représente un objet. Utilisations principales des BD NoSQL orientées Documents : I Enregistrement d’événements. I Systèmes de gestion de contenu. I Web analytique ou analytique temps-réel. I Catalogue de produits. I Systèmes d’exploitation... Minyar Sassi Hidri Les BDs NoSQL 37 / 194
- 38. Taxonomie des basesNoSQL BD NoSQL orientées documents BD NoSQL orientées documents Forces et faiblesses des BD NoSQL orientées Documents Forces : I Modèle de données simple mais puissant (expressions de structures imbri- quées). I Bonne mise à l’échelle. I Pas de maintenance de la BD requise pour ajouter/supprimer des colonnes. I Forte expressivité de requêtage (requêtes assez complexes sur des structures imbriquées). Faiblesses : I Inadaptée pour les données interconnectées. I Modèle de requête limitée à des clés (et indexes). I Peut alors être lent pour les grandes requêtes (avec MapReduce). Minyar Sassi Hidri Les BDs NoSQL 38 / 194
- 39. Taxonomie des basesNoSQL BD NoSQL orientées graphes BD NoSQL orientées graphes I Elles permettent la modélisation, le stockage et la manipulation de données complexes liées par des relations non-triviales ou variables. I Modèle de représentation des données basé sur la théorie des graphes. I S’appuie sur les notions de nœuds, de relations et de propriétés qui leur sont rattachées. I Implémentations les plus connues : - Neo4J. - OrientDB (fondation Apache), ... I Elles utilisent : - Un moteur de stockage pour les objets (similaire à une base documentaire, chaque entité de cette base étant nommée nœud). - Un mécanisme de description d’arcs (relations entre les objets), arcs orientés et avec propriétés (nom, date, ...) I Elles sont bien plus efficaces que les BDR pour traiter les problématiques liées aux réseaux (cartographie, relations entre personnes, ...). I Sont adaptées à la manipulation d’objets complexes organisés en réseaux : cartographie, réseaux sociaux,... Minyar Sassi Hidri Les BDs NoSQL 39 / 194
- 40. Taxonomie des basesNoSQL BD NoSQL orientées graphes BD NoSQL orientées graphes Minyar Sassi Hidri Les BDs NoSQL 40 / 194
- 41. Taxonomie des basesNoSQL BD NoSQL orientées graphes Exemples Minyar Sassi Hidri Les BDs NoSQL 41 / 194
- 42. Taxonomie des basesNoSQL BD NoSQL orientées graphes BD NoSQL orientées graphes Forces et faiblesses des BD NoSQL orientées graphes Forces : I Modèle de données puissant. I Rapide pour les données liées, bien plus rapide que SGBDR. I Modèles d’interrogation bien établis et performants : Tinkerpop pile (fournit un ensemble commun d’interfaces permettant aux différentes technologies informatiques graphiques de travailler ensemble, que le développeur utilise en cas de besoin), SparQL et Cypher. Faiblesses : I Fragmentation (sharding) : - Même si elles peuvent évoluer assez bien. - Pour certains domaines, on peut aussi fractionner. Minyar Sassi Hidri Les BDs NoSQL 42 / 194
- 43. Taxonomie des basesNoSQL BD NoSQL orientées graphes BD NoSQL orientées Graphes Utilisations principales des BD NoSQL orientées graphes Les BD NoSQL type orientées graphes sont principalement utilisées pour : I Moteurs de recommandation. I Business Intelligence (BI). I Semantic Web. I Social computing. I Données géospatiales. I Généalogie. I Web of things. I Catalogue des produits. I Sciences de la Vie et calcul scientifique (bio-informatique). I Données liées, données hiérarchiques. I Services de routage, d’expédition et de géolocalisation. I Services financiers : chaîne de financement, dépendances, gestion des risques, détection des fraudes,... Minyar Sassi Hidri Les BDs NoSQL 43 / 194
- 44. Technologies communément utiliséesdans les bases NoSQL 1 Mouvement NoSQL Nouveaux besoins en gestion de données Limites des systèmes SGBD classiques Racines et concepts fondateurs Caractéristiques générales des BD NoSQL 2 Taxonomie des bases NoSQL BD NoSQL Clé/Valeur (Key/Value Store) BD NoSQL orientées Colonnes BD NoSQL orientées documents BD NoSQL orientées graphes 3 Technologies communément utilisées dans les bases NoSQL Prise en charge de l’extensibilité Partitionnement dans les systèmes NoSQL Compromis sur la Cohérence Consultation de données : MapReduce 4 Avantages / Inconvénients des bases NoSQL Minyar Sassi Hidri Les BDs NoSQL 44 / 194
- 45. Technologies communément utiliséesdans les bases NoSQL Prise en charge de l’extensibilité Prise en charge de l’extensibilité Il existe plusieurs fac¸ons de mettre en œuvre l’extensibilité : I Par réplication, on duplique sur plusieurs nœuds les données. Deux modes : - Maitre-Esclave : le maître rec¸oit les requêtes en écriture et réplique les modifications sur les esclaves. Les esclaves servent les requêtes en lecture. Ce mode est limité par la capacité du Maître à traiter les requêtes en écriture. - Maître-Maître : tous les nœuds servent à la fois en lecture et en écriture et contiennent une copie des données. Il se pose alors les problèmes de gestion de la concurrence et de la cohérence. I Sharding ou distribution de données : décrit un ensemble de techniques qui permet de répartir les données sur plusieurs machines pour assurer la scalabilité de l’architecture. I 2 fac¸ons de partitionner (sharder) la donnée : verticalement ou horizontalement : - Le partitionnement vertical est le plus communément utilisé : il s’agit d’isoler, de séparer des concepts métier. Par exemple, on décidera de stocker les clients sur une base et leur contrat sur une autre. - La notion de partitionnement horizontal renvoie à l’idée de répartir l’ensemble des enregistrements d’une table (au sens d’une BD) sur plusieurs machines. Ainsi, on choisira par exemple de stocker les clients de A à M sur une machine #1 et les clients de N à Z sur une autre machine #2. Le sharding horizontal nécessite une clé de répartition - la première lettre du nom dans l’exemple. Minyar Sassi Hidri Les BDs NoSQL 45 / 194
- 46. Technologies communément utiliséesdans les bases NoSQL Partitionnement dans les systèmes NoSQL Distribution de données : Sharding I Les données peuvent être aussi partitionnées afin que : - Les données accédées ou mises à jour en même temps, résident sur le même nœud. - La charge soit uniformément répartie entre les nœuds. I Tables distribuées par partitionnement simple : Pour pallier à la problématique de montée en charge et en volume, une solution simple est de partitionner la table, divisant ainsi le volume et la charge entre toutes les instances. - Cette approche simple peut entraîner une répartition inégale des données entre les instances, il a donc été nécessaire de trouver des solutions pour palier à ce problème de déséquilibre. I Sharding : Mécanisme de partitionnement des données dans lequel les données sont stockées sur des nœuds serveurs différents en fonction d’une clé (ex : fonction de hachage) : - L’accès à une clé se fait en transformant à l’aide d’une fonction la clé en une valeur de hachage. La table des clés est répartie sur des nœuds et la fonction de hachage permet de répartir les clés sur les différents nœuds puis ensuite de retrouver le nœud sur lequel se trouve une clé. Minyar Sassi Hidri Les BDs NoSQL 46 / 194
- 47. Technologies communément utiliséesdans les bases NoSQL Partitionnement dans les systèmes NoSQL Distribution de données : Consistent hashing I Consistent hashing : Mécanisme de partitionnement (horizontal) dans lequel les objet-données sont stockés sur des nœuds-serveurs différents en utilisant la même fonction de hachage à la fois pour le hachage des objets et le hachage des nœuds : Nœuds et objets sont associés par une même fonc- tion de hachage, et imaginés être placés sur un anneau (rack/cluster de serveurs) Exemple : A, B, C sont des nœuds (serveurs) et 1, 2, 3, 4 sont des objets. Un objet est associé au premier nœud serveur dans le sens horaire : Exemple : Les objets 4 et 1 sont associés au œud A. 2 à B. 3 à C. D’après Strauch. Minyar Sassi Hidri Les BDs NoSQL 47 / 194
- 48. Technologies communément utiliséesdans les bases NoSQL Partitionnement dans les systèmes NoSQL Distribution de données : Consistent hashing Quand un nœud quitte l’anneau, les données qui lui sont liées sont alors associées à leur nœud adjacent dans le sens horaire : Exemple : Le nœud C quitte l’anneau, 3 est alors associé avec 4 et 1 au nœud A. Quand un nœud entre dans l’anneau, il est placé (haché) sur l’anneau et des données lui seront as- sociées selon sa place dans l’anneau : Exemple : Le nœud D entre dans l’anneau, les données 3 et 4 lui sont associées. D’après Strauch. Minyar Sassi Hidri Les BDs NoSQL 48 / 194
- 49. Technologies communément utiliséesdans les bases NoSQL Partitionnement dans les systèmes NoSQL Tolérance au partitionnement (1) I Protocole de communication Gossip : Le protocole Gossip (commérage) est un protocole de communication inspiré par la manière dont les commérages ou rumeurs sont propagées à travers un réseau sociale ou dans la vie réelle. Le protocole Gossip implique des interactions périodiques par paire de nœuds. I De manière périodique, chaque nœud envoi à un autre nœud (choisi de manière aléatoire) un message. Ce message contient son état. Le nœud qui rec¸oit le message envoi un accusé de réception et éventuellement une information sur un autre nœud que celui-ci n’arrive pas à joindre (pas rec¸u d’accusé de réception). I Avant de considérer qu’un autre nœud est réellement indisponible, un mécanisme de quorum peut être mise en œuvre pour évaluer la rumeur (Cassandra implémente ce mode de communication). Minyar Sassi Hidri Les BDs NoSQL 49 / 194
- 50. Technologies communément utiliséesdans les bases NoSQL Partitionnement dans les systèmes NoSQL Tolérance au partitionnement (2) I Hinted Handoff : - Lors d’une écriture, si un nœud contenant un répliqua de la ligne est connu pour être indisponible (par exemple à travers le protocole Gossip), le système écrira la donnée sur un autre nœud contenant un répliqua en indiquant que l’écriture devra être rejouée plus tard sur le nœud indisponible. - Si tous les nœuds contenant un répliqua sont indisponibles, un nœud de coordination va prendre en charge l’écriture (alors que normalement il ne doit contenir cette donnée). - Une fois qu’un nœud découvre qu’un autre nœud pour lequel il détient une écriture en instance est à nouveau disponible (par exemple à travers le protocole Gossip), il lui renvoi la ligne de données correspondante. ⇒ On améliore fortement la tolérance au partitionnement et la disponi- bilité en écriture mais on augmente le risque d’incohérence . Minyar Sassi Hidri Les BDs NoSQL 50 / 194
- 51. Technologies communément utiliséesdans les bases NoSQL Compromis sur la Cohérence Evaluation du niveau de cohérence Soient : I N : le nombre de nœuds qui contiennent une copie des données. I W : quorum en écriture, c’est le nombre de copies qui doivent accuser réception d’une mise à jour avant qu’une mise à jour soit considérer comme complète (fin de la transaction). I R : quorum en lecture, c’est le nombre de copies qui doivent être consultés lorsqu’une donnée est accédée lors d’une lecture. Alors : I Si W +R > N alors on a une cohérence Forte. Il y a toujours chevauchement entre les nœuds sur lesquels on écrit et ceux sur lesquels on lit (lors de la lecture, au moins un des nœuds aura toujours la dernière version de la valeur). I Si W + R <= N alors on a une cohérence éventuelle. Minyar Sassi Hidri Les BDs NoSQL 51 / 194
- 52. Technologies communément utiliséesdans les bases NoSQL Compromis sur la Cohérence ´Evaluation du niveau de cohérence Cas particuliers : I Si R = N et W = N, c’est le cas extrême, dans ce cas R + W = 2N, le système garantie une cohérence forte (tous les nœuds disposent de la même version), et il peut alors fournir une garantie ACID. I Si R = 1 et W = N, la cohérence est forte. On peut le mettre en place dans le cas où on a un beaucoup plus grand volume en lecture qu’en écriture, la charge en lecture n’est traitée que par un nœud alors que l’écriture nécessite tous les nœuds. Mais si un des nœuds est indisponible ou injoignable, alors tout le système devient indisponible en écriture. I Si R = N et W = 1, c’est le cas inverse, mais les risques d’incohérence sont forts. Avec un R = N, on s’assure d’au moins lire sur le nœud qui a la dernière version. Cependant si un nœud est indisponible ou injoignable, la lecture n’est plus possible. I Si R = W alors R = W = (N + 1)/2, on a quorum suffisant pour garantir une cohérence éventuelle. Minyar Sassi Hidri Les BDs NoSQL 52 / 194
- 53. Technologies communément utiliséesdans les bases NoSQL Compromis sur la Cohérence Gestion de la concurrence Contrôle de concurrence Multi-Version (MVCC) I Méthode de contrôle de concurrence couramment utilisée par les SGBD pour gérer des accès simultanés à la base de données avec mises à jour. I Dans une BD NoSQL, la gestion des mises à jour est faite : - Non pas en supprimant une fraction contenant les données avant mo- dification et en la remplac¸ant par une fraction contenant les données modifiées. - Mais en marquant les anciennes données comme obsolètes et en ajoutant une nouvelle version contenant les nouvelles données. - Il existe ainsi plusieurs versions enregistrées, une seule est la plus récente. I Nécessite généralement un balayage périodique pour supprimer les don- nées obsolètes. Minyar Sassi Hidri Les BDs NoSQL 53 / 194
- 54. Technologies communément utiliséesdans les bases NoSQL Compromis sur la Cohérence Gestion de la cohérence Horloges Vectorielle (Vector Clocks) I Les ensembles de données répartis sur nœuds peuvent être lus et modifiés sur chaque nœud et aucune cohérence stricte est assurée par des protocoles de transactions distribuées. Problème : Comment faire des modifications concurrentes ? I Une solution : les horloges vectorielles : I Un vecteur d’horloge est défini comme un n-uplet V [0], V [1], ..., V[n] des valeurs d’horloge à partir de chaque nœud. I À tout instant le nœud i maintient un vec- teur d’horloge représentant son état et ce- lui des autres nœuds répliques : (Vi [0] = valeur de l’horloge du premier nœud, Vi [1] = valeur de l’horloge du deuxième nœud, ... Vi [i] = sa propre valeur d’horloge, ... Vi [n] = valeur de l’horloge du dernier nœud). I Les valeurs d’horloge peuvent être de réelles timestamps dérivées d’une hor- loge locale de nœud, du numéro de ver- sion/révision, etc. Minyar Sassi Hidri Les BDs NoSQL 54 / 194
- 55. Technologies communément utiliséesdans les bases NoSQL Consultation de données : MapReduce MapReduce I Appliqué à la BD, MapReduce traite un ensemble de clés en appliquant les fonctions Map et Reduce aux nœuds de stockage qui appliquent localement la fonction Map aux clés qui doivent être traitées et qu’ils possèdent. I Les résultats intermédiaires peuvent être hachés comme des données ordinaires et traitées par les nœuds suivants dans le sens horaire, qui appliquent la fonction Reduce aux résultats intermédiaires et produisent les résultats finaux. I Du fait du hachage des résultats intermédiaires, aucun coordinateur est utilisé pour diriger les nœuds de traitement vers ces résultats. Minyar Sassi Hidri Les BDs NoSQL 55 / 194
- 56. Avantages / Inconvénientsdes bases NoSQL 1 Mouvement NoSQL Nouveaux besoins en gestion de données Limites des systèmes SGBD classiques Racines et concepts fondateurs Caractéristiques générales des BD NoSQL 2 Taxonomie des bases NoSQL BD NoSQL Clé/Valeur (Key/Value Store) BD NoSQL orientées Colonnes BD NoSQL orientées documents BD NoSQL orientées graphes 3 Technologies communément utilisées dans les bases NoSQL Prise en charge de l’extensibilité Partitionnement dans les systèmes NoSQL Compromis sur la Cohérence Consultation de données : MapReduce 4 Avantages / Inconvénients des bases NoSQL Minyar Sassi Hidri Les BDs NoSQL 56 / 194
- 57. Avantages / Inconvénientsdes bases NoSQL Avantages Avantages I Leurs performances ne s’écroulent jamais quel que soit le volume traité. Leur temps de réponse est proportionnel au volume. I Elles se migrent facilement. En effet, contrairement aux SGBDR classiques, il n’est pas nécessaire de procéder à une interruption de service pour effectuer le déploiement d’une fonctionnalité impactant les modèle de données. I Sharding automatique : Aussi appelé élasticité, une base NoSQL peut se ré- partir sur plusieurs serveurs sans l’aide de l’application. De plus des serveurs peuvent être ajoutés ou retirés à la volée. I Elles sont consistantes de manière pratique (pour l’utilisateur, une requête aura toujours la même réponse quel que soit le nœud du cluster). I Elles s’intègrent facilement aux SI déployés dans les Clouds du marché. I Les schémas de la base ne sont pas figés : les données sont dorénavant bien plus flexibles car la structure et le type des données peuvent changer à tout moment sans forcément impacter l’application. Minyar Sassi Hidri Les BDs NoSQL 57 / 194
- 58. Avantages / Inconvénientsdes bases NoSQL Inconvénients Inconvénients I `A première vue, le principal désavantage du NoSQL est sa jeunesse. I Les outils de supervision ne sont pas très développés pour le moment et cela peut constituer un frein à une mise en production sur des applications critiques. I Le NoSQL a aussi une image de système à déployer uniquement sur des appli- cations nécessitant d’être très performante et travaillant sur de gros volumes que seules de grosses compagnies peuvent s’offrir. Minyar Sassi Hidri Les BDs NoSQL 58 / 194
- 59. Chapitre 2 -MongoDB 1 Structure de données 2 L’invite interactive de MongoDB 3 Réplication dans MongoDB 4 Le sharding dans MongoDB 5 Programmation client 6 MongoDB et MapReduce Minyar Sassi Hidri Les BDs NoSQL 59 / 194
- 60. Structure de données 1Structure de données 2 L’invite interactive de MongoDB 3 Réplication dans MongoDB 4 Le sharding dans MongoDB 5 Programmation client 6 MongoDB et MapReduce Minyar Sassi Hidri Les BDs NoSQL 60 / 194
- 61. Structure de donnéesCaractéristiques Caractéristiques I ´Ecrit en C++. I Orienté documents à schéma flexible et distribuable. I Interprète les requêtes Javascript (coté serveur). I Distribué sous licence AGPL (Licence publique générale Affero). I Une table vide occupe environs 200Mo. I La taille maximale d’un objet est 4Mo. Pour pouvoir stocker les objets volumineux MongoDB implémente son propre système de découpage GridFS). ⇒ Il est utilisé dans le cas où on recherche des performances élevées sur des bases de grande taille. http ://www.mongodb.org/ http ://www.php.net/manual/en/class.mongo.php Minyar Sassi Hidri Les BDs NoSQL 61 / 194
- 62. Structure de donnéesCaractéristiques Structure de données I Données représentées dans un schéma flexible. I Données stockées sous forme de documents (paires clé/valeur) JSON-like (un format de données textuel dérivé de la syntaxe d’expression des objets en JavaScript). I Pour l’utilisateur, la structure visible est du JSON. I Ce document sera stocké par MongoDB dans un format plus compact, plus pratique pour le stockage et les traitements, le BSON (Binary JSON) : repré- sentation binaire sérialisées d’une document JSON. I Les documents sont contenus dans des collections, qui correspondent plus ou moins aux tables des SGBDR. I Les documents d’une même collection ont une structure similaire (homogé- néité). I Les collections peuvent être regroupées dans des espaces de noms, et sont stockées dans des BDs (databases). Un espace de noms est simplement un préfixe ajouté aux collections (et séparé de celles-ci par un point), qui permet de les regrouper, un peu comme le concept de schémas de la norme SQL. I Une BD peut être considérée comme une collection de collections. Minyar Sassi Hidri Les BDs NoSQL 62 / 194
- 63. Structure de donnéesCaractéristiques Définition d’un schéma de données avec MongoDB Les documents I Un document c’est quoi ? - ´Equivalent d’un enregistrement (tuple) en relationnel. - Trois modes d’insertion : - En utilisant la commande db.<nom collection>.insert() du schell. - En utilisant la commande db.<nom collection>.save () du schell. - En utilisant un driver : PHP, Ruby, Java et Python. - Chaque document crée contient le champ id : - Sa valeur peut être fournie ou générée automatiquement. - Type primary key. - Indexé. - Structure de données JSON-like, composée de paires clef/valeur. - Stocké sur le disque sous forme de document BSON. - Supporte plus de types de données que JSON. - La partie valeur peut avoir n’importe quel type supporté par BSON, dont d’autres documents, des tableaux, et des tableaux de documents. Minyar Sassi Hidri Les BDs NoSQL 63 / 194
- 64. Structure de donnéesCaractéristiques Définition d’un schéma de données avec MongoDB Les documents Minyar Sassi Hidri Les BDs NoSQL 64 / 194
- 65. Structure de donnéesCaractéristiques Définition d’un schéma de données avec MongoDB Les documents I Le champ id - Seul champ obligatoire, utilisé comme clé primaire dans une collection. De type nommé ObjectId, d’une taille de 96 octets. Sa valeur est créée par un algorithme qui garantit une très faible probabilité de collision. I Les champs indexés ont une taille limite (1Mo). I Les noms des champs ne peuvent pas commencer par un $, contenir le caractère <<.>> ou le caractère <<null>>. I Limites : - Taille max d’un document : 16Mo - Utilisation de l’API GridFS pour stocker des documents plus larges que la taille autorisée. - GridFS permet de diviser les documents en chunks de même taille, et les stockent sous forme de documents séparés. - Les métadonnées des fichiers sont conservées dans une autre collection, nom- mée files. - MongoDB préserve l’ordre des champs du document, comme défini à leur création, sauf : - Que le champs id doit toujours figurer en premier. - Les opérations de update qui incluent le renommage d’un champs peut entraîner le changement de l’ordre des champs dans le document. Minyar Sassi Hidri Les BDs NoSQL 65 / 194
- 66. Structure de donnéesCaractéristiques Définition d’un schéma de données avec MongoDB Structure de documents I Deux manières des relations entre les données : références et données Imbriquées. I Références : - Inclusion de liens ou références d’un docu- ment à un autre. - C’est à l’application de résoudre ces réfé- rences pour accéder aux données associées. - On dit qu’on utilise des Modèles de Données Normalisés. I Données Imbriquées (Embedded Data) : - Sauvegarde des données associées dans la même structure de documents. - Il est possible d’inclure des documents dans un champ ou un tableau. - Permet aux applications d’extraire et mani- puler plusieurs niveaux de hiérarchie en une seule instruction. - Ce sont les Modèles de Données Dénormali- sés. Minyar Sassi Hidri Les BDs NoSQL 66 / 194
- 67. Structure de donnéesCaractéristiques Définition d’un schéma de données avec MongoDB Structure de documents I Comment choisir entre références et données imbriquées ? I On choisit les références quand : - L’imbrication va produire des données dupliquées sans grands avantages en terme de performance de lecture. - On veut représenter des relations many-to-many complexes. - On veut modéliser de larges ensembles de données hiérarchiques. I On choisit les données imbriquées quand : - On a des relations contains entre les éléments (modèles one-to-one). Exemple : personne et adresse. - On a des relations one-to-many, où les documents fils (many) apparaissent toujours dans le contexte des documents parents (one). Exemple : personne et plusieurs emails. Minyar Sassi Hidri Les BDs NoSQL 67 / 194
- 68. L’invite interactive deMongoDB 1 Structure de données 2 L’invite interactive de MongoDB 3 Réplication dans MongoDB 4 Le sharding dans MongoDB 5 Programmation client 6 MongoDB et MapReduce Minyar Sassi Hidri Les BDs NoSQL 68 / 194
- 69. L’invite interactive deMongoDB Installation Instance MongoDB I Installation : https ://docs.mongodb.com/manual/installation/ I Caractéristiques d’une instance MongoDB : - Un port d’écoute (par défaut 27017). - Un processus serveur. - Un répertoire racine de stockage. - Un fichier de log. - Un fichier de configuration : mongod.conf. I Les outils et commandes MongoDB : mongod : le moteur de base. - mongo : le shell Javascript. - mongos : le contrôleur de Sharding (partitionnement). - Les outils d’import/export : mongoimport, mongoexport, mongodump, mongores- tore, bsondump. - mongofiles : l’utilitaire GridFS. - mongostat : visualisation des stats d’une instance mongoDB. - mongosniff : le tcpdump de mongo. Minyar Sassi Hidri Les BDs NoSQL 69 / 194
- 70. L’invite interactive deMongoDB Création de la base et mise en œuvre du schéma Les bases de données (1) I La distribution de MongoDB inclue un outil en ligne de commande (MongoDB interactive shell). Cet utilitaire permet d’envoyer des commandes au serveur à partir de la ligne de la commande. Il permet aussi d’exécuter des fichiers JavaScript pour exécuter des scripts d’administration. Ce shell permet de : - Consulter le contenu de la base. - Tester des requêtes de consultation. - Créer des indexes. - Exécuter des scripts de maintenance. - Administrer la base. I Affichage de la base en cours : > db I Affichage de la liste des bases : > show dbs I Mongo créé par défaut deux bases : - local : une base qui a la particularité de n’être jamais dupliqué et qui peut servir à stocker des documents qui n’ont d’utilité que sur une machine. - test : base vide sans particularité. - Il peut aussi contenir une base admin permettant à ses utilisateurs d’utiliser des commandes d’administration (comme l’arrêt du serveur) qui ne sont pas disponibles avec les autres bases et config qui est utilisée en mode partitionnement pour stocker des informations sur les nœuds. Minyar Sassi Hidri Les BDs NoSQL 70 / 194
- 71. L’invite interactive deMongoDB Création de la base et mise en œuvre du schéma Les bases de données (2) I Création / Suppression - Démarrage de l’outil en ligne de commande : mongo - Création de bases de données : >use <db name> - Suppression de bases de données : > use <db name> ; > db.runCommand({dropDatabase : 1}) ; > db.dropDatabase() ; I Pour chaque base : - Initialisation de deux fichiers <db name>.0 et <db name>.1 - La taille de chaque fichier est le double de la taille du précédent (64, 128, 256, etc.). - Taille maximale d’un fichier = 2Gb. - Le fichier <nom fichier>.ns stocke les namespaces de la base (16 Mb par défaut, modifiable via l’option -nssize, avec pour taille maximale 2Gb). I Il est possible d’exécuter des commandes écrites dans un fichier au moyen de la fonction load : load( test.js ) Minyar Sassi Hidri Les BDs NoSQL 71 / 194
- 72. L’invite interactive deMongoDB Définition d’un schéma de données avec MongoDB Définition d’un schéma de données avec MongoDB Les collections I Un schéma de données orienté documents possède deux éléments de base : Documents et collections. I Une collection c’est quoi ? - ´Equivalent de la table en relationnel. Deux modes de création. - Automatiquement lors d’une insertion de document (tuple). - En exécutant la commande db.createCollection(”<nom collection>”). I Les opérations sur les collections : - Créer : - > db.createCollection(’gens’). - Supprimer : - >db.collection.drop(). - Lister : - > show collections. - > db.getCollections(). - Insérer un document : - > show collections. - > db.<collection name>.insert({var1 : ”valeur”, var2 : ”valeur”, var3 : ”valeur”,}) ; - Supprimer : - > db.<nom collection>.drop() ; Minyar Sassi Hidri Les BDs NoSQL 72 / 194
- 73. L’invite interactive deMongoDB Définition d’un schéma de données avec MongoDB Définition d’un schéma de données avec MongoDB - Lister les bases créées > show dbs - Création de la base > use bibliotheque > show collections - Création des collections > db.createCollection(”livres”); > db.createCollection(”Editeurs”); > show collections - Renommer une Collection > db.Editeurs.renameCollection(”editeurs”); > show collections - Exemple complet : https ://docs.mongodb.org/ Minyar Sassi Hidri Les BDs NoSQL 73 / 194
- 74. L’invite interactive deMongoDB Lecture/´Ecriture Insertion de documents I Pour insérer un document dans une collection (que la collection existe ou non) : >db.collection.insert(document) >db.collection.insert(documents) - document est un tableau clefs / valeurs. - documents est une liste de tableaux clefs / valeurs. - collection est le nom de la collection à laquelle on souhaite ajouter le(s) document(s). Si la collection n’existait pas au préalable, elle est créée (c’est de cette manière qu’on crée les collections). >db.etudiants.insert({’prenom’ : ’Camille’,’nom’ : ’Simon’}) >db.etudiants.insert({ ’prenom’ : ’Thomas’ }) >db.etudiants.insert([ { ’prenom’ : ’Jordan’ }, { ’prenom’ : ’Mélanie’} ] ) >db.etudiants.insert([ {’prenom’ : ’Camille’,’nom’ : ’Alberti’}, {’prenom’ : ’Laura’,’nom’ : ’Seban’}]) >db.cours.insert([{ ’code’ : ’IO2’, ’intitulé’ : ’Internet et outils’ }, { ’code’ : ’TO2’, ’intitulé’ : ’Types de données et objets’}]) Minyar Sassi Hidri Les BDs NoSQL 74 / 194
- 75. L’invite interactive deMongoDB Lecture/´Ecriture Recherche I Recherche standard : MongoDB propose deux fonctions de recherche simples : - findOne() : recherche et retourne un document. - find() : retourne une liste de documents, avec un curseur permettant de se déplacer à l’intérieur de la liste. I Cible une unique collection spécifique de documents. I Cible un critère ou des conditions spécifiques, pour identifier le document à retourner. I Peut inclure une projection sur les champs du document à retourner. I Peut définir des modificateurs pour imposer des limites, un ordre, un filtre... I Pour consulter des documents dans une collection : >db.collection.find() >db.collection.find(requête) >db.collection.find(requête, projection) - Sans paramètre, tous les documents sont renvoyés. - requête est un tableau clefs / valeurs spécifiant des opérateurs sur les champs des documents recherchés. - projection est un tableau permettant de limiter les champs que l’on souhaite consulter dans les documents recherchés (suite...). Minyar Sassi Hidri Les BDs NoSQL 75 / 194
- 76. L’invite interactive deMongoDB Lecture/´Ecriture Recherche Fonction find() (1) I Exemple : >db.etudiants.find() >db.etudiants.find({ ’prenom’ : ’Camille’}) I Résultat : > db.etudiants.find( { ’prenom’ : ’Camille’ } ) { ” id” : ObjectId(”532d40c72d150b4635b8cfc9”), ”prenom” : ”Camille”, ”nom” : ”Simon” } { ” id” : ObjectId(”532d40c72d150b4635b8cfcd”), ”prenom” : ”Camille”, ”nom” : ”Alberti” } - Le champ id a été ajouté par le système au moment de l’opération insert. On peut ensuite l’utiliser pour désigner un document précis : > db.etudiants.find({ id : ObjectId(”532d40c72d150b4635b8cfc9”) }) { ” id” : ObjectId(”532d40c72d150b4635b8cfc9”), ”prenom” : ”Camille”, ”nom” : ”Simon” } I Le résultat renvoyé par find est un curseur, un objet qui permet d’itérer sur les documents. Considérons un exemple d’utilisation simple, comme un tableau : > var c = db.etudiants.find({’prenom’ : ’Camille’}) > c[0] { ” id” : ObjectId(”532d40c72d150b4635b8cfc9”),”prenom” : ”Camille”,”nom” : ”Simon”} > c[0].nom Simon Minyar Sassi Hidri Les BDs NoSQL 76 / 194
- 77. L’invite interactive deMongoDB Lecture/´Ecriture Recherche Fonction find() (2) I On peut également utiliser l’opérateur $or pour indiquer un OU logique, sur le modèle : >db.collection.find({$or : [ {field1 : value1},{field2 :value2}]}) I Plutôt que d’indiquer une valeur fixe dans ces instructions conditionnelles, on peut également utiliser des opérateurs tel que supérieur à, inférieur à, etc.. ils respectent la syntaxe suivante : {field : {operator :value}} I Et on dispose des opérateurs suivantes : - $gt : plus grand que. - $gte : plus grand ou égal a. - $lt : plus petit que. - $lte : plus petit ou égal a. - $ne : different de. Minyar Sassi Hidri Les BDs NoSQL 77 / 194
- 78. L’invite interactive deMongoDB Lecture/´Ecriture Recherche Fonction find() (3) I On peut également indiquer, par le biais d’un second argument à find(), quels champs on souhaite sélectionner. Si ce second argument n’est pas spécifié, tous les champs du document sont renvoyés. .find({...},{field1 :[0|1],field2 :[0|1],...}) I Pour sélectionner tous les élèves mais sans extraire leurs noms et prénoms : >db.eleves.find({}, {prenom :0,nom :0}) I On peut également appliquer un équivalent de l’opérateur limit par le biais des fonctions limit() et skip() à appliquer respectivement à find() et à limit(). - pour sélectionner les N premiers documents : .find(...).limit(N). - pour sélectionner les N premier documents à partir du Mième document : .find(...).limit(N).skip(M). Minyar Sassi Hidri Les BDs NoSQL 78 / 194
- 79. L’invite interactive deMongoDB Lecture/´Ecriture Recherche Fonction find() (4) I On peut également trier les documents résultant de notre recherche. Pour ce faire, on va utiliser la fonction .sort() à appliquer à find(). .find(...).sort({field1 :[1|-1], filed2 :[1|-1],...) ...où 1 désigne un ordre ascendant et -1 un ordre descendant. I Un autre opérateur utilisable au sein des instructions conditionnelles est l’opérateur in. {filed : {in : [value1, value2, value3,...]}} Minyar Sassi Hidri Les BDs NoSQL 79 / 194
- 80. L’invite interactive deMongoDB Lecture/´Ecriture Recherche Fonction findOne() I La fonction findOne fait la même chose que find mais sans s’embarrasser d’un curseur, lorsqu’on souhaite récupérer un document unique (par son identifiant, par exemple). I Si la requête désigne plusieurs documents, le premier trouvé est renvoyé. > var camille = db.etudiants.findOne({’ id’ : ObjectId(’532d40c72d150b4635b8cfc9’)}) > camille {” id” : ObjectId(”532d40c72d150b4635b8cfc9”), ”prenom” : ”Camille”,”nom” : ”Simon”} > camille.nom Simon Minyar Sassi Hidri Les BDs NoSQL 80 / 194
- 81. L’invite interactive deMongoDB Lecture/´Ecriture Modification/Suppression Fonction Update/ Fonction Remove I Pour modifier un ou des documents existant : >db.collection.update(requête, modifications) - requête est de la même forme que pour find. - modification est un tableau clefs / valeurs définissant des opérations sur les champs. - Exemple : L’opérateur set pour ajouter un champ : >db.users.update({’prenom’ : ’Thomas’}, {’$set’ : {nom : ’Hummel’}}) I Pour supprimer un ou plusieurs documents : >db.collection.remove() >db.collection.remove(requête) - sans paramètre, tous les documents sont supprimés (attention, donc). - requête est de la même forme que pour find, elle désigne les documents qui seront supprimés. > db.etudiants.find( { ’prenom’ : ’Camille’ } ) { ” id” : ObjectId(”532d40c72d150b4635b8cfc9”), ”prenom” : ”Camille”, ”nom” : ”Simon” } { ” id” : ObjectId(”532d40c72d150b4635b8cfcd”), ”prenom” : ”Camille”, ”nom” : ”Alberti” } > db.etudiants.remove({ id : ObjectId(”532d40c72d150b4635b8cfc9”) }) > db.etudiants.find({prenom : ’Camille’}) { ” id” : ObjectId(”532d40c72d150b4635b8cfcd”), ”prenom” : ”Camille”, ”nom” : ”Alberti” } Minyar Sassi Hidri Les BDs NoSQL 81 / 194
- 82. L’invite interactive deMongoDB Exemple Exemple Insertion des données dans MongoDB (1) I Nous insérons trois documents (livres, auteur, editeur) dans notre base, ils reprennent notre structure mais ont chacun des champs supplémentaires : Minyar Sassi Hidri Les BDs NoSQL 82 / 194
- 83. L’invite interactive deMongoDB Exemple Exemple Insertion des données dans MongoDB (2) I Nous commenc¸ons par ajouter les éditeurs : >show dbs >use bibliotheque >db.editeurs.insert({ nom : ”Hachette”}) ; >db.editeurs.insert({ nom : ”Hatier”}) ; >db.editeurs.insert({ nom : ”O’Reilly”}) ; I Consultons le contenu de la collection editeurs : > db.editeurs.find({}) I On a bien ajouté trois documents dans la collection editeurs. On remarque que MongoDB a automatiquement ajouté un identifiant. On peut maintenant ajouter les documents livres en reprenant les Id des éditeurs. > db.livres.insert({type : ”livre”, titre : ”Aubonheurdesdames”, annee : 2010, editeur : new DBRef ( editeurs , ObjectId(”4fa40cbe9ff 7ba90f 5d13eed”)), ISBN : ”2012814557”, auteurs : [{nom : ”Zola”, prenom : ”Emile”}]}); > db.livres.insert({type : ”livre”, titre : ”Germinal”, annee : 1995, editeur : newDBRef ( editeurs , ObjectId(”4fa40d359ff 7ba90f 5d13eee”)), format : ”Poche”, auteurs : [{nom : ”Zola”, prenom : ”Emile”}]}); > db.livres.insert({type : ”livre”, titre : ”TheDefinitiveGuidetoMongodb”, annee : 2003, editeur : newDBRef ( Editeurs , ObjectId(”4fa40dfb7b071ce946d6dc34”)), ISBN : ”1449381561”, pages : 206, langue : ”Anglais”, auteurs : [{nom : ”Dirolf ”, prenom : ”Michael”}, {nom : ”Dirolf ”, prenom : ”Kristina”}]}); I Vérification du nombre de livres en base : >db.livres.count() Minyar Sassi Hidri Les BDs NoSQL 83 / 194
- 84. L’invite interactive deMongoDB Exemple Exemple Consultation des données avec MongoDB (1) I Recherche standard : MongoDB propose deux fonctions de recherche simples : - findOne() : recherche et retourne un document. - find() : retourne une liste de documents, avec un curseur permettant de se déplacer à l’intérieur de la liste. - Rechercher un document suivant la clé titre : > db.livres.findOne({titre : ”Germinal”}) ; - Rechercher uniquement les titres des documents ayant pour nom d’auteur Zola : > db.livres.find({”auteurs.nom” : ”Zola”}, {titre : 1}) ; - Rechercher uniquement les titres des documents ayant pour nom d’auteur Dirolf : > db.livres.find({”auteurs.nom” : ”Dirolf ”}, {titre : 1}) ; - Rechercher uniquement les titres des documents publiés après 2000 : > db.livres.find({”annee” : {$gt : 2000}}, {titre : 1}) ; - Requête composée regroupant les deux précédentes recherches (année > 2000 et nom auteur = Zola : > db.livres.find({”annee” : {$gt : 2000}, ”auteurs.nom” : ”Zola”}, {titre : 1}); - Retrouver les livres qui ne possèdent pas la clé ISBN : > db.livres.find({ISBN : { $exists : false}}, {titre : 1}) ; - Retrouver l’éditeur d’un livre dont la langue est en Anglais : > db.livres.findOne({”langue” : ”Anglais”}).editeur.fetch() ; Minyar Sassi Hidri Les BDs NoSQL 84 / 194
- 85. L’invite interactive deMongoDB Exemple Exemple Consultation des données avec MongoDB (2) I Requêtes agrégées : MongoDB dans la version V2.2 offre la possibilité d’exécuter des requêtes agrégées. On retrouve alors une partie des fonction- nalités d’agrégation des SGBDR. Les fonctionnalités sont : - Count : calcul le nombre de documents qui correspondent à un critère. - Distinct : retourne les valeurs distinctes d’un champs dans une collections (les dou- blons ne sont pas retournés). - Group : permet de retourner un résultat agrégé sur un ou plusieurs critères. Par exemple on pourrait retourner le nombre d’oeuvres publiées par un éditeur par années. I Indexation : - Pour déterminer la pertinence d’un index pour optimiser une requête, MongoDB permet d’obtenir le plan d’exécution à l’aide de la commande Explain. > db.livres.find({”auteurs.nom” : ”Dirolf ”}, {titre : 1}).sort({annee : −1}).explain(); - Pour connaître l’espace consommé en RAM pour une collection. > db.livres.totalIndexSize(); Minyar Sassi Hidri Les BDs NoSQL 85 / 194
- 86. Réplication dans MongoDB 1Structure de données 2 L’invite interactive de MongoDB 3 Réplication dans MongoDB 4 Le sharding dans MongoDB 5 Programmation client 6 MongoDB et MapReduce Minyar Sassi Hidri Les BDs NoSQL 86 / 194
- 87. Réplication dans MongoDBRéplication dans MongoDB Réplication dans MongoDB Les Replica Sets I Réplication : permet d’assurer la redondance et la haute disponibilité. I Processus de synchronisation d’un ensemble de données sur de multiples ser- veurs. I Fournit la haute disponibilité : si un serveur MongoDB crash, un autre prendra la relève. I Qu’est-ce que le Replica Set ? - Permet d’assurer la redondance et la haute disponibilité. - Permet aux données d’être dupliquées de manière transparente. - Utilise la notion de groupe de serveurs appelé set : chaque set possède : - un nœud principal (primaire) : lecture/écriture. - n serveurs de backup (secondaire) : lecture uniquement. - Concrètement : les Replica Set permettent de répliquer les données entre des instances MongoDB. Minyar Sassi Hidri Les BDs NoSQL 87 / 194
- 88. Réplication dans MongoDBRéplication dans MongoDB Réplication dans MongoDB I Replica Set : correspond à un ensemble de processus mongod qui hébergent le même ensemble de données : - Le premier mongod, le mongod primaire, rec¸oit toutes les opérations de lecture et écriture. - Les autres instances mongod, les répliques secondaires, appliquent les instructions rec¸ues par le membre primaire afin d’avoir exactement le même ensemble de données. - Un replica set ne peut avoir qu’un seul membre primaire uniquement qui accepte les opérations d’écriture. - Afin de supporter la réplication, le membre primaire enregistre tous les changements réalisés sur son ensemble de données dans son oplog (globalement on peut le qualifier de journal enregistrant toutes les opérations d’écritures du membre). - De cette fac¸on, les membres secondaires vont pouvoir s’appuyer sur cet oplog afin de répliquer les mêmes opérations sur leur propre ensemble de données. Minyar Sassi Hidri Les BDs NoSQL 88 / 194
- 89. Réplication dans MongoDBRéplication dans MongoDB Réplication dans MongoDB I Types de membres dans un replicat set : - Primaire : reçoit toutes les opérations d’écriture/lecture. - Secondaire : réplication des opérations du primaire pour maintenir des répliques identiques à l’original. - Arbitre : ne conserve pas de copie de la donnée, mais joue un rôle dans les élections qui sélectionnent un membre primaire, si le primaire actuel est indisponible. - Il faut au minimum 3 nœuds pour fonctionner : - 1 maître - 2 esclaves. - En cas de crash du maître, une élection se produit entre les es- claves pour élire le nouveau maître. Minyar Sassi Hidri Les BDs NoSQL 89 / 194
- 90. Réplication dans MongoDBRéplication dans MongoDB Stratégies de réplication Primaire I Seul membre qui reçoit les opérations d’écriture. I MongoDB applique les opérations d’écriture sur le primaire, puis les enregistre dans son log (oplog). I Les membres secondaires dupliquent ce log et appliquent les opérations sur leurs données. I Tous les membres d’un replicat set peuvent accepter une opération de lecture. I Par défaut, une application dirige ces opérations vers le primaire. I Un replicat set a au plus un primaire. I Si le primaire tombe en panne, une élection a lieu pour en choisir un autre. Minyar Sassi Hidri Les BDs NoSQL 90 / 194
- 91. Réplication dans MongoDBRéplication dans MongoDB Stratégies de Réplication Secondaires I Maintiennent une copie des données du primaire. I Pour répliquer les données, un secondaire applique les opérations du oplog du primaire sur ses propres données, de manière asynchrone. I Un replicat set peut avoir un ou plusieurs secondaires. I Même si les clients ne peuvent pas écrire des données sur les secondaires, ils peuvent en lire. I Un secondaire peut devenir un primaire, suite à une élection. I Il est possible de configurer un secondaire : - L’empêcher d’être élu pour devenir primaire, lui permettant de rester toujours comme un backup. - Empêcher les applications de lire à partir de lui, lui permettant ainsi de se consacrer à certaines applications nécessitant un trafic séparé. - Exécuter des snapshots périodiques pour garder un historique. Minyar Sassi Hidri Les BDs NoSQL 91 / 194
- 92. Réplication dans MongoDBRéplication dans MongoDB Stratégies de réplication Arbitre I Arbitre - N’a pas de copie des données et ne peut pas devenir un primaire. - Permet de voter pour un primaire. - Doit être défini pour les replicat sets avec un nombre pair de membres. I Élections - Ont lieu à la création d’un replicat set, ou bien quand un primaire devient indisponible. - Processus qui prend du temps, et qui rend le replicat set en readonly. - Chaque membre a une priorité déterminant son éligibilité à devenir primaire. - L’élection choisit le membre ayant la plus haute priorité comme primaire. - Par défaut, tous les membres ont la même priorité (1). - Il est possible de modifier la priorité d’un membre ou groupe, selon leur position géographique par exemple. - Chaque membre a la possibilité de voter pour un seul autre membre. - Le membre recevant le plus grand nombre de votes devient primaire. Minyar Sassi Hidri Les BDs NoSQL 92 / 194
- 93. Réplication dans MongoDBRéplication dans MongoDB Réplication dans MongoDB Principales commandes I Démarrage d’un serveur dans un Replica Set : mongod –replSet (indique à quel Replica Set appartient l’instance) –shardsvr (active le partitionnement horizontal) ... I Ajout d’un nœud dans un Replica Set sur le serveur maître : PRIMARY> rs.add(”host :port”) ; I Sortir un nœud d’un Replica Set sur le serveur maître : PRIMARY> rs.remove(”host :port”) ; I Les principales commandes d’exploitation : rs.initiate(cfg) ; (permet d’initialiser la configuration d’un Replica Set) db.isMaster() ; (permet de vérifier qui est le maître) rs.status() ; (permet de vérifier l’état du Replica Set) rs.slaveOk() ; (permet d’activer les lectures sur les serveurs esclaves) rs.syncFrom(”host :port”) ; (permet de forcer la synchronisation) ... Minyar Sassi Hidri Les BDs NoSQL 93 / 194
- 94. Le sharding dansMongoDB 1 Structure de données 2 L’invite interactive de MongoDB 3 Réplication dans MongoDB 4 Le sharding dans MongoDB 5 Programmation client 6 MongoDB et MapReduce Minyar Sassi Hidri Les BDs NoSQL 94 / 194
- 95. Le sharding dansMongoDB Le sharding dans MongoDB Architecture I Pré-requis : mise en place des Replica Set. I Permet une scalabilité horizontale. I Distribution du stockage des données sur différentes instances MongoDB. I Chaque machine stocke un sous ensemble des données (chunk). I Utilise une clé de sharding pour répartir le stockage. I Shards : - Stockent les données. - Les données sont distribuées et répliquées sur les shards. I Query Routers - Instances mongos. - Interfaçage avec les applications clientes. - Redirige les opérations vers le shard approprié et retourne le résultat au client. - Plusieurs QR pour la répartition des tâches. I Config Servers - Stockent les méta-données du cluster. - Définissent le mapping entre les data et les shards. - Dans les env. de prod., 3 CS doivent être définis. Minyar Sassi Hidri Les BDs NoSQL 95 / 194
- 96. Le sharding dansMongoDB MongoDB Partitionnement de données I Partitionnement des données au niveau des collections, via la shard key. I Shard key : champs simple ou composé, indexé qui existe dans chaque document de la collection. I MongoDB divise les valeurs de la clé en morceaux (chunks) et les distribuent de manière équitable entre les shards. I La répartition des clés suit l’une de ces deux méthodes de partitionnement : 1. Basée sur le rang. 2. Basée sur le Hash. 3. Basée sur les tags. Minyar Sassi Hidri Les BDs NoSQL 96 / 194
- 97. Le sharding dansMongoDB Partitionnement de données Partitionnement basé sur le rang I Définition d’intervalles qui ne se chevauchent pas, dans lesquelles les valeurs de la shard key peuvent se trouver. I Permet aux documents avec des clés proches de se trouver dans le même shard. I Plus facile de retrouver le shard pour une donnée. I Risque de distribution non équitable des données (par exemple si la clé est le temps, alors toutes les requêtes dans un même intervalle de temps sont sur le même serveur, d’où une grande différence selon les heures de grande ou de faible activité). Minyar Sassi Hidri Les BDs NoSQL 97 / 194
- 98. Le sharding dansMongoDB Partitionnement de données Partitionnement basé sur le hash I Calcul de la valeur du hash d’un champ, puis utilise ces hash pour créer des partitions. I Deux documents ayant des clés proches ont peu de chance de se trouver dans le même shard. I Distribution aléatoire d’une collection dans le cluster, d’où une distribution plus équitable. I Moins efficace, car le temps de recherche de la donnée est plus grand. I Dans le cas d’une requête portant sur des données se trouvant dans un intervalle défini, le système doit parcourir plusieurs shards. Minyar Sassi Hidri Les BDs NoSQL 98 / 194
- 99. Le sharding dansMongoDB Partitionnement de données Partitionnement basé sur les tags I Les administrateurs peuvent définir des tags, qu’ils associent à des intervalles de clé. I Ils associent ces tags aux différents shards en essayant de respecter la distribution équitable des données. I Un balancer migre les données taggées vers les shards adéquats. I Le meilleur moyen pour assurer une bonne répartition des données. Minyar Sassi Hidri Les BDs NoSQL 99 / 194
- 100. Le sharding dansMongoDB Partitionnement de données Maintien d’une distribution équitable I L’ajout de nouvelles données ou nouveaux serveurs peut rendre la dis- tribution des données déséquilibrée. I Splitting : - ´Evite d’avoir des chunks trop larges. - Quand la taille d’un chunk augmente au delà d’une valeur prédéfinie (chunk size), MongoDB divise cet ensemble de données en deux sur le même shard. - Les insertions et les modifications déclenchent les splits. - Un split change les méta-données, mais ne fait pas migrer les données ni n’affecte le contenu des shards. Minyar Sassi Hidri Les BDs NoSQL 100 / 194
- 101. Le sharding dansMongoDB Partitionnement de données Maintien d’une distribution équitable I Balancing : - Balancer : processus en arrière plan, gérant les migrations de chunks. - Peut être lancé à partir de n’importe quel query router. - Quand la distribution des données est déséquilibrée, le balancer fait migrer des chunks du shard ayant le plus de chunks vers celui qui en a le moins, jusqu’à ce que la collection devienne équitablement répartie. - Étapes : - Le shard destination reçoit tous les documents du chunk à migrer. - Le shard destination applique tous les changements faits aux données durant le processus de migration. - Finalement, les métadonnées concernant l’emplacement du chunk sur le config server sont modifiées. Minyar Sassi Hidri Les BDs NoSQL 101 / 194
- 102. Le sharding dansMongoDB Partitionnement de données Ajout ou suppression de shards I Dans le cas d’un ajout de shard : - Un dé-séquilibre est créé entre les shards du cluster, car le nouveau shard n’a pas de chunks. - MongoDB peut commencer le processus de migration immédiatement, mais cela risque de prendre du temps avant que le cluster ne soit équilibré. I Dans le cas d’une suppression de shard : - Le balancer migre tous les chunks de ce shard vers les autres shards. - Une fois toutes les données migrées et les méta-données mises à jour, la suppression peut avoir lieu. Minyar Sassi Hidri Les BDs NoSQL 102 / 194
- 103. Le sharding dansMongoDB Le sharding dans MongoDB Principales commandes I Ajouter des nœuds au sharding : db.runCommand({addshard : ”<nom Replica Set/host1 :port,host2 :port,hostN :port”}) ; I Activer le sharding pour une base de données : db.runCommand({enablesharding : ”<nom base>”}) ; I Définir une clé de partitionnement pour le sharding : db.runCommand({shardcollection : ”<namespace>”, key :{” :<nom champ>” :1}}) ; I Afficher les informations sur le sharding : db.printShardingStatus() ; db.<collection>.stats() ; Minyar Sassi Hidri Les BDs NoSQL 103 / 194
- 104. Le sharding dansMongoDB Les principaux paramètres Renseignés dans le fichier mongod.conf. I dbpath : emplacement des données d’une instance I logpath : emplacement des logs I logappend : continu à écrire des anciens logs ou créer un nouveau fichier I nojournal = true : désactive ou pas la journalisation I noprealloc = true : désactive la pré-allocation des fichiers data I nssize = <size> : taille du fichier d’espace de nom I port = 27017 : port utilisé par une instance I auth = true : active l’authentification sous MongoDB I fork = true : démarrage de mongod en tâche de fond I objcheck = true : inspection des documents avant insertion ( utf-8 ,type ect .. ) I nohttpinterface = true : active ou désactive l’interface Web de monitoring (Defaults to localhost :27018). I ... Minyar Sassi Hidri Les BDs NoSQL 104 / 194
- 105. Programmation client 1 Structurede données 2 L’invite interactive de MongoDB 3 Réplication dans MongoDB 4 Le sharding dans MongoDB 5 Programmation client 6 MongoDB et MapReduce Minyar Sassi Hidri Les BDs NoSQL 105 / 194
- 106. Programmation client Programmationclient Programmation client I MongoDB développe des bibliothèques pour de nombreux langages, appelés pilotes (drivers). I Celui pour Python se nomme PyMongo . I Avant de l’installer, nous nous assurons que le paquet python-dev est installé sur la machine. sudo apt-get install python-dev I Nous installons ensuite le pilote pymongo avec pip. I Exemple d’utilisation, dans un fichier source Python, en créant d’abord un dictionnaire Python qui contient le document que nous allons stocker. I Nous avons ici effectué notre écriture avec l’instruction db.articles.insert(article, safe=True), ce qui signifie : dans la BD db ouverte, dans la collection articles, insérer le dictionnaire article. I L’objet sera automatiquement transformé en document JSON par PyMongo. Si la collection articles n’existe pas, elle sera créée.. Minyar Sassi Hidri Les BDs NoSQL 106 / 194
- 107. Programmation client Programmationclient Programmation client I Le paramètre safe=True indique d’effectuer l’insertion en mode synchrone. I Le pilote PyMongo effectue l’insertion en mode asynchrone par défaut, ce qui est pour le moins une option dangereuse pour une application sérieuse : une erreur resterait silencieuse. I Une autre option permet de s’assurer que l’écriture est bien effectuée sur un nombre défini de nœuds dans une configuration en replica set : db.articles.insert(article, w=2) I Ici, nous indiquons que l’écriture doit avoir été réellement effectuée sur deux nœuds avant de redonner la main. I Cette option implique bien sûr le mode synchrone, il est donc inutile de spé- cifier safe=True. I Il nous suffit donc d’exécuter notre fichier Python dans notre environnement : ∼/python env/bin/python ∼/insertion.py Minyar Sassi Hidri Les BDs NoSQL 107 / 194
- 108. MongoDB et MapReduce 1Structure de données 2 L’invite interactive de MongoDB 3 Réplication dans MongoDB 4 Le sharding dans MongoDB 5 Programmation client 6 MongoDB et MapReduce Minyar Sassi Hidri Les BDs NoSQL 108 / 194
- 109. MongoDB et MapReduceParallélisation : MapReduce Parallélisation : MapReduce I MongoDB possède également une fonction mapreduce() interne. I Elle est relativement limitée (essentiellement par le type de traitement qu’on peut effectuer sur les données), mais peut avoir son utilité. I Syntaxe : Minyar Sassi Hidri Les BDs NoSQL 109 / 194
- 110. MongoDB et MapReduceParallélisation : MapReduce Exemple I Imaginons qu’on ait par exemple une collection orders ; contenant les documents suivants : I On va exécuter la commande suivante : ...afin d’appliquer un traitement MapReduce aux documents dont le champs status vaut A ; on générera des couples (clef ;valeur) contenant l’identifiant client et le total de la commande dans Map, et on renverra la somme de tous les totaux obtenus après shuffle pour chaque clef distincte dans Reduce. Minyar Sassi Hidri Les BDs NoSQL 110 / 194
- 111. MongoDB et MapReduceParallélisation : MapReduce Exemple I Le traitement et son résultat : (lui-même stocké dans un champs or- der totals) Minyar Sassi Hidri Les BDs NoSQL 111 / 194
- 112. MongoDB et MapReduceConnecteur Hadoop Connecteur Hadoop I MongoDB dispose d’un connecteur Hadoop. Ce connecteur vise à permettre à des programmes MapReduce Hadoop de directement adresser MongoDB comme source des données d’entrée du programme ou comme destination des données de sorties. I Ce connecteur est lui-aussi Open Source (licence AGPLv3). Il n’est en revanche pas inclus par défaut dans la distribution de MongoDB. I URL du repository du projet : https ://github.com/mongodb/mongo-hadoop I Ce connecteur est disponible au sein d’une librairie Java .jar, et téléchargeable depuis le dépôt Github. I Il a par ailleurs pour dépendance la librairie fournissant l’API Java de connexion à MongoDB. I Le connecteur fonctionne en mettant à disposition du développeur des formats Hadoop supplémentaires d’entrée et de sortie, permettant de directement lire et écrire au sein de bases/collections MongoDB plutôt que depuis/sur HDFS. I L’inclusion de la librairie (et de sa dependance) sera donc nécessaire au sein du projet Java MapReduce si on souhaite s’en servir. I Le connecteur va par ailleurs nous permettre, si on lit/écrit via MongoDB plutôt que HDFS, de passer des objets contenant directement les données BSON dans les classes map et/ou reduce, à la place des types Hadoop standards comme IntWritable ou Text. Minyar Sassi Hidri Les BDs NoSQL 112 / 194
- 113. MongoDB et MapReduceConnecteur Hadoop Liens utiles I MongoDB en pratique : https ://mongoteam.gitbooks.io/ http ://blog.xebia.fr/2010/12/15/mongodb-en-pratique/ I Opérations de lecture / écriture https ://docs.mongodb.org/manual/core/read-operations-introduction/ I Documentation MongoDB : https ://www.mongodb.org I Livres : http ://www.mongodb.org/books (en Anglais) I Blog : http ://blog.mongodb.org/ I MongoDB Management Service (un service gratuit en cloud pour la surveillance et backup des déploiement de mongodb) : http ://mms.mongodb.com/ Minyar Sassi Hidri Les BDs NoSQL 113 / 194
- 114. Chapitre 3 -Cassandra 1 Découverte de Cassandra 2 Partitionnement dans Cassandra 3 Replication dans Cassandra 4 Consistance dans Cassandra 5 Gestion de données et des objets dans Cassandra Minyar Sassi Hidri Les BDs NoSQL 114 / 194
- 115. Découverte de Cassandra 1Découverte de Cassandra 2 Partitionnement dans Cassandra 3 Replication dans Cassandra 4 Consistance dans Cassandra 5 Gestion de données et des objets dans Cassandra Minyar Sassi Hidri Les BDs NoSQL 115 / 194
- 116. Découverte de Cassandra Présentation ISGBD NoSQL orienté colonnes. I Initié par Facebook. I ´Ecrit en Java. I Distribué. I Haute disponibilité : no SPOF. I Massivement parallèle. I Scalabilité linéaire. I ´Ecrit plus rapidement qu’il ne lit. ⇒ `A utiliser dans le cas ou on doit surtout stocker (écrire) des données plus que les lire. Il peut aussi être utile si l’architecture complète doit être en Java. I Composés de plusieurs nœuds identiques : - Pas de notion de NameNode ou nœud maître. I Les données sont partitionnées par défaut à travers les différents nœuds du cluster. - L’utilisateur contrôle le nombre de répliques qu’il désire avoir pour ses données. I Lecture et écriture à partir de n’importe quel nœud, indépendamment de l’emplacement des données. I Utilisation du protocole Gossip pour la communication entre les différents nœuds du cluster. - ´Echange de données entre les nœuds chaque seconde. I Comparatif des NoSQL : http ://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis http ://www-igm.univ-mlv.fr/ dr/XPOSE2010/Cassandra/nosql.html Minyar Sassi Hidri Les BDs NoSQL 116 / 194
- 117. Partitionnement dans Cassandra 1Découverte de Cassandra 2 Partitionnement dans Cassandra 3 Replication dans Cassandra 4 Consistance dans Cassandra 5 Gestion de données et des objets dans Cassandra Minyar Sassi Hidri Les BDs NoSQL 117 / 194
- 118. Partitionnement dans Cassandra Partitionnementdans Cassandra I Le partitionnement permet de répartir les lignes sur les nœuds du cluster (à partir de la clé). I Partitionnement facile des don- nées à travers les différents nœuds participants du cluster. I Chaque nœud est responsable d’une partie de la base de don- nées. I Les données sont insérées par l’utilisateur dans une famille de colonnes. I Elles sont ensuite placées sur un nœud, selon sa clé de colonne. Minyar Sassi Hidri Les BDs NoSQL 118 / 194
- 119. Partitionnement dans Cassandra Partitionnementdans Cassandra I Partitionnement aléatoire (RandomPartitioner) : - Par défaut, recommandé. - Données partitionnées le plus équitablement possible à travers les différents nœuds. - Un token est défini au niveau de chaque nœud (un BigInteger entre 0 et 2∗∗127). - Chaque nœud est responsable des clés qui sont dans l’intervalle qu’il gère (intervalle entre le token du nœud précédent et le token du nœud). - Un hash (M5 ou Murmur3) de la clé est effectué et définit un token. La ligne est envoyée sur le nœud qui gère l’intervalle concerné. I Partitionnement ordonné (ByteOrderedPartitioner) : - Sauvegarde les clés de familles de colonnes par ordre à travers les nœuds d’un cluster. - Peut provoquer des problèmes, surtout pour la répartition des charges (des nœuds avec des données plus volumineuses que d’autres). I Stratégie spécifiée dans un fichier de configuration cassandra.yaml . I Si la stratégie d’une base est modifiée, il faut recharger toutes les données. Minyar Sassi Hidri Les BDs NoSQL 119 / 194
- 120. Replication dans Cassandra 1Découverte de Cassandra 2 Partitionnement dans Cassandra 3 Replication dans Cassandra 4 Consistance dans Cassandra 5 Gestion de données et des objets dans Cassandra Minyar Sassi Hidri Les BDs NoSQL 120 / 194
- 121. Replication dans Cassandra Replicationdans Cassandra I La réplication est gérée au niveau d’un keyspace par le replication factor . I Le replication factor définit le nombre de copies globales sur le cluster d’une ligne. I La fac¸on dont sont placés les replicas dé- pend de la stratégie choisie. I Stratégie Simple (SimpleStrategy) : - La colonne originelle est placée sur un nœud determiné par le partitionneur (partitio- ner). - La réplique est placée sur le nœud suivant de l’anneau (clockwise). - Pas de considération pour l’emplacement dans un Data-Center ou dans une rack (baie) - approprié pour les déploiement sur un seul Data-Center). I Stratégie par topologie du réseau (NetworkTopologyStrategy) : - Les réplicas peuvent être placés dans un autre rack, un autre Data-Center. - Il faut définir la topology du cluster : Snitch. Minyar Sassi Hidri Les BDs NoSQL 121 / 194
- 122. Replication dans Cassandra Replicationdans Cassandra I Utilisation de Snitch : - Définition de la manière dont les nœuds sont groupés dans un réseau. - Répartition des nœuds entre baies et Data- Centers. I Plusieurs types de Snitch : - Simple Snitch : utilise la stratégie simple. - Rack-Inferring Snitch : détermine la topologie du réseau en analysant les adresses IP : Second octet de l’adresse IP : Data-Center, Troisième octet de l’adresse IP : Baie. - Property File Snitch : se base sur une description de l’utilisateur pour determiner l’emplacement des nœuds (cassandra-topology.properties). - EC2 (Elastic Compute Cloud) Snitch : pour déploiement dans Amazon EC2. Utilise l’API AWS (Amazon Web Services) pour déterminer la topologie. I Définit dans le fichier de configuration cassandra.yaml. Minyar Sassi Hidri Les BDs NoSQL 122 / 194
- 123. Consistance dans Cassandra 1Découverte de Cassandra 2 Partitionnement dans Cassandra 3 Replication dans Cassandra 4 Consistance dans Cassandra 5 Gestion de données et des objets dans Cassandra Minyar Sassi Hidri Les BDs NoSQL 123 / 194
- 124. Consistance dans Cassandra Consistancedans Cassandra I P2P ⇒ on contacte n’importe quel nœud. I Nœud contacté = coordinateur ; I Le coordinateur contacte les répliques. I Le client peut se connecter à n’importe quel nœud, dans n’importe quel Data- Center, et lire/écrire les données qu’il veut. I Le consistency level est lié au replication factor. Il définit le nombre de nœuds devant se synchroniser avant de répondre à une opération. I ´Ecriture : - Données écrites d’abord dans un commit log pour la durabilité. - Ensuite, écriture en mémoire dans une MemTable. - Une fois la MemTable pleine, les données sont sauvegardées dans le disque, dans une SSTable (Sorted Strings Table). - Même si les transactions relationnelles (commits et rollbacks) ne sont pas supportées, les écritures sont atomiques au niveau des colonnes. Minyar Sassi Hidri Les BDs NoSQL 124 / 194
- 125. Consistance dans Cassandra Consistancedans Cassandra I Niveau de consistance : combien de répliques doivent être écrites avec succès avant de retourner acquittement au client. I Consistance : à quel point est-ce qu’une donnée est à jour et synchronisée sur toutes ses répliques. I Cassandra est la BD NoSQL la plus rapide en écriture. I Extension du concept de consistance éventuelle à une consistance ajustable. I Choix possible entre une consistance forte ou éventuelle selon les besoins. I Ce choix est fait par opération, ce n’est pas une stratégie globale pour la base de données (ex, pour changer la stratégie de lecture en quorum). I Consistance gérée à travers plusieurs data centers. Minyar Sassi Hidri Les BDs NoSQL 125 / 194
- 126. Consistance dans Cassandra Consistancedans Cassandra Stratégies d’écriture Niveau de consistance : Combien de répliques doivent être écrites avec succès avant de retourner acquittement au client. I Any : une écriture doit réussir sur n’im- porte quel nœud, au moins un. - Offre la plus haute disponibilité, mais la plus basse consistance. I One (défaut dans CQL) : une écriture doit réussir sur le commit log et la memtable d’au moins une réplique. I Quorum : une écriture doit réussir sur un certain pourcentage de répliques (pourcentage =(facteur de replication/2)+1). I Local-Quorum : une écriture doit réussir sur un certain pourcentage de nœuds répliqués sur le même Data-Center que le nœud coordinateur. I Each-Quorum : une écriture doit réussir sur un certain pourcentage de nœuds répliqués sur tous les Data-Centers. I All : une écriture doit réussir sur tous les nœuds répliqués d’une colonne. - Offre la plus haute consistance, mais la plus basse disponibilité. Minyar Sassi Hidri Les BDs NoSQL 126 / 194
- 127. Consistance dans Cassandra Consistancedans Cassandra Stratégies d’écriture I Cassandra utilise les Hinted Handoffs. I Elle tente de modifier une colonne sur toutes les répliques. I Si certains des nœuds répliques ne sont pas disponibles, un indice (hint) est sauvegardé sur l’un des nœuds répliques en marche, pour mettre à jour tous les nœuds répliqués en panne une fois disponibles. I Si aucun nœud réplique n’est disponible, l’utilisation de la stratégie Any permettra au nœud coordinateur de stocker cet indice. Mais la donnée ne sera lisible que quand l’un des nœuds est disponible de nouveau. Minyar Sassi Hidri Les BDs NoSQL 127 / 194
- 128. Consistance dans Cassandra Consistancedans Cassandra Stratégies de lecture I Niveau de consistance : combien de répliques doivent répondre avant de retourner le résultat à l’application cliente. I Cassandra vérifie le nombre de répliques pour la donnée la plus récente pour satisfaire une demande de lecture (basée sur le temps). I One (défaut dans CQL) : obtention d’une réponse à partir de la réplique la plus proche selon le Snitch. - Offre la plus faible consistance, mais la plus haute disponibilité. I Quorum : obtention du résultat le plus récent à partir d’un certain pourcentage de nœuds répliques (pourcentage = (facteur de réplication/2)+1). - Meilleure alternative en terme de consistance et de disponibilité. I Local-Quorum : obtention du résultat le plus récent à partir d’un certain pourcentage de nœuds répliques sur le même datacenter que le nœud coordinateur. - Évite la latence due à la communication inter-Data-Centers. I Each-Quorum : obtention du résultat le plus récent à partir d’un certain pourcentage de nœuds répliques sur tous les Data-Centers. I All : obtention du résultat le plus récent à partir de tous les nœuds répliques. - Offre la plus haute consistance, mais la plus basse disponibilité. Minyar Sassi Hidri Les BDs NoSQL 128 / 194
- 129. Consistance dans Cassandra Consistancedans Cassandra Stratégies de lecture I Pour réparer de l’inconsistance quand elle se produit (perte d’un nœud,...) : - Hintend handoff : Quand un nœud n’est pas disponible, les insertions sont envoyées à un autre nœud qui lui renverra quand le nœud redeviendra disponible. - Read repair : En lecture, si les valeurs différents, les nœuds désynchronisés sont réparés en insérant les nouvelles valeurs (basé sur le Timestamp). - Cassandra assure que les données fréquem- ment lues soient consistantes. - `A la lecture d’une donnée, le nœud coor- dinateur compare toutes ses répliques en arrière plan. - Si ces données ne sont pas consistantes, envoie une demande d’écriture aux nœuds réplicas pour mettre à jour leur donnée et afficher la donnée la plus récente. - Read Repair peut être configuré par famille de colonnes et est activé par défaut. Minyar Sassi Hidri Les BDs NoSQL 129 / 194
- 130. Gestion de donnéeset des objets dans Cassandra 1 Découverte de Cassandra 2 Partitionnement dans Cassandra 3 Replication dans Cassandra 4 Consistance dans Cassandra 5 Gestion de données et des objets dans Cassandra Minyar Sassi Hidri Les BDs NoSQL 130 / 194
- 131. Gestion de donnéeset des objets dans Cassandra Gestion de données et des objets dans Cassandra Cas pratiques - Client / API I Cassandra-cli : Outil ligne de commande fourni par Cassandra permettant d’interroger l’espace de stockage. Toutes les opérations de bases sont prévues : - Requêtage (get, list). - Création, Modification, Suppression d’objets de lignes, colonnes et famille de colonnes. - Administration : Keyspace, Niveau de consistance, etc. I CQL (Cassandra Query Language) : Est apparu à partir de la V0.8 pour harmoniser la manière d’attaquer Cassandra avec tous les langages. Il est basé sur la syntaxe SQL. - Utilisée pour créer/manipuler des données en utilisant un langage proche de SQL. - Objets tels que les keyspaces, familles de colonnes et index sont crées, 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 : Ne supporte pas des operations telles que GROUP BY, ORDER BY (sauf pour les clés composées, et ordonnées seulement selon la deuxième clé 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,...). I Programmation client : Hector ou DataStax (Java), Pycassa (Python), PhpCassa (PHP). I OPSCenter : Outil de management et monitoring. Minyar Sassi Hidri Les BDs NoSQL 131 / 194
- 132. Gestion de donnéeset des objets dans Cassandra Liens utiles I Sites : - Documentation : http ://docs.datastax.com/en/archived/cassandra/1.0/docs/index.html - 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/ - 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 I Présentations : - Harri Kauhanen, NOSQL Databases, Futurice, Septembre 2010. I Rapport : - Mouna Laroussi, ´Etude et mise en place de la technologie Big Data pour la télécommunication, Projet de fin d’études, INSAT, 2013. I Livres Blancs : - Top 5 Considerations when evaluating NOSQL Databases, MongoDB White Paper, Juin 2013. Minyar Sassi Hidri Les BDs NoSQL 132 / 194
- 133. Chapitre 4 -Les autres bases de données de la mouvance NoSQL 1 HBase 2 Neo4j 3 Redis Minyar Sassi Hidri Les BDs NoSQL 133 / 194
- 134. HBase 1 HBase 2 Neo4j 3Redis Minyar Sassi Hidri Les BDs NoSQL 134 / 194
- 135. HBase Présentation deHBase Présentation de HBase I HBase est un système de stockage efficace pour des données très volumineuses. I Il permet d’accéder aux données très rapidement même quand elles sont gigantesques. I HBase est utilisé par Facebook pour stocker tous les messages SMS, email et chat. I HBase mémorise des n-uplets constitués de colonnes (champs). Les n-uplets sont identifiés par une clé. À l’affichage, les colonnes d’un même n-uplet sont affichées successivement : Clés Colonnes et Valeurs isbn7615 colonne=auteur valeur=”Jules Verne” isbn7615 colonne=titre valeur=”De la Terre à la Lune” isbn7892 colonne=auteur valeur=”Jules Verne” isbn7892 colonne=titre valeur=”Autour de la Lune” I Pour obtenir une grande efficacité, les données des tables HBase sont séparées en régions : - Une région contient un certain nombre de n-uplets contigus (intervalle de clés successives). - Lorsqu’on crée une table, elle est mise dans une seule région. - Lorsqu’une table dépasse une certaine limite, elle se fait couper en deux régions au milieu de ses clés. Et ainsi de suite si les régions deviennent trop grosses. - Chaque région est gérée par un Serveur de Région (Region Server). - Ces serveurs sont distribués sur le cluster, ex : un par machine. - Un même serveur de région peut s’occuper de plusieurs régions de la même table. I Au final, les données sont stockées sur HDFS. Minyar Sassi Hidri Les BDs NoSQL 135 / 194
- 136. HBase Tables etrégions Tables et régions I Une table est découpée en régions faisant à peu près la même taille. I Le découpage est basé sur les clés. I Chaque région est gérée par un Serveur de région. I Un même serveur gère plusieurs régions : Minyar Sassi Hidri Les BDs NoSQL 136 / 194
- 137. HBase Différences entreHBase et SQL Différences entre HBase et SQL I Les n-uplets sont classés selon leur clé, dans l’ordre alphabétique. ⇒ Cette particularité est extrêmement importante pour la recherche rapide d’information. I On est amené à définir les clés de façon à rapprocher les données connexes. I Les n-uplets de HBase peuvent être incomplets. Les colonnes ne sont pas forcément remplies pour chaque n-uplets, au point qu’on peut même avoir des colonnes différentes pour les n-uplets. I On qualifie ça de matrice creuse (sparse data). I Les colonnes appelées qualifiers sont groupées en familles. I Les valeurs sont enregistrées en un certain nombre de versions, avec une date appelée timestamp. I Les données ont une structure assez complexe : - Au plus haut niveau, une table HBase est un dictionnaire <clé, n-uplet> trié sur les clés. - Chaque n-uplet est une liste de familles. - Une famille est un dictionnaire <nomcolonne, cellule> trié sur les noms de colonnes (aussi appelées qualifier). - Une cellule est une liste de paires (valeur, timestamp). I Donc finalement, pour obtenir une valeur isolée, il faut fournir un quadruplet : (clé, nomfamille, nomcolonne, timestamp) I Si on ne spécifie pas le timestamp, HBase retourne la valeur la plus récente. Minyar Sassi Hidri Les BDs NoSQL 137 / 194
- 138. HBase Exemple Exemple I Onveut enregistrer les coordonnées et les achats de clients. On va construire une table contenant trois familles : - La famille pers contiendra les informations de base : colonnes pers :nom et pers :prenom - La famille coords contiendra l’adresse : colonnes coords :rue, coords :ville, coords :cp, coords :pays - La famille achats contiendra les achats effectués : colonnes achats :date, achats :montant, achats :idfacture I HBase autorise à dé-normaliser un schéma (redondance dans les informations) afin d’accéder aux données plus rapidement. Minyar Sassi Hidri Les BDs NoSQL 138 / 194
- 139. HBase HBase :Vue logique HBase : Vue logique Source : IBM Minyar Sassi Hidri Les BDs NoSQL 139 / 194
- 140. HBase HBase :Vue logique HBase : Vue logique Source : IBM Minyar Sassi Hidri Les BDs NoSQL 140 / 194
- 141. HBase HBase :Vue physique HBase : Vue physique Source : IBM Minyar Sassi Hidri Les BDs NoSQL 141 / 194
- 142. HBase Architecture ducluster HBase Architecture du cluster HBase (1) Définitions et rôles des composants HBase Source : IBM Minyar Sassi Hidri Les BDs NoSQL 142 / 194
- 143. HBase Architecture ducluster HBase Architecture du cluster HBase (2) Définitions et rôles des composants HBase I Region : - Une région est une partition horizontale d’une table avec une ligne (row) de départ et une ligne de fin. - Les régions sont l’élément fondamental de la disponibilité et de la répartition les tables. - Une région est automatiquement divisée par le serveur de la région d’hébergement lorsqu’elle atteint une taille spécifiée. - Périodiquement, un équilibreur de charge (load balancer ) va déplacer des régions dans le cluster pour équilibrer la charge. - Lorsqu’un serveur de région échoue, ses régions seront réaffectées à d’autres serveurs de région. I Region Server : - Le serveur de régions met à la disposition des clients un ensemble de régions. Il le vérifie avec le Maître. - WAL (Write-Ahead-Logstores) toutes les modifications apportées au Store. Il y a un WAL par serveur de région. Toutes les éditions pour toutes les régions portées par un serveur de région particulier sont entrés en premier dans le WAL. - La région stocke des données pour une certaine partition d’une table. Il existe plusieurs stores pour une seule région. - Un store détient une famille de colonnes dans une région. Il a un memstore et un ensemble de zéro ou plus HFiles. I Master : - Responsable de la coordination des serveurs régionaux. - Le Master gère les opérations de cluster. - Détecte le statut des serveurs régionaux, effectue l’équilibrage de la charge (load balancing) du region server. - Affecte les régions aux serveurs régionaux. - Très disponible avec ZooKeeper et un (des) serveur (s) de sauvegarde supplémentaire (s). I Zookeeper : - Zookeeper fournit un service de coordination. - Le client trouve le serveur de région via ZK. - Le client écrit/lit directement à/depuis le serveur de région. - Les serveurs régionaux envoient des heartbeats au ZK. - Le Master surveille ZK pour les serveurs de régions. Minyar Sassi Hidri Les BDs NoSQL 143 / 194
- 144. HBase HBase etHadoop HBase et Hadoop Source : IBM Minyar Sassi Hidri Les BDs NoSQL 144 / 194
- 145. HBase Shell deHBase Shell de HBase I HBase offre plusieurs mécanismes pour travailler, dont : - Un shell où on tape des commandes. - Une API à utiliser dans des programmes Java. - Une API Python appelée HappyBase. I Il y a aussi une page Web dynamique qui affiche l’état du service et permet de voir les tables. I Lancement du shell HBase : hbase shell I Il faut savoir que c’est le langage Ruby qui sert de shell. Les commandes sont écrites dans la syntaxe de ce langage. I Premières commandes : - Un shell où on tape des commandes. - status affiche l’état du service HBase. - version affiche la version de HBase. - list affiche les noms des tables existantes. - describe ’table’ décrit la table dont on donne le nom. Minyar Sassi Hidri Les BDs NoSQL 145 / 194
- 146. HBase Shell deHBase Création/Suppression d’une table I Deux syntaxes de création d’une table : Create ’NOMTABLE’, ’FAMILLE1’, ’FAMILLE2’... Create ’NOMTABLE’, {NAME=>’FAMILLE1’},{NAME=>’FAMILLE2’}... Create ’table 1’, ’column family1’, ’column family2’, ’column family3’ I La seconde syntaxe est celle de Ruby. On spécifie les familles par un dictionnaire {propriété=>valeur}. I D’autres propriétés sont possibles, par exemple VERSIONS pour indiquer le nombre de versions à garder. Alter ’table 1’, {NAME=>’column family1, VERSIONS => 3} I Remarques : - Les familles doivent être définies lors de la création. - On ne définit que les noms des familles, pas les colonnes. Les colonnes sont créées dynamiquement. I Suppression d’une table : - C’est en deux temps, il faut d’abord désactiver la table, puis la supprimer : 1. Disable ’NOMTABLE’ 2. Drop ’NOMTABLE’ Minyar Sassi Hidri Les BDs NoSQL 146 / 194
- 147. HBase Shell deHBase Création/Suppression d’une table Vue conceptuelle / vue physique Source : IBM Minyar Sassi Hidri Les BDs NoSQL 147 / 194
- 148. HBase Ajout, suppressionet affichage de n-uplets Ajout et suppression de n-uplets I Ajout de n-uplets : - Un n-uplet est composé de plusieurs colonnes. L’insertion d’un n-uplet se fait colonne par colonne. On indique la famille de la colonne. Les colonnes peuvent être créées à volonté. Put ’NOMTABLE’, ’CLE’, ’FAMILIY COLUMN :COLONNE’, ’VALEUR’ Put ’table 1’, ’row1’, ’column family1 :c11’, ’r1v11’ Put ’table 1’, ’row1’, ’column family1 :c12’, ’r1v12’ Put ’table 1’, ’row1’, ’column family2 :c21’, ’r1v21’ Put ’table 1’, ’row1’, ’column family3 :c31’, ’r1v31’ Put ’table 1’, ’row2’, ’column family1 :d11’, ’r2v11’ Put ’table 1’, ’row2’, ’column family1 :d12’, ’r2v12’ Put ’table 1’, ’row2’, ’column family2 :d21’, ’r2v21’ I Suppression de n-uplets : - Il y a plusieurs variantes selon ce qu’on veut supprimer, seulement une valeur, une colonne ou tout un n-uplet : Delete ’NOMTABLE’, ’CLE’, ’FAMILIY COLUMN :COLONNE’, TIMESTAMP Delete ’NOMTABLE’, ’CLE’, ’FAMILIY COLUMN :COLONNE’ Delete ’NOMTABLE’, ’CLE’ I Affichage de n-uplets : - La commande get affiche les valeurs désignées par une seule clé. On peut spécifier le nom de la colonne avec sa famille et éventuellement le timestamp. Get ’NOMTABLE’, ’CLE’ Get ’NOMTABLE’, ’CLE’, ’FAMILIY COLUMN :COLONNE’ Get ’NOMTABLE’, ’CLE’, ’FAMILIY COLUMN :COLONNE’, TIMESTAMP - La première variante affiche toutes les colonnes ayant cette clé. La dernière affiche toutes les valeurs avec leur timestamp pour une colonne. Minyar Sassi Hidri Les BDs NoSQL 148 / 194
- 149. HBase Recherche den-uplets Recherche de n-uplets I La commande scan affiche les n-uplets sélectionnés par les conditions. La difficulté, c’est d’écrire les conditions en Ruby. Scan ’NOMTABLE’, {CONDITIONS} I Conditions : - COLUMNS=>[’FAMILIY COLUMN :COLONNE’,...] pour sélectionner certaines co- lonnes. - STARTROW=>’CLE1’, STOPROW=>’CLE2’ pour sélectionner les n-uplets entre CLE1 et CLE2. - VERSIONS=>NB affiche NB versions des valeurs. - FILTER=>”ValueFilter(OP, ’binary :CONSTANTE’)” permet de comparer les valeurs à une constante, mettre <, <=, =, ! =, >, >= pour OP. Il existe quelques autres filtres. - .... Scan ’table 1’, {FILTER => ”ColumnPrefixFilter (’d11’)”} I Voici comment compter les n-uplets d’une table, en configurant le cache pour en prendre 1000 à la fois : Count ’NOMTABLE’, CACHE => 1000 I HBase n’est qu’un stockage de mégadonnées. Il n’a pas de dispositif d’interrogations so- phistiqué. Minyar Sassi Hidri Les BDs NoSQL 149 / 194
- 150. HBase API deHBase API de HBase I On peut écrire des programmes Java qui accèdent aux tables HBase. I Il y a un petit nombre de classes et de méthodes à connaître pour démarrer. I Nous allons voir comment : - Créer une table. - Ajouter des cellules (identifiant de ligne, famille, colonne, valeur). - Récupérer une cellule. - Parcourir les cellules. I Pour commencer, les classes à importer : import org.apache.hadoop.conf.Configuration ; import org.apache.hadoop.hbase.* ; import org.apache.hadoop.hbase.client.* ; import org.apache.hadoop.hbase.util.* ; I Ensuite, chaque fonction contient ces lignes qui établissent une connexion avec le serveur HBase : Configuration config = HBaseConfiguration.create() ; HBaseAdmin admin = new HBaseAdmin(config) ; try { ... } finally { admin.close() ; } Minyar Sassi Hidri Les BDs NoSQL 150 / 194
- 151. HBase API deHBase Création/ Suppression d’une table I Voici une fonction qui crée une table : void CreerTable(String nomtable, String[] familles) { Configuration config = HBaseConfiguration.create() ; HBaseAdmin admin = new HBaseAdmin(config) ; try {TableName tn = TableName.valueOf(nomtable) ; HTableDescriptor htd = new HTableDescriptor(tn) ; for (String famille : familles) { htd.addFamily(new HColumnDescriptor(famille)) ; } admin.createTable(tabledescriptor) ; } finally { admin.close() ; } } I Voici comment on supprime une table, en vérifiant au préalable si elle existe : void SupprimerTable(String nomtable) { Configuration conf = HBaseConfiguration.create() ; HBaseAdmin admin = new HBaseAdmin(conf) ; try {TableName tn = TableName.valueOf(nomtable) ; if (admin.tableExists(tn)) { admin.disableTable(tn) ; admin.deleteTable(tn) ; } }finally { admin.close() ; } } Minyar Sassi Hidri Les BDs NoSQL 151 / 194
- 152. HBase API deHBase Manipulation d’une table I Dans les fonctions suivantes, on va modifier les données d’une table existante. I Pour cela, il faut récupérer un objet HTable représentant la table. I Il est important de libérer cet objet dès qu’il ne sert plus. void OperationSurTable(String nomtable, ...) { Configuration config = HBaseConfiguration.create() ; HTable table = new HTable(config, nomtable) ; try { ... opérations sur le contenu de la table ... } finally { table.close() ; } } Minyar Sassi Hidri Les BDs NoSQL 152 / 194
- 153. HBase API deHBase Insertion d’une valeur Transformation en tableaux d’octets I L’insertion d’une valeur consiste à créer une instance de la classe Put. Cet objet spécifie la valeur à insérer : - identifiant du n-uplet auquel elle appartient - nom de la famille - nom de la colonne - valeur - en option, le timestamp à lui affecter. I Toutes les données concernées doivent être converties en tableaux d’octets. I Transformation en tableaux d’octets : - HBase stocke des données binaires quelconques : chaînes, nombres, images jpg, etc. Il faut seulement les convertir en byte[]. - Convertir une donnée en octets se fait quelque soit son type par : final byte[] octets = Bytes.toBytes(donnée) ; Minyar Sassi Hidri Les BDs NoSQL 153 / 194
- 154. HBase API deHBase Insertion d’une valeur Transformation inverse I La récupération des données à partir des octets n’est pas uniforme. I Il faut impérativement connaître le type de la donnée pour la récupérer cor- rectement. Il existe plusieurs fonctions : String chaine = Bytes.toString(octets) ; Double nombre = Bytes.toDouble(octets) ; Long entier = Bytes.toLong(octets) ; I Dans certains cas, HBase nous retourne un grand tableau d’octets dans lequel nous devons piocher ceux qui nous intéressent. I Nous avons donc trois informations : le tableau, l’offset du premier octet utile et le nombre d’octets. Il faut alors faire ainsi : Double nombre = Bytes.toDouble(octets, debut, taille) ; Minyar Sassi Hidri Les BDs NoSQL 154 / 194
- 155. HBase API deHBase Insertion d’une valeur (fonction) void AjouterValeur(String nomtable, String id, String fam, String col, String val) { Configuration config = HBaseConfiguration.create() ; HTable table = new HTable(config, nomtable) ; // Construire un Put final byte[] rawid = Bytes.toBytes(id) ; Put action = new Put(rawid) ; final byte[] rawfam = Bytes.toBytes(fam) ; final byte[] rawcol = Bytes.toBytes(col) ; final byte[] rawval = Bytes.toBytes(val) ; action.add(rawfam, rawcol, rawval) ; // Effectuer l’ajout dans la table table.put(action) ; } Minyar Sassi Hidri Les BDs NoSQL 155 / 194
- 156. HBase API deHBase Extraction d’une valeur I La récupération d’une cellule fait appel à un Get. I Il se construit avec l’identifiant du n-uplet voulu. I Ensuite, on applique ce Get à la table. Elle retourne un Result conte- nant les cellules du n-uplet. static void AfficherNuplet(String nomTable, String id) { final byte[] rawid = Bytes.toBytes(id) ; Get action = new Get(rawid) ; // appliquer le get à la table Configuration config = HBaseConfiguration.create() ; HTable table = new HTable(config, nomTable) ; Result result = table.get(action) ; AfficherResult(result) ; } Minyar Sassi Hidri Les BDs NoSQL 156 / 194
- 157. HBase API deHBase Extraction d’une valeur Résultat d’un Get I Un Result est une sorte de dictionnaire (famille, colonne) → valeur. - Sa méthode getValue(famille, colonne) retourne les octets de la valeur désignée, s’il y en a une : byte[] octets = result.getValue(rawfam, rawcol) ; - On peut parcourir toutes les cellules par une boucle : void AfficherResult(Result result) { for (Cell cell : result.listCells()) { AfficherCell(cell) ; } } Minyar Sassi Hidri Les BDs NoSQL 157 / 194
- 158. HBase API deHBase Affichage d’une cellule I C’est un peu lourdingue car il faut extraire les données de tableaux d’octets avec offset et taille. void AfficherCell(Result result) { // Extraire la famille String fam = Bytes.toString(cell.getFamilyArray(), cell.getFamilyOffset(), cell.getFamilyLength()) ; // Extraire la colonne (qualifier) String col = Bytes.toString(cell.getQualifierArray(), cell.getQualifierOffset(), cell.getQualifierLength()) ; // Extraire la valeur String val = Bytes.toString(cell.getValueArray(), cell.getValueOffset(), cell.getValueLength()) ; System.out.println(fam+” :”+col+” = ”+val) ; } Minyar Sassi Hidri Les BDs NoSQL 158 / 194
- 159. HBase API deHBase Parcours des n-uplets d’une table I Réaliser un Scan par programme n’est pas très compliqué. I Il faut fournir la clé de départ et celle d’arrêt (ou alors le scan se fait sur toute la table). On reçoit une énumération de Result. void ParcourirTable(String nomtable, String start, String stop) { final byte[] rawstart = Bytes.toBytes(start) ; final byte[] rawstop = Bytes.toBytes(stop) ; Scan action = new Scan(rawstart, rawstop) ; Configuration config = HBaseConfiguration.create() ; HTable table = new HTable(config, nomTable) ; ResultScanner results = table.getScanner(action) ; for (Result result : results) { AfficherResult(result) ; } } Minyar Sassi Hidri Les BDs NoSQL 159 / 194
- 160. HBase API deHBase Paramétrage d’un Scan I Il est possible de filtrer le scan pour se limiter à : - Certaines familles et colonnes (on peut en demander plusieurs à la fois), sinon par défaut, c’est toutes les colonnes. action.add(rawfam, rawcol) ; - Rajouter des filtres sur les valeurs, par exemple ci-dessous, on cherche les colonnes supérieures ou égales à une limite. SingleColumnValueFilter filter = new SingleColumnValueFilter( rawfam, rawcol, CompareOp.GREATER OR EQUAL, rawlimite) ; action.setFilter(filter) ; Minyar Sassi Hidri Les BDs NoSQL 160 / 194
- 161. Neo4j 1 HBase 2 Neo4j 3Redis Minyar Sassi Hidri Les BDs NoSQL 161 / 194
- 162. Neo4j Neo4j I Neo4j estl’une des meilleures bases de données orientée graphes. I Bien qu’elle soit développée en Java, elle offre d’excellentes performances et permet de traiter rapidement de grandes quantités de relations. I Installation : http ://debian.neo4j.org/ I Neo4j s’installe et démarre en tant que service. I Accès possible au serveur Web d’administration : http ://localhost :7474/we- badmin/. I Les langages de Neo4j : - Mis à part les pilotes spécifiques pour les langages clients, qui permettent de mani- puler les noeuds et les relations dans un mode procédural, Neo4j offre deux langages spécifiques : - Cypher : langage déclaratif inspiré du SQL, qui permet d’exprimer une requête complexe de façon élégante et compacte. - Gremlin : langage de script basé sur Groovy (un langage pour la plate-forme Java dont la syntaxe s’inspire de langages de script comme Python et Ruby). Il permet d’envoyer des scripts qui seront exécutés du côté serveur à travers l’interface REST de Neo4j. . - Cypher et Gremlin peuvent également être lancées en ligne de commande avec l’invite neo4j-shell. Minyar Sassi Hidri Les BDs NoSQL 162 / 194
- 163. Neo4j Neo4j : Exemple(1) I Tout d’abord, nous créons un nœud : CREATE n = {nom : ’Milou’, ville : ’Paris’} ; I Affichage : START n=node(1) RETURN n ; I Résultat : ==> +-−-−-−-−-−-−-−-−-−-−-−-−-−-−-−-−-−-−+ ==> | n | ==> +-−-−-−-−-−-−-−-−-−-−-−-−-−-−-−-−-−-−+ ==> | Node[1]{nom : Milou ,ville : Paris } | ==> +-−-−-−-−-−-−-−-−-−-−-−-−-−-−-−-−-−-−+ ==> 1 row ==> 0 ms Minyar Sassi Hidri Les BDs NoSQL 163 / 194
- 164. Neo4j Neo4j : Exemple(2) I Nous allons maintenant ajouter un deuxième nœud et une relation dans la même commande : START Milou = node(1) CREATE Tintin = { nom : ’Tintin’, ville : ’Paris’ }, Milou-[r :AMI]->Tintin RETURN Tintin ; I Ce qui retourne : ==> +-−-−-−-−-−-−-−-−-−-−-−-−-−-−-−-−-−-−+ ==> | Tintin | ==> +————————————-+ ==> | Node[2]{nom : Tintin ,ville : Paris } | ==> +-−-−-−-−-−-−-−-−-−-−-−-−-−-−-−-−-−-−+ ==> 1 row ==> Nodes created : 1 ==> Relationships created : 1 ==> Properties set : 2 ==> 42 ms ==> Minyar Sassi Hidri Les BDs NoSQL 164 / 194
- 165. Neo4j Neo4j : Exemple(3) I `A l’aide de la commande START, nous avons indiqué le point de départ de notre pattern, c’est-à-dire de notre instruction. I Nous avons ensuite créé un nœud et une relation que nous avons nommée AMI. I Ajoutons encore quelques nœuds : START Milou = node(1), Tintin = node(2) CREATE Haddock = { nom : ’Capitain Haddock’, ville : ’Moulinsart’}, Castafiore = { nom : ’Castafiore’, ville : ’Pesaro’}, Tintin-[r :AMI]->Haddock, Haddock -[r :AMI]->Castafiore ; I Les relations, comme les nœuds, sont numérotées. Nous pouvons maintenant appliquer toutes sortes de requêtes pour traverser l’arbre et chercher les relations. I Exemple : la requête suivante cherche s’il y a une relation de type AMI entre Milou et la Castafiore : START Milou=node(1), Castafiore=node(4) MATCH Milou[r :AMI*]->Castafiore RETURN r ; I La requête peut se lire ainsi : pour Milou et la Castafiore, s’il y a une relation de type AMI qui va de Milou à la Castafiore en passant par un nombre indéfini (*) de relations intermédiaires, retourne-moi cette relation. Le résultat est : ==> +-−-−-−-−-−-−-−-−-−-−-−-−-−-−-−-−-−-−+ ==> | r | ==> +-−-−-−-−-−-−-−-−-−-−-−-−-−-−-−-−-−-−+ ==> | [ :AMI[2] {}, :AMI[1] {}, :AMI[0] {}] | ==> +-−-−-−-−-−-−-−-−-−-−-−-−-−-−-−-−-−-−+ ==> 1 row ==> 4 ms I Bibliothèques clientes pour différents langages. I Le client pour Python s’appelle py2neo. Minyar Sassi Hidri Les BDs NoSQL 165 / 194
- 166. Redis 1 HBase 2 Neo4j 3Redis Minyar Sassi Hidri Les BDs NoSQL 166 / 194
- 167. Redis Redis : présentation IRedis est un moteur non relationnel qui travaille principalement en mémoire. I Objectif : manipuler le plus rapidement possible les structures de don- nées qui y sont maintenues. I Il est à la fois un outil de gestion de paires clé-valeur et un cache de données à la manière de memcached. - Il offre les mêmes fonctionnalités et avantages que memcached, mais avec un modèle beaucoup plus riche et solide. - Le but de Redis est d’être très rapide, très efficace et léger. I Redis est livré avec une invite interactive nommée redis-cli, qui permet d’envoyer des commandes au serveur. I Installation : http ://redis.io/download I Configuration : https ://github.com/antirez/redis Minyar Sassi Hidri Les BDs NoSQL 167 / 194
- 168. Redis Types dedonnées Types de données I Redis travaille en paires clé-valeur, les valeurs pouvant être de cinq types : - Chaînes : - Une chaîne de caractères en Redis est un peu plus qu’une chaîne. Elle permet également de stocker correctement les valeurs numériques et binaires (binary safe), ce qui la rend adaptée pour les calculs ou les fichiers binaires comme des images. La taille maximale supportée par ce type est de 512 Mo. - Listes : - Les listes sont simplement des listes de chaînes maintenues dans un ordre défini à l’insertion. Lorsque vous ajoutez une chaîne à la liste, vous pouvez définir si vous voulez l’ajouter au début (à gauche) ou à la fin (à droite) de la liste, à l’aide des commandes LPUSH (gauche) ou RPUSH (droite). - Ensembles : - Un ensemble (set) est une collection non triée de chaînes. Il représente un ensemble correspondant plus ou moins à ce que la théorie des ensembles entend par un set : il est non trié et n’accepte pas les doublons. - Hachages : - Ils représentent une table de hachage (un dictionnaire), ce qui permet de stocker une représentation d’objet, à l’image d’un document JSON plat (non hiérarchique), dans Redis. Le stockage est optimisé, ce qui fait que le hachage prend peu de place en mémoire. - Ensembles triés : - L’ensemble trié se comporte comme un ensemble mais chaque membre est en plus associé à une note (un score) qui permet de trier l’ensemble. Plusieurs membres peuvent avoir la même note. Minyar Sassi Hidri Les BDs NoSQL 168 / 194
- 169. Chapitre 5 -Mise en œuvre d’une base NoSQL 1 Quand aller vers le NoSQL et quelle base choisir ? 2 Mise en place d’une solution NoSQL 3 Maintenance et supervision des bases NoSQL Minyar Sassi Hidri Les BDs NoSQL 169 / 194
- 170. Quand aller versle NoSQL et quelle base choisir ? 1 Quand aller vers le NoSQL et quelle base choisir ? 2 Mise en place d’une solution NoSQL 3 Maintenance et supervision des bases NoSQL Minyar Sassi Hidri Les BDs NoSQL 170 / 194
- 171. Quand aller versle NoSQL et quelle base choisir ? Par rapport aux cas d’utilisation... Par rapport aux cas d’utilisation... Quand est-il une bonne idée d’utiliser une base NoSQL ? I Du point de vue des atouts du non relationnel : - Les données que vous devez gérer sont peu structurées, et les structures sont plutôt changeantes. ⇒ Vous allez naturellement vous tourner vers une base orientée documents. - Vous devez privilégier les performances d’écriture et de restitution, et vous assurer que l’accès aux données se fasse toujours en dessous de quelques millisecondes. ⇒ Une base en mémoire comme Redis sera alors un bon choix. - Vous devez stocker et manipuler de grandes quantités de données, par exemple plusieurs téraoctets. ⇒ Un moteur distribué sera alors un choix naturel. - Vous accéderez à vos données principalement par un seul point de recherche, qui constituera la clé de vos documents ou de vos paires clé-valeur. Par exemple, vous voulez afficher sur une page toutes les données d’un utilisateur. ⇒ Un document JSON qui stocke ces informations et que vous requêterez par l’identifiant de l’utilisateur (la clé) sera idéal. Minyar Sassi Hidri Les BDs NoSQL 171 / 194
- 172. Quand aller versle NoSQL et quelle base choisir ? Choix par rapport au type d’application Par rapport au type d’application... I Blog : - Un moteur NoSQL orienté documents, comme MongoDB ou CouchDB, est particulièrement indiqué pour ce genre d’application. - L’indexation en plein texte des documents JSON avec un outil comme ElasticSearch est donc la meilleure solution. I Données de gestion, ERP : - Les volumes de données, très structurées, restent raisonnables et nécessitent rarement de distribuer le traitement. - Toutes ces raisons font qu’un SGBDR reste le meilleur choix dans ce genre de cas. I Reporting et analyse OLAP : - Un moteur orienté colonnes, comme HBase ou Cassandra est une bonne solution. - Quitte à stocker des données précalculées et dupliquées selon plusieurs clés correspondant aux axes d’analyse, et à profiter de traitements en MapReduce. I E-commerce : - L’e-commerce est typiquement un domaine où les moteurs NoSQL peuvent être utilisés en parallèle avec les SGBDR. I Logistique : - Suivi d’un colis ou d’un container via un document JSON dans lequel sont listées toutes les étapes du transport. - Recherche d’un chemin optimal en utilisant une BD orientée graphes comme Neo4J... I Données spatiales : - Plusieurs moteurs NoSQL commencent à implémenter des fonctionnalités de calcul spatial, comme les calculs de distance entre les points de MongoDB, ou le support naissant de la spécification GeoJSON (http ://www.geojson.org/, une définition de document JSON comportant des objets spatiaux comme des points ou des polygones) dans CouchBase Server. Minyar Sassi Hidri Les BDs NoSQL 172 / 194
- 173. Quand aller versle NoSQL et quelle base choisir ? Comparaison des principales bases NoSQL Comparaison des principales bases NoSQL (1) Quelle base choisir ? I HBase : projet de la fondation Apache. - `A choisir pour : - HBase est un choix intéressant uniquement si vous prévoyez de gérer un volume de données très important. - Basé sur Hadoop, il permet de distribuer les données en utilisant le système de fichiers distribué HDFS d’Hadoop. - Cela n’a donc pas de sens de vouloir utiliser HBase sur un système non distribué. De plus, sa mise en œuvre est relativement complexe. - Maintien de la cohérence : - Garantie ACID sur une ligne. - Cela veut dire que des commandes qui appliquent des modifications sur plusieurs lignes ne constituent pas une opération atomique, mais une suite de modifications de lignes individuellement atomiques, qui vont retourner un état de succès ou d’erreur pour chaque ligne. Mode de distribution : - Basé sur Hadoop et HDFS, avec maître centralisé. - Un cluster HBase est constitué d’un maître (HMaster) qui maintient les métadonnées du cluster et gère des serveurs de région (RegionServer). Chaque région contient une partie des données. - Développé en : Java. Toute la pile Hadoop, HDFS et HBase est en Java. - Protocole : REST et Thrift. Il existe également une API Java native et une interface Avro. - Points forts : - Utiliser pour le Big Data, très bonne montée en charge horizontale, solidité de la conception et excellente tolérance au partitionnement. - Utilisé par des acteurs comme Facebook pour stocker tous les messages de ce réseau social. Minyar Sassi Hidri Les BDs NoSQL 173 / 194
- 174. Quand aller versle NoSQL et quelle base choisir ? Comparaison des principales bases NoSQL Comparaison des principales bases NoSQL (2) Quelle base choisir ? I Cassandra : projet de la fondation Apache. - `A choisir pour : - Choix intéressant pour de grands volumes de données et les besoins de bases distribuées, hautement disponibles et décentralisées, sur de multiples data centers. - Comme pour HBase, Cassandra n’est pas un choix intéressant pour des volumes de données moyens ou des systèmes non distribués. - Maintien de la cohérence : - La cohérence en écriture et en lecture sont paramétrables. Par exemple, on peut forcer une écriture, ou une lecture, à être validée sur plusieurs réplicas avant d’être considérée comme effectuée. - `A partir de Cassandra 1.1, l’ACIDité est garantie par ligne. - Mode de distribution : - Décentralisé, chaque nœud est indépendant et il n’y a pas besoin de serveur maître. Les connexions utilisateurs peuvent se faire sur n’importe quel nœud, qui se chargera de re-diriger le client vers le nœud qui contient les données souhaitées. - La répartition (sharding) est réalisée par hachage consistant. - Développé en : Java. - Protocole : l’API Cassandra est de type natif pour CQL. Une interface Thrift existe mais elle est dépréciée. - Points forts : - Implémentation solide, système décentralisé, souplesse de configuration, cohérence paramétrable. - Ne nécessite pas un système de fichiers distribué comme HBase. - Cassandra est un produit mature, largement utilisé et très populaire, c’est une excellente solution pour bâtir un système de gestion de données volumineux et décentralisé. Minyar Sassi Hidri Les BDs NoSQL 174 / 194
- 175. Quand aller versle NoSQL et quelle base choisir ? Comparaison des principales bases NoSQL Comparaison des principales bases NoSQL (3) Quelle base choisir ? I CouchDB : projet de la fondation Apache. - `A choisir pour : - CouchDB est la BD du Web. Son orientation documents et son interface REST excellent pour construire des projets Web ou à destination des terminaux mobiles. - CouchDB est à préférer pour les besoins où la richesse fonctionnelle l’emporte sur les grands volumes et la disponibilité. Pour les besoins de grandes performances, voir du côté de Couchbase Server, le successeur de CouchDB. - Maintien de la cohérence : - CouchDB maintient automatiquement un numéro de version sur chaque document. - Pour modifier un document existant, il faut indiquer son dernier numéro de révision, sinon la mise à jour est refusée. - Mode de distribution : - Pas de distribution native. - Un système de réplication des données permet d’échanger les modifications d’une base avec un autre serveur, mais cela doit être géré manuellement. Pour une version nativement distribuée, voir Couchbase Server. - Développé en : Erlang, un langage développé à l’origine par la société Ericksson et qui est conçu spécialement pour le traitement parallèle et l’informatique distribuée. - Protocole : REST. - Points forts : - Grande richesse fonctionnelle au niveau du serveur, vues, filtres dans des documents de design et incorporation possible de traitements complexes sur le serveur, ce qui peut l’amener à devenir également un vrai serveur applicatif. - Simplicité de mise en œuvre est aussi un des points forts de CouchDB, qu’on a étiqueté de BD du Web. Minyar Sassi Hidri Les BDs NoSQL 175 / 194
- 176. Quand aller versle NoSQL et quelle base choisir ? Comparaison des principales bases NoSQL Comparaison des principales bases NoSQL (4) Quelle base choisir ? I Couchbase Server : Apache pour l’édition communautaire, et commerciale. - `A choisir pour : - Couchbase est un moteur décentralisé paires clé-valeur et document JSON. - C’est un excellent moteur pour des besoins de stockage simple ou de type document avec un besoin d’élasticité dans la montée en charge. - Maintien de la cohérence : - Cohérence forte, simplement parce que l’écriture et la lecture sont réalisées sur le même noeud, qui est maître des données. - Les réplicas existent pour la redondance uniquement. - Mode de distribution : - Décentralisé, chaque nœud est indépendant et il n’y a pas besoin de serveur maître. - Développé en : C++ et Erlang. - Protocole : memcached pour l’accès aux clés, REST pour l’accès aux vues. - Points forts : - Excellentes performances dans l’accès aux clés, richesse fonctionnelle au niveau du serveur à travers les vues, élasticité de la montée en charge. Minyar Sassi Hidri Les BDs NoSQL 176 / 194
- 177. Quand aller versle NoSQL et quelle base choisir ? Comparaison des principales bases NoSQL Comparaison des principales bases NoSQL (5) Quelle base choisir ? I MongoDB : GNU AGPL v 3.0, licence Apache pour les pilotes. - `A choisir pour : - Tout type de besoin de stockage de documents, c’est-à-dire de données structurées : sérialisation d’objets, pages Web, formulaires de saisie, informations d’applications. - Maintien de la cohérence : - Cohérence finale à travers les réplicas. - Les écritures ont une option (write concern) pour indiquer qu’elles sont validées si elles ont écrit sur un certain nombre de réplicas ou sur une majorité (N/2+1). - Mode de distribution : - Centralisé, autosharding et réplication automatique. - Les métadonnées des shards sont centralisées sur un serveur de configuration, qui peut lui-même être répliqué pour fournir de la redondance. - La connexion client se fait aussi sur un serveur maître, qui redirige la requête vers le bon serveur de shard. Ce serveur maître peut lui aussi être redondant. - Développé en : C++. - Protocole : natif, question-réponse sur un socket. - Points forts : - Moteur solide, bonnes performances, simplicité d’utilisation du point de vue du développement client et bonne intégration des pilotes dans les langages. - Ses capacités de sharding et de réplication automatiques permettent de monter en charge horizontalement au fur et à mesure de l’augmentation des besoins. Minyar Sassi Hidri Les BDs NoSQL 177 / 194
- 178. Quand aller versle NoSQL et quelle base choisir ? Comparaison des principales bases NoSQL Comparaison des principales bases NoSQL (6) Quelle base choisir ? I Riak : Apache 2.0. - `A choisir pour : - Riak est un entrepôt de paires clé-valeur bien conçu, solide, performant et qui monte très bien en charge. - C’est un excellent choix pour un moteur qui doit à la fois être distribué et offrir une latence faible, sur des systèmes qui doivent être prêts à monter en charge très rapidement et de façon automatique. - Mode de distribution : - Décentralisé par hachage consistant, à la manière de Dynamo d’Amazon. - Pas de serveur maître et chaque nœud est indépendant. - Les connexions utilisateurs peuvent s’effectuer sur n’importe quel nœud, qui se chargera de rediriger le client vers le nœud contenant les données souhaitées. - Développé en : Erlang, un langage développé initialement par la société Ericksson et qui est spécialement adapté au traitement parallèle et à l’informatique distribuée. - Protocole : Protobuf et REST. Protobuf est bien sûr à privilégier pour de meilleures performances. L’interface REST est intéressante pour les opérations d’administration ou un accès aux données par des applications mobiles. - Points forts : - Une des implémentations qui se rapprochent le plus de Dynamo d’Amazon et qui reprend ses solutions techniques : hachage consistant, read repair, hinted handoffs, etc. Minyar Sassi Hidri Les BDs NoSQL 178 / 194
- 179. Quand aller versle NoSQL et quelle base choisir ? Comparaison des principales bases NoSQL Comparaison des principales bases NoSQL (7) Quelle base choisir ? I Redis : BSD (Berkeley Software Distribution Licence). - `A choisir pour : - Redis est un excellent choix pour maintenir des données en mémoire pour un accès en temps réel très rapide. - C’est une forme de remplacement d’un cache tel que memcached pour offrir une plus grande richesse fonctionnelle et une manipulation de structures de données plus riches. - Maintien de la cohérence : - Pas de notion particulière de cohérence. - Une seule écriture est bien sûr atomique. - Mode de distribution : - Décentralisé par hachage consistant, à la manière de Dynamo d’Amazon. - Pas de serveur maître et chaque nœud est indépendant. - Les connexions utilisateurs peuvent s’effectuer sur n’importe quel nœud, qui se chargera de rediriger le client vers le nœud contenant les données souhaitées. - Développé en : ANSI C. - Protocole : natif, mode question-réponse à travers un socket. - Points forts : - Extrême rapidité, solidité et intelligence de la construction, richesse fonctionnelle du langage pour la manipulation des données, opérations sur les ensembles. Minyar Sassi Hidri Les BDs NoSQL 179 / 194
- 180. Quand aller versle NoSQL et quelle base choisir ? Comparaison des principales bases NoSQL Comparaison des principales bases NoSQL (8) Comparatif des bases NoSQL Minyar Sassi Hidri Les BDs NoSQL 180 / 194
- 181. Mise en placed’une solution NoSQL 1 Quand aller vers le NoSQL et quelle base choisir ? 2 Mise en place d’une solution NoSQL 3 Maintenance et supervision des bases NoSQL Minyar Sassi Hidri Les BDs NoSQL 181 / 194
- 182. Mise en placed’une solution NoSQL Importation / Exportation de données Importation / Exportation de données MongoDB I MongoDB propose deux outils en ligne de commande pour effectuer des imports et des exports de fichiers au format JSON ou CSV. I Notez que le format de stockage MongoDB (BSON) comporte des types légèrement différents du JSON originel ; vous pouvez donc rencontrer des différences entre le JSON généré et les données stockées. I Exemple d’export : mongoexport −−db passerelles −−collection articles −−out ∼/passerelles.articles.json mongoexport −−db passerelles −−collection articles −−jsonArray −−out ∼/passerelles. articles.json mongoexport −−db passerelles −−collection articles −−query ’{ ”auteur.nom” : ”Brizard”}’ −−out ∼//passerelles.articles.brizard.json mongoexport −−db passerelles −−collection articles −−csv −−out ∼/passerelles.articles. csv −−fields=auteur.nom,auteur.e-mail - La première commande exporte la collection articles de la base passerelles dans un seul fichier JSON. - La deuxième fait de même mais génère un fichier contenant un tableau de documents JSON. - La troisième filtre les données pour n’exporter que les documents où le nom de l’auteur est Brizard. - Enfin, la dernière commande exporte le nom et l’e-mail de l’auteur dans un fichier séparé par des virgules, dont nous reproduisons le contenu ci-après. auteur.nom,auteur.e-mail ”Brizard”,”annie.brizardcocomail.com” ”Brizard”,”annie.brizard@cocomail.com” Minyar Sassi Hidri Les BDs NoSQL 182 / 194
- 183. Mise en placed’une solution NoSQL Importation / Exportation de données Importation / Exportation de données MongoDB I Une ligne d’en-tête avec le nom des colonnes a été ajoutée par mongoexport. I Exemple d’import de ce fichier CSV dans une nouvelle collection auteurs, qui sera automatiquement créée à l’import : mongoimport −−db passerelles −−collection auteurs −−type csv −−file ∼/passerelles. articles.csv −headerline I La ligne d’en-tête est comptée dans l’import, mais grâce à l’option -headerline, elle ne sera pas considérée comme une ligne de données. Voyons le contenu de notre collection dans l’invite mongo : > use passerelles ; switched to db passerelles > db.auteurs.find() ; {” id” : ObjectId(”50e2e278b95794cfad02012e”), ”auteur.nom” : ”Brizard”, ”auteur.email” : ”annie.brizardcocomail.com”} {” id” : ObjectId(”50e2e278b95794cfad02012f”), ”auteur.nom” : ”Brizard”, ”auteur.e-mail” : ”annie.brizardcocomail.com”} - `A partir d’un import CSV, MongoDB crée une structure BSON plate, non hiérarchique : la liste auteurs n’a pas été recréée. Minyar Sassi Hidri Les BDs NoSQL 183 / 194
- 184. Mise en placed’une solution NoSQL Importation / Exportation de données Importation de données Cassandra I Cassandra propose plusieurs outils pour réaliser des imports et des exports. I Le plus simple consiste à faire appel à des commandes CQL créées sur le modèle de commandes PostgreSQL : COPY FROM et COPY TO. I Exemple : la commande suivante - saisie dans une session cqlsh - exporte le contenu de la famille de colonnes articles dans un fichier articles.txt situé dans le répertoire personnel de l’utilisateur, en séparant les colonnes par une barre verticale, et en ajoutant en première ligne le nom des colonnes : COPY articles (KEY, auteur email, auteur nom, auteur prenom, titre) TO ’∼/articles.txt’ WITH DELIMITER = ’|’ AND QUOTE = ”” AND ESCAPE = ”” AND NULL = ’<null>’ AND HEADER = ’tr I La commande suivante réimporte le même fichier dans une famille de colonnes nommée articles import, que nous devons créer au préalable : CREATE TABLE articles import (KEY varchar PRIMARY KEY) ; COPY articles import (KEY, auteur email, auteur nom, auteur prenom, titre) FROM ’∼ / articles.txt’ WITH DELIMITER = ’|’ AND QUOTE = ”” AND ESCAPE = ”” AND HEADER = ’true’ ; - L’option NULL n’est pas reconnue dans le COPY FROM. L’inconvénient de cette méthode est qu’en présence de <null>, la colonne se créera quand même et stockera la valeur de chaîne ”<null>”. I Les utilitaires sstable2json et json2sstable permettent d’exporter une famille de colonnes contenue dans une SSTable vers un document JSON, et inversement. Son appel est très simple. Minyar Sassi Hidri Les BDs NoSQL 184 / 194
- 185. Mise en placed’une solution NoSQL Exemples de développements Exemples de développements I La distribution de Cassandra par DataStax comporte une application d’exemple en Java, nommée Portfolio Manager, qui utilise le pilote JDBC du langage CQL. Vous en trouvez un descriptif à cette adresse : http ://www.datastax.com/docs/1.0/getting started/dsc demo. I Twissandra est une application similaire à Twitter, utilisant Cassandra comme moteur de BD. Vous pouvez la tester sur http ://twissandra.com/. Malgré son interface un peu spartiate, les fonctionnalités sont basiquement semblables à Twitter. Les codes sources de cette application sont disponibles à l’adresse https ://github.com/twissandra/twissandra. I Des programmes de démonstration semblables existent pour Redis, disponibles à l’adresse http ://redis.io/topics/twitter-clone. Un autre exemple intéressant d’application basée sur Redis est haplocheirus (https ://github.com/twitter/haplocheirus), un système de gestion de timelines (lignes de temps). I NodeCellar (http ://nodecellar.coenraets.org/) est une application d’exemple utilisant NodeJS avec MongoDB comme moteur de données. Il s’agit d’une application de gestion de caves à vin. Le code source est disponible sur GitHub : https ://github.com/ccoenraets/nodecellar. I En ce qui concerne Riak, une liste de petites applications d’exemples est disponible sur le site de Basho : http ://docs.basho.com/riak/1.3.0/references/appendices/community/Sample- Applications/. I L’application Sofa, développée pour le livre CouchDB. Il s’agit d’une application de Blog totalement développée en CouchDB en utilisant CouchApp. Son code source est disponible à l’adresse https ://github.com/jchris/sofa. Minyar Sassi Hidri Les BDs NoSQL 185 / 194
- 186. Maintenance et supervisiondes bases NoSQL 1 Quand aller vers le NoSQL et quelle base choisir ? 2 Mise en place d’une solution NoSQL 3 Maintenance et supervision des bases NoSQL Minyar Sassi Hidri Les BDs NoSQL 186 / 194
- 187. Maintenance et supervisiondes bases NoSQL Tests de charge Tests de charge I Tests de charge : - Nombre d’utilisateurs - Volume de données qu’est capable de supporter un serveur. I HBase, Cassandra, Riak et MongoDB sont capables de monter en charge horizontalement et automatiquement par l’ajout de machines dans le cluster. I Pour supporter un pic d’activités, il suffit alors d’ajouter de nouvelles machines. I Exemple : Cassandra est livré avec un outil de test de charge, écrit en Java et nommé cassandra-stress (voir : http ://www.datastax.com/docs/1.1/references/stress java). Il y a quelques options intéressantes, notamment : - −−nodes : liste de nœuds sur lesquels il est possible d’effectuer le test. - −−threads : nombre de threads à exécuter, 50 par défaut. Minyar Sassi Hidri Les BDs NoSQL 187 / 194
- 188. Maintenance et supervisiondes bases NoSQL Supervision avec les outils Linux Supervision avec les outils Linux (1) I Linux comporte un certain nombre d’outils de supervision qui vous permettront de surveiller les performances de bases NoSQL. I Le plus utile est sysstat, une collection d’outils de supervision de performances développés par un Français nommé Sébastien Godard (http ://sebastien.godard.pagesperso-orange.fr/). I sysstat peut être installé sur Ubuntu par un paquet des dépôts officiels : sudo apt-get install sysstat I Lorsque le paquet est installé, vous avez à disposition plusieurs outils qui vous fournissent des indications sur l’état du système. I La commande iostat : - Retourne des statistiques de charge disque, cumulées depuis le démarrage du système. - Les colonnes retournées sont : - Device : le disque physique tel qu’il apparaît. - tps : nombre de transactions par seconde, lectures et écritures cumulées. - kB read/s : nombre de Ko lus par seconde. - kB wrtn/s : nombre de Ko écrits par seconde. - kB read : nombre total de Ko lus. - kB wrtn : nombre total de Ko écrits. Minyar Sassi Hidri Les BDs NoSQL 188 / 194
- 189. Maintenance et supervisiondes bases NoSQL Supervision avec les outils Linux Supervision avec les outils Linux (2) I La commande pidstat : - La commande pidstat retourne des informations sur un processus. - Vous pouvez l’utiliser pour surveiller différents aspects de votre moteur NoSQL, grâce aux options suivantes : - −d : informations sur l’activité disque. - −r : utilisation mémoire et fautes de pages. - −s : utilisation de la pile (stack). - −u : utilisation du CPU. - −w : changements de contextes. - −c : filtrage des processus par expression rationnelle pour ne conserver que les processus souhaités. - L’option −r donne des informations sur l’occupation mémoire et les fautes de pages. - Une faute de page indique un défaut de mémoire : le processus cherche à accéder à une page de mémoire dans l’espace d’adressage virtuel (la RAM rendue disponible par le système) à l’aide de l’adresse fournie par le SE, et cette page n’est pas présente à l’adresse désignée. Il faut donc que le système la récupère. - Si la faute est majeure (major page fault), la page n’est pas présente en mémoire, mais sur le disque (en swap), il faut donc la remonter en mémoire. - Un excès de fautes de pages majeures indique probablement qu’il n’y a pas assez de mémoire dans le système. Minyar Sassi Hidri Les BDs NoSQL 189 / 194
- 190. Maintenance et supervisiondes bases NoSQL Supervision avec les outils Linux Supervision avec les outils Linux (3) I Exemple MongoDB : pidstat -c mongod -r -p ALL I Le résultat retourne les colonnes suivantes : - minflt/s : nombre de fautes de pages mineures par seconde. - majflt/s : nombre de fautes de pages majeures par seconde. - VSZ : taille en mémoire virtuelle (la RAM allouée par le système au processus) en Ko. - RSS (Resident Set Size) : taille de mémoire physique, non swappée, utilisée par leprocessus et exprimée en Ko. - %MEM : pourcentage de mémoire physique utilisée par le processus. I La différence entre VSZ et RSS indique la partie de la mémoire du processus qui est dans le swap. I Cette occupation mémoire inclut l’utilisation de bibliothèques partagées, qui peuvent aussi être utilisées par d’autres processus. Minyar Sassi Hidri Les BDs NoSQL 190 / 194
- 191. Maintenance et supervisiondes bases NoSQL Supervision avec les outils Linux Supervision avec les outils Linux (4) I La commande sar : - sysstat installe un démon qui collecte des statistiques d’utilisation à travers le temps. - Pour activer cette collecte, éditez le fichier de configuration /etc/default/sysstat et changez ENABLED=”false” en ENABLED=”true”. Les statistiques seront collectées dans /var/log/sysstat/ et pourront être interrogées avec la commande sar. Les options de la commande sar sont : - −B : statistiques de pagination. - −b : statistiques d’entrées-sorties. - −d : statistiques disque pour chaque bloc présent dans /dev. - −H : statistiques d’utilisation des hugepages. - −m : statistiques de gestion d’énergie. - −n : statistiques réseau. - −q : statistiques sur les files d’attente et de la charge du système. - −R : statistiques mémoire. - −r : statistiques d’utilisation de la mémoire. - −u : utilisation des CPU. - −W : statistiques de swap. - −w : créations de tâches et switchs du système. - Exemple : sar −q 1 3 −−Demande des statistiques de file d’attente pour un intervalle d’une minute, sur les 3 dernières valeurs enregistrées. - Les hugepages sont des zones de mémoire qui sont allouées via la fonction système mmap() a des tailles bien plus importantes que les pages de mémoire traditionnelles. - Cette allocation permet de meilleures performances car la mémoire est accédée plus rapidement, sans qu’il soit nécessaire de recourir à des tables de traduction de l’adresse mémoire. Minyar Sassi Hidri Les BDs NoSQL 191 / 194
- 192. Maintenance et supervisiondes bases NoSQL Supervision avec les outils intégrés Supervision avec les outils intégrés MongoDB I Les moteurs NoSQL comportent souvent leurs propres outils de monitoring, qui vous permettent de suivre l’activité en récupérant des compteurs internes spécifiques. I MongoDB : - MongoDB inclut la commande mongostat, qui retourne en permanence le nombre de requêtes exécutées et d’autres indicateurs. - Les résultats obtenus avec la commande mongostat contient les indicateurs suivants : - insert : nombre d’objets insérés par seconde. - query : nombre de requêtes par seconde. - update : nombre d’objets modifiés par seconde. - delete : nombre d’objets supprimés par seconde. - getmore : nombre d’appels de curseurs sur des objets ouverts, par seconde. - command : nombre de commandes par seconde. - flushes : nombre de fsync() par seconde, donc de flush de la mémoire vers le disque. - mapped : total des données mappées en mémoire, en Mo. - vsize : taille de la mémoire utilisée par MongoDB. - res : taille de la mémoire résidente, non swappée. - faults : nombre de fautes de pages par seconde. - locked % : pourcentage de temps utilisé où un verrou global d’écriture est posé. - idx miss % : pourcentage de tentatives d’accès à une page d’index qui a déclenché une faute, donc où la page d’index n’était pas en mémoire et a dû être chargée depuis le disque. - qr|qw : longueur des files d’attente de lecture (r) et d’écriture (w). - ar|aw : nombre de clients en train de lire (r) et d’écrire (w). - NetIn : trafic réseau entrant en octets. - NetOut : trafic réseau sortant en octets. - conn : nombre de connexions ouvertes. Minyar Sassi Hidri Les BDs NoSQL 192 / 194
- 193. Maintenance et supervisiondes bases NoSQL Supervision avec les outils intégrés Supervision avec les outils intégrés (2) Cassandra I Cassandra inclut l’outil nodetool, qui permet d’administrer certains de ses éléments et de récupérer des informations. I Les commandes suivantes sont utiles pour la supervision : - nodetool ring : retourne des informations sur l’anneau des nœuds. - nodetool info : retourne des informations sur le nœud sur lequel il est exécuté. - nodetool cfstats : retourne des statistiques sur les familles de colonnes. - nodetool tpstats : retourne des informations sur les threads. - nodetool netstats : retourne des informations sur l’activité réseau. - nodetool compactionstats : retourne des informations sur les opérations de compactage. I Exemple d’appel de nodetool info : nous obtenons l’état du nœud, la taille occupée en mémoire, la taille et les statistiques du cache des clés et du cache des lignes. En combinant les différentes commandes nodetool, on peux effectivement surveiller l’activité de des nœuds Cassandra. Token : 50296331533206892393222798876815311727 Gossip active : true Thrift active : true Load : 316.99 MB Generation No : 1360329584 Uptime (seconds) : 190262 Heap Memory (MB) : 346,26 / 478,00 Data Center : datacenter1 Rack : rack1 Exceptions : 0 Key Cache : size 480 (bytes), capacity 24117216 (bytes), 13 hits, 23 requests, 0,565 recent hit rate, 14400 save period in seconds Row Cache : size 0 (bytes), capacity 0 (bytes), 0 hits, 0 requests, NaN recent hit rate, 0 save period in seconds Minyar Sassi Hidri Les BDs NoSQL 193 / 194
- 194. Maintenance et supervisiondes bases NoSQL Supervision avec Ganglia Supervision avec Ganglia I Ganglia (http ://ganglia.sourceforge.net/) est un système de supervision qui se distingue de ses concurrents libres comme Nagios par ses capacités de montée en charge. I Conçu dès le départ pour assurer la supervision d’architectures fortement distribuées (en grid), il permet de surveiller des dizaines de milliers de machines. I Développé à l’université de Berkeley, il est utilisé par un grand nombre d’entreprises de taille importante qui doivent gérer un très grand parc de machines, comme Twitter, Flickr, Reuters, Boeing et même Microsoft. I Ganglia est composé de plusieurs modules qui assurent différentes tâches permettant la distribution du travail de récupération des compteurs. - Le démon gmond recueille les mesures. - Le démon gmetad recueille les statistiques. - Une application Web (démon gweb) permet d’afficher ces statistiques et d’accumuler des graphes à l’aide de RRDTool, une bibliothèque de stockage et d’affichage de données journalisées dans le temps. I Installation et ajout de modules : https ://github.com/ganglia/gmond python modules/t. Minyar Sassi Hidri Les BDs NoSQL 194 / 194