C'è qualcosa di rivoluzionario in NoSQL? [chiuso]

Sono un ragazzo di Database relazionale molto solido e capisco fino alla terza forma normale, apprezzo le radici algebriche della teoria degli insiemi di SQL e probabilmente posso relazionalizzare un cuore spezzato (o meno).

Non ho capito una struttura di database relazionale PER le serate di appuntamenti con mia moglie, ma HO pensato a progetti di database relazionali SU serate di appuntamenti con mia moglie ..

Ora sto ascoltando NoSQL e sto studiando. Per quanto riguarda l'inseguimento, c'è qualcosa in NoSQL che è innovativo, matematicamente nuovo o un "ehi di cui non hai nemmeno bisogno di organizzare i tuoi dati in modo relazionale, questo è molto più semplice" tipo di approccio?

NoSQL è come una super shell per la struttura dei dati? A mio avviso, i dati devono in definitiva avere una struttura da recuperare e il recupero deve essere definito in una lingua di qualche tipo.

NoSQL è più evolutivo che rivoluzionario. Combina essenzialmente le idee esistenti di "archiviazione di database esterni" con "l'utilizzo di strutture di dati familiari, non di tabelle relazionali".

Esistono più tipi di database rispetto a quelli relazionali, ad esempio database gerarchici . Sebbene arcaico per gli standard odierni, si integrava molto bene con le strutture dei dati dei suoi dati (ad esempio i record COBOL ). Il punto è che i dati nel database sono stati modellati da vicino al modo in cui i record sono stati disposti nei linguaggi di programmazione che li hanno utilizzati.

Avanti rapidamente all'invenzione dei database relazionali , dove alla fine il database ha separato le preoccupazioni e, se correttamente normalizzato, è un ottimo modo per visualizzare la maggior parte dei tipi di dati e le relazioni tra i dati. È davvero facile da capire rispetto ad altri tipi di database. Ciò in cui fallisce completamente, tuttavia, è la memorizzazione dei dati in un modo che rispecchia oggetti e classi in un programma. Quindi, l'invenzione della mappatura relazionale oggetto . In altre parole, la progettazione del database è in realtà un ostacolo alla progettazione del programma che lo utilizza, motivo per cui abbiamo bisogno di librerie ORM come Hibernate. Mentre pulito e coerente, c'è sempre quel fastidioso dubbio nella parte posteriore della mia mente che qualcosa non è proprio lì.

Ciò ha dato origine ad altri due tipi di database, database di oggetti e NoSQL .

Entrambi tentano di risolvere i problemi introdotti dai database relazionali senza esponerci agli orrori sconvolgenti dei database gerarchici. I dati sono ancora disposti in repository che assomigliano vagamente alle tabelle, ma in realtà sono più simili alla programmazione delle strutture di dati che alle tabelle relazionali. Mentre i database degli oggetti seguono regole per lo più ben definite, la mia comprensione è che NoSQL è piuttosto arbitrario. Ad esempio, una tabella potrebbe essere visualizzata come una tabella hash o un array. Non esiste un modo semplice e ben definito per interrogarli utilizzando uno strumento arbitrario analogo a Oracle SQL Developer o SQL Server Management Studio .

L'idea è che si possano definire strutture di dati facilmente ricercabili nel codice, piuttosto che mettere insieme query SQL più adatte a un motore di database SQL anziché esprimere la query desiderata. Ad esempio, le corrispondenze fuzzy o parziali sono più difficili e peggiorano in un database relazionale, mentre un database NoSQL può avere una struttura ottimizzata per tale ricerca e completata in una frazione del tempo.

Esistono lingue per l'interrogazione di NoSQL. Tuttavia, non esiste un linguaggio universale come quello che è SQL per i database relazionali.

Modifica tardiva:

Mentre ho abbastanza familiarità con i database NoSQL, questa domanda è stata la spinta per me ad acquistare un libro di qualità sull'argomento e iniziare a leggerlo con l'obiettivo finale di essere un vero esperto sull'argomento. I restanti commenti si basano su NoSQL Distilled: una breve guida al mondo emergente della persistenza poliglotta di Pramod Sadalage e Martin Fowler .

Gli autori affermano che i database relazionali non si adattano bene ai cluster in grado di servire i dati necessari per siti come Amazon e Google: NoSQL è stato sviluppato per adattarsi a questa nicchia, rilassando la concorrenza e la durata in ACID al fine di server un gran numero di query che utilizzano ampiamente dati statici (quindi, le transazioni ACID non sono così importanti).

Inoltre, ritengono che i database NoSQL funzionino senza uno schema (pagina 10) che consente ai database NoSQL di modificare più facilmente la struttura dei dati. Non sono sicuro che la presenza o l'assenza di uno schema formale sia importante al riguardo, poiché anche i database SQL consentono di modificare gli schemi. Indipendentemente da ciò, i due rinomati autori sostengono l'affermazione, quindi vale la pena esaminarli.

