Risposte:
Un archivio chiave-valore fornisce il modello di dati più semplice possibile ed è esattamente ciò che suggerisce il nome: è un sistema di archiviazione che archivia i valori indicizzati da una chiave. Sei limitato alla query per chiave ei valori sono opachi , il negozio non ne sa nulla . Ciò consente operazioni di lettura e scrittura molto veloci (un semplice accesso al disco) e vedo questo modello come una sorta di cache non volatile (cioè adatto se hai bisogno di accessi veloci tramite chiave a dati di lunga durata).
Un database orientato ai documenti estende il modello precedente ei valori vengono memorizzati in un formato strutturato (un documento, da cui il nome) che il database può comprendere. Ad esempio, un documento potrebbe essere un post sul blog e i commenti e i tag archiviati in modo denormalizzato. Poiché i dati sono trasparenti , il negozio può svolgere più lavoro (come l'indicizzazione dei campi del documento) e non sei limitato a eseguire query per chiave. Come ho accennato, tali database consentono di recuperare i dati di un'intera pagina con una singola query e sono adatti per applicazioni orientate al contenuto (motivo per cui piacciono a grandi siti come Facebook o Amazon).
Altri tipi di database NoSQL includono archivi orientati alle colonne , database a grafo e persino database a oggetti . Ma questo va oltre la domanda.
Bene, ho indagato su NoSQL da solo nell'ultimo mese o giù di lì. Penso che generalmente si potrebbe affermare qualcosa di simile
Un database orientato ai documenti, o archivio di documenti, serve per archiviare, recuperare e gestire le informazioni orientate ai documenti, che sono dati semi-strutturati. L'archivio valori-chiave è ereditato dal database orientato ai documenti. La differenza sta nel modo in cui i dati vengono elaborati; in un archivio chiave-valore i dati sono considerati intrinsecamente opachi per il database, mentre un sistema orientato al documento si basa sulla struttura interna del documento per estrarre i metadati che il motore di database utilizza per un'ulteriore ottimizzazione.
Se ci occupiamo della differenza tra MOngoDb e Cassandra. MongoDB si comporta in modo molto simile a un database relazionale. Il suo modello di dati consiste in un database al livello superiore, quindi raccolte che sono come tabelle in MySQL (ad esempio) e quindi documenti che sono contenuti all'interno della raccolta, come righe in MySQL. Ogni documento ha un campo e un valore in cui questo è simile a colonne e valori in MySQL. I campi possono essere semplici chiave / valore ad es. {'Name': 'David Mytton'} ma possono contenere anche altri documenti ad es. {'Name': {'first': David, 'last': 'Mytton'}}. In Cassandra i documenti sono conosciuti come "colonne" che in realtà sono solo una singola chiave e valore. es. {'chiave': 'nome', 'valore': 'David Mytton'}. C'è anche un campo timestamp che serve per la replica interna e la coerenza. Il valore può essere un valore singolo ma può contenere anche un'altra "colonna". Queste colonne esistono quindi all'interno di famiglie di colonne che ordinano i dati in base a un valore specifico nelle colonne, a cui fa riferimento una chiave.
Ma al livello più alto c'è un keyspace, che è simile al database MongoDB.