Potresti scoprire che questa è una risorsa utile:
Progettazione di applicazioni ad alta intensità di dati: le grandi idee dietro sistemi affidabili, scalabili e manutenibili
link
Discute ad alto livello su come Twitter ha affrontato un problema simile.
È una buona lettura. Nel frattempo, spero che il seguito possa aiutarti nel tuo viaggio:
Vedo che questo è taggato con OOP. Questa è più una questione di tecnologia / design di database. Un database RDBMS ben sintonizzato può probabilmente portarti lontano, ma dovresti prendere in considerazione una combinazione di elaborazione batch e aggiornamenti db in tempo reale. Ciò richiederà trade off che sono unici per la tua applicazione: un post di un amico può essere posticipato di secondi, minuti o ore? mantieni i dati che gli utenti scoprono che i dati di valore elevato scorrono rapidamente e rallentano i dati di valore inferiore.
What I did, is just to build relationships users-posts, and then we
can look up those relationships and see if that content is or not
available.
Questo deve evolversi come base utente & l'uso cresce
Alcune cose da considerare:
Hai de-normalizzato la tua relazione post-utente. questo è destinato a causare problemi di scala. Anche gli utenti che si registrano, ma non visualizzano i contenuti, ti costano spazio, perf e $$. come relazioni utente tra gruppi, & gli amici cambiano, la necessità di modificare i dati nella tabella di Thins potrebbe essere complicata.
Considera l'archiviazione dei dati in un modo che rappresenti il modo in cui hai descritto il tuo modello di dominio:
- Post pubblici (post-id - post-data)
- Post utente (user-id post-id, post-data)
- Post di amici (id utente post-id, post-data)
- Post di gruppo (id-id di gruppo, post-data)
In questo modo la relazione di un utente con amici e gruppi avrà un impatto su ciò che vedono. (che è probabilmente ciò che gli utenti si aspettano).
Inoltre, considera ciò che una tabella dei post pubblici significherebbe per la riduzione dei dati e la necessità di scrivere e scrivere nel database.
Fai del caching un problema di prima classe.
Hai esaurito le opportunità di memorizzazione nella cache sul server, sul client e su tutti i livelli dell'applicazione. Se lo hai, esauriscile ulteriormente. Un modo efficace per ridurre il problema del DB-come-bottleneck consiste nel licenziare il DB il più possibile.
- Puoi memorizzare nella cache dei post "pubblici" recenti?
- Puoi memorizzare nella cache recenti & post popolari di "gruppi" in memoria?
- Puoi identificare gruppi comuni con alti tassi di lettura?
Se il tuo sistema può acquisire dati da una combinazione di dati memorizzati nella cache e risultati SQL, sarai molto più in forma. Ancora meglio se si combinano i dati con i dati memorizzati nella cache nel browser.
Considerare i modi in cui il sistema può raccogliere rapidamente i dati memorizzati nella cache e aumentare il lato client con il db più lento.
ex:
- Carica post comuni (operazione sincrona) dalla cache.
- Inizia a raccogliere post personalizzati (gruppi / amici),
- esegue il rendering dell'interfaccia utente
- L'interfaccia utente riceve i post personalizzati e aggiorna l'interfaccia utente.
- L'interfaccia utente può memorizzare nella cache post personalizzati per richieste future.
Può aiutare ad aumentare la sensazione di un tempo di caricamento veloce e a ridurre la necessità di recuperare i dati di dame dal database attraverso le richieste,
Un altro suggerimento:
assicurati di conoscere i modelli di utilizzo dei tuoi utenti. Alcuni di questi suggerimenti non hanno senso se si considera la frequenza con cui vengono pubblicati i post.
Considera di memorizzare quali operazioni di lettura e scrittura è necessario eseguire, per cercare modelli comuni.
Verifica come si stanno formando le amicizie
-
Se la maggior parte delle persone ha 10 amici, e progetti e collaudi per questo, ma i valori anomali hanno 100.000 cose brutte potrebbero accadere.
-
Può anche avere un impatto sulla cache e regole che impediscono agli utenti di incasinare la cache per tutti gli altri. Oppure, magari provvedendo a quei valori anomali
Infine, consiglierei di raccogliere dati sulle prestazioni reali.
- Benchmark
- Migliora
- Benchmark
- Migliorare
Quando un grande sistema che ha esigenze specifiche di rendimento, solo le modifiche che puoi dimostrare hanno un impatto dimostrabile. Renderà il tuo codice più complicato. Assicurati di introdurre complessità (e costi di manutenzione) per i benefici per i tuoi utenti. Lanciare la complessità di un problema che potrebbe aiutare gli utenti è un modo sicuro per creare un sistema che preferiresti non mantenere.