NoSQL : définitions et exemples

Le NoSQL est une famille de bases de données qui ont la particularité de prendre en charge un modèle de données non relationnelles. À l'opposé des bases de données traditionnelles dites SQL, les bases NoSQL ont fait leur apparition avec le Big Data, dès lors qu'il fallait pour stocker, historiser et requêter sur des volumétries très importantes. Au sein de cette famille, on retrouve plusieurs modèles qui répondent à des besoins différents.

Dans cet article, nous allons détailler le fonctionnement de chaque modèle de la famille NoSQL, présenter quelques exemples d'outils/services populaires, et expliquer leurs avantages.

Introduction au NoSQL

NoSQL (pour Not Only SQL) est un terme qui fut inventé au tout début des années 2000. À cette époque, la très grande majorité des bases de données étaient de type SQL, c'est-à-dire avec des modèles de données relationnelles, organisées sous forme de tables. Ce modèle relationnel a été très étudié et très utilisé au sein des entreprises.

Mais avec l'avènement du Big Data, ces bases de données ont commencé à présenter des lacunes.

• Les bases de données SQL ne sont pas adaptées pour des très grandes volumétries (centaines et milliers de Go). Lorsque les tables sont volumineuses, les requêtes deviennent bien trop lentes (plusieurs dizaines de secondes, voire minutes), ce qui peut être problématique, notamment dans les systèmes dits « transactionnels » (OLTP).
• Le modèle relationnel est trop rigide pour certains besoins. Au fur et à mesure que la quantité des données explose, leur variété augmente. Le modèle relationnel ne permet pas cette flexibilité, car il suppose que tous les éléments d'une table aient exactement les mêmes champs.

C'est alors que de nouvelles bases de données ont vu le jour pour pallier les faiblesses du SQL. On peut citer notamment HBase de la fondation Apache, sortie en 2006, ou de Neo4j, la base graphe sortie en 2000. À la suite, de nombreuses entreprises ont développé leurs propres bases de données comme DynamoDB pour Amazon, CosmosDB pour Microsoft ou encore BigTable pour Google : la mouvance NoSQL est née.

À lire aussi : découvrez notre formation Data Engineer

Modèles NoSQL

Comme évoqué, la principale différence avec le modèle SQL vient dans l'absence d'un modèle relationnelle, ce qui signifie que les données ne sont plus matérialisées et représentées par des tables. Cette absence (ou flexibilité, en fonction des modèles) de schéma de données permet de faire évoluer l'architecture de la base de données avec le temps, ce qui est beaucoup plus difficile dans un contexte SQL.

Les bases de données NoSQL sont également pensées pour la mise à l'échelle. Elles ont la possibilité d'être distribuées, ce qui permet à la fois de supporter de grandes charges de travail (milliers de lectures/écritures par seconde) tout en assurant une haute disponibilité, grâce aux mécanismes de réplication de données.

En contrepartie, chaque outil utilise son propre langage de requête : là où la plupart des bases de types SQL supportent à 90% le langage SQL, avec le NoSQL, chaque base de données dispose de son propre langage de requête. Il est donc plus difficile de changer de base de données NoSQL, car cela revient à repenser son architecture et modifier l'utilisation du langage de requêtes.

Parmi les bases dites NoSQL, nous retrouvons plusieurs modèles de bases de données.

• Les bases orientées colonnes : Cassandra, AWS DynamoDB, HBase.
• Les bases orientées documents : MongoDB, Elasticsearch.
• Les bases orientées clé/valeur : Redis, Memcached.
• Les bases orientées graphes : Neo4j, InfluxDB.

Le choix du modèle de base NoSQL dépend principalement des besoins et du cas d’usage. Si l’on doit souvent manipuler des données temporelles, on se dirigera vers une base adaptée pour les séries temporelles. À l’inverse, les bases orientées colonnes peuvent être intéressants dans les situations où l’on doit gérer des articles ECommerce par exemple.

Les bases orientées colonnes

Les bases orientées colonnes peuvent être vues comme une extension des tables relationnelles. On y retrouve le principe des tables et des colonnes.

