Un magasin clé-valeur fournit le modèle de données le plus simple possible et c'est exactement ce que son nom suggère: c'est un système de stockage qui stocke des valeurs indexées par une clé. Vous êtes limité à la requête par clé et les valeurs sont opaques , le magasin n'en sait rien . Cela permet des opérations de lecture et d'écriture très rapides (un simple accès disque) et je vois ce modèle comme une sorte de cache non volatile (c'est-à-dire bien adapté si vous avez besoin d'accéder rapidement par clé à des données de longue durée).
Une base de données orientée document étend le modèle précédent et les valeurs sont stockées dans un format structuré (un document, d'où le nom) que la base de données peut comprendre. Par exemple, un document peut être un article de blog et les commentaires et les balises stockés de manière dénormalisée. Étant donné que les données sont transparentes , le magasin peut effectuer plus de travail (comme l'indexation des champs du document) et vous n'êtes pas limité à la requête par clé. Comme je l'ai laissé entendre, de telles bases de données permettent de récupérer les données d'une page entière avec une seule requête et sont bien adaptées aux applications orientées contenu (c'est pourquoi les grands sites comme Facebook ou Amazon les aiment).
Les autres types de bases de données NoSQL incluent les magasins orientés colonnes , les bases de données graphiques et même les bases de données d'objets . Mais cela va au-delà de la question.
Les magasins de valeurs-clés n'ont pas à être effectués avec un accès disque et les appeler non volatiles est incorrect dans certaines implémentations. Vous pouvez créer un magasin clé-valeur en mémoire sans écriture directe ni réécriture sur un support de stockage non volatile. Le fait d'appeler les données à longue durée de vie est également trompeur, car la durée de vie des données n'a rien à voir avec la manière dont vous les récupérez.
Anthony
17
Eh bien, j'ai moi-même enquêté sur NoSQL le mois dernier. Je pense qu'il pourrait généralement être dit quelque chose comme
Les magasins KV ne connaissent pas la valeur du contenu réellement stocké pour une clé
Document based vous permet de définir des index secondaires dans le contenu de valeur, car la base de données connaît la structure du document (par exemple, les balises d'un article de blog).
Les solutions NoSQL ont chacune des fonctionnalités spécifiques qui doivent être prises en compte, telles que
Types de données spéciaux dans un magasin KV (par exemple, ensembles avec pop / push gauche / droite comme dans Redis)
cluster facile à monter / descendre comme le dit riak (je ne l'ai pas essayé ... encore)
magasin de données enfichable comme dans Voldemort
configuration Web intégrée et prise en charge des applications Web comme dans CouchDB / couchapp
Une base de données orientée document, ou magasin de documents, sert au stockage, à la récupération et à la gestion des informations orientées document, qui sont des données semi-structurées. Le magasin de valeurs-clés est hérité de la base de données orientée document. La différence réside dans la manière dont les données sont traitées; dans un magasin clé-valeur, les données sont considérées comme intrinsèquement opaques pour la base de données, tandis qu'un système orienté document repose sur la structure interne du document afin d'extraire les métadonnées que le moteur de base de données utilise pour une optimisation supplémentaire.
Si nous traitons de la différence entre MOngoDb et Cassandra. MongoDB agit un peu comme une base de données relationnelle. Son modèle de données se compose d'une base de données au niveau supérieur, puis de collections qui sont comme des tables dans MySQL (par exemple) et puis des documents qui sont contenus dans la collection, comme des lignes dans MySQL. Chaque document a un champ et une valeur où cela est similaire aux colonnes et aux valeurs de MySQL. Les champs peuvent être une simple clé / valeur par exemple {'name': 'David Mytton'} mais ils peuvent également contenir d'autres documents, par exemple {'name': {'first': David, 'last': 'Mytton'}}. Dans Cassandra, les documents sont appelés «colonnes» qui ne sont en réalité qu'une seule clé et valeur. par exemple {'clé': 'nom', 'valeur': 'David Mytton'}. Il existe également un champ d'horodatage pour la réplication interne et la cohérence. La valeur peut être une valeur unique mais peut également contenir une autre «colonne». Ces colonnes existent alors au sein de familles de colonnes qui ordonnent les données en fonction d'une valeur spécifique dans les colonnes, référencées par une clé.
Mais, au niveau supérieur, il y a un espace de clés, qui est similaire à la base de données MongoDB.
Réponses:
Un magasin clé-valeur fournit le modèle de données le plus simple possible et c'est exactement ce que son nom suggère: c'est un système de stockage qui stocke des valeurs indexées par une clé. Vous êtes limité à la requête par clé et les valeurs sont opaques , le magasin n'en sait rien . Cela permet des opérations de lecture et d'écriture très rapides (un simple accès disque) et je vois ce modèle comme une sorte de cache non volatile (c'est-à-dire bien adapté si vous avez besoin d'accéder rapidement par clé à des données de longue durée).
Une base de données orientée document étend le modèle précédent et les valeurs sont stockées dans un format structuré (un document, d'où le nom) que la base de données peut comprendre. Par exemple, un document peut être un article de blog et les commentaires et les balises stockés de manière dénormalisée. Étant donné que les données sont transparentes , le magasin peut effectuer plus de travail (comme l'indexation des champs du document) et vous n'êtes pas limité à la requête par clé. Comme je l'ai laissé entendre, de telles bases de données permettent de récupérer les données d'une page entière avec une seule requête et sont bien adaptées aux applications orientées contenu (c'est pourquoi les grands sites comme Facebook ou Amazon les aiment).
Les autres types de bases de données NoSQL incluent les magasins orientés colonnes , les bases de données graphiques et même les bases de données d'objets . Mais cela va au-delà de la question.
Voir également
la source
Eh bien, j'ai moi-même enquêté sur NoSQL le mois dernier. Je pense qu'il pourrait généralement être dit quelque chose comme
la source
Une base de données orientée document, ou magasin de documents, sert au stockage, à la récupération et à la gestion des informations orientées document, qui sont des données semi-structurées. Le magasin de valeurs-clés est hérité de la base de données orientée document. La différence réside dans la manière dont les données sont traitées; dans un magasin clé-valeur, les données sont considérées comme intrinsèquement opaques pour la base de données, tandis qu'un système orienté document repose sur la structure interne du document afin d'extraire les métadonnées que le moteur de base de données utilise pour une optimisation supplémentaire.
Si nous traitons de la différence entre MOngoDb et Cassandra. MongoDB agit un peu comme une base de données relationnelle. Son modèle de données se compose d'une base de données au niveau supérieur, puis de collections qui sont comme des tables dans MySQL (par exemple) et puis des documents qui sont contenus dans la collection, comme des lignes dans MySQL. Chaque document a un champ et une valeur où cela est similaire aux colonnes et aux valeurs de MySQL. Les champs peuvent être une simple clé / valeur par exemple {'name': 'David Mytton'} mais ils peuvent également contenir d'autres documents, par exemple {'name': {'first': David, 'last': 'Mytton'}}. Dans Cassandra, les documents sont appelés «colonnes» qui ne sont en réalité qu'une seule clé et valeur. par exemple {'clé': 'nom', 'valeur': 'David Mytton'}. Il existe également un champ d'horodatage pour la réplication interne et la cohérence. La valeur peut être une valeur unique mais peut également contenir une autre «colonne». Ces colonnes existent alors au sein de familles de colonnes qui ordonnent les données en fonction d'une valeur spécifique dans les colonnes, référencées par une clé.
Mais, au niveau supérieur, il y a un espace de clés, qui est similaire à la base de données MongoDB.
la source