Worldlex Wiki Les bases de données NoSQL sont populaires dans le domaine du Big Data et des applications web en temps réel en raison de leur conception simple, de leur capacité à évoluer sur des clusters de machines (appelée mise à l'échelle horizontale ) et du contrôle précis qu'elles offrent sur la disponibilité des données . Ces structures peuvent accélérer certaines tâches et sont souvent considérées comme plus adaptables que les tables de bases de données classiques. Cependant, de nombreux systèmes NoSQL privilégient la vitesse et la disponibilité à la cohérence stricte (conformément au théorème CAP ), en utilisant la cohérence éventuelle : les mises à jour finissent par atteindre tous les nœuds, généralement en quelques millisecondes, mais peuvent entraîner de brefs délais d'accès aux données les plus récentes, appelés lectures obsolètes . Bien que la plupart ne prennent pas entièrement en charge les transactions ACID , certaines, comme MongoDB , les intègrent comme fonctionnalité clé.
Les obstacles à une adoption plus large des bases de données NoSQL incluent leur utilisation de langages de requêtes de bas niveau au lieu de SQL, l'impossibilité d'effectuer des jointures ad hoc entre tables, le manque d'interfaces standardisées et les investissements importants déjà réalisés dans les bases de données relationnelles. Certains systèmes NoSQL risquent de perdre des données suite à des erreurs d'écriture ou autres, bien que des fonctionnalités comme la journalisation anticipée des modifications (WAL ), une méthode permettant d'enregistrer les modifications avant leur application, puissent contribuer à prévenir ce risque. Pour le traitement transactionnel distribué sur plusieurs bases de données, le maintien de la cohérence des données représente un défi tant pour les systèmes NoSQL que relationnels, car les bases de données relationnelles ne peuvent pas imposer de règles liant des bases de données distinctes, et peu de systèmes prennent en charge à la fois les transactions ACID et les normes X/Open XA pour la gestion des mises à jour distribuées. Les limitations de l'environnement d'interface sont surmontées grâce aux protocoles de virtualisation sémantique, ce qui permet aux services NoSQL d'être accessibles à la plupart des systèmes d'exploitation .Histoire
Le terme NoSQL a été utilisé par Carlo Strozzi en 1998 pour désigner sa base de données relationnelle open source légère, Strozzi NoSQL, qui n'exposait pas l'interface standard du langage SQL (Structured Query Language ), mais restait relationnelle. Son SGBDR NoSQL se distingue du concept général de bases de données NoSQL apparu vers 2009. Strozzi suggère que, puisque le mouvement NoSQL actuel « s'éloigne complètement du modèle relationnel, il aurait donc été plus justement appelé "NoREL" », signifiant « non relationnel ».
Johan Oskarsson, alors développeur chez Last.fm , a réintroduit le terme NoSQL début 2009 lorsqu'il a organisé un événement pour discuter des « bases de données distribuées open source non relationnelles ». Le nom tentait d'étiqueter l'émergence d'un nombre croissant de magasins de données distribués non relationnels, y compris les clones open source de Bigtable / MapReduce de Google et de DynamoDB d'Amazon .
Types et exemples
Il existe différentes manières de classer les bases de données NoSQL, avec différentes catégories et sous-catégories, dont certaines se chevauchent. Ce qui suit est une classification non exhaustive par modèle de données, avec des exemples :
magasin clé-valeur
Le modèle clé-valeur est l'un des modèles de données non triviaux les plus simples, et les modèles de données plus riches sont souvent implémentés comme une extension de celui-ci. Le modèle clé-valeur peut être étendu à un modèle discrètement ordonné qui conserve les clés dans l'ordre lexicographique . Cette extension est puissante sur le plan du calcul, car elle permet de récupérer efficacement des plages de clés spécifiques .
Les bases de données clé-valeur peuvent utiliser des modèles de cohérence allant de la cohérence éventuelle à la sérialisabilité . Certaines bases de données prennent en charge l'ordonnancement des clés. Il existe diverses implémentations matérielles ; certains utilisateurs stockent leurs données en mémoire vive (RAM), tandis que d'autres les stockent sur des disques SSD ou des disques durs (HDD).
Magasin de documents
Les différentes implémentations proposent différentes manières d'organiser et/ou de regrouper les documents :
- Collections
- Étiquettes
- Métadonnées non visibles
- hiérarchies de répertoires
Par rapport aux bases de données relationnelles, les collections peuvent être considérées comme analogues aux tables et les documents comme analogues aux enregistrements. Cependant, elles diffèrent : chaque enregistrement d’une table possède la même séquence de champs, tandis que les documents d’une collection peuvent avoir des champs totalement différents.
Graphique
- Bases de données graphiques et leur langage de requête
Performance
Les performances des bases de données NoSQL sont généralement évaluées à l'aide du débit , mesuré en opérations par seconde. Cette évaluation doit prendre en compte des critères de référence pertinents , tels que les configurations de production, les paramètres des bases de données, le volume de données prévu et la charge de travail simultanée des utilisateurs .
Ben Scofield a classé différentes catégories de bases de données NoSQL comme suit :
| Modèle de données | Performance | Évolutivité | Flexibilité | Complexité | Intégrité des données | Fonctionnalité |
|---|---|---|---|---|---|---|
| magasin clé-valeur | haut | haut | haut | aucun | faible | variable (aucune) |
| Magasin organisé en colonnes | haut | haut | modéré | faible | faible | minimal |
| Magasin axé sur les documents | haut | variable (élevé) | haut | faible | faible | variable (faible) |
| Base de données graphiques | variable | variable | haut | haut | faible à moyen | théorie des graphes |
| Base de données relationnelle | variable | variable | faible | modéré | haut | algèbre relationnelle |
Les comparaisons de performances et d'évolutivité sont le plus souvent effectuées à l'aide du benchmark YCSB .
Gestion des données relationnelles
La plupart des bases de données NoSQL ne prenant pas en charge les jointures dans les requêtes, leur schéma doit généralement être conçu différemment. Il existe trois techniques principales pour gérer les données relationnelles dans une base de données NoSQL. (Voir jointure de tables et prise en charge ACID pour les bases de données NoSQL qui prennent en charge les jointures.)
Requêtes multiples
Au lieu de récupérer toutes les données en une seule requête, il est courant d'effectuer plusieurs requêtes pour obtenir les données souhaitées. Les requêtes NoSQL sont souvent plus rapides que les requêtes SQL traditionnelles ; le coût de requêtes supplémentaires peut donc être acceptable. Si un nombre excessif de requêtes s'avère nécessaire, l'une des deux autres approches est plus appropriée.
Mise en cache, réplication et données non normalisées
Au lieu de se limiter au stockage des clés étrangères, il est courant de stocker les valeurs étrangères elles-mêmes avec les données du modèle. Par exemple, chaque commentaire de blog peut inclure le nom d'utilisateur en plus de son identifiant, permettant ainsi d'accéder facilement au nom d'utilisateur sans avoir à effectuer une nouvelle recherche. Cependant, lorsqu'un nom d'utilisateur change, il faudra le modifier à de nombreux endroits dans la base de données. Cette approche est donc plus adaptée lorsque les lectures sont beaucoup plus fréquentes que les écritures.
Données d'imbrication
Avec les bases de données documentaires comme MongoDB, il est courant de regrouper davantage de données dans un nombre réduit de collections. Par exemple, dans une application de blog, on peut choisir de stocker les commentaires au sein du document « article », afin d'obtenir tous les commentaires en une seule requête. Ainsi, dans cette approche, un seul document contient toutes les données nécessaires à une tâche spécifique.
ACID et rejoignez le soutien
Une base de données est considérée comme prenant en charge les propriétés ACID (atomicité, cohérence, isolation, durabilité) ou les opérations de jointure si sa documentation l'indique. Toutefois, cela ne signifie pas nécessairement que cette fonctionnalité est pleinement prise en charge, comme c'est le cas pour la plupart des bases de données SQL.
| Base de données | ACIDE | Rejoint | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Aérospike | Apache Ignite | ArangoDB | Amazon DynamoDB | Couchbase | CouchDB | IBM Db2 | InfinityDB | LMDB | MarkLogic | MongoDB | OrientDB | DynamoDB , MongoDB , Cassandra , Couchbase , HBase et Redis, présentent des comportements variés lors de l'interrogation de champs non indexés. Nombre d'entre elles effectuent une analyse complète de la table ou de la collection pour ces requêtes, en appliquant des opérations de filtrage après la récupération des données. Cependant, les bases de données NoSQL modernes intègrent souvent des fonctionnalités avancées pour optimiser les performances des requêtes. Par exemple, MongoDB prend en charge les index composés et les stratégies d'optimisation des requêtes, Cassandra propose des index secondaires et des vues matérialisées, et Redis utilise des mécanismes d'indexation personnalisés adaptés à des cas d'utilisation spécifiques. Des systèmes comme Elasticsearch utilisent des index inversés pour des recherches textuelles efficaces, mais peuvent néanmoins nécessiter une analyse complète des champs non indexés. Ce comportement reflète la priorité accordée par de nombreux systèmes NoSQL à la scalabilité et à l'efficacité des opérations sur les clés plutôt qu'à l'optimisation des requêtes sur des champs arbitraires. Par conséquent, bien que ces bases de données excellent dans les opérations CRUD de base et les recherches basées sur des clés, leur aptitude aux requêtes complexes impliquant des jointures ou un filtrage non indexé varie en fonction du type de base de données (document, clé-valeur, colonne large ou graphe) et de l'implémentation spécifique. |