Quale database devo usare per gestire la relazione?

2

Ho bisogno di 2 capacità:

  • calcolo reciproco di amici che distinguono tra diversi tipi di bordi (ad esempio FRIEND, ENEMY e altri)
  • ottenere relazioni che distinguono tra diversi tipi di bordi come sopra

Il mio problema è la velocità: se uso un database come MySQL, posso ottenere migliaia di relazioni in pochi momenti, ma se ho bisogno di calcolare amici comuni, costa molto per il mio server, vero?

Ho circa 100.000 account sul mio sito e voglio introdurre un sistema di relazioni, ma ovviamente devo decidere il modo giusto per svilupparlo. Hai qualche idea?

    
posta rodi 22.10.2011 - 16:31
fonte

4 risposte

3

Dato che sul sito sono presenti 100k account utente, eseguirò una stima rapida per te:

  • 100k account
  • [ipotesi] ~ il 30% degli account è effettivamente attivo
  • [ipotesi] ~ il 20% degli account attivi avrà in media 100 relazioni
  • [ipotesi] ~ l'80% degli account attivi avrà mediamente 10 relazioni

O in altre parole:

  • Gli utenti di 70k sono sostanzialmente inattivi
  • Gli utenti 24k avranno in media 10 relazioni
  • 6k gli utenti avranno in media 100 relazioni

Questo significa che la tua tabella delle relazioni molti-a-molti avrà:

70k * 0 + 24k * 10 + 6k * 100 = 840k righe o ~ 1 milione di righe

Onestamente, le file 1M sono noccioline per un RDBMS correttamente configurato. Inoltre, probabilmente riuscirai a far fronte fino a quando avrai circa qualche milione di account semplicemente aumentando il livello.

Nota: l'ipotesi è che tu aggiunga una tabella simile a questa:

SourceUserId, DestinationUserId, LoveOrHate
    
risposta data 21.11.2011 - 12:22
fonte
2

Prima di tutto, ottenere l'elenco dei reciproci amici è un'operazione abbastanza facile e veloce, indipendentemente dalla soluzione scelta. È solo ottenere tutti gli utenti A amici, ottenere tutti gli amici B dell'utente e intersecare i risultati.

Molti RDBMS implementano quello nativamente usando INTERSECT , alcuni degli archivi NoSQL hanno anche comandi di intersezione impostati ( ad es. SINTER in Redis ).

Un'altra cosa è che le prestazioni dei DB grafici non sono grandiose. Ovviamente pubblicizzano il miglioramento di "1000x o più rispetto ai DB relazionali" . Tuttavia, questo è un miglioramento per grafici generici e algoritmi di grafici generici. Ti danno molta più flessibilità, ma se hai solo pochi tipi di relazioni, il codice dedicato costruito su RDBMS o NoSQL sarà più efficiente.

    
risposta data 21.11.2011 - 14:23
fonte
1

Controlla qualsiasi nuova generazione di database NoSQL. per esempio. MongoDB, CounchDB, Redis. Anche il Gabinetto di Tokyo o il Gabinetto di Kyoto merita di essere esplorato a seconda del tempo di risposta che stai cercando.

Fondamentalmente MySQL o qualsiasi database relazionale impiegherebbe join che saranno costosi !! Prendi in considerazione la duplicazione dei dati al momento dell'archiviazione, in modo da non dover partecipare al momento della query !! I tuoi dati non devono essere in perfetto stato normalizzato .

Un altro aspetto importante che non hai specificato qui è quanto transazionale questa operazione deve essere! Vuoi che l'integrità dei dati sia mantenuta ogni secondo o secondo o ogni minuto o minuto? L'integrità è definitiva?

    
risposta data 22.10.2011 - 17:18
fonte
1

Puoi utilizzare un database grafico come Neo4j .

...an open-source, high-performance, enterprise-grade NOSQL graph database.

Neo4j is a robust (fully ACID) transactional property graph database. Due to its graph data model, Neo4j is highly agile and blazing fast. For connected data operations, Neo4j runs a thousand times faster than relational databases....

Sono utili per le relazioni tra utenti, ad es. un sito di social network.

    
risposta data 22.10.2011 - 16:47
fonte

Leggi altre domande sui tag