Database di documenti contro database relazionale: come scegliere?

Sono un tipo SQL, ma so che non ci sono solo database SQL , principalmente documenti-database. Come per la maggior parte delle tecnologie, ci sono pro e contro per ogni tecnologia.

Ho letto alcuni articoli, ma erano troppo teorici. Quello che vorrei sono due casi reali:

quando il passaggio da un database relazionale a un documento ha dato un miglioramento
quando il passaggio dal documento al database relazionale ha dato un miglioramento

Il miglioramento è tutto ciò che rende i programmi migliori: meno tempo di sviluppo, scalabilità, prestazioni, tutto ciò che è legato alla programmazione. C'è un avvertimento per 2.: storie come "ricadere nel database relazionale perché tutti conoscono l'SQL" non va bene

nosql relational-database

— Johan Buret
fonte

Approccio sbagliato. Non si tratta di "prestazioni" o "scalabilità". Si tratta di quale modello si adatta al problema che stai cercando di risolvere. Potresti voler aggiornare la tua domanda per consentire l'idea che forse il database relazionale non sia adatto a numerosi tipi di problemi.

— S.Lott

@ S.Lott, la scelta è spesso molto di prestazione. considera che qualsiasi DB relazionale può essere usato come un semplice documento DB - solo la prestazione sarebbe una caratteristica distintiva.

— edA-qa mort-ora-y

Ho riformulato la mia domanda in modo che non venga caricata in alcun modo.

— Johan Buret,

@ edA-qa mort-ora-y: "qualsiasi DB relazionale può essere usato come un semplice documento DB". Deve essere falso o la gente non avrebbe inventato un'alternativa. "solo la performance sarebbe una caratteristica distintiva". Vero solo se supponi che il modello relazionale faccia tutto ugualmente bene. Se facesse tutto, non ci sarebbero alternative. Ancora. Abbiamo alternative. Esistono molti problemi (come le gerarchie) che non si adattano perfettamente al modello relazionale e richiedono trucchi intelligenti. O un modello di dati alternativo.

— S.Lott

"leggi alcuni articoli"? Fornisci alcuni link o titoli o riferimenti o citazioni. Non sappiamo cosa significhi "troppo teorico" per te.

— S.Lott

Risposte:

La ragione principale per la scelta di un database NoSQL negli ultimi anni è stata la disponibilità . Per aziende come Amazon, Google e Facebook un'ora di inattività non è accettabile. Per ottenere un'elevata disponibilità è necessario ridurre il singolo punto di errore, ciò significa che è necessario utilizzare un sistema distribuito con più computer in caso di arresto anomalo del computer, il servizio è ancora disponibile.

I database Relatione tradizionali non sono molto buoni in una configurazione multi-master distribuita. Ecco perché NoSQL è stato così popolare ultimamente. Quindi se hai bisogno di alta disponibilità puoi scegliere un database NoSQL come Riak, Cassandra, HBase, S3 o BigTable.

C'è un buon post sul blog sulla dinamo di Amazon che è una buona introduzione ai database distribuiti NoSQL.

Ora, il termine NoSQL è molto ampio, quindi ci sono molti database NoSQL che non sono distribuiti. Ma risolvono altri problemi. Ad esempio Neo4j : un database grafico è adatto a un tipo di query per le quali RDBMS tradizionale non è ottimizzato. O come nel tuo caso un database di documenti, in cui non è necessario modificare lo schema se si desidera aggiungere alcuni campi per alcuni documenti. In altre parole, un database di documenti è valido quando la maggior parte dei post (documenti) ha campi diversi, quindi una tabella relazionale con colonne predefinite non è utilizzabile.

Tuttavia, la maggior parte dei database NoSQL non è flessibile come i tradizionali database RDBMS, quindi è una buona scelta utilizzare un database RDBMS tradizionale fino a quando non sarà più in grado di risolvere i problemi.

— Jonas
fonte

+1, concordato, la flessibilità è un prezzo enorme da pagare se non è necessario.

— maple_shaft

Ho un approccio semplice per determinare il database che meglio si adatta ai dati.

Mi chiedo solo: supponendo che non avrei un database, preferirei salvare la maggior parte e i dati importanti come documento o li memorizzerei in un foglio di calcolo.

Quando la risposta è "Foglio di calcolo", questo è un chiaro segno che un modello relazionale e un RDBMS tradizionale si adattano meglio alle attività la maggior parte delle volte. Se i dati sono davvero semplici, come solo le coppie di valori-chiave o le tabelle semplici e l'integrità referenziale non è un argomento, allora un database NoSQL è probabilmente il più adatto per l'attività e potrebbe migliorare molto le prestazioni!

Inoltre, quando non è possibile trovare una struttura comune, un database NoSQL è più adatto per l'attività.

Quando i dati sono più simili a documenti, ad esempio dati testuali strutturati gerarchicamente senza relazioni chiare, penso immediatamente a un database XML, che consente di archiviare facilmente documenti strutturati gerarchici. A volte, tuttavia, è meglio utilizzare un software di gestione dei documenti.

Quindi, per dare una risposta concreta e semplice a entrambe le tue domande: dipende dai dati.

quando il passaggio da un database relazionale a un documento ha dato un miglioramento

Quando è necessario conservare i dati testuali strutturati gerarchicamente, un database Xml può rappresentare un grande miglioramento in termini di manutenibilità e probabilmente anche di scalabilità.

quando il passaggio dal documento al database relazionale ha dato un miglioramento

Bene, ad esempio quando i dati sono principalmente in forma di tabella con relazioni chiare e devi garantire l'integrità.

— Falco
fonte

+1 per il foglio di calcolo e l'analogia dei documenti - enorme aiuto - grazie.

— HDave,

Abbiamo dovuto rinunciare al modello relazionale perché i dati che stavamo ottenendo non avevano uno schema statico semplice, ovvio, fisso.

Gli utenti - e le storie degli utenti - non avevano uno schema fisso statico.

Abbiamo cercato di imporre uno schema RDBMS fisso, statico, ma è stato un errore.

Ogni consegna di dati di terze parti (da parte di clienti e fornitori) era simile, ma non identica. Abbiamo provato a mapparlo su uno schema relazionale fisso, ma la variabilità era troppo grande. O dovevamo aggiungere campi con ogni file (diversi ogni settimana) o dovevamo allontanarci dallo schema relazionale fisso e statico.

Se consideravamo ogni record come un "documento" con un sottoinsieme comune di elementi e una raccolta univoca (oltre che mal definita) di ulteriori elementi di dati, eravamo molto, molto più felici.

La raccolta mal definita di elementi di dati è ciò di cui gli utenti hanno effettivamente bisogno per i loro casi d'uso.

Lo schema fisso e statico del modello relazionale non si adattava ai nostri casi d'uso.

— S. Lott
fonte

Ho visto altri progetti non soddisfare i requisiti a causa esattamente dei requisiti che hai descritto. Questo è ciò per cui sono stati pensati i database dei documenti.

— maple_shaft