Le document présente les différences entre SGBDR et NoSQL, en détaillant les types de bases NoSQL (clés/valeurs, colonnes, documents, graphes) et leurs cas d'utilisation respectifs. Il met en avant les avantages des bases NoSQL, telles que la flexibilité et la rapidité, tout en soulignant leurs inconvénients, notamment le manque de structure et de contrôle sur l'intégrité des données. En conclusion, bien que NoSQL offre plus de souplesse et de rapidité, il impose des précautions supplémentaires pour maintenir la cohérence et l'intégrité des données.

1. SGBDR vs NOSQL
Différences et « Uses Cases »
(ou dans quels cas utiliser l’un plutôt que l’autre au-delà de l’effet de mode ;p)
- Présentation par Eric DYKSTEIN le 19 Avril 2018 @ Epitech, Montpellier -
Montpellier

2. Qu’est-ce que le NOSQL ?
Montpelllier

3. Qu’est-ce que le NOSQL ?
• Acronyme créé en 2009 : « Not Only SQL » -> il n’y a pas que le SQL dans la vie ;) !
• Moteurs de stockage de bases de données plus que « Systèmes de Gestion » :
→ Données stockées de manière non structurée (chaque « record » peut contenir des champs ≠ )
→ Aucun contrôle sur l’intégrité des données (aucune règle d’écriture applicable -> les propriétés
« cohérence » et/ou « isolation » du concept ACID ne sont généralement pas respectées)
→ Aucun système d’intégrité référentielle des données entre « entités » différentes.
→ Systèmes de requêtage des données plus ou moins élaborés
• 4 familles / types de moteurs de stockage distincts :
→ Clés / valeurs (ex : Redis, DynamoDB, Voldemort)
→ Colonnes (ex : Cassandra, BigTables, Hbase)
→ Documents (ex : MongoDB, CouchDB, CouchBase)
→ Graphe (ex : Neo4j)
Montpelllier

4. Pourquoi le NOSQL ?
Montpelllier

5. Pourquoi le NOSQL ?
• Pour répondre à des problématiques spécifiques de performance :
→ En cas de très grosse volumétrie de données
→ En cas de très grosses montées en charges (sites à fort trafic)
vLes moteurs NOSQL sont plus rapides en lecture et en écriture qu’un SGBDR classique car ils
n’effectuent aucun contrôle sur les données, la plupart peuvent charger leurs données en
mémoire vive et/ou être répartis sur plusieurs serveurs en parallèle (sharding).
• Pour répondre à des problématiques fonctionnelles spécifiques :
→ Designer une base de donnée pour développer un système de gestion du cache (modèle Clés /
Valeurs)
→ Designer une base de données à la structure « super flexible » pour la réalisation d’un POC ou
d’un MVP (modèles Documents et Colonnes)
→ Designer une base de données à nœuds multiples (type réseau social via le modèle Graphe)
→ Designer une base de données pour se lancer dans l’aventure « Big Data » <(-_-)>
Montpelllier

6. Les bases de données de type Clé / Valeur
• Elles permettent un stockage de paires « clé / valeur » : la clé identifie
l’enregistrement, la valeur étant la (ou les données) elle(s)-même(s)
qui est/sont gérée(s) de manière « opaque » -> le type de donnée(s)
est indéterminé et stocké généralement de manière binaire.
• Elles offrent une large flexibilité concernant le type de donnée(s) à
stocker : il peut s’agir d’une simple chaine de caractère, ou de tout
autre type de données tel un objet JSON ou des données binaires
(image, vidéo, exécutable, etc…).
• Elles stockent les données en mémoire vive lorsqu’elles sont actives
afin d’obtenir des temps de réponses très rapides.
Montpelllier

7. Les bases de données de type Colonnes
• Type de BDD le plus proche des SGBDR en terme de structuration de données :
Nous avons à faire à des lignes et des colonnes contenues dans des Tables -> Sauf
que les colonnes sont créées pour chaque ligne et qu’elles ne sont pas décrites
structurellement dans la définition de la Table.
• Une colonne n’existe donc pas tant qu’une donnée n’a pas été enregistrée en
base et la manière dont celles-ci sont stockées s’apparente à une paire « clé /
valeur » où la clé est le nom de la colonne et la valeur est la donnée que l’on veut
exploiter.
• Ainsi, les données ne seront pas stockées par ligne mais par colonne -> Objectif
pouvoir faire des traitements sur des colonnes spécifiques et non sur des lignes
complètes pour un balayage des données par colonne plus rapide.
Montpelllier

