Come dovrò aggiornare "views_count" ogni volta (!) un utente carica la mia pagina? Sarà costoso. E non ho bisogno di tale precisione quando aggiorno "views_count" dopo che un utente carica una pagina.
Quindi c'è un modo per di bufferare "views_count" in qualche posto in modo che io possa aggiornare un campo nel database in un colpo solo, diciamo, di +5 una volta ogni N minuti?
Come viene solitamente implementato?
Suggerirei di aggiornare il contatore su ogni vista. Come suggerito da @amon, questa parte difficile sta determinando QUANDO aggiornare il contatore.
Un vecchio adagio: nessun anticipo prematuro prima del suo tempo. Significato: non scrivere codice complicato per un problema che non hai ancora.
Tu e amp; altri hanno chiesto se si tratta di un problema di prestazioni - e lo ribattere chiedendo - Perché dovrebbe essere? Hai delle prove che ti preoccupano?
Puoi e dovresti modellare questo rapidamente usando la matematica del tovagliolo - quante persone ti aspettano realisticamente sul tuo sito al giorno - suddividila in un'ora o al minuto. Ti aspetti 1 milione? o 1.000? o 100?
Raccogli le tue statistiche del registro web esistenti per aiutare a modellare questo (se disponibile). E se questo è un sito Web interno per un'azienda, il totale dei dipendenti è il più grande di cui ti devi preoccupare.
Rompere l'annuale in una statistica oraria (e potrebbero esserci 5 giorni in una settimana se prevedi l'accesso solo nei giorni lavorativi). Utilizza la frazione Utenti Nuova vs Ripeti: moltiplicare per la statistica della visualizzazione della pagina ogni ora per determinare la frequenza di aggiornamento del contatore. Gioca con il numero - inizia con 70/30 (Ripeti / Nuovo). Indovina se non riesci a trovare buone statistiche dal tuo product manager. Cosa succede se è 1/99 o 99/1? È un risultato preoccupante?
Ho scoperto che i numeri tendono ad essere molto più piccoli di quanto inizialmente immaginato - e vedrai che un computer può facilmente gestirlo.
Basta scrivere il codice in modo da poterlo inserire / rifattore in caso di problemi. Ci sono molti modelli là fuori.
Ad esempio: link
Vuoi un contatore di viste per ogni pagina, quindi sì, dovrai incrementare un contatore su ogni vista. È improbabile che questo rappresenti un problema di prestazioni per la stragrande maggioranza dei siti Web.
La parte difficile non è il mantenimento efficiente di quel contatore della vista, ma la decisione su cosa conta come una vista e il motivo per cui hai bisogno di questo contatore in primo luogo. Per esempio. potresti voler escludere i carichi di pagina dai bot. Potresti voler contare più carichi di pagina dallo stesso utente di una singola vista, ad es. se ricaricano la pagina. Potresti voler ignorare le visualizzazioni se l'utente immediatamente si allontana. In realtà potresti essere alla ricerca di una soluzione analitica pronta per l'uso.
Quindi, a seconda di come si definisce una "vista", si dovranno memorizzare diversi tipi di dati, possibilmente un registro eventi completo. Questo probabilmente coinvolgerà un database, anche se le scelte tecnologiche specifiche saranno influenzate dalla tua architettura esistente.
Dopo aver trovato una soluzione funzionante e aver scoperto che non è in grado di gestire il torrent delle visualizzazioni (probabilmente una volta che si passano regolarmente 50 visualizzazioni al secondo), si può pensare all'ottimizzazione della soluzione. Se non si partecipa alla visualizzazione dei conteggi con altri dati, è possibile che un semplice archivio di valori-chiave separato dal DB principale sia adeguato e possa essere ridimensionato in futuro. Anche se questo sarebbe eccessivo come soluzione iniziale.
In un'applicazione altamente scalabile, sarà inevitabilmente necessario che più macchine elaborino il carico di lavoro, e queste macchine di solito saranno distribuite su più data center con una buona quantità di latenza tra questi data center.
In tali scenari, un contatore distribuito può essere implementato non aggiornando un numero, ma aggiungendo un database grafico di log distribuito. Il motivo per utilizzare un grafico di log è che non è necessario tenere un blocco globale per aggiungere un registro DAG , e otterrai un conteggio globale alla fine coerente. Il grafico del log viene in seguito estratto e aggregato da un processo di visualizzazione delle viste per un gruppo di macchine (un riduttore locale), che quindi invia i subtotali a un aggregatore centrale (un riduttore globale).
Si noti che questo tipo di soluzione di conteggio distribuito ha un fattore costante molto grande. Su scale più piccole, un incremento intero ben ottimizzato è molto più semplice e funzionerà molto meglio di quanto un contatore distribuito potrebbe mai fare. La maggior parte delle applicazioni non avrebbe mai abbastanza traffico per essere utile.
A prescindere da ciò che hanno detto altri, credo che sia possibile staccare i conteggi delle visualizzazioni dal processo di rendering e caricamento delle pagine effettuando una chiamata Ajax a una web API esterna in un server diverso. Sviluppa e distribuisci la tua API Web per le statistiche o utilizza un fornitore di statistiche di siti Web come Google Analytics, StatCounter, ecc. Quindi sarai in grado di sincronizzare il tuo DB chiamando la loro web api per il recupero delle statistiche.
Leggi altre domande sui tag database web caching message-queue