# 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"](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
--- ### 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](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