Post on 09-Jan-2017
Formation NoSQL
Ceci est un extrait d’un formation NoSQL disponible sur
http://www.eisiform.com/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é.
SOLUTIONNoSQL
- 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.
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é
RelationnelNoSQL
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
RiakMysql
PostgreSQL
CouchBase Mongodb
HBaseII-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
WRITEWRITE
SlaveSlave
II-4. Sharding et replication
Duplication : Replica-set
Slave SlaveREADREAD
II-4. Sharding et replication
Duplication : Replica-set
Slave MasterREADREAD
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êteAVANTAGES
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éesAVANTAGES
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 sessionSession 1 -> JérémieSession 2 -> FrédéricSession 3 -> John
Request -> Session 3
Le besoin : Mémoire partagée
IV-1. Clé-valeur
S4
S2
S1
S3Load
bal
ance
rRequest -> Session 3
Session 1 -> JérémieSession 2 -> Frédéric
Session 3 -> JohnSession 4 -> Franck
Session 5 -> JohnSession 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 -> DocumentsBase 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.
AnalyseDé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
Ceci est un extrait d’un formation NoSQL disponible sur
http://www.eisiform.com/nosql/