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?
- il clustering
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:
- Non sono sicuro di come implementare un database di documenti.
- In che modo i database dei documenti ottengono tolleranza alle partizioni?
- 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?
- Quali altri pro / contro ci sono?