SlideShare une entreprise Scribd logo
1  sur  106
Télécharger pour lire hors ligne
Formation NoSQL
Avant propos : NoSQL n’est ni une évolution,
ni une révolution !
I
C’est simplement de nouvelles opportunités.
I
I - Introduction au
NoSQL
I
[…] Des slides sont sautés
4. Stocker les données en
fonction des intentions d’usage
I-4. Penser usage
Quels objectifs ?
- Comprendre la notion d’usage de la donnée
- Avoir une première vision de la modélisation des données en fonction
de l’usage
I-4. Penser usage
- Quelles sont les conséquences d’une mauvaise modélisation de la
donnée
La chocolaterie
I-4. Penser usage
La chocolaterie
?
I-4. Penser usage
Le relationnel dans la réalité
Mon article de blog
Commentaires
Table articles
Table commentairesTable utilisateurs
I-4. Penser usage
Mon article de blog
Commentaires
Le NoSQL dans la réalité
I-4. Penser usage
Stockage de donnée déjà packagées
Titre : Mon article de blog
Contenu :
Commentaires : [
{ user, contenu … },
{ user, contenu … },
{ user, contenu … }
]
Une modélisation loupée
Titre : Mon article de blog
Contenu :
Commentaires : [
{ user, contenu … },
{ user, contenu … },
{ user, contenu … }
]
Titre : Mon article de blog
Contenu :
Commentaires : [
{ user, contenu … },
{ user, contenu … },
{ user, contenu … }
]
Titre : Mon article de blog
Contenu :
Commentaires : [
{ user, contenu … },
{ user, contenu … },
{ user, contenu … }
]
Titre : Mon article de blog
Contenu :
Commentaires : [
{ user, contenu … },
{ user, contenu … },
{ user, contenu … }
]
Titre : Mon article de blog
Contenu :
Commentaires : [
{ user, contenu … },
{ user, contenu … },
{ user, contenu … }
]
Titre : Mon article de blog
Contenu :
Commentaires : [
{ user, contenu … },
{ user, contenu … },
{ user, contenu … }
]
Titre : Mon article de blog
Contenu :
Commentaires : [
{ user, contenu … },
{ user, contenu … },
{ user, contenu … }
Titre : Mon article de blog
Contenu :
Commentaires : [
{ user, contenu … },
{ user, contenu … },
{ user, contenu … }
Titre : Mon article de blog
Contenu :
Commentaires : [
{ user, contenu … },
{ user, contenu … },
{ user, contenu … }
I-4
Titre : Mon article de blog
Contenu :
Commentaires : [
{ user, contenu … },
{ user, contenu … },
{ user, contenu … }
]
Titre : Mon article de blog
Contenu :
Commentaires : [
{ user, contenu … },
{ user, contenu … },
{ user, contenu … }
]
Titre : Mon article de blog
Contenu :
Commentaires : [
{ user, contenu … },
{ user, contenu … },
{ user, contenu … }
]
Titre : Mon article de blog
Contenu :
Commentaires : [
{ user, contenu … },
{ user, contenu … },
{ user, contenu … }
]
Titre : Mon article de blog
Contenu :
Commentaires : [
{ user, contenu … },
{ user, contenu … },
{ user, contenu … }
]
Titre : Mon article de blog
Contenu :
Commentaires : [
{ user, contenu … },
{ user, contenu … },
{ user, contenu … }
]
Titre : Mon article de blog
Contenu :
Commentaires : [
{ user, contenu … },
{ user, contenu … },
{ user, contenu … }
Titre : Mon article de blog
Contenu :
Commentaires : [
{ user, contenu … },
{ user, contenu … },
{ user, contenu … }
Titre : Mon article de blog
Contenu :
Commentaires : [
{ user, contenu … },
{ user, contenu … },
{ user, contenu … }
I-4
Comment récupérer les 10 derniers commentaires postés sur
le blog ?
Titre : Mon article de blog
Contenu :
Commentaires : [
{ user, contenu … },
{ user, contenu … },
{ user, contenu … }
]
Titre : Mon article de blog
Contenu :
Commentaires : [
{ user, contenu … },
{ user, contenu … },
{ user, contenu … }
]
Titre : Mon article de blog
Contenu :
Commentaires : [
{ user, contenu … },
{ user, contenu … },
{ user, contenu … }
]
A retenir
Le NoSQL demande de penser usage
Impossible de créer le schéma de la donnée sans connaitre l’expérience
utilisateur finale.
NoSQL est très performant pour un usage précis
En packageant toutes les données relatives à un usage précis, NoSQL ne
requête qu’un emplacement au lieu de « n » emplacements.
I-4. Penser usage
Le modèle relationnel est plus flexible
Dans le modèle relationnel, la donnée peut être assemblée à souhait quelque
soit la demande.
En NoSQL, un besoin non anticipé peut coûter très très cher en temps et
donc en performance.
5. Différence entre le
NoSQL et le Big Data
I-5. NoSQL et BigData
Pourquoi s’intéresser au Big data ?
- Comprendre en quoi NoSQL est un outil de choix pour le Big Data
- Savoir distinguer la limite entre Big Data et NoSQL
I-5. NoSQL et BigData
- Saisir l’étendu du Big Data
I-5. NoSQL et BigData
Qu’est ce que le Big Data ?
I-5. NoSQL et BigData
Manipulation de très gros volumes de données
provenant de sources hétérogènes.
Big data :
- Gros volume de données
PROBLEME
- Besoin de performance dans le traitement et la manipulation
des données
CONSEQUENCE
- Besoin de machines en cluster
- Besoin d’un design de la donnée performant et donc
pensé en fonction de l’usage plutôt que des relations
SOLUTION
NoSQL
I-5. NoSQL et BigData
- Données provenant de sources hétérogènes.
PROBLEME
- Besoin d’un design de donnée semi-structuré plutôt
que structuré.
SOLUTION
NoSQL
- Données non structurée que l’on va essayer d’organiser pour
pouvoir les traiter.
CONSEQUENCE
- La diversité initiale empêche de respecter un format rigide
de donnée finale.
I-5. NoSQL et BigData
[…] Des slides sont sautés
II - La scalabilité des
bases de donnée
II
2. Le théorème de CAP
II-2. Théorème de CAP
[…] Des slides sont sautés
Finalement, CAP revient à dire…
Partitionnement
(tolérance aux pannes)
II-2. Théorème de CAP
OU
Disponibilité
Cohérence
Mais dans la réalité, tout est en nuance…
Partitionnement
(tolérance aux pannes)
Disponibilité
Cohérence
II-2. Théorème de CAP
OU
Et en posant le problème autrement…
Partitionnement
(tolérance aux pannes)
Temps de réponse
Cohérence
Temps réel
Sécurité
OU
II-2. Théorème de CAP
C’est LE problème.
D’ou vient exactement ce temps de réponse ?
Crédits: kleppmann.com II-2
C dans CAP est différent de C dans ACID
ACID Cohérence de la donnée à l’échelle d’un seul
noeud.
CAP Cohérence de la donnée à l’échelle d’un cluster.
II-2. Théorème de CAP
Le cluster recherche de la stabilité
II-2. Théorème de CAP
• Lorsque la donnée est cohérente dans le cluster, tous
les noeuds renvoient le même contenu à la lecture.
• Le problème survient lorsqu’une requête insère une
nouvelle donnée et que celle-ci doit être propagée dans
les réplicas.
La différence entre Relationnel et NoSQL
• Relationnel est normalisé donc les transactions sont
essentielles et très fréquentes. Utilisation intensive de l’ACID.
• Or l’ACID sur un cluster est coûteux en temps
• Il scale plus ou moins facilement sur un cluster en fonction du
niveau de cohérence demandé
Relationnel
NoSQL
II-2
• NoSQL est pensé pour limiter le nombre de relations entre les
tables donc limiter le besoin de l’ACID. Donc plus performant.
Les bases de donnée en fonction de la cohérence
Disponibilité
Tolérant aux pannesCohérence
CouchDb
Cassandra
Riak
Mysql
PostgreSQL
CouchBase
Mongodb
HBase
II-2. Théorème de CAP
[…] Des slides sont sautés
4. Architecturer le cluster :
Distribution et duplication des
données
II-4. Sharding et replication
II-4. Sharding et replication
Duplication : Replica-set
Master
READ
READREAD
WRITE
WRITE
SlaveSlave
II-4. Sharding et replication
Duplication : Replica-set
Slave Slave
READREAD
II-4. Sharding et replication
Duplication : Replica-set
Slave Master
READREAD
II-4. Sharding et replication
Distribution : Sharding
M
S S
M
S S
M
S S
product facture, order users
productfacture, order users product facture, orderusers
II-4. Sharding et replication
Distribution : Sharding
M
S
M
S
M
S
Minimum pour 75 Go sur 3 shards25 Go 25 Go 25 Go
25 Go 25 Go 25 Go
- 6 serveurs pour les données
- 3 serveurs arbitres
III - Développer avec
NoSQL
III
III-2. Points communs
2. Points communs entre
les bases NoSQL
Quel points communs à toutes les bases NoSQL ?
Aucun.
III-2. Points communs
Quel points communs à la plupart des bases
NoSQL ?
- Un schéma implicite
- L’absence de relations
- L’absence du language SQL
III-2. Points communs
- L’open source
III-3. Modélisation
3. Modélisation de la
donnée
III-3. Modélisation
Rappel : Fonctionnement des bases relationnelles
- Support de l’ACID (transactions)
- Aucune redondance des données
- Des entités décrites par des métadonnée fortement typées
- Utilisation de jointures
- Les entités sont liées par des relations
- Les métadonnées ne sont pas dupliquée à chaque ligne
III-3
Rappel : Distribution et duplication en NoSQL
- Distribution de la donnée
Factures Clients Produits
Produits FacturesClients
- Replication de la donnée
Serveur 1 Serveur 2 Serveur 3
III-3
Factures Clients Produits
Produits FacturesClients
Serveur 1 Serveur 2 Serveur 3
Problème : Partitionnement des données
Dans ce cas de figure les jointures ne sont pas performantes
Solution apportée par le NoSQL
La donnée contient l’intégralité des informations
nécessaires pour une requête.
agrégat
III-3. Modélisation
La notion d’agrégat
- Une unité d’information complexe et isolée (semi-structurée)
- Identifiée par un élément racine (id)
- Traité / Stocké / Echangé de manière atomique
- On y accède uniquement par la racine
III-3. Modélisation
[…] Des slides sont sautés
L’agrégat en NoSQL
- Rapide car pas d’agrégat à construire lors de la requête
AVANTAGES
INCONVENIENT
- Entraine la duplication des données
- Plus besoin de transaction car l’agrégat est atomique avec lui
même
- Des données à mettre à jours à plusieurs endroits
- L’agrégat est désignée pour un usage précis et peu flexible
III-3. Modélisation
L’agrégation via les requêtes SQL
- Extrême flexibilité dans le requêtage des données
AVANTAGES
INCONVENIENT
- Besoin de transactions pour modifier les différentes tables en
« simultané »
- Aucune redondance de la donnée, ni des métadonnées
- Lenteur de l’exécution de la requête du à la formation de l’agrégat
- Difficulté pour distribuer la donnée sur le cluster, dû aux
dépendances entre les tables
III-3. Modélisation
III-4. Inconvénients
4. De nouvelles problématiques
de développement
III-4. Inconvénients
Problématique 1 : Schéma implicite
User
{ name: "Franck", age: 20 }
{ name: "Franck" }
{ name: "Franck", age: "20" }
{ book: "Colère de l’ombre", publication: 2005 }
[…] Des slides sont sautés
III-4. Inconvénients
Problématique 2 : Requêtage propriétaire
db.collection.find( {} )
MATCH (all) RETURN all
GET /collection
DESCRIBE keyspaces;
MongoDb
Neo4j
CouchDB
Cassandra
III-4. Inconvénients
Problématique 3 : Plus de normalisation
- Des données peuvent être dupliquées
- Les update / insert / delete doivent être réalisé à plusieurs
endroits
- Des scripts batch peuvent vérifier l’état de la donnée ou la
corriger
III-4. Inconvénients
Problématique 4 : Gestions des transactions ACID
[…] Des slides sont sautés
III-4. Inconvénients
Problématique 5 : Gestions des modifications concurrentes
[…] Des slides sont sautés
IV - Les différents
types de bases
IV
IV-1. Clé-valeur
1. Bases clé-valeur
IV-1. Clé-valeur
S1
RAM : Hash map session
Session 1 -> Jérémie
Session 2 -> Frédéric
Session 3 -> John
Request ->
Session 3
Le besoin : Mémoire partagée
IV-1. Clé-valeur
S4
S2
S1
S3
Loadbalancer
Request ->
Session 3
Session 1 -> Jérémie
Session 2 -> Frédéric
Session 3 -> John
Session 4 -> Franck
Session 5 -> John
Session 6 -> Franck ?
RAM : Hash map session
Le besoin : Mémoire partagée
[…] Des slides sont sautés
Autre besoin : Queue
- Envoi d’email est très lent
- Inscription -> Email de validation
- Envoi de l’email en différé
IV-1. Clé-valeur
[…] Des slides sont sautés
Cas d’utilisation
[…] Des slides sont sautés
Découverte de Redis
IV-1. Clé-valeur
set "formation:the.mail.queue:state" "enable"
Commande redis
Clé respectant le standard Valeur
Découverte de Redis : Types de données
IV-1. Clé-valeur
- String (set, get, incr, incrby…)
- List (lpush, rpush, lindex, lrange…)
- Hash (hset, hmset, hget…)
- Set (sadd, sdiff, sunion…)
- Sorted set (zadd, zscore, zrange…)
[…] Des slides sont sautés
VI-2. Colonnes
2. Bases colonnes
[…] Des slides sont sautés
Cas d’utilisation
Fonctionnalité Ebay : Likes, Own, Want
Fonctionnalité Ebay : Exemple des likes
Crédits : Ebay Tech blog
Fonctionnalité Ebay : Exemple des likes
Crédits : Ebay Tech blog
Fonctionnalité Ebay : Exemple des likes
Crédits : Ebay Tech blog
Fonctionnalité Ebay : Exemple des likes
Crédits : Ebay Tech blog
Fonctionnalité Ebay : Performances finales
Crédits : Ebay Tech blog
Mysql : ~ 3 ms / requête
Cassandra : ~ 0.12 ms / requête
IV-3. Documents
3. Bases documents
IV-3. Documents
Les besoins
- Création d’entités classique (user, facture, produits…)
- Une majorité de requête read et peu en write
- Savoir à l’avance les requêtes que l’on va faire
+
Populaire
IV-3. Documents
Les bases du modèle de donnée
- Base de donnée -> Collection -> Documents
Base de donnée Table Rows
- Donnée semi-structurées en JSON
{ user: jeremie, hobbies: [technologie, sport]}
Construction du modèle d’un blog
- Afficher l’article sur la page article et les 10 premiers
commentaires. Charger les suivants si l’utilisateur scroll.
- Afficher le résumé des 5 derniers articles sur la page d’accueil,
le top 3 des articles et les 2 derniers commentaires
- Les auteurs peuvent se connecter pour rédiger des articles et ont
un ou des rôles spécifiques (admin, rédacteur, correcteur…)
IV-3. Documents
- Lister les articles d’un auteur
[…] Des slides sont sautés
IV-4. Graphes
4. Bases graphes
Besoin : Relations nombreuses et complexes
Relation bi-directionelle
Relation directionelle
Entité de type différent
Personne Voiture
Relation qui a plus de poids
Emprunte à
Relation nommée
[…] Des slides sont sautés
Pourquoi choisir une base graphe ?
- Facilité de requêtage dans le graphe
- Haute performance sur les graphes
- ACID + Forte cohérence dans le cluster
IV-4. Graphes
[…] Des slides sont sautés
V - Vers le NewSQL ?
V
V-3. Etat du NewSQL
1. Notion de NewSQL
Google Megastore
We believe it is better to have application programmers
deal with performance problems due to overuse of
transactions as bottlenecks arise, rather than always
coding around the lack of transactions.
V-1. Notion de NewSQL
[…] Des slides sont sautés
Le NewSQL aujourd’hui
V-1. Notion de NewSQL
V-2. In-Memory et BigData
3. NewSQL in-memory et
BigData
Usage classique de VoltDB
Un important flux de données entrantesIngère
Nécessite un traitement par évènement pour
analyser les résultats en temps réel.
Analyse
Décide
Exporte les données vers une base persistence
pour du stockage ou du batch ultérieur par exemple
(Export)
V-2. In-Memory et BigData
Crédits : VoltDB
Big Data streaming architecture
V-2. In-Memory et BigData
VI - Elastic Search
VI
1. Particularités de la base
Elastic Search
VI-1. Spécificités Elasticsearch
[…] Des slides sont sautés
VI-1. Spécificités Elasticsearch
Elastic Search
- Bâti autour de Apache Lucene
- Ajoute la persistence (stockage) des données à Lucene
- Simplifie la configuration et unifie / approfondit le requêtage
- Base de donnée document NoSQL ayant un index inversé
2. Expérimentations sur
elastic search
VI-2. Expérimentations
Indexation, Requêtage, Filtrage, Facette, Aggrégation, géolocalisation,
catégorisation…
[…] Des slides sont sautés

Contenu connexe

Tendances (6)

Les BD NoSQL
Les BD NoSQLLes BD NoSQL
Les BD NoSQL
 
Nosql, hadoop, map reduce, hbase, sqoop, voldemort, cassandra -intro
Nosql, hadoop, map reduce, hbase, sqoop, voldemort, cassandra -introNosql, hadoop, map reduce, hbase, sqoop, voldemort, cassandra -intro
Nosql, hadoop, map reduce, hbase, sqoop, voldemort, cassandra -intro
 
Vhdl
VhdlVhdl
Vhdl
 
Bases de données NoSQL
Bases de données NoSQLBases de données NoSQL
Bases de données NoSQL
 
Bases de données réparties
Bases de données répartiesBases de données réparties
Bases de données réparties
 
cours base de données
cours base de donnéescours base de données
cours base de données
 

Similaire à Formation NoSQL

Optimisation des performances d’un site sous TYPO3
Optimisation des performances d’un site sous TYPO3Optimisation des performances d’un site sous TYPO3
Optimisation des performances d’un site sous TYPO3
Aliénor.net
 
Dwh udl 2014_2015_v0.22 - student
Dwh udl 2014_2015_v0.22 - studentDwh udl 2014_2015_v0.22 - student
Dwh udl 2014_2015_v0.22 - student
Carlos Sanin
 
Devoir Final dans No Sql Base de donnée avec corrigé
Devoir Final dans No Sql Base de donnée avec corrigéDevoir Final dans No Sql Base de donnée avec corrigé
Devoir Final dans No Sql Base de donnée avec corrigé
RimaDaqch
 

Similaire à Formation NoSQL (20)

Toutes les raisons d'adopter MongoDB
Toutes les raisons d'adopter MongoDBToutes les raisons d'adopter MongoDB
Toutes les raisons d'adopter MongoDB
 
Réussir une montée en charge avec MongoDB
Réussir une montée en charge avec MongoDBRéussir une montée en charge avec MongoDB
Réussir une montée en charge avec MongoDB
 
Alphorm.com-Formation MongoDB Administration
Alphorm.com-Formation MongoDB AdministrationAlphorm.com-Formation MongoDB Administration
Alphorm.com-Formation MongoDB Administration
 
Introduction aux bases de données NoSQL
Introduction aux bases de données NoSQLIntroduction aux bases de données NoSQL
Introduction aux bases de données NoSQL
 
Optimisation des performances d’un site sous TYPO3
Optimisation des performances d’un site sous TYPO3Optimisation des performances d’un site sous TYPO3
Optimisation des performances d’un site sous TYPO3
 
00_intro_PrincipRelatConceptOracle.pdf
00_intro_PrincipRelatConceptOracle.pdf00_intro_PrincipRelatConceptOracle.pdf
00_intro_PrincipRelatConceptOracle.pdf
 
Global Training Day Paris - Drupal 8
Global Training Day Paris - Drupal 8Global Training Day Paris - Drupal 8
Global Training Day Paris - Drupal 8
 
MariaDB une base de donnees NewSQL
MariaDB une base de donnees NewSQLMariaDB une base de donnees NewSQL
MariaDB une base de donnees NewSQL
 
Base de donnees Avancees et Intro à NoSQL.ppt
Base de donnees Avancees et Intro à  NoSQL.pptBase de donnees Avancees et Intro à  NoSQL.ppt
Base de donnees Avancees et Intro à NoSQL.ppt
 
Webinaire 3 de la série « Retour aux fondamentaux » : Conception de schémas :...
Webinaire 3 de la série « Retour aux fondamentaux » : Conception de schémas :...Webinaire 3 de la série « Retour aux fondamentaux » : Conception de schémas :...
Webinaire 3 de la série « Retour aux fondamentaux » : Conception de schémas :...
 
Cours bases de données partie 1 Prof. Khalifa MANSOURI
Cours bases de données partie 1 Prof. Khalifa MANSOURICours bases de données partie 1 Prof. Khalifa MANSOURI
Cours bases de données partie 1 Prof. Khalifa MANSOURI
 
Dwh udl 2014_2015_v0.22 - student
Dwh udl 2014_2015_v0.22 - studentDwh udl 2014_2015_v0.22 - student
Dwh udl 2014_2015_v0.22 - student
 
Drupal7 - Bonnes Pratiques (Partie 1)
Drupal7 - Bonnes Pratiques (Partie 1)Drupal7 - Bonnes Pratiques (Partie 1)
Drupal7 - Bonnes Pratiques (Partie 1)
 
Mariadb une base de données NewSQL
Mariadb une base de données NewSQLMariadb une base de données NewSQL
Mariadb une base de données NewSQL
 
Devoir Final dans No Sql Base de donnée avec corrigé
Devoir Final dans No Sql Base de donnée avec corrigéDevoir Final dans No Sql Base de donnée avec corrigé
Devoir Final dans No Sql Base de donnée avec corrigé
 
Cours SGBD - L3 Bio-informatique - Mohamed Skander DAAS.pdf
Cours SGBD  - L3 Bio-informatique - Mohamed Skander DAAS.pdfCours SGBD  - L3 Bio-informatique - Mohamed Skander DAAS.pdf
Cours SGBD - L3 Bio-informatique - Mohamed Skander DAAS.pdf
 
BDRO.pdf
BDRO.pdfBDRO.pdf
BDRO.pdf
 
Création de bases de données
Création de bases de donnéesCréation de bases de données
Création de bases de données
 
MySQL Innovation & Cloud Day - Document Store avec MySQL HeatWave Database Se...
MySQL Innovation & Cloud Day - Document Store avec MySQL HeatWave Database Se...MySQL Innovation & Cloud Day - Document Store avec MySQL HeatWave Database Se...
MySQL Innovation & Cloud Day - Document Store avec MySQL HeatWave Database Se...
 
Bases de donnees fondamentaux
Bases de donnees fondamentauxBases de donnees fondamentaux
Bases de donnees fondamentaux
 

Formation NoSQL

  • 2. Avant propos : NoSQL n’est ni une évolution, ni une révolution ! I
  • 3. C’est simplement de nouvelles opportunités. I
  • 4. I - Introduction au NoSQL I
  • 5. […] Des slides sont sautés
  • 6. 4. Stocker les données en fonction des intentions d’usage I-4. Penser usage
  • 7. Quels objectifs ? - Comprendre la notion d’usage de la donnée - Avoir une première vision de la modélisation des données en fonction de l’usage I-4. Penser usage - Quelles sont les conséquences d’une mauvaise modélisation de la donnée
  • 10. Le relationnel dans la réalité Mon article de blog Commentaires Table articles Table commentairesTable utilisateurs I-4. Penser usage
  • 11. Mon article de blog Commentaires Le NoSQL dans la réalité I-4. Penser usage Stockage de donnée déjà packagées Titre : Mon article de blog Contenu : Commentaires : [ { user, contenu … }, { user, contenu … }, { user, contenu … } ]
  • 12. Une modélisation loupée Titre : Mon article de blog Contenu : Commentaires : [ { user, contenu … }, { user, contenu … }, { user, contenu … } ] Titre : Mon article de blog Contenu : Commentaires : [ { user, contenu … }, { user, contenu … }, { user, contenu … } ] Titre : Mon article de blog Contenu : Commentaires : [ { user, contenu … }, { user, contenu … }, { user, contenu … } ] Titre : Mon article de blog Contenu : Commentaires : [ { user, contenu … }, { user, contenu … }, { user, contenu … } ] Titre : Mon article de blog Contenu : Commentaires : [ { user, contenu … }, { user, contenu … }, { user, contenu … } ] Titre : Mon article de blog Contenu : Commentaires : [ { user, contenu … }, { user, contenu … }, { user, contenu … } ] Titre : Mon article de blog Contenu : Commentaires : [ { user, contenu … }, { user, contenu … }, { user, contenu … } Titre : Mon article de blog Contenu : Commentaires : [ { user, contenu … }, { user, contenu … }, { user, contenu … } Titre : Mon article de blog Contenu : Commentaires : [ { user, contenu … }, { user, contenu … }, { user, contenu … } I-4
  • 13. Titre : Mon article de blog Contenu : Commentaires : [ { user, contenu … }, { user, contenu … }, { user, contenu … } ] Titre : Mon article de blog Contenu : Commentaires : [ { user, contenu … }, { user, contenu … }, { user, contenu … } ] Titre : Mon article de blog Contenu : Commentaires : [ { user, contenu … }, { user, contenu … }, { user, contenu … } ] Titre : Mon article de blog Contenu : Commentaires : [ { user, contenu … }, { user, contenu … }, { user, contenu … } ] Titre : Mon article de blog Contenu : Commentaires : [ { user, contenu … }, { user, contenu … }, { user, contenu … } ] Titre : Mon article de blog Contenu : Commentaires : [ { user, contenu … }, { user, contenu … }, { user, contenu … } ] Titre : Mon article de blog Contenu : Commentaires : [ { user, contenu … }, { user, contenu … }, { user, contenu … } Titre : Mon article de blog Contenu : Commentaires : [ { user, contenu … }, { user, contenu … }, { user, contenu … } Titre : Mon article de blog Contenu : Commentaires : [ { user, contenu … }, { user, contenu … }, { user, contenu … } I-4 Comment récupérer les 10 derniers commentaires postés sur le blog ? Titre : Mon article de blog Contenu : Commentaires : [ { user, contenu … }, { user, contenu … }, { user, contenu … } ] Titre : Mon article de blog Contenu : Commentaires : [ { user, contenu … }, { user, contenu … }, { user, contenu … } ] Titre : Mon article de blog Contenu : Commentaires : [ { user, contenu … }, { user, contenu … }, { user, contenu … } ]
  • 14. A retenir Le NoSQL demande de penser usage Impossible de créer le schéma de la donnée sans connaitre l’expérience utilisateur finale. NoSQL est très performant pour un usage précis En packageant toutes les données relatives à un usage précis, NoSQL ne requête qu’un emplacement au lieu de « n » emplacements. I-4. Penser usage Le modèle relationnel est plus flexible Dans le modèle relationnel, la donnée peut être assemblée à souhait quelque soit la demande. En NoSQL, un besoin non anticipé peut coûter très très cher en temps et donc en performance.
  • 15. 5. Différence entre le NoSQL et le Big Data I-5. NoSQL et BigData
  • 16. Pourquoi s’intéresser au Big data ? - Comprendre en quoi NoSQL est un outil de choix pour le Big Data - Savoir distinguer la limite entre Big Data et NoSQL I-5. NoSQL et BigData - Saisir l’étendu du Big Data
  • 17. I-5. NoSQL et BigData Qu’est ce que le Big Data ?
  • 18. I-5. NoSQL et BigData Manipulation de très gros volumes de données provenant de sources hétérogènes. Big data :
  • 19. - Gros volume de données PROBLEME - Besoin de performance dans le traitement et la manipulation des données CONSEQUENCE - Besoin de machines en cluster - Besoin d’un design de la donnée performant et donc pensé en fonction de l’usage plutôt que des relations SOLUTION NoSQL I-5. NoSQL et BigData
  • 20. - Données provenant de sources hétérogènes. PROBLEME - Besoin d’un design de donnée semi-structuré plutôt que structuré. SOLUTION NoSQL - Données non structurée que l’on va essayer d’organiser pour pouvoir les traiter. CONSEQUENCE - La diversité initiale empêche de respecter un format rigide de donnée finale. I-5. NoSQL et BigData
  • 21. […] Des slides sont sautés
  • 22. II - La scalabilité des bases de donnée II
  • 23. 2. Le théorème de CAP II-2. Théorème de CAP
  • 24. […] Des slides sont sautés
  • 25. Finalement, CAP revient à dire… Partitionnement (tolérance aux pannes) II-2. Théorème de CAP OU Disponibilité Cohérence
  • 26. Mais dans la réalité, tout est en nuance… Partitionnement (tolérance aux pannes) Disponibilité Cohérence II-2. Théorème de CAP OU
  • 27. Et en posant le problème autrement… Partitionnement (tolérance aux pannes) Temps de réponse Cohérence Temps réel Sécurité OU II-2. Théorème de CAP C’est LE problème.
  • 28. D’ou vient exactement ce temps de réponse ? Crédits: kleppmann.com II-2
  • 29. C dans CAP est différent de C dans ACID ACID Cohérence de la donnée à l’échelle d’un seul noeud. CAP Cohérence de la donnée à l’échelle d’un cluster. II-2. Théorème de CAP
  • 30. Le cluster recherche de la stabilité II-2. Théorème de CAP • Lorsque la donnée est cohérente dans le cluster, tous les noeuds renvoient le même contenu à la lecture. • Le problème survient lorsqu’une requête insère une nouvelle donnée et que celle-ci doit être propagée dans les réplicas.
  • 31. La différence entre Relationnel et NoSQL • Relationnel est normalisé donc les transactions sont essentielles et très fréquentes. Utilisation intensive de l’ACID. • Or l’ACID sur un cluster est coûteux en temps • Il scale plus ou moins facilement sur un cluster en fonction du niveau de cohérence demandé Relationnel NoSQL II-2 • NoSQL est pensé pour limiter le nombre de relations entre les tables donc limiter le besoin de l’ACID. Donc plus performant.
  • 32. Les bases de donnée en fonction de la cohérence Disponibilité Tolérant aux pannesCohérence CouchDb Cassandra Riak Mysql PostgreSQL CouchBase Mongodb HBase II-2. Théorème de CAP
  • 33. […] Des slides sont sautés
  • 34. 4. Architecturer le cluster : Distribution et duplication des données II-4. Sharding et replication
  • 35. II-4. Sharding et replication Duplication : Replica-set Master READ READREAD WRITE WRITE SlaveSlave
  • 36. II-4. Sharding et replication Duplication : Replica-set Slave Slave READREAD
  • 37. II-4. Sharding et replication Duplication : Replica-set Slave Master READREAD
  • 38. II-4. Sharding et replication Distribution : Sharding M S S M S S M S S product facture, order users productfacture, order users product facture, orderusers
  • 39. II-4. Sharding et replication Distribution : Sharding M S M S M S Minimum pour 75 Go sur 3 shards25 Go 25 Go 25 Go 25 Go 25 Go 25 Go - 6 serveurs pour les données - 3 serveurs arbitres
  • 40. III - Développer avec NoSQL III
  • 41. III-2. Points communs 2. Points communs entre les bases NoSQL
  • 42. Quel points communs à toutes les bases NoSQL ? Aucun. III-2. Points communs
  • 43. Quel points communs à la plupart des bases NoSQL ? - Un schéma implicite - L’absence de relations - L’absence du language SQL III-2. Points communs - L’open source
  • 45. III-3. Modélisation Rappel : Fonctionnement des bases relationnelles - Support de l’ACID (transactions) - Aucune redondance des données - Des entités décrites par des métadonnée fortement typées - Utilisation de jointures - Les entités sont liées par des relations - Les métadonnées ne sont pas dupliquée à chaque ligne
  • 46. III-3 Rappel : Distribution et duplication en NoSQL - Distribution de la donnée Factures Clients Produits Produits FacturesClients - Replication de la donnée Serveur 1 Serveur 2 Serveur 3
  • 47. III-3 Factures Clients Produits Produits FacturesClients Serveur 1 Serveur 2 Serveur 3 Problème : Partitionnement des données Dans ce cas de figure les jointures ne sont pas performantes
  • 48. Solution apportée par le NoSQL La donnée contient l’intégralité des informations nécessaires pour une requête. agrégat III-3. Modélisation
  • 49. La notion d’agrégat - Une unité d’information complexe et isolée (semi-structurée) - Identifiée par un élément racine (id) - Traité / Stocké / Echangé de manière atomique - On y accède uniquement par la racine III-3. Modélisation
  • 50. […] Des slides sont sautés
  • 51. L’agrégat en NoSQL - Rapide car pas d’agrégat à construire lors de la requête AVANTAGES INCONVENIENT - Entraine la duplication des données - Plus besoin de transaction car l’agrégat est atomique avec lui même - Des données à mettre à jours à plusieurs endroits - L’agrégat est désignée pour un usage précis et peu flexible III-3. Modélisation
  • 52. L’agrégation via les requêtes SQL - Extrême flexibilité dans le requêtage des données AVANTAGES INCONVENIENT - Besoin de transactions pour modifier les différentes tables en « simultané » - Aucune redondance de la donnée, ni des métadonnées - Lenteur de l’exécution de la requête du à la formation de l’agrégat - Difficulté pour distribuer la donnée sur le cluster, dû aux dépendances entre les tables III-3. Modélisation
  • 53. III-4. Inconvénients 4. De nouvelles problématiques de développement
  • 54. III-4. Inconvénients Problématique 1 : Schéma implicite User { name: "Franck", age: 20 } { name: "Franck" } { name: "Franck", age: "20" } { book: "Colère de l’ombre", publication: 2005 }
  • 55. […] Des slides sont sautés
  • 56. III-4. Inconvénients Problématique 2 : Requêtage propriétaire db.collection.find( {} ) MATCH (all) RETURN all GET /collection DESCRIBE keyspaces; MongoDb Neo4j CouchDB Cassandra
  • 57. III-4. Inconvénients Problématique 3 : Plus de normalisation - Des données peuvent être dupliquées - Les update / insert / delete doivent être réalisé à plusieurs endroits - Des scripts batch peuvent vérifier l’état de la donnée ou la corriger
  • 58. III-4. Inconvénients Problématique 4 : Gestions des transactions ACID
  • 59. […] Des slides sont sautés
  • 60. III-4. Inconvénients Problématique 5 : Gestions des modifications concurrentes
  • 61. […] Des slides sont sautés
  • 62. IV - Les différents types de bases IV
  • 64. IV-1. Clé-valeur S1 RAM : Hash map session Session 1 -> Jérémie Session 2 -> Frédéric Session 3 -> John Request -> Session 3 Le besoin : Mémoire partagée
  • 65. IV-1. Clé-valeur S4 S2 S1 S3 Loadbalancer Request -> Session 3 Session 1 -> Jérémie Session 2 -> Frédéric Session 3 -> John Session 4 -> Franck Session 5 -> John Session 6 -> Franck ? RAM : Hash map session Le besoin : Mémoire partagée
  • 66. […] Des slides sont sautés
  • 67. Autre besoin : Queue - Envoi d’email est très lent - Inscription -> Email de validation - Envoi de l’email en différé IV-1. Clé-valeur
  • 68. […] Des slides sont sautés
  • 70. […] Des slides sont sautés
  • 71. Découverte de Redis IV-1. Clé-valeur set "formation:the.mail.queue:state" "enable" Commande redis Clé respectant le standard Valeur
  • 72. Découverte de Redis : Types de données IV-1. Clé-valeur - String (set, get, incr, incrby…) - List (lpush, rpush, lindex, lrange…) - Hash (hset, hmset, hget…) - Set (sadd, sdiff, sunion…) - Sorted set (zadd, zscore, zrange…)
  • 73. […] Des slides sont sautés
  • 75. […] Des slides sont sautés
  • 77. Fonctionnalité Ebay : Likes, Own, Want
  • 78. Fonctionnalité Ebay : Exemple des likes Crédits : Ebay Tech blog
  • 79. Fonctionnalité Ebay : Exemple des likes Crédits : Ebay Tech blog
  • 80. Fonctionnalité Ebay : Exemple des likes Crédits : Ebay Tech blog
  • 81. Fonctionnalité Ebay : Exemple des likes Crédits : Ebay Tech blog
  • 82. Fonctionnalité Ebay : Performances finales Crédits : Ebay Tech blog Mysql : ~ 3 ms / requête Cassandra : ~ 0.12 ms / requête
  • 84. IV-3. Documents Les besoins - Création d’entités classique (user, facture, produits…) - Une majorité de requête read et peu en write - Savoir à l’avance les requêtes que l’on va faire + Populaire
  • 85. IV-3. Documents Les bases du modèle de donnée - Base de donnée -> Collection -> Documents Base de donnée Table Rows - Donnée semi-structurées en JSON { user: jeremie, hobbies: [technologie, sport]}
  • 86. Construction du modèle d’un blog - Afficher l’article sur la page article et les 10 premiers commentaires. Charger les suivants si l’utilisateur scroll. - Afficher le résumé des 5 derniers articles sur la page d’accueil, le top 3 des articles et les 2 derniers commentaires - Les auteurs peuvent se connecter pour rédiger des articles et ont un ou des rôles spécifiques (admin, rédacteur, correcteur…) IV-3. Documents - Lister les articles d’un auteur
  • 87. […] Des slides sont sautés
  • 89. Besoin : Relations nombreuses et complexes Relation bi-directionelle Relation directionelle Entité de type différent Personne Voiture Relation qui a plus de poids Emprunte à Relation nommée
  • 90. […] Des slides sont sautés
  • 91. Pourquoi choisir une base graphe ? - Facilité de requêtage dans le graphe - Haute performance sur les graphes - ACID + Forte cohérence dans le cluster IV-4. Graphes
  • 92. […] Des slides sont sautés
  • 93. V - Vers le NewSQL ? V
  • 94. V-3. Etat du NewSQL 1. Notion de NewSQL
  • 95. Google Megastore We believe it is better to have application programmers deal with performance problems due to overuse of transactions as bottlenecks arise, rather than always coding around the lack of transactions. V-1. Notion de NewSQL
  • 96. […] Des slides sont sautés
  • 97. Le NewSQL aujourd’hui V-1. Notion de NewSQL
  • 98. V-2. In-Memory et BigData 3. NewSQL in-memory et BigData
  • 99. Usage classique de VoltDB Un important flux de données entrantesIngère Nécessite un traitement par évènement pour analyser les résultats en temps réel. Analyse Décide Exporte les données vers une base persistence pour du stockage ou du batch ultérieur par exemple (Export) V-2. In-Memory et BigData
  • 100. Crédits : VoltDB Big Data streaming architecture V-2. In-Memory et BigData
  • 101. VI - Elastic Search VI
  • 102. 1. Particularités de la base Elastic Search VI-1. Spécificités Elasticsearch
  • 103. […] Des slides sont sautés
  • 104. VI-1. Spécificités Elasticsearch Elastic Search - Bâti autour de Apache Lucene - Ajoute la persistence (stockage) des données à Lucene - Simplifie la configuration et unifie / approfondit le requêtage - Base de donnée document NoSQL ayant un index inversé
  • 105. 2. Expérimentations sur elastic search VI-2. Expérimentations Indexation, Requêtage, Filtrage, Facette, Aggrégation, géolocalisation, catégorisation…
  • 106. […] Des slides sont sautés