8. Les bases de données de type Documents
• Type de BDD NOSQL le plus populaire, notamment grâce à MongoDB
• Stockage des données dans des collections de documents -> Par rapport aux bases de
données relationnelles, les collections sont aux tables ce que les documents sont aux
enregistrements.
• Les données sont généralement formatées en JSON -> pratique à manipuler avec du
JavaScript, d’où le célèbre couplage « NodeJS / MongoDB »
• Possibilité de stocker tous types de données « primitives » dans une collection (boolean,
number, string), mais aussi des tableaux de données ou des objets JSON contenant eux-
mêmes des données de tous types -> possibilité de créer des arborescences de données
complexes dans un document.
• Exemple de document : {"_id" : 1 ; "marque" : "Toyota", "modele" : "Prius+", "immat" :
"DH-040-VT", "proprietaire" : {"nom" : "DYKSTEIN", "prenom" : "Eric", "adresse" : { "voie"
: "72, rue paradis" , "cp" : "13006", "ville" : "Marseille" } } }
Montpelllier

9. Les bases de données de type Graphe
• Type de BDD NOSQL le moins répandu, car il couvre un besoin fonctionnel très particulier
-> les relations multi-nœuds (type réseau social)
• Les enregistrements d’une base Graphe sont soit de des « noeuds » (ou « nodes »), soit
des « arcs » (ou « edges ») qui correspondent aux relations entre les « noeuds » .
• Les nœuds correspondent à une entité de données, pouvant contenir des données ou
des tableaux de données exclusivement de types primitifs (boolean, number, string),
ayant la spécificité d’être reliable à un ou plusieurs autres nœuds par des arcs.
• Un arc contient les données permettant de relier deux noeuds : un « identifiant de
noeud » de départ, un « identifiant de noeud » d’arrivée et, éventuellement, des
données complémentaires caractérisant le lien entre les deux nœuds.
• Le système de requêtage n’est pas des plus simples (pour ce que j’ai entrevu de Neo4j :p)
En théorie…
Montpelllier

10. Les bases de données de type Graphe
En pratique… -> Design d’un modèle de réseau social
Relationnel
Personnes
Perso_id
Perso_nom
Perso_prenom
Relations
Perso_id_from
Perso_id_to
Relation_type
1 n
1
n
Problématiques d’interrogation de la base de
données pour retrouver le lien entre deux
personnes :
- Nombre de jointures compliqué à déterminer
pour trouver le parent/enfant le plus « éloigné » ou
le « chemin le plus court »
- Impossibilité de chercher dans deux directions
sans se casser la tête (ou faire exploser le SGBDR)
GrapheVS
Personnes
(noeud)
Perso_id
Perso_nom
Perso_prenom
Relations
(arc)
_from
_to
type
Dans une base de type graphe, les personnes sont
enregistrés comme « nœuds » et les relations comme
« arcs ». Le moteur de graphe permet d’effectuer une
recherche mono ou bidirectionnelle sans la
« lourdeur » du SQL face à cette problématique
fonctionnelle. Il est possible de déterminer une
« profondeur » de recherche.
1 n
1
n
Montpelllier

11. Inconvénients du NOSQL
• Pas de structure de données « in database » et Zéro contrôle à l’insertion des données,
donc :
→ Il faut concevoir une « structure logique » de vos collections de données et coder des contrôles
vous-même avant chaque insertion / modification pour assurer l’intégrité du type de données à
stocker (ce que vous êtes déjà censés faire, ou qu’un framework fait pour vous ;D)
→ Les modifications manuelles sont à éviter pour limiter les risques de bugs dans votre application
• Pas de système de clé étrangère pour lier les collections entre elles, cependant :
→ Possibilité de créer des arborescences de données à l’intérieur d’un enregistrement dans une
base de type Documents -> inconvénient sous-jacent : coder de manière récursive la lecture des
données…
→ Possibilité de raccorder des « enregistrements » entre eux avec une base de type Graphe
→ Sinon, relations à l’ancienne (MyISAM style pour les connaisseurs ;p) -> indiquer dans un champs
d’un document ou dans une colonne, l’identifiant du document ou de l’enregistrement d’une
autre collection / table lié à celui-ci.
Partie 1
Montpelllier

12. Inconvénients du NOSQL
• Mais même si on contourne le problème de l’absence de clés étrangères…
→ Aucune gestion des contraintes d’intégrité référentielle, donc il va aussi falloir les coder soi-
même dans son applicatif si besoin.
→ Aucune modification ou suppression en cascade dans le cas d’une gestion des relation via
une base graphe ou bien d’une gestion des relations à « l’ancienne » entre deux collections /
tables…
• En conclusion : Beaucoup plus souple, plus rapide, mais aussi plus de
précautions à prendre lors de la manipulation des données pour
conserver une certaine forme de cohérence et d’intégrité. Sans parler de la
nécessité de coder tout ce qui a attrait aux relations entre les données
lorsque c’est nécessaire.
Partie 2
Montpelllier

13. Des questions :) ?
Contact info :
Mail : eric@recrut-info.com / e@riw.fr
Twitter : @edykstein
Merci pour votre attention ^o^ !
Montpellier