Che cos'è un database di archivio chiave / valore?

Ho cercato la pagina di Wikipedia per NoSQL ed elenca diverse varianti nel database dell'archivio chiave / valore, ma non riesco a trovare alcun dettaglio su cosa significhi nell'archivio chiave / valore in questo contesto. Qualcuno potrebbe spiegare o collegare una spiegazione a me? Inoltre, quando dovrei usare un tale database?

Conosci il concetto di coppia chiave / valore? Presumendo che tu abbia familiarità con Java o C # questo è nella lingua come una mappa / hash / datatable / KeyValuePair (l'ultimo è nel caso di C #)

Il modo in cui funziona è dimostrato in questo piccolo diagramma di esempio:

Color        Red
Age          18
Size         Large
Name         Smith
Title        The Brown Dog

Dove hai una chiave (a sinistra) e un valore (a destra) ... nota che può essere una stringa, int o simili. La maggior parte degli oggetti KVP ti consente di memorizzare qualsiasi oggetto sulla destra, perché è solo un valore.

Poiché avrai sempre una chiave univoca per un particolare oggetto che desideri restituire, puoi semplicemente eseguire una query nel database per quella chiave univoca e ottenere i risultati da qualunque nodo abbia l'oggetto (ecco perché è buono per i sistemi distribuiti, dal momento che ci sono altre cose coinvolte come il polling per i primi n nodi che restituiscono un valore che corrisponde ad altri ritorni dei nodi).

Ora il mio esempio sopra è molto semplice, quindi ecco una versione leggermente migliore di KVP

user1923_color    Red
user1923_age      18
user3371_color    Blue
user4344_color    Brackish
user1923_height   6' 0"
user3371_age      34

Come puoi vedere, la semplice generazione di chiavi consiste nel mettere "user" il numero univoco, un carattere di sottolineatura e l'oggetto. Ancora una volta, questa è una semplice variazione, ma penso che iniziamo a capire che fino a quando possiamo definire la parte a sinistra e averla formattata in modo coerente, possiamo estrarne il valore.

Si noti che non ci sono restrizioni sul valore della chiave (ok, ci possono essere alcune limitazioni, come solo il testo) o sulla proprietà del valore (potrebbe esserci una limitazione della dimensione) ma finora non ho avuto sistemi davvero complessi. Proviamo ad andare un po 'oltre:

app_setting_width      450
user1923_color         Red
user1923_age           18
user3371_color         Blue
user4344_color         Brackish
user1923_height        6' 0"
user3371_age           34
error_msg_457          There is no file %1 here
error_message_1        There is no user with %1 name
1923_name              Jim
user1923_name          Jim Smith
user1923_lname         Smith
Application_Installed  true
log_errors             1
install_path           C:\Windows\System32\Restricted
ServerName             localhost
test                   test
test1                  test
test123                Brackish
devonly
wonderwoman
value                  key

Ti viene l'idea ... tutti quelli sarebbero archiviati in un'unica "tabella" sui nodi distribuiti (c'è la matematica dietro tutto) e chiederesti semplicemente al sistema distribuito il valore di cui hai bisogno per nome.

Per lo meno, questa è la mia comprensione di come funziona tutto. Potrei avere alcune cose sbagliate, ma queste sono le basi.

link wikipedia obbligatorio http://en.wikipedia.org/wiki/Associative_array

In termini SQL, un database NoSQL è una singola tabella con due colonne: una è la chiave (primaria) e l'altra è il valore. E questo è tutto, questa è tutta la magia di NoSQL.

Utilizzeresti NoSQL per un motivo principale: la scalabilità.

Se l'applicazione deve gestire milioni di query al secondo, l'unico modo per raggiungerla è aggiungere più server. Questo è molto economico e facile con NoSQL. Al contrario, il ridimensionamento di un database SQL tradizionale è molto più complicato.

Solo i più grandi siti Web là fuori stanno sfruttando appieno il potenziale NoSQL, ad esempio Facebook, con migliaia di server che eseguono Cassandra .

Consiglio vivamente di leggere questo post sul blog, confrontando SQL, NoSQL e ORM:

http://seldo.com/weblog/2010/07/12/in_defence_of_sql

Presumo che tu abbia una conoscenza di base del movimento NoSQL e dei modelli di database non relazionali.

Key Value store è uno dei modelli di database non di relazione, come i grafici, i modelli di database orientati ai documenti.

Key Value store e il movimento NoSQL

In generale, SQL è riuscito a gestire dati appositamente strutturati e ha consentito query altamente dinamiche in base alle esigenze del dipartimento in questione.

Sebbene non ci siano ancora veri concorrenti per SQL in questo specifico campo, il caso d'uso nelle applicazioni Web quotidiane è diverso. Non troverai una gamma altamente dinamica di query piene di join interni ed esterni, sindacati e calcoli complessi su tabelle di grandi dimensioni. Di solito troverai un modo di pensare molto orientato agli oggetti. Soprattutto con l'adozione di modelli come MVC, i dati nel back-end di solito non vengono modellati per un database, ma per l'integrità logica che aiuta anche le persone a essere in grado di far fronte alla comprensione di enormi infrastrutture software. Ciò che viene fatto per inserire questi modelli orientati agli oggetti nei database relazionali è una grande quantità di normalizzazione che porta a complesse gerarchie di tabelle e si oppone completamente all'idea principale alla base della programmazione orientata agli oggetti.

Il fatto che SQL consenta query dinamiche arbitrarie per insiemi di dati complessi viene reso inutile utilizzando un database SQL solo per l'archiviazione persistente di dati orientati agli oggetti, che è ciò che sostanzialmente fanno la maggior parte delle applicazioni in questi giorni.

È qui che entrano in gioco i negozi Key Value. Key value stores allow the application developer to store schema-less data. This data is usually consisting of a string which represents the key and the actual data which is considered to be the value in the "key - value" relationship. I dati stessi sono in genere una sorta di primitiva del linguaggio di programmazione (una stringa, un numero intero, un array) o un oggetto che viene eseguito il marshalling dai bind dei linguaggi di programmazione nell'archivio valori chiave. Ciò sostituisce la necessità di un modello di dati fisso e rende meno rigoroso il requisito di dati correttamente formattati.

They all allow storage of arbitrary data which is being indexed using a single key to allow retrieval. La differenza principale per i negozi "più semplici" è il modo in cui è possibile (o non è possibile) autenticare o accedere a diversi negozi (se possibile). Mentre i vantaggi di velocità nella memorizzazione e nel recupero dei dati potrebbero essere un motivo per considerarli rispetto ai comuni database SQL, un altro grande vantaggio che emerge quando si utilizzano gli archivi di valori-chiave è che il codice risultante tende ad apparire pulito e semplice rispetto alle stringhe SQL incorporate in il tuo linguaggio di programmazione. Questo è qualcosa che le persone tendono a combattere con i framework di mappatura relazionale agli oggetti come Hibernate o Active Record. Avere un mappatore relazionale di oggetti sembra fondamentalmente emulare un archivio di valori chiave aggiungendo molto codice molto complesso tra un database SQL e un linguaggio di programmazione orientato agli oggetti.

Un'intera comunità di persone si riunisce sotto il tag " NoSQL " e discute di questi vantaggi e anche degli svantaggi dell'utilizzo di alternative ai sistemi di gestione di database relazionali. leggi di più
Questo è un articolo un po 'vecchio, ma l'ho trovato molto utile.

when would I use such a database? Could someone explain or link an explanation to me?
È più una decisione architettonica, e discutibile ... Devi considerare molti fattori come la scalabilità, le prestazioni ecc ...

Visualizza le diapositive / articoli seguenti e avrai un'idea di quando, perché e perché non utilizzare l'archivio valori chiave :)

