Quel SGBD NoSQL pour vos besoins IT ? Critères de choix

Les quatre principaux types de SGBD NoSQL et leurs usages

Une base de données clé/valeur convient parfaitement à un accès aux données au moyen d'une clé, comme dans le cas de la recherche d'un livre d'après son numéro international normalisé (ISBN). Dans cet exemple, le numéro ISBN est la clé et toutes les autres informations concernant le livre sont la valeur. La clé est obligatoirement connue et peut donc être recherchée. En revanche, la valeur est un ensemble de données sans signification qui doivent être interprétées après lecture.

Une base de données orientée documents gère et stocke des données au niveau du document. Elle ressemble à une base de données clé/valeur, mais affiche une structure imposée aux données : l'ensemble de données non structurées qui formait la valeur est ici décrit dans une structure de document, en général au format JSON (JavaScript Object Notation) ou XML. Une base de données orientée documents peut être interrogée sur tous les composants du schéma défini, alors qu'une base de données clé/valeur ne peut être interrogée que sur sa clé.

Un SGBD orienté colonnes (également appelé stockage en colonnes) réoriente le focus des données de la ligne sur la colonne, en stockant les données en colonnes et non en lignes. Dans les bases de données relationnelles traditionnelles, les données sont modélisées sous forme de lignes de colonnes, l'accès se faisant toujours par les lignes. Le stockage NoSQL en colonnes gère les enregistrements dans des familles de colonnes qui peuvent contenir un grand nombre de colonnes dynamiques. Il n'existe pas de schéma fixe ; autrement dit les noms et les clés des colonnes peuvent varier. Une base de données orientée colonnes convient aux données faisant l'objet de peu d'écritures, pour lesquelles les attributs ACID (atomicité, cohérence, isolation, durabilité) ne sont pas impératifs et dont le schéma est variable.

Une base de données orientée graphes privilégie les relations entre les valeurs et stocke les données en utilisant la théorie mathématique des graphes. Pour représenter et stocker les données, ce type de base de données utilise la structure des graphes en noeuds, en relations et en propriétés. Dans ces bases de données, chaque élément contient un pointeur direct vers l'élément adjacent et aucun recours à un index n'est nécessaire.

Le mantra du NoSQL : la persistance polyglotte, ou utiliser le SGBD approprié pour répondre à un besoin spécifique

Les SGBD NoSQL sont de plus en plus utilisés pour les mises en oeuvre à l'échelle du Web, du Big Data et à caractère analytique. Chaque catégorie de SGBD NoSQL est adaptée à des types d'applications et d'utilisations distincts, ce qui a donné naissance à un nouveau terme, fréquemment employé dans la communauté NoSQL : la persistance polyglotte.

Il s'agit de recourir à différents systèmes de bases de données pour différentes applications et utilisations, en fonction de la manière dont la base de données gère les besoins de l'application. Le mantra du NoSQL consiste donc à utiliser le SGBD approprié pour répondre à un besoin spécifique, même si cela implique l'introduction d'un nouveau système de bases de données.

Avantages et inconvénients du NoSQL

Pourquoi choisir un SGBD NoSQL plutôt qu'un SGBD de type relationnel ? Les plus grandes qualités d'un SGBD NoSQL sont sans doute d'être décentralisé, évolutif et tolérant aux pannes ; qualités que partagent la plupart des technologies de base de données NoSQL.

Les bases de données NoSQL permettent de personnaliser la solution de gestion des données pour chaque cas d'utilisation. Autant les bases de données relationnelles sont pensées pour des cas d'utilisation très variés, autant chaque SGBD NoSQL est conçu pour un cas d'utilisation spécifique. En adoptant la persistance polyglotte, une entreprise peut choisir la technologie de base de données qui correspond le mieux à chaque usage.

Qui plus est, la plupart des produits NoSQL sont plus légers et induisent moins de gestion qu'une solution relationnelle. Comme les produits NoSQL sont conçus pour des cas d'utilisation et des questions spécifiques, leur fonctionnalité est moindre que celle de la plupart des SGBDR (relationnel), pensés pour une multiplicité d'usages. Ainsi, un SGBD NoSQL demande moins de code, ce qui lui donne potentiellement un avantage en termes de performances par rapport à un SGBD plus complexe.

Bien sûr, la technologie NoSQL n'a pas que des avantages. La prise en charge ACID, par exemple, est standard dans un SGBDR, mais absente le plus souvent (pas toujours) des SGBD NoSQL. Si la prise en charge ACID est indispensable, cherchez à savoir si la base de données NoSQL que vous ciblez en est dotée.

