Perché lo storage NoSQL (Key-Value) è diventato popolare in questi giorni?

NoSQL non è necessariamente l'assenza di SQL. Può significare "Non solo SQL". È nato a causa del web e dell'aumento di strutture informatiche ampiamente distribuite dove il sovraccarico di SQL diventa una passività piuttosto che una risorsa. È lo stesso con la programmazione funzionale.

Il Lisp esiste già dagli anni '60, ML dagli anni '70, ed Erlang per un bel po 'di tempo. Ha cominciato a salire quando le persone hanno scoperto che la mutabilità di stato in un ambiente concorrente offre una serie di problemi.

Prima di ciò, la programmazione orientata agli oggetti forniva uno strumento per l'organizzazione del progetto e per la separazione delle preoccupazioni che, sebbene forse un po 'più lento del codice procedurale ancora usato nel calcolo numerico, era adatto alle nuove architetture di programmazione web.

Quindi è davvero una questione di avere gli strumenti giusti per il lavoro. A volte hai bisogno di SQL, a volte non lo fai.

Ecco le mie teorie:

1. È nuovo ed è brillante. Guardami!

2. Facebook / google / twitter / chiunque lo usi, quindi deve essere buono.

3. La modellazione dei dati (correttamente) è difficile. Molti sviluppatori non hanno imparato questa abilità.

4. In superficie sembra fantastico. Semplice, gratuito, scalabile. Inoltre non devo imparare SQL!

5. Le persone non hanno una buona conoscenza di ACID.

La domanda è, per cosa la stai usando?

La stragrande maggioranza delle cose che utilizzano database non ci preoccupa in modo significativo di ACID e integrità relazionale. È bene conoscere questi concetti in modo che quando ne hai bisogno, sai dove (non) guardare.

Quando MySQL tornò alla scena nel '95 non aveva ACID. Non è ancora un server ACID in base alla progettazione (alcune delle strutture di tabella consentono di eseguire transazioni atomiche). Affermare che ACID è una caratteristica mancante in NoSQL manca che non sia una caratteristica critica nemmeno nei database non-NoSQL.

Guardando MySQL e dove è stato utilizzato, e quello che ha fatto si può vedere che è stato usato dove la velocità di servire i dati è il re. Questo ha ancora il suo ruolo oggi che altri sistemi non forniscono. Grandi database, eventualmente distribuiti, che servono i dati.

Questa idea dello storage a valore-chiave non è particolarmente nuova, è solo che l'hardware e il software hanno raggiunto l'idea in modo tale da poter preformare dove deve essere competitivo con altre soluzioni più pesanti. Guarda spazio tupla che è stato in giro almeno negli anni '80.

JavaSpaces (un'implementazione di spazi di tuple) ha provato questo, mi ricordo di averlo guardato molto tempo fa, ma non sembrava off.

QuestaimmaginenondovrebbeesseretropposconosciutaacolorocheusanoundatabaseNoSQL.IdatabaseTupleseNoSQLsonospessocitatiinsiemel'unl'altro.

Nonècosìtantocheèpopolareoggi(ederaimpopolareinpassato),mapiuttostochelanicchiacheundatabaseNoSQLpuòriempireconsentediessereriempitoconqualcosacheèmoltodiversodaquellochegliutentideldatabasemainstreamsonofamiliaritàconÈsolochelatecnologiahacoltol'occasioneperriempirequestanicchiapiùfacilmente(JavaSpaceseraunproblemadausare)rispettoaprima,eivantaggicheoffreperriempirequestanicchiasuperanogliapproccipiùdiffusi(senzaunsaccodihardwareaesso)

Vedianche Persistenza di Polygot di Martin Fowler.

Le tecnologie vengono e le tecnologie vanno. Le nuove tecnologie vengono spesso pubblicizzate come migliori per essere più recenti e aver imparato dall'errore implicito di alcuni aspetti chiave delle tecnologie precedenti. Nella memoria recente, Java avrebbe reso tutto più facile, migliore e più affidabile di C, C ++ e altre lingue del 20 ° secolo. Ora altri linguaggi renderanno tutto più semplice, migliore e più affidabile di Java. Allo stesso modo, algebra relazionale e SQL avrebbero reso tutto più semplice con cui lavorare rispetto ai database "di rete" che li hanno preceduti, e ora i database "no SQL" renderanno le cose migliori di SQL.

In pratica, queste nuove tecnologie non fanno mai ciò che affermano, almeno non su base ampia e non a lungo. Fanno bene nel ristretto mondo per il quale erano stati originariamente definiti, e poi iniziano ad accrescere i cambiamenti e si trasformano nel drago che avrebbero dovuto uccidere. Durante il loro periodo di crescita, che si è accorciato mentre Internet ha accelerato il cambiamento delle tecnologie di programmazione, le nuove tecnologie offrono grandi promesse. NoSQL sta già iniziando a mostrare i suoi punti deboli (" consistenza finale "? Sheesh!), Portando alla ridefinizione revisionista di "NoSQL" come "Not [O] nly SQL".