Extrait d'une formation d'introduction au NoSQL et à Elasticsearch. L'objectif est de parfaitement comprendre les tenants et les aboutissants des différentes technologies NoSQL et d'avoir l'occasion de les manipuler. Le NoSQL permet à l'entreprise de résoudre avec des performances remarquables des problématiques complexes en adaptant le bon outil au bon usage. Pour suivre cette formation ou en savoir plus, rendez-vous sur http://constellation.tech/formation-nosql Constellation propose également des formations plus spécialisée telles que MongoDB, ELK ou des formations orientées Big Data et Machine learning. Bon visionnage :)

1. 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

8. La chocolaterie
I-4. Penser usage

9. La chocolaterie
?
I-4. Penser usage

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

44. III-3. Modélisation
3. Modélisation de la
donnée

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

63. IV-1. Clé-valeur
1. Bases clé-valeur

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

69. Cas d’utilisation

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

74. VI-2. Colonnes
2. Bases colonnes

75. […] Des slides sont sautés

76. Cas d’utilisation

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

83. IV-3. Documents
3. Bases documents

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

88. IV-4. Graphes
4. Bases graphes

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