formations/cesi/nosql/01-Présentation.md

# Initiation à NoSQL

## Sylvain Eliade, Cadoles

------

## C'est quoi NoSQL ?

* Désigne toutes les bases de données non-relationnelles
* Base relationnelle (RDBMS) = généralement SQL
* Mais on peut faire du SQL non-relationnel !
* Donc maintenant, NoSQL = "Not Only SQL"
* Au final, un mot un peu trop vague, comme "Web 2.0"

---

## Rappel : RDBM

<figure>
	<img src="Images/rdbm.svg" alt="" />
</figure>

---

## Rappel : ACID

* Atomique = tout changement (transaction) à la BDD doit fonctionner ou échouer en entier (mais pas être exécuté à moitié et échouer à moitié !)
* Consistant = toutes les règles imposées doivent être valides (clés, triggers, contraintes, etc.) pour empêcher la corruption de la BDD
* Isolation = les transactions pouvant être exécutées en même temps, une requête concurrente ne doit pas avoir accès à un état transitoire de la BDD
* Durabilité = une transaction écrite dans la BDD doit le rester en cas de crash logiciel ou coupure du serveur

---

## Différences entre RDBMS et NoSQL

* Généralement pas ACID (Atomicity, Consistency, Isolation, Durability)
* Mais parfois oui (CouchDB), parfois partiellement
* Théoriquement plus facile à dimensionner horizontalement
* En pratique les RDBMS se dimensionnent très bien aussi
* La plus grosse différence et intérêt : non relationnel ! :)

---

### Quand utiliser une BDD noSQL ?

* Besoin de très grosses performances
* … ou stockage de très gros volume de données
* Données très spécifiques et non-relationnelles
* Et surtout : pas de besoins relationnels !

---

### Quand utiliser une BDD noSQL ?

* … mais même dans ces cas, un RDBM est souvent plus simple et rapide à mettre en œuvre
* Et un RDBM supporte aussi de très grandes quantités de données et de bonnes performances… si vous savez bien l'utiliser :)
* Vous n'êtes pas Google, Amazon ou Alibaba !
* Une solution SQL (Postgre, MySQL, SQL Server, Oracle…) sera adaptée à 95% des besoins
* Sinon : petit projet, "pour tester", qui ne sera pas amené à évoluer, car changer de BDD est lourd !

---

## NoSQL : une solution parmi d'autres

* Les bases NoSQL ont été créées pour répondre à des besoins de très gros acteurs
* Besoins qui sont rarement atteints ailleurs
* NoSQL est une solution, pas LA solution
* Bien évaluer le problème avant de choisir la ou les solutions :)
* Le bon côté : NoSQL a initié une modernisation des RDBMs

---

## Google abandonne NoSQL

* Google, à l'origine de BigTable et MapReduce, premières solutions NoSQL
* … sont repassés à SQL avec [Spanner et le "Standard SQL"](https://blog.timescale.com/blog/why-sql-beating-nosql-what-this-means-for-future-of-data-time-series-database-348b777b847a/) commun à plusieurs outils internes.
* Car SQL facilite l'arrivée de nouveaux développeurs et la possibilité de communiquer avec des outils différents mais avec le même langage.
* Résultat : solutions NoSQL requêtables en SQL :)

---

## NoSQL dans SQL, le meilleur des deux mondes ?