L'absence de support SQL constitue un autre inconvénient des bases de données NoSQL. Pendant toute son existence, soit plus de 40 ans, le langage SQL a évolué dans la lingua franca de l'accès aux données. Un SGBD qui ne prend pas en charge SQL contraint les développeurs à apprendre d'autres techniques de programmation pour accéder aux données. Tout comme pour ACID, certaines bases de données NoSQL intègrent des capacités SQL de l'ordre du complément. Elles sont généralement moins exhaustives que celles des bases de données relationnelles. Autrement dit, ne vous attendez pas à pouvoir lancer une requête SQL relationnelle sur une base de données NoSQL sans devoir y apporter d'importants changements.

Le marché NoSQL actuel est également déroutant. Vous avez littéralement le choix entre des centaines de bases de données NoSQL différentes. Contrairement au modèle relationnel, il n'existe pas de modèle de données formel (théorie des ensembles) et chaque SGBD NoSQL peut être, et généralement est, très différent des autres, parfois dans le même type d'offre. A moins de recherches poussées et de beaucoup de zèle, cet imbroglio peut entraver l'aboutissement d'une solution NoSQL.

Cas d'utilisation des SGBD NoSQL

Sachant que la technologie NoSQL a été conçue pour appliquer des techniques de persistance des données adaptées à des cas d'utilisation spécifiques, examinons dans quels cas il est intéressant d'utiliser chaque type de base de données NoSQL.

Clé/valeur. La base de données clé/valeur répond aux besoins en haute disponibilité et de faible latence des applications des domaines du jeu, du commerce de détail et de la mobilité. La flexibilité du schéma des bases de données clé/valeur les rend parfaitement adaptées à la gestion de sessions, à la desserte de contenus publicitaires et à la gestion des profils utilisateur ou produit. Autrement dit, une base de données clé/valeur est un choix judicieux lorsque les données sont codées de multiples façons sans schéma rigoureux.

Les bases de données clé/valeur ne sont pas spécialement adaptées à la gestion des relations complexes entre différents ensembles de données ni à l'interrogation au moyen de tout élément autre que la clé définie.

Base de données orientée documents. Ce type de base de données est parfaitement adapté au stockage de différents types de données pour chaque document, grâce à la flexibilité qu'il offre en matière de recherches à l'échelle de toutes les données. Les bases de données orientées documents constituent également un choix judicieux lorsque le schéma n'est pas rigide, mais qu'il est tout de même nécessaire d'effectuer des requêtes en utilisant un élément autre qu'une simple clé. Les bases de données orientées documents sont adaptées pour la journalisation d'événements, au commerce en ligne, à la gestion de contenu et au traitement analytique approfondi. La flexibilité du schéma des bases de données orientées documents est également utile pour les projets qui nécessitent un prototypage rapide.

Malheureusement, elles ne sont pas spécialement adaptées au traitement de transactions complexes. Leur utilisation n'est pas idéale non plus pour les applications qui recourent à l'agrégation de données. En effet, leur schéma flexible signifie que les données ne sont pas homogènes sur tous les documents et ont, par conséquent, peu de chances d'être correctement agrégées.

Base de données orientée colonnes. Ce type de base de données stocke les données dans des familles de colonnes en tant que lignes. Plusieurs colonnes sont associées à une clé (un identifiant). Comme pour les autres types de bases de données NoSQL, ici encore le schéma est flexible. Une famille peut donc être composée de colonnes différentes pour chaque ligne. En outre, les données d'un stockage en colonnes sont accessibles par des colonnes différentes de la clé.

Le concept de base de données orientée colonnes n'est pas nouveau, et des variantes ont déjà été mises en œuvre sous forme de base de données relationnelle (par exemple, SAP Sybase IQ et IBM DB2 BLU). Bien que la colonne relationnelle se focalise sur la colonne en tant qu'unité de stockage, les colonnes ne peuvent pas être différentes selon les lignes, comme c'est le cas dans un stockage orienté colonnes NoSQL.

Les stockages orientés colonnes sont efficaces pour les systèmes affichant peu d'opérations en écriture, et dans lesquels un faible nombre de colonnes présentant de nombreuses lignes doivent être lues fréquemment et simultanément. Ce type de stockage est adapté à la journalisation d'événements, à la gestion de contenu et au comptage et/ou la catégorisation d'analytiques. Il est également pratique pour les données qui présentent une échéance, car il est possible de définir l'expiration automatique d'une colonne.

Evitez les stockages orientés colonnes sur les systèmes qui affichent des requêtes très différentes. En effet, ceux-ci sont susceptibles d'impliquer la refonte conceptuelle des familles de colonnes. Pour terminer, le stockage orienté colonnes n'est pas adapté aux transactions ACID.

