Quando dovresti usare un database document vs relational vs graph? [chiuso]

Ai fini della discussione consideriamo uno scenario di FourSquare.

Scenario

Entità:

• utenti
• posti

rapporti:

• Check-in: utenti <-> luoghi, molti a molti
• Amici: utenti <-> utenti, molti a molti

Progettazione di database

Molto probabilmente questi avranno errori, per favore segnalali.

RDBMS

tabelle:

• utenti
• posti
• Check-in (svincolo)
• Amici (incrocio)

Professionisti:

• PAC: coerenza, disponibilità

Contro:

• CAP: tolleranza di partizione, aka sharding
• schemi = struttura non flessibile
• scarsa replica?

Grafico

Oggetti:

• utenti
• posti

bordi:

• Amici: Utente <-> Utente
• Check-in: Utente -> Luoghi
  • contiene il timestamp

Professionisti:

• PAC: coerenza, disponibilità?
• oggetti e bordi schematici e facilmente mutabili
• query di attraversamento di grafici, ad esempio:
  • il clustering
    • trovare gruppi di amici
    • trovare ristoranti che piacciono a persone simili
  • altre domande comuni / utili?

Contro:

• CAP: tolleranza partizione?

Documento / Oggetto

3 database separati?

• utenti
  • lista di amici
• checkin
  • timestamp
  • utente
  • posto
• posti

Professionisti:

• CAP: disponibilità, tolleranza della partizione
• oggetti schematici e facilmente mutabili

Contro:

• PAC: coerenza

Domande

Per la cronaca, hanno finito per usare MongoDB. Oltre a tutti quei punti interrogativi sopra:

1. Non sono sicuro di come implementare un database di documenti.
2. In che modo i database dei documenti ottengono la tolleranza della partizione?
3. Per ottenere i check-in di un singolo utente, suppongo che l'operazione analizzerebbe tutti i check-in e filtrerebbe i metadati per nome utente (mappa + filtro). Le prestazioni di analisi di oltre 1.000.000 di documenti per ciascun utente sarebbero terribilmente scadenti. Presumo che questo non sia il comportamento corretto?
4. Quali altri vantaggi / svantaggi ci sono?

La tua domanda potrebbe essere l'argomento di un corso universitario lungo un semestre. Devi scomporlo in pezzi gestibili. Come tale, lancerò solo alcune risposte parziali.

Una delle prime cose da considerare nel decidere quale tipo di database utilizzare è il tipo di query che eseguirai e se le conoscerai tutte prima della creazione del database. I database SQL hanno il vantaggio di query potenti e flessibili su tutti i dati nel database. I database di grafi dispongono di funzionalità di query altamente specializzate che li rendono i migliori per i dati di grafi e pessimi per i dati non di grafi (sebbene i database di grafi possano essere componenti nei database di SQL). I database NoSQL sono molto più limitati nella loro capacità di recuperare e operare sui dati.

Il prossimo è quello che pensi delle proprietà ACID: atomicità, coerenza, isolamento e durata. I database SQL offrono solide garanzie su tutti i 4. I database NoSQL in genere non promettono tutti e 4, e il modo in cui partono sono tra le principali differenze che differenziano le varie implementazioni del database NoSQL. D'altra parte, non è possibile garantire coerenza e disponibilità di fronte a una partizione (vedere il thorem CAP di Brewer ), quindi nessun database SQL farà se si insiste sulla piena disponibilità di fronte a una partizione. Personalmente, mi preoccupo molto della durabilità dei dati nel database, poiché in genere lavoro con dati in cui anche una perdita di dati dello 0,0001% è inaccettabile e i set di dati sono abbastanza piccoli da non dovermi preoccupare delle partizioni, quindi favorire fortemente i database SQL.

Un'altra considerazione molto pratica è la qualità del codice del server, la disponibilità degli amministratori e dei programmatori di database, la qualità del supporto disponibile per i problemi che si presentano, la qualità e la disponibilità delle librerie di interfaccia per connettere l'applicazione al database e così via. MySQL è in circolazione da quasi 2 decenni, ha risolto la stragrande maggioranza dei bug, è ampiamente utilizzato e quindi ha sia un grande supporto che una grande disponibilità di personale e probabilmente sarà supportato per i prossimi 10 anni. Non puoi dire nessuna di queste cose su Riak.

Si noti che mentre Google ha praticamente inventato i database NoSQL in modo che potessero archiviare una versione cache e indicizzata dell'intero world wide web, usano ancora MySQL per alcune cose.