Une technologie intelligente pour une industrie manufacturière forte avec une production ininterrompue 24h/24 et 7j/7 de solutions IIoT pour les entreprises.
Une base de données clé-valeur est un stockage de données NoSQL conçu pour stocker, récupérer et gérer une structure de données mieux connue sous le nom de dictionnaire. Les dictionnaires contiennent des objets qui peuvent avoir plusieurs champs, chacun contenant des données. Chaque objet est stocké et récupéré à l’aide d’une clé qui identifie de manière unique l’objet. Des exemples de bases de données clé-valeur sont Amazon DynamoDB et Redis.
Dans une base clé-valeur, chaque entité est un ensemble de paires clé-valeur. Contrairement aux bases de données RDBMS, les objets (ou enregistrements) dans une base clé-valeur peuvent avoir des champs différents pour chaque enregistrement. Cela offre une flexibilité énorme et correspond davantage aux concepts modernes comme la programmation orientée objet.
De plus, les attributs optionnels ne sont généralement pas stockés dans une base clé-valeur, ce qui réduit la mémoire utilisée pour stocker les mêmes données par rapport aux bases RDBMS.
Les bases clé-valeur peuvent utiliser différents modèles de cohérence (par ex. eventual consistency), et certaines conservent les données en mémoire (RAM) tandis que d’autres utilisent des disques SSD ou des disques rotatifs.
La plupart des key-value stores sont également distribuées ou “shardées”. Cela signifie qu’elles sont spécifiquement conçues pour permettre une montée en charge horizontale plutôt que verticale, et peuvent être étendues avec des shards supplémentaires pour stocker plus de données. Le sharding pose cependant à nouveau la question de la cohérence, et des décisions doivent être prises sur le modèle de cohérence à appliquer.
Dans un véritable key-value store, les requêtes ne peuvent être effectuées que via la clé ou des composants de la clé. Il n’est pas possible de requêter directement sur le contenu de la valeur ou de créer des requêtes complexes sur le contenu des données.
C’est là qu’interviennent les object stores, ou bases orientées documents. Ce sont un type particulier de key-value store qui étend les fonctionnalités d’un key-value store pur avec de puissantes capacités de requêtes sur le contenu des données.
Comme dit précédemment, il n’existe pas de “one ring to rule them all” : tout dépend du cas d’utilisation.
Bien que les bases clé-valeur soient puissantes, il n’existe pas de standard comme pour les bases RDBMS, et chaque type de base clé-valeur est conçu différemment pour répondre à des besoins variés.
Avantages :
Extrêmement rapide pour les recherches simples
Scalable horizontalement (via le sharding)
Schéma flexible
Faible latence (souvent en mémoire)
Désavantages:
Pas de requêtes complexes ni de relations
Capacités de filtrage limitées
Duplication des données lors de la modélisation de structures complexes
Mise en cache (par ex. Redis comme session store)
Systèmes de recommandations en temps réel
Stockage des configurations ou des données de session
Les bases de données orientées documents sont en fait des key-value stores spécialisées.
Exemples de bases de données NoSQL orientées documents : MongoDB, Microsoft Azure CosmosDB et Couchbase.
Nous appelons ces bases de données « orientées documents », non pas parce qu’elles contiennent des documents comme des fichiers PDF ou Word, mais parce qu’elles supportent pleinement un format de type document. Les bases de données orientées documents complètes disposent de puissantes capacités de requêtes qui les distinguent des key-value stores mentionnés précédemment.
Le concept central d’une base de données orientée documents est la notion de document ou d’objet. Les documents encapsulent et codent les données dans un format ou un encodage standard. Les encodages fréquemment rencontrés sont XML, YAML, JSON ainsi que des formats binaires comme BSON.
La nature flexible, semi-structurée et hiérarchique des documents et des bases orientées documents leur permet d’évoluer avec les besoins des applications.
Les objets dans une base orientée documents ne sont pas obligés de respecter un schéma standard, ni de posséder toutes les mêmes sections, propriétés ou clés. En général, les programmes utilisant des objets contiennent de nombreux types différents d’objets, et ces objets ont souvent de nombreux champs optionnels. Chaque objet, même de la même classe, peut être très différent. Les document stores sont similaires en ce sens qu’ils permettent différents types de documents dans un même stockage et autorisent les champs à être optionnels. Plusieurs encodages sont même possibles pour la même classe : un objet peut être stocké en JSON tandis qu’un autre peut être stocké en XML.
Avantages :
Schéma flexible (ajout facile de nouveaux champs)
Bonnes performances avec des données hiérarchiques ou imbriquées
Intégration facile avec les applications web et mobiles (JSON)
Scalabilité horizontale
Désavantages:
Moins adapté aux transactions ou jointures complexes
Duplication possible des données
Généralement cohérence éventuelle lors de modifications des structures de documents
Systèmes de gestion de contenu
Applications web utilisant des données JSON
Données d’événements et de journaux (logging)