2010-07-29 11 views
9

Sto progettando un'applicazione che coinvolga gli utenti che "seguono" l'attività l'uno dell'altro, nel senso di Twitter, ma non ho molta esperienza con database/design/efficienza delle query. Ci sono le migliori pratiche per gestirlo, insidie ​​da evitare, ecc.? Ho capito che questo può creare un carico molto grande sul db se non eseguito correttamente (o forse anche allora?)."Followers" ed efficienza

Se fa la differenza, è probabile che le persone "seguano" solo un numero relativamente piccolo di persone (ma una persona potrebbe avere molti seguaci). Tuttavia questo non è certo, e non vorrei contarci.

Qualsiasi consiglio ricevuto con gratitudine. Grazie.

risposta

6

Abbastanza semplice e facile da fare con pieno normalisation. Se si dispone di una tabella di utenti, ognuno con un ID univoco, si avrà una tabella TABLE_FOLLOWERS con le colonne, USERID e FOLLOWERID che descriverà tutti i follower per ciascun utente come rapporto uno a uno a molti.

Anche con milioni di assosciazioni su un server di database decente questo si comporterà bene e velocemente finché si utilizza un buon database (IE, non MS-Access).

+0

So che è stato a lungo, mi chiedo 'store FOLLOWERID'would più valori? – lazyprogrammer

1

Dipende dal numero di utenti che ci si aspetta di dover supportare; quanti follower ti aspetti che gli utenti abbiano; e che tipo di finanziamento/sviluppo-sforzo ti aspetti di avere a disposizione se le tue risposte alle domande precedenti si dimostrassero ottimistiche.

Per un progetto su piccola scala probabilmente ignorerei il database, progettare l'applicazione come un semplice modello di oggetto con gli oggetti User che mantengono uno List[followers]. Mantieni tutto nella RAM per il normale funzionamento e usa un ORM per persistere su un database periodicamente (probabilmente postgresql o mysql).

Per un progetto più ampio, non utilizzerei affatto un database relazionale; ma esattamente quello che userei dipenderebbe dai dettagli specifici del progetto.

Se si sta tentando di aumentare il concetto, seguire l'approccio ORM; ma, tieni presente che non verrà ridimensionato.

+0

Ti dispiacerebbe indicarmi la direzione di un materiale introduttivo sull'archiviazione degli oggetti RAM? Di quali tecnologie stiamo parlando, in particolare? Qualcosa come Redis? – Chris

+0

Per uno spike intendo in realtà mantenere semplici strutture dati direttamente nella RAM. Supponendo che 100.000 utenti, con una media di 100 follower e un semplice oggetto ~ 100 byte per utente, e riferimenti a 4 byte richiedano solo ~ 40 MB per il grafico follower e 10 MB per il DB utente. Anche con l'overhead di indicizzazione di 3x è facilmente qualcosa che puoi inserire nella RAM e persistere senza troppe difficoltà in un DB. – Recurse

4

Il modello è abbastanza semplice. Il problema è nelle dimensioni della tabella Sottoscrizione; se ci sono 1 milione di utenti e ognuno sottoscrive 1000, la tabella Sottoscrizione ha 1 miliardo di righe.

alt text http://www.damirsystems.com/dp_images/follower_model.png

+0

bel diagramma. Grazie. – user749665

+0

@Damir .. potresti spiegare il senso di "EnableSubscription" nel tuo diagramma? E 'un bool? Come dovrebbe funzionare in entrambi i modi, seguire e seguire? E perché l'uso di un bool? Non si può semplicemente usare una tabella pivot e fare riferimento a userID sia come utente che follower?È usato EnableSubcription per vietare a un utente di seguirti? – Chriz74