Sistema di notifica della rete sociale

10

Sfondo

Sto lavorando su un'app per un client che include alcune funzionalità di social networking. Inizialmente stavo sviluppando il front-end mobile, ma le circostanze mi hanno lasciato in carico nello sviluppo del back-end.

Come sfondo generale, il nostro sistema consente agli utenti di seguire altri utenti e ricevere notifiche su quelli che stanno seguendo, come ci si aspetterebbe da un social network. Un avvertimento è che solo un piccolo sottoinsieme (al massimo poche centinaia) di utenti sarà seguito, con l'aspettativa che la maggior parte della base di utenti seguirà almeno uno di questi individui.

Sul lato dell'interfaccia utente, avremo un pulsante di notifica con un numero su di esso e facendo clic sul pulsante ti verrà visualizzata la schermata di notifica.

Il problema

Ho svolto ricerche sulle strategie per l'implementazione delle notifiche e sulla maggior parte delle risorse che ho trovato utile per creare una o più tabelle di notifica nel database. (Un esempio che mi piace è la risposta accettata qui: link ).

La cosa che mi sta scoraggiando è che la maggior parte delle strategie basate su database per le notifiche richiedono l'inserimento di una riga per ogni notifica per ciascun follower. Quindi se migliaia di persone stanno seguendo Sally, inseriamo un migliaio di righe nella tabella corrispondente. È scalabile? Cosa succede se arriviamo al punto in cui decine o centinaia di migliaia di utenti stanno seguendo Sally e sta facendo qualche dozzina di post al giorno?

La mia idea originale era stata di gestire tutto con le query: il numero sul pulsante di notifica sarebbe stato ottenuto richiedendo il conteggio delle righe sul contenuto pubblicato più recentemente rispetto all'ultima volta che hai visitato la schermata di notifica, mentre le singole notifiche sarebbero state generate da query più dettagliate quando hai visitato la schermata di notifica. Questo approccio non richiederebbe scritture o storage extra, ma è inflessibile e probabilmente bloccherà il server abbastanza duramente.

SETUP

Il back-end (come stabilito dallo sviluppatore precedente) utilizza CodeIgniter e un MySQL database. Attualmente è in esecuzione su un account di hosting condiviso GoDaddy scadente, ma presumo (spero?) Che questo verrà aggiornato prima di entrare in produzione e il pacchetto di hosting verrà ridimensionato con la crescita degli utenti.

Attualmente il nostro unico front-end è un'app mobile, ma abbiamo in programma di creare in seguito un sito web. Al momento non sono interessato ad ottenere aggiornamenti push in tempo reale dal server riguardo alle notifiche.

APPENDICE

Non sono specializzato in backend e sono sopra la mia testa in quel dipartimento. Il cliente lo sa, e ho fatto del mio meglio per cercare di spiegare lo scopo di un progetto di questo tipo, ma hanno chiarito che a questo punto non si fideranno di nessun altro per lavorare sul progetto. Probabilmente avremo un altro mese di lavoro da fare prima di poter aggiungere nuovi tester e ottenere qualsiasi tipo di metrica sul rendimento. Non riesco davvero a stimare quanti utenti potremmo avere o quale hardware potremmo avere nei prossimi 5 anni, ma penso che il cliente speri per centinaia di migliaia di utenti o più.

Spero che questo sia un problema specifico da pubblicare qui; Posso perfezionarlo se necessario. Si prega di chiedere se avete domande o ho omesso dettagli importanti.

tl; dr

  • Un sistema di notifica basato su database ha implicazioni negative per la scalabilità a lungo termine quando tutti gli utenti seguono solo alcune delle poche centinaia di persone?
  • C'è un modo per rendere le notifiche guidate da database senza bisogno di una riga di notifica separata per ogni notifica per ogni follower?
  • Un sistema di notifica interamente basato su query potrebbe essere scalabile o avere vantaggi oltre a non scrivere dati nel DB?
  • Sto pensando troppo a questo troppo presto? Dovrei semplicemente creare qualcosa che funzioni per ora e possiamo preoccuparci di ottimizzarlo se diventa un problema, dato che il cliente ha un budget limitato e non sappiamo ancora se il prodotto finale sarà popolare?
posta user45623 01.05.2015 - 04:41
fonte

1 risposta

10

So if a thousand people are following Sally, we insert a thousand rows into the corresponding table. Is that scalable?

Sì, a condizione che le tabelle del database siano correttamente indicizzate.

What happens if we get to the point where tens or hundreds of thousands of users are following Sally and she's making a few dozen posts per day?

Genererai poche decine o centinaia di migliaia di record di notifica al giorno per Sally, supponendo che tu voglia tenere traccia di ogni notifica per sempre. La percentuale di utenti come Sally con quel tipo di traffico è sempre molto piccola.

My original idea had been to handle everything with queries: the number on the notification button would be obtained by requesting row-counts on content posted more recently than the last time you visited the notification screen, while individual notifications would be generated from more detailed queries when you visited the notification screen.

Questo sembra inutilmente complicato. Se hai bisogno di statistiche dettagliate sulle notifiche, è sufficiente memorizzare le notifiche.

Does a database-driven notification system have negative implications for long-term scalability when all of the users are only following some of the same few hundred people?

Ecco perché funziona ... un numero limitato di persone genera sempre la maggior parte del traffico.

Is there a way to make the notifications database-driven without needing a separate notification row for each notification for each follower?

Sì ... Non memorizzare le notifiche; basta inviare le e-mail di notifica, in stile fire-and-forget. Oppure, memorizzare le notifiche per un certo periodo di tempo, quindi eliminarle. Oppure, scarta ogni notifica dopo che è stata letta.

Would an entirely query-driven notification system be scalable, or have any advantages besides not writing any data to the DB?

Non sono sicuro di cosa intendi con questo. Se vuoi interrogare le notifiche, devi memorizzarle nel database. Altrimenti, non c'è nulla da interrogare.

Am I overthinking this too early?

Parla con qualcuno che può aiutarti a progettare un database indicizzato correttamente normalizzato con le tabelle corrette al suo interno. Non vedo alcuna ragione per cui un tale database non possa gestire efficacemente gli scenari che descrivi.

Un esempio di vita reale

Per quanto ne so, Stack Exchange memorizza tutto per sempre, incluse tutte le notifiche. Usano la tecnologia di database simile a MySql e alcune tecnologie di caching. Mentre il loro hardware e spazio di archiviazione è notevole, la quantità di traffico che ricevono è un buon problema.

    
risposta data 01.05.2015 - 05:27
fonte

Leggi altre domande sui tag