La principale différence avec le modèle relationnel est que les colonnes (schéma des tables) ne sont pas identiques à chaque ligne. Elles utilisent souvent des clés (clés primaires et clés de tri) pour requêter efficacement dessus.

Cela va optimiser l’espace de stockage car l’historisation peut être effectuée sur une seule ligne. L'autre particularité vient aussi des valeurs possibles : dans une colonne, on peut avoir des structures plus élaborées que simplement des nombres ou des textes. Il est possible d'avoir des structures d'objets ou des listes comme valeurs.

Les bases orientées colonnes sont pensées pour la volumétrie : de ce fait, les tables peuvent facilement contenir des dizaines de millions de lignes avec des centaines de colonnes différentes.

Néanmoins, cela empêche certaines fonctionnalités historiquement présentes dans le modèle relationnel d’être présente. Par exemple, avec Cassandra, il n’est pas possible d’effectuer des jointures.

Les bases orientées colonnes sont adaptées lorsque les données sont très volumineuses et que de nombreux événements surviennent.

• Analyse de données collectées par Webscraping.
• Comportement des utilisateurs.
• Gestion de catalogues (produits, achats, ventes)/

Elles gardent, dans leur forme, un certain lien avec les bases relationnelles. De nombreux services Cloud proposent des bases orientées colonnes, comme Amazon DynamoDB ou Google BigTable.

Les bases orientées documents

Dans les bases orientées documents, on considère des collections de documents, où chaque document contient une liste de champs clé/valeur. Le format utilisé dans les documents est principalement le JSON ou le XML.

Chaque document possède sa propre structure, ce qui permet d’être très flexible au sein d’une même collection. Notons qu'il est possible d’ajouter des schémas de données pour obliger un minimum de structure.

Il faut les utiliser lorsqu'il n’y pas de relations entre les documents et les collections.

• Gestion de catalogues diversifiés (produits, achats, ventes)
• Base d’utilisateurs et de clients
• Web Analytics

S’il y a une cohérence assez forte entre les données (colonnes plus ou moins similaires), on préférera utiliser une base NoSQL orientée colonnes.

À lire aussi : découvrez notre formation Data Engineer

Les bases orientées clé/valeur

Les bases orientées clé/valeur sont utilisées pour le stockage temporaire de données ou pour un accès rapide sans requêtes complexes.

Chaque donnée est référencée par une clé : c’est à partir de cette référence que l’on y accède. Le principe est très similaire aux systèmes de stockage d’objets où on accède aux objets via une clé.

Contrairement aux autres bases NoSQL, celles-ci sont plus faciles à utiliser mais leurs usages sont limités. En effet, il n’est pas possible d’effectuer des requêtes poussées sur ces bases.

La principale utilisation des bases NoSQL orientées clé/valeur concerne la mise en cache d’informations.

• Panier d’utilisateur (E-Commerce).
• Collecte d’événements (tracking utilisateur).
• Partage d’information pour des applications en équilibrage de charge.

Quand utiliser une base de données NoSQL ?

Les bases de données NoSQL sont aujourd'hui omniprésentes dans les entreprises de toutes tailles. Elles se révèlent particulièrement efficaces dans les situations suivantes.

• La volumétrie est importante : les bases NoSQL sont adaptées pour stocker et requêter sur des centaines de Go et données. Elle ont été conçues avec l'idée de pouvoir gérer une forte volumétrie de données.
• La structure de données est flexible et peut évoluer au cours du temps. Si par exemple, une startup lance un produit et ne sais pas encore comment son modèle économique va évoluer au cours des prochains mois, la flexibilité d'une base NoSQL lui permettra d'adapter son architecture sans trop de difficultés.
• La base de données peut être redimensionnée à grande échelle. Il peut être difficile de mettre à l'échelle horizontalement une base de données SQL, ce qui est plus facile avec du NoSQL, car elles utilisent des mécanismes particuliers (comme les replicas ou le sharding) afin de gérer de très grandes charges de travail.

Un des autres avantages des bases NoSQL est qu’elles ne nécessitent pas autant de modélisation en amont que les bases SQL. En raison de leur flexibilité,