• Database non relazionali e archivi chiave / valore
• Key-Value-Stores: la chiave per il ridimensionamento?
• http://highscalability.com/blog/category/key-value-store [deve leggere]
• http://ayende.com/Blog/archive/2010/03/29/that-no-sql-thing-keyvalue-stores.aspx

Altri hanno spiegato questo, ma ho intenzione di prendere un colpo comunque.

Un database chiave / valore archivia i dati in base a una chiave primaria. Questo ci consente di identificare in modo univoco un record in un bucket. Poiché tutti i valori sono unici, le ricerche sono incredibilmente veloci: è sempre una ricerca semplice del disco.

Il valore è qualsiasi tipo di valore. Il modo in cui i dati vengono archiviati è opaco per il database stesso. Quando si archiviano i dati in un archivio chiave / valore, il database non conosce o si preoccupa se si tratta di XML, JSON, testo o immagine. In effetti, ciò che stiamo facendo in un archivio chiave / valore è spostare la responsabilità di comprendere come i dati vengono archiviati dal database nelle applicazioni che recuperano i nostri dati. Dal momento che hai una sola gamma di chiavi di cui preoccuparti per bucket, è molto facile diffondere le chiavi su molti server e utilizzare tecniche di programmazione distribuita per consentire l'accesso rapido a questi dati (ogni server memorizza una gamma di dati) .

Uno svantaggio di questo approccio ai dati è che la ricerca è un compito molto difficile. Devi leggere ogni record nel tuo secchio di dati oppure devi creare tu stesso indici secondari .

Esistono alcuni motivi per cui potresti voler utilizzare un database chiave / valore:

• Quando la performance di scrittura è la tua massima priorità. Mozilla Test Pilot utilizza un database chiave / valore per registrare rapidamente i dati.
• Quando le letture sono garantite solo da PK.
• Quando si lavora con un modello di dati flat.
• Quando si lavora con un modello di dati ricco e complesso che non può essere modellato in un RDBMS.

Ci sono circa altrettanti motivi per usare un database chiave / valore quanti ne sono per usare un RDBMS e ci sono altrettanti argomenti per giustificare l'uno sull'altro. È importante dare un'occhiata al modo in cui si esegue la query dei dati e capire come quel modello di accesso ai dati guida il modo in cui verranno inseriti e archiviati i dati.

Basta ricordare che un database chiave / valore è solo un tipo di database NoSQL.

Se si dispone di un database relazionale, è possibile sperimentare facilmente questo:

create table keyvalue (my_key varchar2(255), my_value varchar2(255));
create unique index ix_keyvalue on keyvalue (my_key, my_value);

Ecco come erano tutti i database, con Berkeley DBM come un buon esempio, dal 1979. Da allora, le cose sono avanzate (puoi avere molti valori per chiave in qualsiasi RDBMS). Per molte applicazioni è sufficiente un archivio di valori-chiave (ad esempio, in questo modo sendmail memorizza i suoi alias). Ma se ti ritrovi a pre-elaborare il valore nel tuo codice (o concatenare stringhe per creare la tua "chiave"), forse suddividendo il valore su un delimitatore o analizzandolo, prima di poterlo utilizzare, probabilmente starai meglio con un RDBMS e in realtà lo memorizza in quel modo.