Quando si dovrebbe usare un documento vs database relazionale vs grafico? [chiuso]

29

Ai fini della discussione consideriamo uno scenario di FourSquare.

Scenario

Entità:

  • Utenti
  • Luoghi

Relationships:

  • Controlla: utenti < - > luoghi, molti a molti
  • Amici: utenti < - > utenti, molti a molti

Progettazione database

Probabilmente avranno errori, per favore segnalali.

RDBMS

Tavoli:

  • Utenti
  • Luoghi
  • Controllo (svincolo)
  • Amici (junction)

Pro:

  • CAP: consistenza, disponibilità

Contro:

  • CAP: tolleranza della partizione, aka sharding
  • schemi = struttura inflessibile
  • Scarsa replica?

Grafico

oggetti:

  • Utenti
  • Luoghi

Bordi:

  • Amici: utente < - > Utente
  • Controlla: utente - > posti
    • contiene la data / ora

Pro:

  • CAP: coerenza, disponibilità?
  • schemi, oggetti e bordi facilmente modificabili
  • query di attraversamento grafico, ad esempio:
    • il clustering
      • trovare gruppi di amici
      • trovare ristoranti apprezzati da persone simili
    • altre domande frequenti / comuni?

Contro:

  • CAP: tolleranza della partizione?

Documento / Oggetto

3 database separati?

  • Utenti
    • elenco amici
  • Checkins
    • timestamp
    • utente
    • posto
  • Luoghi

Pro:

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

Contro:

  • CAP: consistenza

Domande

Per la cronaca, hanno finito con l'uso di MongoDB. Oltre a tutti i punti interrogativi sopra riportati:

  1. Non sono sicuro di come implementare un database di documenti.
  2. In che modo i database dei documenti ottengono tolleranza alle partizioni?
  3. Per ottenere i controlli di un singolo utente, presumo che l'operazione analizzerà tutti i check-in e filtrerà i metadati per il nome utente (mappa + filtro). La performance di analizzare oltre 1.000.000 di documenti per ogni utente sarebbe terribilmente scarsa. Presumo che questo non sia il comportamento corretto?
  4. Quali altri pro / contro ci sono?
posta wting 10.05.2012 - 14:00
fonte

1 risposta

12

La tua domanda potrebbe essere l'argomento di un corso universitario della durata di un semestre. Hai bisogno di scomporlo in pezzi gestibili. Come tale, mi limiterò a buttare fuori alcune risposte parziali.

Una delle prime cose da considerare nel decidere quale tipo di database utilizzare è il tipo di query che verranno eseguite 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 grafici hanno funzionalità di query altamente specializzate che li rendono i migliori per i dati dei grafici e molto negativi per i dati non grafici (sebbene i database di grafici possano essere componenti nei database SQL). I database NoSQL sono molto più limitati nella loro capacità di recuperare e operare sui dati.

Il prossimo è come ti senti riguardo alle proprietà ACID: Atomicità, Consistenza, Isolamento e Durata. I database SQL offrono solide garanzie su tutti i 4. I database NoSQL in genere non promettono tutti e 4, e le modalità con cui partono sono tra le principali differenze che differenziano le varie implementazioni del database NoSQL. D'altra parte, non è possibile garantire la coerenza e la disponibilità di fronte a una partizione (vedere CAP del birrificio thorem ), quindi nessun database SQL farà se insiste sulla piena disponibilità di fronte a una partizione. Personalmente, mi preoccupo molto della durabilità dei dati nel database, dato che di solito lavoro con dati in cui persino una perdita di dati dello 0,0001% non è accettabile, e i set di dati sono abbastanza piccoli da non dovermi preoccupare delle partizioni, quindi favorisce strongmente i database SQL.

Un'altra considerazione molto pratica è la qualità del codice server, la disponibilità di amministratori e programmatori di database, la qualità del supporto disponibile per i problemi che si presentano, la qualità e la disponibilità di librerie di interfacce per connettere l'applicazione al database e presto. MySQL è in circolazione da quasi 2 decenni, ha la grande maggioranza degli errori risolti, è ampiamente utilizzato e quindi ha sia un grande supporto sia una grande disponibilità di personale, ed è probabile che sarà supportato per i prossimi 10 anni. Non puoi dire nessuna di quelle cose su Riak.

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

    
risposta data 11.05.2012 - 04:05
fonte