Perché NoSQL su SQL? [duplicare]

Question

Perché NoSQL su SQL? [duplicare]

#1 da (8 voti)
#2 da (5 voti)

14

Quanto bene SQL e NoSQL vanno testa a testa. Ho letto da qualche parte che i database SQL non vanno bene per i dati che sono ben strutturati o con qualche grafia associata. È davvero il caso?

Oltre a Facebook, Google e altri grandi giocatori sul web, non so quanto bene i piccoli giocatori e le start-up abbiano usato questi strumenti. Ho trovato un'altra domanda simile sullo stesso qui . Ma non sono riuscito a raccogliere molte statistiche da qui. Questi sono alcuni casi specifici, e c'è un modello generale (come quello sopra menzionato) per cui possono essere usati questi database NoSQL?

Quanto sarebbe saggio per uno start-up andare su un database NoSQL se gli sviluppatori sanno che la quantità di dati coinvolti sarà un po 'grande e ben strutturata, ma richiede frequenti operazioni CRUD?

Qui su StackOverflow, si possono trovare domande su quando non usare SQL, ma ci sono degli scenari in cui si dovrebbe evitare di usare i database NoSQL? Inoltre, quanto sarà efficace usare entrambi in parallelo in modo da ottenere il meglio da entrambi?

Un'ultima domanda, questi database NoSQL distribuiti funzionano altrettanto bene quando vengono utilizzati in una configurazione a nodo singolo?

sql database nosql database-design

posta c0da 19.09.2011 - 07:14

fonte

2 risposte

Leggi altre domande sui tag sql database nosql database-design

I veri programmatori usano i debugger? [chiuso] Come gestire gli errori di post-convalida in comando (DDD + CQRS)

score 8 · Answer 1

Ecco alcuni vantaggi per database SQL classici come Oracle, MS SQL, Sybase, DB / 2 contro NO / SQL:

molto maturo
ecosistema esistente (documentazione, strumenti, molti fornitori di terze parti, collegamenti a diversi linguaggi di programmazione ecc.)
estesi modelli di sicurezza
semplici query ad-hoc, con linguaggi di query molto potenti
molti di questi sono scalabili per centinaia di utenti / connessioni
Visualizzazioni e stored procedure
modelli di transazione affidabili
diverse capacità di indicizzazione
cose diverse come meccanismi di replica, tipi di dati geografici, ecc.

Queste funzionalità sono davvero utili se hai intenzione di sviluppare un sistema software aziendale, in cui non sai esattamente quali applicazioni lavoreranno con questi dati in pochi anni. Non penso che oggi ci siano database No / SQL disponibili che possono competere con le funzionalità elencate con uno qualsiasi dei "grandi" database SQL.

D'altro canto, i database NO / SQL mostrano vantaggi quando non sono necessari molti di questi elementi, ad esempio, come backb db di un'applicazione web non è necessario un modello di sicurezza complesso, perché potrebbe essere per lo più solo un utente (il processo del server delle applicazioni) collegato a voi db in fase di produzione. Naturalmente, è possibile utilizzare anche un leggero database SQL come SQLlite per questo tipo di applicazioni (e molte persone lo fanno), ma poi c'è anche da considerare la struttura dei dati che si stanno per memorizzare. Ad esempio, un sistema di blog, un forum di QA, un sistema di gestione dei contenuti, un Wiki: c'è un sacco di testo o codice html o codice xml da memorizzare e meno dati amministrativi. Potrebbero essere sistemi in cui NO / SQL può mostrare i suoi benefici.

score 5 · Answer 2

C'è uno scenario solo uno in cui NoSQL è la strada da percorrere. E questo è il momento in cui devi essere molto flessibile riguardo al traffico del database.

Ciò significa che devi aspettarti che all'improvviso le richieste del database esplodano di un fattore di - diciamo - 10 o 100. La capacità di reagire a tali situazioni si chiama elasticità.

Qui si verifica un problema con i database relazionali classici, poiché a causa della loro specializzazione sull'ottimizzazione per i JOIN non possono essere copiati su un altro server garantendo comunque l'integrità relazionale. E anche allora copiare questi enormi database richiede molto tempo.

Quindi, per affrontare l'esplosione delle situazioni di richiesta, le aziende hanno creato diversi concetti di database che sono specializzati per questo.

Se non devi aspettarti tali fluttuazioni estreme nel carico della tua richiesta, allora la relazione è la strada da seguire. E forse per sempre, perché ciò che molte persone non capiscono è che la relazionalità non è solo una parola informata del secolo scorso: l'informazione è quasi sempre intrinsecamente di natura vettoriale e quindi relazionale.