Che cos'è NoSQL, come funziona e quali vantaggi offre? [chiuso]

Ho sentito parlare di NoSQL e che alla fine potrebbe diventare il rimpiazzo dei metodi di archiviazione di DB SQL a causa del fatto che l'interazione tra DB è spesso un collo di bottiglia per la velocità sul web.

Quindi ho solo alcune domande:

1. Che cosa è esattamente?

2. Come funziona?

3. Perché sarebbe meglio che usare un database SQL? E quanto è meglio?

4. La tecnologia è troppo nuova per iniziare ancora l'implementazione o vale la pena dare un'occhiata?

1. Che cosa è esattamente?

   Da un lato, un sistema specifico , ma è anche diventato una parola generica per una varietà di nuovi back-end di archiviazione dati che non seguono il modello DB relazionale.

2. Come funziona?

   Ognuno dei sistemi etichettati con il nome generico funziona in modo diverso, ma l'idea di base è offrire una migliore scalabilità e prestazioni utilizzando modelli DB che non supportano tutte le funzionalità di un RDBMS generico, ma comunque sufficienti per essere utili. In un certo senso è come MySQL, che un tempo mancava del supporto per le transazioni ma, proprio per questo, è riuscito a superare gli altri sistemi DB. Se potessi scrivere la tua app in un modo che non richiedesse transazioni, sarebbe stato grandioso.

3. Perché sarebbe meglio che usare un database SQL? E quanto è meglio?

   Sarebbe meglio quando il tuo sito deve ridimensionarsi in modo così massiccio che il miglior RDBMS in esecuzione sul miglior hardware che puoi permetterti e ottimizzare il più possibile semplicemente non può tenere il passo con il carico. Quanto sia meglio dipende dal caso d'uso specifico (molte attività di aggiornamento combinate con molti join è molto difficile su RDBMS "tradizionali") - potrebbe essere un fattore 1000 in casi estremi.

4. La tecnologia è troppo nuova per iniziare ancora l'implementazione o vale la pena dare un'occhiata?

   Dipende principalmente da ciò che stai cercando di ottenere. È certamente abbastanza maturo da usare. Ma poche applicazioni hanno davvero bisogno di ridimensionarlo in modo massiccio. Per la maggior parte, un RDBMS tradizionale è sufficiente. Tuttavia, con l'utilizzo di Internet sempre più diffuso, è molto probabile che le applicazioni che lo fanno diventeranno più comuni (anche se probabilmente non dominanti).

NoSQL non esiste!

NoSQL è una parola d'ordine.

Per decenni, quando le persone parlavano di database, intendevano database relazionali. E quando le persone parlavano di database relazionali, intendevano quelli che controlli con il linguaggio strutturato per le query di Edgar F. Codd. Archiviazione dei dati in qualche altro modo? Follia! Nient'altro è solo file flat.

Ma negli ultimi anni, la gente ha iniziato a mettere in discussione questo dogma. Le persone si chiedevano se le tabelle con righe e colonne fossero davvero l'unico modo per rappresentare i dati. Le persone hanno iniziato a pensare e programmare, e hanno escogitato molti nuovi concetti su come organizzare i dati. E hanno iniziato a creare nuovi sistemi di database progettati per questi nuovi modi di lavorare con i dati.

Le filosofie di tutti questi database erano diverse. Ma una cosa che tutti questi database avevano in comune era che il Structured Query Language non era più adatto per usarli. Quindi ogni database ha sostituito SQL con i propri linguaggi di query. E così è nato il termine NoSQL, come etichetta per tutte le tecnologie di database che sfidano il classico modello di database relazionale.

Quindi cosa hanno in comune i database NoSQL?

In realtà, non molto.

Senti spesso frasi come:

• NoSQL è scalabile!
• NoSQL è per BigData!
• NoSQL viola ACID!
• NoSQL è un archivio chiave / valore glorificato!

È vero? Bene, alcune di queste affermazioni potrebbero essere vere per alcuni database comunemente chiamati NoSQL, ma ognuno è falso anche per almeno un altro. In realtà, l'unica cosa che i database NoSQL hanno in comune è che sono database che non usano SQL. Questo è tutto. L'unica cosa che li definisce è ciò che li distingue l'uno dall'altro.

Quindi cosa distingue i database NoSQL?

Quindi abbiamo chiarito che tutti quei database comunemente indicati come NoSQL sono troppo diversi per valutarli insieme. Ognuno di essi deve essere valutato separatamente per decidere se sono adatti per risolvere un problema specifico. Ma da dove iniziamo? Per fortuna, i database NoSQL possono essere raggruppati in determinate categorie, che sono adatte a diversi casi d'uso:

Documento orientato

Esempi: MongoDB, CouchDB

Punti di forza: dati eterogenei, lavoro orientato agli oggetti, sviluppo agile

Il loro vantaggio è che non richiedono una struttura dati coerente. Sono utili quando le tue esigenze e quindi il layout del tuo database cambiano costantemente o quando hai a che fare con set di dati che si uniscono ma che sembrano ancora molto diversi. Quando hai molte tabelle con due colonne chiamate "chiave" e "valore", allora vale la pena esaminarle.

