Layer di memorizzazione nella cache dell'API

4

Primer: abbiamo un'app mobile servita da un'API (scritta in PHP). Il punto principale dell'app è quello di visualizzare i prodotti da una tabella di articoli di grandi dimensioni nel database, in una moltitudine di diverse configurazioni. Categorie, articoli suggeriti, feed compilati dall'utente, feed "simili a". Fondamentalmente la maggior parte, se non tutti i dati del display provengono da una singola tabella, tuttavia il filtraggio e l'ordinamento è davvero ciò che fa l'app.

Alcuni feed sono abbastanza semplici, come "prendi tutti gli oggetti che si trovano in una di queste categorie usando una tabella di collegamenti alla categoria". Altri sono più complessi usando la ricerca full-text per filtrare, insieme ai filtri di categoria e ai filtri di scorta e talvolta potremmo anche richiedere che i risultati abbiano un filtro aggiuntivo come "escludere elementi da qualsiasi categoria che non ha 10 articoli corrispondenti in quella categoria" (una specie di auto-regolazione, invalidazione del filtro di categoria).

Ora stiamo cercando di accelerare l'API e stiamo cercando di iniziare a inserire la tecnologia, per consentirci di scalare. Abbiamo già deciso alcune cose come i motori di ricerca separati (ad esempio elasticsearch per la sostituzione del testo completo e.c.t.). Tuttavia, una cosa su cui sono un po '"nuova" è la memorizzazione nella cache dei feed API.

La mia unica esperienza di caching è stata la memorizzazione nella cache di output completi di pagine web in cose come Magento / Wordpress. Oppure memorizzando nella cache oggetti complessi creati da diverse query e processi.

Ho deciso che la cache degli oggetti probabilmente non è adatta qui, poiché la maggior parte dei dati degli oggetti finali proviene da una singola tabella. Quindi il caching degli oggetti non fornirebbe molto miglioramento della velocità.

Attualmente sto pensando di aver bisogno di memorizzare nella cache la raccolta di output finale di oggetti, in quanto è proprio il complesso filtraggio e ordinamento che rallenta tutto. Ma è lì che mi blocco ...

Prima di tutto, dovremmo mettere in cache l'intera collezione di oggetti, o semplicemente memorizzare una collezione di oggetti ID, e andare comunque al database per fare la ricerca dei dati finali (la mia teoria è che con tutta la diversa compilazione di feed, l'utilizzo della memoria crescerebbe abbastanza rapidamente nella cache di tutti gli oggetti stessi.

In secondo luogo, memorizziamo nella cache l'output finale del feed, oppure cerchiamo di trovare un punto comune in cui possiamo creare una copia memorizzata nella cache del feed che non è abbastanza corretta. Quindi, per esempio, piuttosto che memorizzare nella cache "prodotti simili a X in cui i prodotti simili sono in 1,2,3 categorie", dovremmo invece memorizzare nella cache "prodotti simili a X", quindi su ogni richiesta, ottenere la raccolta dalla cache e fare il filtro aggiuntivo manualmente dopo aver recuperato la "raccolta di base".

Speriamo che tutto abbia un qualche senso, e ci scusiamo se è un po 'casinista. Sono un po 'fuori dalla mia profondità con questo, ma sono impaziente di imparare. Senza dubbio qualsiasi soluzione decida di implementare per prima, avrà bisogno di molte, molte iterazioni prima che la consideriamo "corretta". Ma al momento, semplicemente non ho alcuna esperienza in questo, per darmi un punto di partenza appropriato, appropriato, per iniziare lo sviluppo.

    
posta Lee 03.10.2013 - 21:43
fonte

1 risposta

3

Cose come questa tendono a dipendere molto dalle strutture dati e dalla progettazione dell'applicazione. Molto simile all'ottimizzazione delle prestazioni in generale, non esiste una risposta definitiva adatta a tutti i casi. La migliore risposta che si può dare è scoprire quali sono i colli di bottiglia esatti. Analizza i dati e decidi per una strategia di memorizzazione nella cache che è più probabile che eviti Questi problemi. Implementalo come "prova del concetto", quindi misura di nuovo. Ripeti fino a quando non sei soddisfatto dei risultati.

E la cosa più importante: provalo con una quantità abbastanza rappresentativa di dati che ti aspetti più tardi nella produzione. Le cose di solito vanno veloci quando sono coinvolti solo 10 record di database, indipendentemente dal codice. Questo non è più vero con 10.000 (o 10 milioni di record).

    
risposta data 03.10.2013 - 22:47
fonte

Leggi altre domande sui tag