238 lines
7.8 KiB
Markdown
238 lines
7.8 KiB
Markdown
# 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 |