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

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