Database del documento rispetto al database relazionale: come scegliere?

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

I database di 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 Amazon's Dynamo che è una buona introduzione ai database NoSQL distribuiti.

Ora, il termine NoSQL è molto ampio quindi ci sono molti database NoSQL che non sono distribuiti. Ma risolvono altri problemi. Per esempio. Neo4j - un database grafico è valido per un tipo di query per cui non sono ottimizzate le RDBMS tradizionali. O come nel caso di 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 sono flessibili come i database RDBMS tradizionali, quindi è una buona scelta utilizzare un database RDBMS tradizionale fino a quando non può più risolvere i problemi.

Ho un approccio semplice per determinare il database più adatto ai dati.

Mi chiedo solo: Supponendo che non avrei un database, preferirei salvare di più e i dati importanti come documento o li memorizzerei in un foglio di calcolo.

Quando la risposta è "Spreadsheet", 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 sono argomenti, un database NoSQL è probabilmente il più adatto per l'attività e potrebbe aumentare parecchio le prestazioni!

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

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

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

when a switch from relational- to document-database gave an improvement

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

when a switch from document- to relational-database gave an improvement

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

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 e statico.

Abbiamo provato a imporre uno schema RDBMS fisso, statico, ma è stato un errore.

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

Se considerassimo ciascun record come un "documento" con un sottoinsieme comune di elementi e una raccolta unica (e non ben definita) di elementi di dati aggiuntivi, eravamo molto, molto più felici.

La raccolta di elementi di dati mal definiti è ciò che gli utenti effettivamente necessitano per i loro casi d'uso.

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