NoSQL - NoSQL

« Stockage structuré » redirige ici. Pour la technologie Microsoft également connue sous le nom de stockage structuré, voir COM Structured Storage .

Un NoSQL ( en référence à l' origine « non SQL » ou « non-relationnel ») base de données fournit un mécanisme pour le stockage et la récupération des données qui sont modélisés dans des moyens autres que les relations tabulaires utilisés dans les bases de données relationnelles . De telles bases de données existent depuis la fin des années 1960, mais le nom « NoSQL » n'a été inventé qu'au début du 21e siècle, déclenché par les besoins des entreprises du Web 2.0 . Les bases de données NoSQL sont de plus en plus utilisées dans le Big Data et les applications Web en temps réel. Les systèmes NoSQL sont également parfois appelés « pas seulement SQL » pour souligner qu'ils peuvent prendre en charge des langages de requête de type SQL ou s'asseoir à côté de bases de données SQL dans des architectures polyglottes persistantes .

Les motivations de cette approche incluent la simplicité de conception , une mise à l' échelle "horizontale" plus simple vers des clusters de machines (ce qui est un problème pour les bases de données relationnelles), un contrôle plus fin de la disponibilité et la limitation de la non -concordance d'impédance objet-relationnelle . Les structures de données utilisées par les bases de données NoSQL (par exemple , paire clé-valeur , colonne large , graphique ou document ) sont différentes de celles utilisées par défaut dans les bases de données relationnelles, rendant certaines opérations plus rapides dans NoSQL. L'adéquation particulière d'une base de données NoSQL donnée dépend du problème qu'elle doit résoudre. Parfois, les structures de données utilisées par les bases de données NoSQL sont également considérées comme "plus flexibles" que les tables de bases de données relationnelles.

De nombreux magasins NoSQL compromettent la cohérence (au sens du théorème CAP ) en faveur de la disponibilité, de la tolérance de partition et de la vitesse. Les obstacles à une plus grande adoption des magasins NoSQL incluent l'utilisation de langages de requête de bas niveau (au lieu de SQL, par exemple), le manque de capacité à effectuer des jointures ad hoc entre les tables, le manque d'interfaces standardisées et d'énormes investissements antérieurs dans les bases de données relationnelles existantes . La plupart des magasins NoSQL ne disposent pas de véritables transactions ACID , bien que quelques bases de données les aient placées au cœur de leurs conceptions.

Au lieu de cela, la plupart des bases de données NoSQL offrent un concept de « cohérence éventuelle », dans lequel les modifications de la base de données sont propagées à tous les nœuds « en fin de compte » (généralement en quelques millisecondes), de sorte que les requêtes de données peuvent ne pas renvoyer de données mises à jour immédiatement ou entraîner la lecture de données qui sont pas précis, un problème connu sous le nom de lectures périmées. De plus, certains systèmes NoSQL peuvent présenter des écritures perdues et d'autres formes de perte de données . Certains systèmes NoSQL proposent des concepts tels que la journalisation en écriture anticipée pour éviter la perte de données. Pour le traitement des transactions distribuées sur plusieurs bases de données, la cohérence des données est un défi encore plus grand qui est difficile pour les bases de données NoSQL et relationnelles. Les bases de données relationnelles "ne permettent pas aux contraintes d'intégrité référentielle de s'étendre sur les bases de données". Peu de systèmes maintiennent à la fois les transactions ACID et les normes X/Open XA pour le traitement des transactions distribuées. Les bases de données relationnelles interactives partagent des techniques d'analyse de relais conformationnelles comme une caractéristique commune. Les limitations au sein de l'environnement d'interface sont surmontées à l'aide de protocoles de virtualisation sémantique, de sorte que les services NoSQL sont accessibles à la plupart des systèmes d'exploitation.

Histoire

Le terme NoSQL a été utilisé par Carlo Strozzi en 1998 pour nommer sa base de données relationnelle open source Strozzi NoSQL légère qui n'exposait pas l' interface SQL ( Structured Query Language ) standard, mais était toujours relationnelle. Son SGBDR NoSQL est distinct du concept général des bases de données NoSQL vers 2009. Strozzi suggère que, parce que le mouvement NoSQL actuel « s'écarte complètement du modèle relationnel, il aurait donc dû être appelé de manière plus appropriée « NoREL » », se référant à « 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 open-source distribuées et non relationnelles ». Le nom a tenté d'étiqueter l'émergence d'un nombre croissant de magasins de données non relationnelles et distribuées, y compris des clones open source de Bigtable / MapReduce de Google et 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 de base par modèle de données, avec des exemples :

Une classification plus détaillée est la suivante, basée sur celle de Stephen Yen :

Taper Exemples notables de ce type
Cache clé-valeur Apache Ignite , Couchbase , Coherence , eXtreme Scale , Hazelcast , Infinispan , Memcached , Redis , Velocity
Magasin clé-valeur Azure Cosmos DB , ArangoDB , Aerospike , Couchbase , Redis
Magasin clé-valeur (à terme cohérent) Azure Cosmos DB , Base de données Oracle NoSQL , Dynamo , Riak , Voldemort
Magasin clé-valeur (commandé) FoundationDB , InfinityDB , LMDB , MemcacheDB
Magasin de tuples Rivière Apache , GigaSpaces
Base de données d'objets Objectivité/DB , Prest , ZopeDB
Magasin de documents Azure Cosmos DB , ArangoDB , BaseX , Clusterpoint , Couchbase , CouchDB , DocumentDB , eXist-db , IBM Domino , MarkLogic , MongoDB , Qizx , RethinkDB , Elasticsearch
Magasin à colonnes larges Azure Cosmos DB , Amazon DynamoDB , Bigtable , Cassandra , Google Cloud Datastore , HBase , Hypertable , ScyllaDB
Base de données multi-modèles native ArangoDB , Azure Cosmos DB , OrientDB , MarkLogic

Les bases de données de corrélation sont indépendantes du modèle et, au lieu d'un stockage basé sur des lignes ou des colonnes, utilisez un stockage basé sur des valeurs.

Magasin clé-valeur

Article principal: base de données clé-valeur

Les magasins clé-valeur (KV) utilisent le tableau associatif (également appelé carte ou dictionnaire) comme modèle de données fondamental. Dans ce modèle, les données sont représentées sous la forme d'une collection de paires clé-valeur, de sorte que chaque clé possible apparaisse au plus une fois dans la collection.

Le modèle clé-valeur est l'un des modèles de données non triviaux les plus simples, et des modèles de données plus riches sont souvent mis en œuvre comme une extension de celui-ci. Le modèle clé-valeur peut être étendu à un modèle ordonné discrètement qui maintient les clés dans l' ordre lexicographique . Cette extension est puissante en termes de calcul, en ce sens qu'elle peut récupérer efficacement des plages de clés sélectives .

Les magasins de valeurs-clés peuvent utiliser des modèles de cohérence allant de la cohérence à terme à la sérialisation . Certaines bases de données prennent en charge l'ordre des clés. Il existe diverses implémentations matérielles, et certains utilisateurs stockent les données dans la mémoire (RAM), tandis que d'autres sur des disques à semi-conducteurs (SSD) ou des disques rotatifs (aka disque dur (HDD)).

Magasin de documents

Articles principaux : Base de données orientée document et base de données XML

Le concept central d'une banque de documents est celui de "document". Bien que les détails de cette définition diffèrent entre les bases de données orientées document, elles supposent toutes que les documents encapsulent et codent des données (ou des informations) dans certains formats ou encodages standard. Les codages utilisés incluent XML, YAML et JSON et des formes binaires comme BSON . Les documents sont adressés dans la base de données via une clé unique qui représente ce document. Une autre caractéristique déterminante d'une base de données orientée document est une API ou un langage de requête permettant de récupérer des documents en fonction de leur contenu.

Différentes implémentations offrent différentes manières d'organiser et/ou de regrouper les documents :

  • Collections
  • Mots clés
  • Métadonnées non visibles
  • Hiérarchies de répertoires

Par rapport aux bases de données relationnelles, les collections pourraient être considérées comme analogues à des tableaux et des documents analogues à des enregistrements. Mais ils sont différents : chaque enregistrement d'une table a la même séquence de champs, tandis que les documents d'une collection peuvent avoir des champs complètement différents.

Graphique

Article principal: base de données de graphes

Les bases de données de graphes sont conçues pour des données dont les relations sont bien représentées sous la forme d'un graphe composé d'éléments connectés par un nombre fini de relations. Des exemples de données incluent les relations sociales, les liaisons de transport public, les cartes routières, les topologies de réseau, etc.

Bases de données de graphes et leur langage de requête
Nom Langue(s) Remarques
AllegroGraph SPARQL RDF triple magasin
Amazon Neptune Gremlin , SPARQL Base de données graphique
ArangoDB AQL, JavaScript , GraphQL Document SGBD multi-modèle , base de données graphique et magasin clé-valeur
Base de données Azure Cosmos Diablotin Base de données graphique
DEX/Sparksee C++ , Java , C# , Python Base de données graphique
BD de troupeau Scala Base de données graphique
IBM DB2 SPARQL Triple magasin RDF ajouté dans DB2 10
Graphique infini Java Base de données graphique
MarkLogic Java , JavaScript , SPARQL , XQuery Base de données de documents multi-modèles et triple magasin RDF
Neo4j Zéro Base de données graphique
Virtuose OpenLink C++ , C# , Java , SPARQL Middleware et moteur de base de données hybride
Oracle SPARQL 1.1 RDF triple store ajouté en 11g
OrientDB Java , SQL Base de données multi-modèles de documents et de graphiques
CHOUETTE Java , SPARQL 1.1 RDF triple magasin
Sens du Profium Java , SPARQL RDF triple magasin
Entreprise Sqrrl Java Base de données graphique

Base de données d'objets

Article principal: base de données d'objets

Tabulaire

Magasin de tuples

Base de données triple/quad store (RDF)

Articles principaux : Triplestore et graphe nommé

Hébergé

Bases de données multivaleurs

Base de données multimodèle

Performance

Les performances des bases de données NoSQL sont généralement évaluées à l'aide de la métrique de débit , qui est mesurée en opérations/seconde. L'évaluation des performances doit prêter attention aux bons repères tels que les configurations de production, les paramètres des bases de données, le volume de données prévu et les charges de travail simultanées des utilisateurs.

Ben Scofield a évalué différentes catégories de bases de données NoSQL comme suit :

Modèle de données Performance Évolutivité La flexibilité Complexité Fonctionnalité
Magasin clé-valeur haute haute haute rien variable (aucune)
Magasin à colonnes haute haute modérer meugler minimal
Magasin orienté document haute variable (élevé) haute meugler variable (faible)
Base de données graphique variable variable haute haute la théorie des graphes
Base de données relationnelle variable variable meugler modérer 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

Étant donné que la plupart des bases de données NoSQL n'ont pas la capacité de joindre les requêtes, le schéma de la base de données 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 le tableau Prise en charge des jointures et 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 avec une seule requête, il est courant de faire 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 des requêtes supplémentaires peut donc être acceptable. Si un nombre excessif de requêtes était 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 stocker uniquement des clés étrangères, il est courant de stocker des valeurs étrangères réelles avec les données du modèle. Par exemple, chaque commentaire de blog peut inclure le nom d'utilisateur en plus d'un identifiant d'utilisateur, offrant ainsi un accès facile au nom d'utilisateur sans nécessiter une autre recherche. Cependant, lorsqu'un nom d'utilisateur change, il devra désormais être modifié à de nombreux endroits dans la base de données. Ainsi, cette approche fonctionne mieux lorsque les lectures sont beaucoup plus courantes que les écritures.

Données d'imbrication

Avec les bases de données de documents comme MongoDB, il est courant de mettre plus de données dans un plus petit nombre de collections. Par exemple, dans une application de blog, on peut choisir de stocker les commentaires dans le document du billet de blog de sorte qu'avec une seule récupération, on obtienne tous les commentaires. Ainsi, dans cette approche, un seul document contient toutes les données dont vous avez besoin pour une tâche spécifique.

ACID et rejoindre le support

Une base de données est marquée comme prenant en charge les propriétés ACID (Atomicité, Cohérence, Isolation, Durabilité) ou les opérations de jointure si la documentation de la base de données fait cette affirmation. Cependant, cela ne signifie pas nécessairement que la capacité est entièrement prise en charge d'une manière similaire à la plupart des bases de données SQL.

Base de données ACIDE Jointure
Aérospike Oui Non
Apache Ignite Oui Oui
ArangoDB Oui Oui
Base de canapé Oui Oui
CouchDB Oui Oui
DB2 Oui Oui
InfinityDB Oui Non
LMDB Oui Non
MarkLogic Oui Oui
MongoDB Oui Oui
OrientDB Oui Oui

Voir également

Les références

Lectures complémentaires

Liens externes