[DB] Criteri per la configurazione della cache

Ciao, sono Jayon.

Oggi spiegherò i criteri per la configurazione della cache. Poiché questo post è scritto sulla base della mia esperienza pratica, ti consiglio di leggerlo come riferimento ㅎㅎ

Cos'è la Cache?

La cache consiste nel memorizzare in anticipo i risultati che potrebbero essere richiesti in futuro, per poi fornire un servizio rapido. In altre parole, si tratta di una tecnica che memorizza i risultati in anticipo e, quando viene ricevuta una richiesta successiva, elabora la richiesta accedendo alla cache anziché fare riferimento al database o all'API. Alla base dell'introduzione di questa cache vi è la legge di Pareto.

La legge di Pareto afferma che l'80% dei risultati è dovuto al 20% delle cause. Ti consiglio di consultare l'immagine seguente!

In altre parole, la cache non richiede la memorizzazione nella cache di tutti i risultati, ma solo del 20% più utilizzato durante l'erogazione del servizio, il che consente di migliorare l'efficienza complessiva.

Quali dati devono essere memorizzati nella cache?

In base alla legge di Pareto, non tutti i dati devono essere memorizzati nella cache, ma solo quelli essenziali. Quindi, quali dati dobbiamo memorizzare nella cache?

Dati che devono essere letti frequentemente ma scritti raramente

In teoria, si dice spesso che "i dati che devono essere letti frequentemente ma scritti raramente devono essere memorizzati nella cache", ma i criteri di "lettura frequente" e "scrittura rara" erano piuttosto vaghi.

Pertanto, per indagare sui dati da memorizzare nella cache, seguo i passaggi seguenti.

• Verificare le prime 5 chiamate di query RDB tramite un APM come DataDog.
• Tra queste, trovare le query di selezione e verificare da quale tabella vengono estratti i dati.
• Verificare quante volte viene chiamata la query di aggiornamento per la tabella in questione.

Attraverso questo processo, si verifica se le query di selezione sono frequenti ma le query di aggiornamento sono rare. Nella tabella che ho verificato in pratica, le query di selezione venivano eseguite 1.740.000 volte al giorno, mentre le query di aggiornamento al massimo 500 volte. In questo caso, si può tranquillamente affermare che è adatto per la cache ㅎㅎ

Dati sensibili all'aggiornamento

I dati sensibili all'aggiornamento devono avere una breve discrepanza tra RDB e cache. Ad esempio, le informazioni relative ai pagamenti sono molto sensibili all'aggiornamento, quindi anche se soddisfano le condizioni della cache di cui sopra, è necessario considerare l'applicazione.

Dovevo memorizzare nella cache una tabella correlata ai pagamenti che soddisfacesse le due caratteristiche sopra menzionate. Pertanto, non ho applicato la cache a tutte le logiche che utilizzano la tabella correlata ai pagamenti, ma ho deciso di applicare la cache parzialmente a logiche relativamente sicure in cui i pagamenti non vengono effettivamente eseguiti.

Cache locale vs Cache globale

Ora abbiamo definito in qualche modo i dati da memorizzare nella cache e l'ambito della memorizzazione nella cache. A questo punto, dobbiamo decidere "dove" memorizzare i dati della cache. In generale, è possibile memorizzarli nella memoria locale o in un server separato come Redis.

Cache locale

La cache locale è un metodo per memorizzare i dati della cache nella memoria del server dell'applicazione e, in genere, si utilizzano Guava cache o Caffeine cache.

**Vantaggi**

• Poiché la cache viene cercata nella memoria dello stesso server durante l'esecuzione della logica dell'applicazione, la velocità è elevata.
• È facile da implementare.

**Svantaggi**

• Se ci sono più istanze, si verificano diversi problemi.

Cache globale

La cache globale è un metodo che utilizza un server separato, come Redis, per memorizzare i dati della cache.

**Vantaggi**

• Poiché la cache è condivisa tra le istanze, anche se la cache viene modificata in un'istanza, tutte le istanze possono ottenere lo stesso valore della cache.
• Anche se viene creata una nuova istanza, è sufficiente guardare l'archivio cache esistente, quindi non è necessario eseguire l'operazione di inserimento della cache.