Database grafici

Esempi: Neo4j, GiraffeDB.

Punti di forza: Data mining

Mentre la maggior parte dei database NoSQL abbandona il concetto di gestione delle relazioni dati, questi database lo abbracciano ancora di più rispetto ai cosiddetti database relazionali.

Il loro obiettivo è quello di definire i dati dalla sua relazione con altri dati. Quando hai molte tabelle con chiavi primarie che sono le chiavi primarie di altre due tabelle (e forse alcuni dati che descrivono la relazione tra loro), allora queste potrebbero essere qualcosa per te.

Negozi con valori-chiave

Esempi: Redis, Cassandra, MemcacheDB

Punti di forza: ricerca rapida dei valori tramite chiavi conosciute

Sono molto semplicistici, ma ciò li rende veloci e facili da usare. Quando non hai bisogno di stored procedure, vincoli, trigger e tutte quelle funzionalità di database avanzate e desideri solo una memorizzazione e un recupero rapidi dei tuoi dati, allora quelli sono per te.

Purtroppo presumono che tu sappia esattamente cosa stai cercando. Hai bisogno del profilo dell'utente157641? Nessun problema, richiederà solo microsecondi. Ma cosa succede quando si desidera che i nomi di tutti gli utenti di età compresa tra 16 e 24 anni abbiano "waffle" come cibo preferito e abbiano effettuato l'accesso nelle ultime 24 ore? Buona fortuna Quando non si dispone di una chiave definita e unica per un risultato specifico, non è possibile estrarla facilmente dal proprio negozio KV.

SQL è obsoleto?

Alcuni sostenitori di NoSQL affermano che il loro database NoSQL preferito è il nuovo modo di fare le cose, e SQL è un ricordo del passato.

Hanno ragione?

No, certo che non lo sono. Sebbene ci siano problemi per i quali SQL non è adatto, ha comunque i suoi punti di forza. Molti modelli di dati sono semplicemente meglio rappresentati come una raccolta di tabelle che si riferiscono a vicenda. Soprattutto perché la maggior parte dei programmatori di database è stata addestrata per decenni a pensare ai dati in modo relazionale e cercando di spingere questa mentalità su una nuova tecnologia che non è stata creata per questo raramente finisce bene.

I database NoSQL non sostituiscono SQL, ma rappresentano un'alternativa.

La maggior parte degli ecosistemi software nei diversi database NoSQL non sono ancora così maturi. Mentre ci sono progressi, non hai ancora strumenti supplementari che sono così maturi e potenti come quelli disponibili per i database SQL più diffusi.

Inoltre, c'è molto più know-how per SQL in giro. Generazioni di informatici hanno trascorso decenni della loro carriera nella ricerca focalizzandosi su database relazionali, e mostra: la letteratura scritta sui database SQL e la modellazione dei dati relazionali, sia pratici che teorici, potrebbe riempire più librerie piene di libri. Come costruire un database relazionale per i tuoi dati è un argomento così ben studiato che è difficile trovare un caso angolare in cui non esiste una best practice generalmente accettata dal libro.

La maggior parte dei database NoSQL, invece, è ancora agli inizi. Stiamo ancora cercando il modo migliore per usarli.

Dal momento che qualcuno ha detto che il mio post precedente era fuori tema, proverò a compensare :-) NoSQL non è, e non lo è mai stato, destinato a essere un sostituto per più database SQL tradizionali, ma un paio di parole sono per ottenere le cose nella giusta prospettiva.

Al centro della filosofia NoSQL sta la considerazione che, probabilmente per motivi commerciali e di portabilità, i motori SQL tendono a ignorare l'enorme potenza del sistema operativo UNIX e dei suoi derivati.

Con un database basato su filesystem, puoi sfruttare immediatamente le capacità e la potenza sempre crescenti del sistema operativo sottostante, che sono in costante aumento da molti anni ormai in conformità con la legge di Moore. Con questo approccio, molti comandi del sistema operativo diventano automaticamente anche "operatori di database" (pensate a "ls" "sort", "find" e alle altre innumerevoli utility della shell UNIX).

Con questo in mente e un po 'di creatività, puoi davvero ideare un database basato su filesystem che è in grado di superare i limiti di molti motori SQL comuni, almeno per schemi di utilizzo specifici, che è il punto alla base della filosofia di NoSQL, il come la vedo io.

Gestisco centinaia di siti Web e tutti usano NoSQL in misura maggiore o minore. In realtà, non ospitano enormi quantità di dati, ma anche se alcuni di loro lo facessero probabilmente potrei pensare a un uso creativo di NoSQL e del filesystem per superare eventuali colli di bottiglia. Qualcosa che sarebbe probabilmente più difficile con le tradizionali "jail" SQL. Vi esorto a google per "unix", "manis" e "shaffer" per capire cosa intendo.