Credo che entrambi questi punti principali servano solo a rafforzare il mio punto principale che NoSQL è evolutivo, non rivoluzionario. Conservano ancora i dati e apportano miglioramenti incrementali alla scala e alla modificabilità. Sottolineano inoltre che NoSQL non cerca di usurpare i database relazionali come re dello storage dei dati, ma solo di fornire un mezzo alternativo di archiviazione dei dati per i tipi di dati che devono ridimensionare e trasformarsi in un modo che (credono) relazionale i database non supportano abbastanza bene.

Penso che ti piacerebbe assolutamente guardare questo articolo di Erik Meijer e Gavin Bierman, intitolato "Contrariamente alla credenza popolare, SQL e NoSQL sono in realtà solo due facce della stessa medaglia" . In breve, afferma che matematicamente entrambi gli approcci si basano sulla stessa teoria, ma con alcune differenze.

Un paio di differenze interessanti sono, a mio avviso, le seguenti: la direzione delle dipendenze tra i tipi (FK in SQL) è l'opposto in SQL e NoSQL e il tipo di raccolte non si limita a impostare in NoSQL (e quindi alcune operazioni teoriche set potrebbe non essere più applicabile nel mondo NoSQL, ma alcuni altri sono ancora validi). Ancora un altro punto interessante dell'articolo è il linguaggio di query singolo proposto per l'interrogazione di database SQL e NoSQL. Si chiama LINQ e se pensi di aver già sentito questo nome prima, hai ragione: questo è il linguaggio di query di Microsoft da C #.

La risposta di Snowman descrive correttamente in che modo SQL e NoSQL differiscono nelle loro strutture di dati e come si accede a questi. Tuttavia, una differenza probabilmente ancora più importante è il rispettivo dominio problematico.

NoSQL non è un successore di SQL. Piuttosto, i vari rami di NoSQL sacrificano alcune qualità di SQL per essere migliori in altri . Il teorema CAP afferma che è impossibile per qualsiasi sistema di database distribuito soddisfare tutte le seguenti proprietà:

• Consistenza
• Disponibilità
• Tolleranza di partizione

Pertanto, alcune varianti NoSQL seguono invece il principio BASE , che allenta il vincolo di coerenza sempre completa di ACID , che è la base per i database SQL classici. Perdendo alcune garanzie di coerenza, ottengono la possibilità di combinare elevata disponibilità e tolleranza di partizione in sistemi ampiamente distribuiti, come per i siti Web con elevate quantità di dati e query degli utenti, ma poca richiesta di coerenza perfetta. Pertanto, tali database NoSQL sono al centro di Google , Facebook e Amazon . Quindi, per rispondere alla tua domanda: Sì, NoSQL è rivoluzionario in quanto praticamente abilita servizi Web così enormi.

Questo è solo un esempio, poiché NoSQL è un campo diversificato e le sue varianti coprono praticamente tutte le possibili combinazioni di parametri all'interno del triangolo CAP .

I casi d'uso comuni di NoSQL sono rivoluzionari nei loro aumenti di produttività rispetto ai comuni database basati su SQL. Ci sono diversi fattori in questo.

Uno è il servizio di pulizie. La maggior parte dei NoSQL sono open source e possono essere installati su una workstation o una VM con pochi comandi e funzionano con impostazioni predefinite ragionevoli. Nella mia esperienza, anche Postgres e MySQL non sono così; la configurazione è in genere necessaria per iniziare anche su una workstation a scopo di sviluppo.

Un altro è lo sviluppo conveniente, come altre risposte hanno descritto in dettaglio. Le funzionalità di indicizzazione JSON di Mongo, o la semantica chiave / valore di redis e Riak, potrebbero essere tutte le webapp necessarie per svolgere il lavoro e le API sono facili. Alcuni NoSQL forniscono le proprie API RESTful, mentre con SQL è necessario scriverle da soli.

Questi fattori rendono i database NoSQL attraenti per i progetti su piccola scala. Il tempo di raccolta tende ad essere basso. Certo, quando vai in produzione devi configurare per sicurezza e scalabilità, ma la capacità di iniziare a programmare e collaborare rapidamente è potente e, secondo me, rivoluzionaria.

Inoltre, in relazione a quanto sopra, per applicazioni su piccola scala (come servizi interni all'azienda o da app ad app), un team può essere in grado di creare un database NoSQL di produzione senza coinvolgere i propri team DBA e senza subire prestazioni o integrità problemi di conseguenza. Ai DBA professionali potrebbe non piacere, ma gli sviluppatori che vedono i DBA come una fonte di ostruzione (giusta o sbagliata) a volte vedono NoSQL come un modo per aggirare la necessità di affrontarli. Lo confesso: una volta ho cambiato un'applicazione su piccola scala da Postgres a SQLite per eliminare il DBA contraddittorio e ho scelto di implementare Mongo piuttosto che Oracle per evitare i processi di approvazione DBA e le restrizioni di accesso. Senza conseguenze negative in entrambi i casi.