Base de données NoSQL : l’essentiel sur le modèle clé-valeur

Qu’est-ce qu’un key-value store ?

Ce type spécifique de base de données NoSQL utilise la méthode clé-valeur et stocke des collections de nombreuses paires clé-valeur en mémoire, sur disque dur ou sur des SSD.

Chaque enregistrement correspond à un jeu de paires de clés-valeur. Une clé est composée d’une clé primaire, l’identifiant unique de l’enregistrement (ou d’une ligne), puis de clés secondaires ou des attributs associés à des valeurs. Les valeurs peuvent être n’importe quelle sorte d’objet, un fichier, un nombre ou une chaîne de caractère, ou même une autre paire clé-valeur, auquel cas la structure de la base de données devient plus complexe.

Contrairement aux bases de données relationnelles, les SGBD clé-valeur n’ont pas de structure spécifique. Les SGBDR, eux, stockent les données dans des tables où chaque colonne est reliée à des variables différentes.

Les clés peuvent porter n’importe quel nom, mais étant donné qu’il s’agit du seul moyen de récupérer les valeurs qui leur sont associées, il convient de les désigner de manière stratégique.

Les noms des clés peuvent aller d’une simple numérotation à des descriptions spécifiques de la valeur qui va suivre. Une base de données clé-valeur peut être comparée à un dictionnaire ou un répertoire. Les dictionnaires ont des mots jouant le rôle de clés et leurs significations comme valeurs.

Les annuaires figurent les noms des personnes comme clés et leurs numéros de téléphone comme valeurs. Tout comme les bases de données clés-valeurs, si vous ne connaissez pas le nom de la personne dont vous avez besoin, vous ne pourrez pas trouver le bon numéro.

Les caractéristiques d’une base de données clé-valeur

En principe, le modèle clé-valeur est l’un des types de bases de données les moins complexes. C’est précisément ce qui le rend si attrayant. Il utilise des fonctions très simples pour stocker, obtenir et supprimer des données.

Par défaut, ce SGBD supporte trois opérations. PUT ajoute ou met à jour une nouvelle paire de clé-valeur. GET retourne la valeur associée à une clé spécifique. La fonction DELETE efface une clé et sa valeur d’une table.

En dehors de ces fonctions principales, les key-value stores ne disposent pas par défaut de langage de requêtes. Les données ne sont d’aucun type et sont déterminées par les exigences de l’application employée pour traiter les données.

Une caractéristique très utile est la redondance intégrée qui améliore la fiabilité de ce type de base de données.

Les cas d’usage d’un key-value store

Pour choisir ses bases de données, une organisation doit comprendre ses besoins et ceux de ses utilisateurs. Par exemple, les key-value stores sont souvent employés pour enregistrer des sessions dans des applications qui requièrent des connexions.

Dans ce cas, les données relatives à chaque session – période allant de la connexion à la déconnexion – sont consignées dans le dépôt clé-valeur. Les sessions sont marquées par des identifiants et toutes les données recueillies sur chaque session – thèmes, profils, offres ciblées, etc. – sont classées sous l’ID approprié.

Un autre cas d’usage plus spécifique, mais similaire au précédent, concerne le e-commerce. Généralement, les paniers d’achats des sites des e-marchands peuvent collecter des données relatives à des sessions d’achat individuelles. Il est préférable d’utiliser un SGBDR pour les traiter les transactions financières.

Cependant, les enregistrements de sessions antérieures au paiement sont probablement mieux conservés dans une base de données orientée clé-valeur. Les clients qui emplissent leur panier et changent ensuite d’avis sur les items sélectionnés sont plus nombreux que ceux qui procèdent immédiatement au paiement. Pourquoi remplir une base de données relationnelle avec toutes ces données, alors qu’il existe une solution plus efficace et plus fiable ?

Un dépôt de paires clé-valeur sera rapide pour enregistrer et obtenir des données simultanément. En outre, grâce à sa redondance intégrée, il garantit qu’aucun article du panier ne sera perdu. L’extensibilité de cette technologie est utile pendant les périodes de pointe, à l’approche des fêtes ou pendant les soldes et les promotions spéciales, car elles entraînent généralement une forte augmentation des ventes et un accroissement encore plus important du trafic sur le site Web. En principe, l’évolutivité de la base de données permet de s’assurer que la charge accrue n’entraîne pas de problèmes de performance.

Avantages des bases de données clé-valeur

Il convient de souligner que différents types de bases de données existent pour répondre à différents objectifs. Dans certains cas, cela rend le choix évident. Bien que les dépôts de paires clé-valeur puissent être limités, ils constituent souvent le bon candidat pour les raisons suivantes :