Base de données orientée graphes. Ce type de base de données est probablement le type de SGBD NoSQL le plus éloigné du concept traditionnel de système de base de données. Les bases de données orientées graphes répondent précisément aux situations où des éléments de données interconnectés affichent entre eux un nombre indéterminé de relations. La mise en oeuvre de réseaux sociaux, comme LinkedIn ou Facebook, représente le cas d'utilisation le plus courant des bases de données orientées graphes.

D'autres applications sont évidemment possibles, comme l'acheminement et l'expédition des livraisons, les systèmes sensibles à la localisation, les réseaux des transports publics, les cartes routières, les conditions préalables des programmes d'étude et les topologies réseau. Les bases de données orientées graphes sont également pratiques pour la prise en charge de moteurs de recommandations, comme ceux utilisés par les sites de vente de détail en ligne.

Les bases de données orientées graphes ne sont pas particulièrement adaptées aux données qui changent fréquemment, ni aux mises à jour en temps réel de grands volumes de données. En outre, si vous prévoyez de partitionner la base de données sur un réseau, ce type de base de données subira probablement une dégradation de ses performances.

Six autres aspects des SGBD NoSQL à prendre en compte

La grande diversité du paysage NoSQL rend assez difficile l'évaluation de sa technologie. Il existe différentes architectures pour différents types et produits de bases de données. Il existe même des différences entre les types de SGBD NoSQL eux-mêmes.

Par ailleurs, il n'existe pas de norme, y compris concernant l'accès aux données (contrairement au modèle relationnel). Pour pallier cela et utiliser une base de données NoSQL, il faut adopter et maîtriser des outils et des interfaces de programmation spécifiques permettant d'accéder aux données dans chaque SGBD. Voici quelques aspects supplémentaires.

Changement rapide. NoSQL est un domaine dynamique, où l'optimisation et l'introduction d'une fonctionnalité côtoient l'introduction de nouveaux produits. Lorsque vous évaluez les systèmes de base de données NoSQL, il peut être difficile de cerner les fonctionnalités les plus récentes et les plus intéressantes.

A la place d'ACID, NoSQL a favorisé le principe BASE

Prise en charge croissante des attributs ACID. L'un des premiers arguments en faveur de la technologie NoSQL concernait la prise en charge de transactions qui n'exigeaient pas un support ACID complet, ce qui allégeait le SGBD et améliorait les performances.

A la place d'ACID, NoSQL a favorisé le principe BASE (Basically Available Soft-state services with Eventual-consistency), à savoir : simplement disponible, état souple, finalement consistant. Néanmoins, de nombreuses applications reposent sur les propriétés ACID. La capacité de prise en charge des transactions ACID est donc une fonctionnalité des SGBD NoSQL de plus en plus recherchée et exploitée.

Absence de prise en charge multiplateforme. La plupart des SGBD NoSQL sont nés du mouvement open source et fonctionnent généralement sous Linux (voire sous une variante Unix). Si vous devez mettre en oeuvre votre SGBD sous Windows ou sur votre mainframe, il vous faudra analyser les produits commerciaux, car ils autorisent souvent le déploiement multiplateforme.

Extension de la prise en charge SQL. Sans SQL, les requêtes sont souvent très élémentaires et susceptibles d'exiger un codage complexe dans un langage évolué. Bien sûr, tout dépend des produits, mais il reste intéressant de rechercher la prise en charge SQL dans un SGBD NoSQL, car de nombreux développeurs connaissent le codage dans ce langage.

Possibilité d'exploiter plusieurs types de bases de données. Certains SGBD NoSQL permettent de modéliser et de mettre en œuvre des données en utilisant des combinaisons flexibles de paires clé-valeur, de documents et de graphes. Ajoutons que les SGBDR commencent à adopter des capacités NoSQL. L'utilisation d'un SGBD capable d'exploiter plusieurs types de stockage de base de données peut faciliter l'adoption par votre entreprise de la persistance polyglotte.

Méfiez-vous de la technologie pré-V1. De nombreux projets open source fonctionnent pendant plusieurs années sans connaître de version 1. Le logiciel peut être robuste et utile, mais les entreprises qui n'aiment pas prendre de risques évitent généralement d'exécuter une technologie pré-V1 dans leur environnement de production.

Comprendre les bases de données NoSQL

Bien que la technologie de base de données NoSQL jouisse actuellement d'une certaine notoriété, son paysage est encore encombré et déconcertant, et change rapidement. Pour comprendre les bases de données NoSQL, il faut étudier plusieurs types de moteurs de base de données et divers cas d'utilisation. Mal choisir une technologie NoSQL peut entraîner l'échec d'un projet.

Le SGBD NoSQL est malgré tout adopté de façon concluante dans de nombreux projets, et la technologie sous-jacente présente des avantages lorsqu'elle est déployée correctement sur les projets appropriés.