Un constat

On assiste ces dernières années à un changement des habitudes des utilisateurs notamment sur l’Internet mondial avec la démocratisation des offres haut débits. Dans ce contexte certaines personnes se sont rendues compte qu’un modèle relationnel des données atteignait ses limites : le NoSQL allait faire son entrée dans le monde de la représentation des données.

Même si initialement le NoSQL est une réponse à la croissance toujours plus importante sur Internet, il trouve également sa place dans le monde de l’entreprise sur des échelles moindres. L’objet de cet article est de confronter les deux approches : le modèle relationnel versus le NoSQL.

Les bases de données relationnelles

Avantages :

  • La technologie est mature (création il y a plusieurs dizaines d’années) ce qui fait qu’aujourd’hui le SQL est un langage standard et normalisé
  • On a une garantie que les transactions sont atomiques, cohérentes, isolées et durables — principe ACID (Atomic, Consistent, Independant, Durable)
  • La possibilité de mettre en œuvre des requêtes complexes (croisement multiple des données)
  • Du fait du nombres d’années d’existence, un large support est disponible et il existe également de fortes communautés.

Inconvénients :

  • La modification du modèle établi peut être couteuse
  • L’évolutivité des performances est privilégiée de manière verticale (augmentation des ressources du serveur) bien qu’une évolutivité horizontale soit possible, cette dernière reste plus coûteuse (environnement type cluster)
  • Sur un très grand volume de données (centaines-milliers de Teraoctets) le modèle peut atteindre des limites en terme de performance
  • Pour certains éditeurs, le prix de licence est élevé.

Quelques exemples de solutions :

  • Oracle Database
  • PostgreSQL
  • Microsoft SQL Sever
  • Oracle MySQL

Les bases de données NoSQL

Avantages :

  • L’évolutivité se fait de manière horizontale (pour augmenter les performances on ajoute des nouvelles machines)
  • Les données sont distribuées sur plusieurs machines (sharding) de ce fait on évite les goulets d’étranglements lors de la récupération des données (fortes performances de lecture)
  • La représentation des données est notable par l’absence de schéma (schemaless)
  • La majorité des solutions est Open Source, néanmoins il existe des Support Pro pour répondre aux besoins des entreprises.

Inconvénients :

  • Il n’existe pas de langage d’interrogation standardisé : chaque éditeur a mis en place le sien
  • La mise en œuvre d’un environnement fortement transactionnel (fort besoin d’écriture) où le séquencement des écritures est primordial, reste complexe puisque l’architecture est distribuée compliquant l’atomicité et la cohérence des transactions
  • L’écriture de requêtes complexes est difficile à mettre en œuvre
  • L’offre NoSQL est segmentée en plusieurs familles où chacune répond à un besoin précis.

Quelques exemples de solutions (divisés en 4 familles) :

  • clé-valeur : Riak, Redis
  • Orientée colonne : Cassandra, HBase
  • Orientée document : MongoDB, CouchDB, ElasticSearch
  • Orientée graphe : Neo4j, HypergraphDB

Famille clé-valeur

Cette catégorie de bases fonctionne comme une table associative clé/valeur ce qui en fait une base simple à mettre en place et permet un accès rapide aux informations (système de cache). Néanmoins il n’est pas possible d’indexer le contenu d’une telle base ce qui entraine un développement plus important pour garantir les performances.

Ce système est adapté dans le cadre de communication temps réel comme une messagerie en ligne.

Famille orientée colonne

La représentation se fait par colonnes et non par lignes comme pour un système classique, il s’agit peut-être du modèle le plus difficile à se représenter.

nosql_relationnel

Modèle d’une base de données relationnelle

nosql_colonne

Modèle d’une base de données NoSQL famille colonne

 

 

 

 

 

 

 

Cette modélisation apporte une simplification d’ajout de colonne et est capable de gérer des millions de colonnes. De plus la valeur « null » a désormais un coût de stockage de zéro. Comme les données d’une même colonne sont similaires, la compression des données en est plus efficace et les recherches « verticales » plus performantes.

Un inconvénient notable est qu’une mise à jour peut nécessiter la modification de toutes les valeurs d’une colonne pour tous les enregistrements et donc devenir très coûteux.

Cette base peut être mise en place pour gérer les commentaires d’un article de blog.

Famille orientée document

Cette famille est une extension de la famille clé/valeur en associant une clé à un document hiérarchique comme le XML, le JSON.

Ici on va pouvoir stocker toute forme de structure non plane simplement, pouvoir profiter de la puissance de l’indexation en ciblant les balises du document et ainsi bénéficier d’une interrogation simplifiée (absence de jointure).

En évoquant la mise en œuvre de requêtes une limite peut être atteinte dans la mise en place de requêtes analytiques complexes.

Dans le web, ce modèle se prête bien à la sauvegarde de profils utilisateur.

Famille orientée graphe

Le principe de cette famille repose sur le fait d’utiliser des objets en s’appuyant sur la théorie des graphes (représentation de nœuds et d’arcs) : chaque élément connait son(ses) voisin(s).

Un tel principe permet de mettre facilement des algorithmes de parcours de graphe (recherche du plus court chemin, nœud(s) ayant une position centrale, …) et via une indexation d’augmenter sensiblement les performances (création de listes chainées).

Cependant ce principe reste un domaine bien spécifique compliqué à utiliser concrètement et sera moins efficace dans l’exploitation des relations.

L’exemple le plus parlant est la mise en place d’un arbre généalogique : avec ce principe il est simple de retrouver les degrés de parenté entre les personnes.

Un petit tableau récapitulatif des différentes familles

nosql_famille

Comparatif familles NoSQL

Pour conclure

Aujourd’hui le NoSQL apporte une nouvelle façon d’appréhender la modélisation des données. Le NoSQL n’est pas là pour remplacer les bases de données relationnelles, il répond à des besoins différents mais les deux approches peuvent cohabiter. Le choix de l’une ou de l’autre sera donc fortement dépendante du contexte et du besoin.