* Stockage JSON dans PostgreSQL (depuis la version 9.2), MySQL (5.7.8), SQLite (3.9.0), SQL Server
* Recherche plein texte, index sur les données JSON, jointures !
* Implémentation légèrement différente dans SQLite
* Performance : pas forcément lent
* PostgreSQL est plus rapide avec JSONB que MongoDB par exemple (mais nécessite plus d'optimisation de la configuration)

---

## Les familles de bases NoSQL

* Clé-valeur (Berkeley DB, memcached, Redis, Apache Ignite, etc.)
* Document (MongoDB, Apache CouchDB, etc.)
* Colonnes ou "wide column" (Cassandra, HBase, etc.)
* Graph (Neo4j, Apache Giraph…)

---

## Bases de données clé-valeur

* Aussi vieilles que l'informatique !
* On référence une valeur à l'aide d'une clé pour aider à retrouver la valeur
* La valeur ne fait pas de différence pour le moteur de BDD (opaque)
* On ne peut donc pas trouver une entrée juste avec une partie de la valeur
* Du plus simple (memcached, Berkeley DB) au plus évolué (Redis)
* Rapide, simple, efficace

---

## Bases de données clé-valeur

<figure>
	<img src="Images/kv.png" alt="" />
</figure>

---

### Quand utiliser une BDD clé-valeur ?

* Données simples et à une seule dimension
* Données qui peuvent expirer
* Pas forcément besoin de persistance
* Exemples : cache, queue, statistiques…

---

### Quand ne pas utiliser une BDD clé-valeur ?

* Données structurées sur plusieurs niveaux (2D+)
* Besoins de jointures entre les données
* Besoin d'index sur le contenu des valeurs
* Besoin de chercher dans les valeurs
* Besoin de lister toutes les clés (lent)
* Données très grandes (selon le moteur de BDD, par exemple si les données sont stockées en RAM)

---

## Bases de données document

* Évolution du modèle clé-valeur (document = valeur)
* Sauf que le contenu de la valeur peut être indexé / référencé
* Plutôt adapté à un modèle où les documents sont indépendants et n'ont pas de relation entre eux
* Exemples : MongoDB, CouchDB, etc.

---

## Bases de données document

<figure>
	<img src="Images/document.png" alt="" />
</figure>

---

### Quand utiliser une BDD document ?

* Données structurées ou complexes
* Structure des données très variable
* Données non relationnelles
* Pas de schéma
* Exemple : fiches produit d'un site ecommerce

---

## Base de données orientée colonnes

* Comme une BDD clé-valeur, mais en 2D !
* On retrouve une donnée à l'aide d'une clé (ligne) et d'un nom de colonne
* Toutes les lignes n'ont pas forcément les même colonnes (contrairement à une table dans un RDBM)
* Les colonnes sont donc indépendantes d'une ligne à l'autre
* Exemples : Cassandra, HBase (historiquement : Google BigTable)

---

### Quand utiliser une BDD orientée colonnes ?

* Beaucoup d'écritures (ajouts)
* Grand volume de données
* Besoins de réplication
* Données peu structurées
* Données en 2D uniquement (clé d'accès + colonnes)
* Exemple idéal : statistiques, messageries temps réel

---

### Quand ne pas utiliser une BDD orientée colonnes ?

* Beaucoup de mises à jour / suppression de lignes
* Besoin de transactions, de rollbacks, de triggers, joins, etc.
* Besoin ACID : ce n'est pas du tout fait pour
* Besoin de parcourir toutes les données stockées : lent !

---

## Base de données graph

* Documents (= nœuds) liés ensemble par des relations (= arcs ou graphs)
* Les relations peuvent disposer de propriétés selon le contexte
* On peut accéder aux nœuds via leurs relations

---

## Base de données graph

<figure>
	<img src="Images/graph.png" alt="" />
</figure>

---

### Quand utiliser une BDD graph ?

* Données non structurées (pas de schéma)
* Liées ensemble de manière non ordonnée
* Exemples : graph d'amis (réseau social), recommandations de produits, détection de fraude…

---

### Quand ne pas utiliser une BDD graph ?

* Données non liées
* Données séquentielles
* Pas de besoin de lire les données
* Données dans un schéma fixe
* Besoin de stocker beaucoup de données dans les propriétés

---

### Exemples de NoSQL chez Skyrock

* Skyrock : 20+ millions d'utilisateurs, 4+ milliards de commentaires, 500.000 articles / jour, 2 millions de commentaires / jour… 2ème site de France 2007-2010
* [Sharedance](https://github.com/jedisct1/sharedance) (clé-valeur, ancêtre de memcached) : stockage de sessions PHP dans un système de fichier en ramdisk
* Topy : serveur de statistiques en RAM (avec autodump sur disque). Exemple : utilisateurs les plus actifs, blogs les plus consultés, etc.
* [Fluxy](http://zmoo.fr/fluxy.php) : serveur de newsfeed en RAM (avec autodump). Liste des événements liés à un utilisateur. 2 serveurs pour 20+ millions d'utilisateurs
* memcached puis Redis : cache de résultats MySQL, liste des utilisateurs connectés, cache des images uploadées en cours de traitement…
* MongoDB : application mobile de chat Smax