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.
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
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.