**Svantaggi**

• Poiché è necessario passare attraverso il traffico di rete, la velocità è inferiore rispetto alla cache locale.
• È necessario disporre di un server cache separato, quindi si generano costi di gestione dell'infrastruttura.

Quale ho scelto?

Attualmente, il server dell'applicazione della mia azienda è strutturato in modo da eseguire più istanze, ma ho scelto la cache locale.

Ci sono tre motivi principali.

• I dati da memorizzare nella cache memorizzati nel database RDB sono poco meno di 40.000 e, anche se vengono caricati tutti in memoria, occupano meno di 4 MB.
• Era necessario che le prestazioni di selezione dei dati relativi ai pagamenti fossero elevate.
• Sebbene Redis fosse già presente, memorizzare una nuova cache in Redis comportava costi di infrastruttura.

Come aggiornare la cache?

Se ci sono più server di applicazioni e viene applicata la cache locale, i valori della cache memorizzati in ogni server di applicazioni possono essere diversi. Ad esempio, i dati della cache memorizzati nel server A sono "1", mentre i dati della cache memorizzati nel server B possono diventare "2" a seguito di una modifica nel server B. In questa situazione, se un utente invia una richiesta al bilanciamento del carico, riceverà valori diversi dal server A e dal server B.

Pertanto, è necessario configurare in modo che la cache venga eliminata automaticamente in ogni istanza e venga eseguita una query dal database RDB. A questo scopo, viene solitamente utilizzato il TTL.

Come impostare il valore TTL?

TTL è l'acronimo di Time To Live ed è un'impostazione che elimina la cache dopo un determinato periodo di tempo. Ad esempio, se il TTL è impostato su 5 secondi, i dati della cache verranno eliminati automaticamente dopo 5 secondi. Successivamente, se si verifica un cache miss, i dati vengono recuperati dal database RDB e memorizzati.

Quindi, come si imposta il valore TTL?

**Lettura/scrittura su un singolo server cache**

Se la lettura/scrittura avviene su un singolo server cache, come Redis, o su un singolo server di applicazioni con cache locale, il valore TTL può essere aumentato a unità di tempo o superiori. In ogni caso, durante la scrittura verrà modificata la cache esistente e il server che accede a tale cache visualizzerà sempre i dati aggiornati.

In questo caso, è anche possibile non impostare il TTL e svuotare gradualmente la cache tramite l'algoritmo LRU quando il server cache è pieno.

**Lettura/scrittura su più server cache**

Se la lettura/scrittura avviene su più server cache, come un server cache distribuito, o su più server di applicazioni con cache locale, è consigliabile impostare il TTL su secondi o minuti. Ciò perché esiste la possibilità di leggere i dati obsoleti di un server cache che non ha ancora riflesso i dati modificati.

In questo caso, il TTL viene determinato in base a vari contesti. Più l'aggiornamento è importante e maggiore è la probabilità di modifica del valore, più il TTL deve essere breve. Viceversa, se l'aggiornamento è meno importante e la probabilità di modifica del valore è bassa, il TTL può essere leggermente più lungo.

Come ho impostato il TTL?

I dati che memorizzo nella cache sono correlati ai pagamenti e, anche se non applico la cache alle logiche rigorose in cui si verificano effettivamente i pagamenti, la natura dei pagamenti richiede comunque un aggiornamento. Tuttavia, la probabilità di aggiornamento è bassa, quindi ho impostato il TTL in modo sicuro a circa 5 secondi.

Conclusione

In sintesi, il metodo di cache che ho scelto è il seguente.

• Dati relativi ai pagamenti
• Le letture sono molto frequenti, ma le modifiche sono rare.
• Applicare la cache solo alle logiche in cui si verificano le selezioni, ma non i pagamenti effettivi.
• Applicata la cache locale e il TTL è impostato su 5 secondi.

Il prossimo passo sarà eseguire un test delle prestazioni sul metodo di cache effettivamente applicato. Sto ancora riflettendo su come eseguire il test delle prestazioni in modo specifico, quindi lo descriverò in un post successivo!