Se ricordo bene, si riferisce a tipi di database che non seguono necessariamente la forma relazionale. Vengono in mente database di documenti, database senza una struttura specifica e che non utilizzano SQL come linguaggio di query specifico.

In genere è più adatto alle applicazioni Web che si basano sulle prestazioni del database e non richiedono funzionalità più avanzate dei motori di database di relazione. Ad esempio, un archivio Chiave-> Valore che fornisce una query semplice tramite l'interfaccia ID potrebbe essere 10-100 volte più veloce dell'implementazione del server SQL corrispondente, con un costo di manutenzione per gli sviluppatori inferiore.

Un esempio è questo documento per un Tuple Store OLTP , che ha sacrificato le transazioni per l'elaborazione a thread singolo (nessun problema di concorrenza perché nessuna concorrenza consentita) e ha mantenuto tutti i dati in memoria; ottenere prestazioni 10-100 volte migliori rispetto a un sistema simile a RDBMS . Fondamentalmente, si sta allontanando dalla vista "One Size Fits All" di SQL e sistemi di database.

In pratica, NoSQL è un sistema di database che supporta un accesso rapido a oggetti binari di grandi dimensioni (documenti, jpg ecc.) Utilizzando una strategia di accesso basata su chiavi. Questa è una deviazione dal tradizionale accesso SQL che è abbastanza buono solo per valori alfanumerici. Non solo la memoria interna e la strategia di accesso, ma anche la sintassi e le limitazioni nel formato di visualizzazione limitano il tradizionale SQL. Anche le implementazioni BLOB dei database relazionali tradizionali soffrono di queste restrizioni.

Dietro le quinte è un'ammissione indiretta del fallimento del modello SQL nel supportare qualsiasi forma di OLTP o supporto per nuovi formati di dati. "Supporto" significa non solo archiviare ma funzionalità di accesso completo - programmatico e querywise utilizzando il modello standard.

Gli appassionati di relazione sono stati rapidi nel modificare la definizione di NoSQL da Not-SQL a Not-Only-SQL per mantenere SQL ancora in figura! Ciò non va bene soprattutto quando vediamo che la maggior parte dei programmi Java oggi ricorre alla mappatura ORM del modello relazionale sottostante. Un nuovo concetto deve avere una definizione chiara. Altrimenti finirà come SOA.

La base dei sistemi NoSQL sta nella coppia chiave-valore casuale. Ma questo non è nuovo. I sistemi di database tradizionali come IMS e IDMS supportavano le chiavi ramdom con hash (senza utilizzare alcun indice) e lo fanno ancora. In effetti, IDMS ha già una parola chiave NONSQL in cui supporta l'accesso SQL al database di rete precedente, definito NONSQL.

È come una Jacuzzi: sia un marchio che un nome generico. Non è solo una tecnologia specifica, ma piuttosto un tipo specifico di tecnologia, in questo caso si riferisce a "database" su larga scala (spesso sparsi) come BigTable di Google o CouchDB.

NoSQL il programma attuale sembra essere un database relazionale implementato in awk usando file flat sul back-end. Sebbene affermino che "NoSQL essenzialmente non ha limiti arbitrari e può funzionare laddove altri prodotti non possono funzionare. Ad esempio, non vi è alcun limite alla dimensione del campo dati, al numero di colonne o alla dimensione del file", non credo che lo sia il database su larga scala del futuro.

Come dice Joel, database estremamente scalabili come BigTable o HBase , sono molto più interessanti. GQL è il linguaggio di query associato a BigTable e App Engine. È in gran parte ottimizzato SQL per evitare funzionalità che Google considera il collo di bottiglia (come i join). Tuttavia, non l'ho mai sentito prima chiamato "NoSQL".

NoSQL è un sistema di database che non utilizza query SQL basate su stringhe per recuperare i dati.

Invece crei query utilizzando un'API che forniranno, ad esempio Amazon DynamoDB è un buon esempio di database NoSQL.

I database NoSQL sono migliori per applicazioni di grandi dimensioni in cui la scalabilità è importante.

NoSQL significa database non relazionale?

Sì, NoSQL è diverso da RDBMS e OLAP. Utilizza modelli di coerenza più ampi rispetto ai tradizionali database relazionali.

I modelli di coerenza vengono utilizzati nei sistemi distribuiti come i sistemi di memoria condivisa distribuita o l'archivio dati distribuito.

Come funziona internamente?

I sistemi di database NoSQL sono spesso altamente ottimizzati per le operazioni di recupero e aggiunta e spesso offrono poche funzionalità oltre all'archiviazione dei record (ad es. Archivi di valori-chiave). La ridotta flessibilità di runtime rispetto ai sistemi SQL completi è compensata da marcati guadagni in termini di scalabilità e prestazioni per determinati modelli di dati.

Può funzionare su dati strutturati e non strutturati. Utilizza le raccolte anziché le tabelle

Come si interroga tale "database"?

Guarda SQL vs NoSQL: Battle of the Backends ; spiega tutto.