• Simplicité. Comme mentionné ci-dessus, les bases de données clé-valeur sont assez simples à utiliser. Les commandes directes et l’absence de types de données facilitent le travail des programmeurs. Grâce à cette caractéristique, les données peuvent prendre n’importe quel type, voire plusieurs types, si nécessaire.
• Rapidité. Cette sobriété rend les bases de données de type clé-valeur réactive, à condition que le reste de l’environnement qui l’entoure soit bien construit et optimisé.
• Évolutivité. C’est un avantage très apprécié des SGBD NoSQL en général, et aux dépôts de paires de clé-valeur en particulier. Contrairement aux bases de données relationnelles, qui ne sont extensibles que verticalement, les key-value stores peuvent s’étendre horizontalement avec pour seule limite l’infrastructure sous-jacente.
• Plus facile à déplacer. L’absence de langage de requêtes signifie que la base de données peut être plus facilement migrée entre différents systèmes sans devoir modifier l’architecture.
• Fiabilité. La redondance intégrée est très utile pour pallier la perte d’un nœud de stockage, les données dupliquées remplaçant celles qui ont été perdues. Cette robustesse n’a plus cours quand le nœud responsable de la duplication tombe, c’est la limite.

Inconvénients des bases de données clé-valeur

Toutes les bases de données clés-valeurs ne sont pas identiques, mais certains des inconvénients généraux sont les suivants :

• Simplicité relative. La liste des avantages et des inconvénients démontre que tout est relatif, et que ce qui est profitable peut aussi présenter des désagréments. Cela prouve encore une fois que vous devez examiner attentivement vos besoins et vos options avant de choisir une base de données. Le fait que les key-value stores ne soient pas complexes signifie également qu’ils ne sont pas raffinés. La gestion des structures de données et des requêtes peut largement différer d’un produit à un autre.
• Pas de langage de requêtes standard. En l’absence d’un langage d’interrogation unifié à utiliser, les requêtes d’un SGBDR peuvent ne pas être transportables dans une base de données clé-valeur. Il est pourtant possible de manipuler SQL ou d’autres moyens à l’aide de quelques ajustements.
• Les valeurs ne peuvent pas être filtrées par défaut. La base de données voit les valeurs comme des blobs et ne peut donc pas conférer beaucoup de sens à ce qu’ils contiennent. Une requête renverra toutes les valeurs attribuées à une clé – plutôt qu’un élément d’information spécifique – et lorsqu’elles sont mises à jour, toutes les valeurs doivent être actualisées.

Bases de données clé-valeur populaires

Si l’on se fie au classement fourni par DB Engines, quelques SGBD dotés du modèle clé-valeur sortent du lot. Redis s’y place en tête, suivie par Amazon DynamoDB, puis Azure Cosmos DB. En quatrième, cinquième et sixième position, l’on retrouve respectivement Memcached, etcd et Hazelcast. AeroSpike arrive en huitième position.

Voici trois exemples de bases de données clé-valeur :

• Redis. Redis est connu comme un serveur de structures de données compatibles avec plusieurs types de valeurs. Au lieu d’associer une clé à une chaîne de caractère, la base de données in-memory peut associer des clés avec des valeurs plus complexes. Le SGBD supporte les clés contenant des listes, des hachages, des chaînes de caractères et des ensembles.
• Amazon DynamoDB. DynamoDB est d’abord une base de données key-value, mais prend également en charge le modèle document. Selon le fournisseur, son produit doit être capable d’endurer des charges élevées et de traiter des trillions de requêtes par jour. Ce DbaaS est dit serverless, c’est-à-dire que le client ne gère ni l’infrastructure, ni les instances sous-jacentes, ni même… la base de données. Il n’administre que les tables à déployer dans différentes régions cloud, place des seuils d’écriture et de lecture, utilise ou non certains index ou encore administre le chiffrement au repos s’il le souhaite. Par ailleurs, il est possible d’installer DynamoDB en local avant de passer un projet en production. Ces capacités ont fait la popularité de ce produit. Cependant, selon l’étude StackOverFlow Developer Survey 2021, les développeurs interrogés préfèrent Redis à Amazon DynamoDB.
• Aerospike. Ce SGBD NoSQL supporte aussi les modèles clé-valeur et documents. Son architecture in-memory le destine à des traitements temps réel, de la mise de données en cache, ou encore le déploiement de moteurs de recommandations.

La liste est longue et comprend de nombreux concurrents. Cependant, il est à noter que la plupart d’entre eux ne proposent pas forcément ou exclusivement des key-value stores. Il s’agit souvent de pallier les défauts du modèle clé-valeur en définissant des clés à usage spécifique ou en y associant un moteur d’indexation fondé sur une ontologie ou sur un algorithme NLP.

En outre, la plupart des acteurs du marché tentent d’incorporer une approche multimodèle à leur produit, à des fins techniques et commerciales. Dès lors, la question est de savoir si vous préférez une seule technologie de base de données supposément capable de gérer la plupart des cas d’usage ou en sélectionner plusieurs, chacune spécialisée dans leur domaine.

Les bases de données clé-valeur servent un objectif spécifique, et elles possèdent des fonctionnalités qui peuvent ajouter de la valeur à certaines, mais imposer des limites à d’autres. C’est pourquoi vous devez toujours évaluer soigneusement vos besoins et l’objectif que vous visez avant de choisir un SGBD. Une fois cela fait, vous pouvez commencer à examiner vos options et vous assurer que votre base de données vous permet de collecter et de tirer le meilleur parti de vos données sans compromettre les performances.