7.8 KiB
7.8 KiB
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
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" 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
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
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
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 (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 : 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