[DB] Criterios para configurar el caché

¿Hola? Soy Jayon.

Hoy voy a explicar los criterios para configurar la caché. Esta publicación está escrita con base en mi experiencia práctica, así que tómenla como una referencia ㅎㅎ.

¿Qué es la caché?

La caché significa almacenar previamente los resultados que se solicitarán en el futuro y proporcionarlos rápidamente. En otras palabras, es una técnica que almacena los resultados por adelantado y, cuando se recibe una solicitud posterior, procesa la solicitud accediendo a la caché en lugar de consultar la base de datos o la API. El trasfondo de esta caché se encuentra en la Ley de Pareto.

La Ley de Pareto establece que el 80% de los resultados se deben al 20% de las causas. ¡Les recomiendo que consulten la siguiente imagen!

Es decir, la caché no necesita almacenar todos los resultados, sino que solo necesita almacenar el 20% que se utiliza con más frecuencia al proporcionar el servicio, lo que puede mejorar la eficiencia general.

¿Qué datos deben almacenarse en caché?

Según la Ley de Pareto, no se deben almacenar en caché todos los datos, sino solo los datos necesarios. Entonces, ¿qué datos debemos almacenar en caché?

Datos que se leen con frecuencia pero que rara vez se escriben

En teoría, se suele decir que "los datos que se leen con frecuencia pero que rara vez se escriben deben almacenarse en caché", pero los criterios de "lectura frecuente" y "escritura poco frecuente" eran bastante ambiguos.

Por lo tanto, investigo los datos que se almacenarán en caché en los siguientes pasos.

• Compruebo los 5 principales historiales de llamadas de consultas de RDB a través de APM como DataDog.
• Entre ellos, busco las consultas de recuperación y verifico de qué tabla se recuperan los datos.
• Verifico cuántas veces se llama a la consulta de actualización de la tabla en cuestión.

A través de este proceso, verifico si se producen muchas recuperaciones pero pocas actualizaciones. En la tabla que verifiqué en mi trabajo práctico, la consulta de recuperación se produjo 1.74 millones de veces al día, pero la consulta de actualización se produjo como máximo 500 veces. Bajo estas condiciones, cualquiera puede considerar que es adecuado para la caché ㅎㅎ.

Datos sensibles a la actualización

Los datos sensibles a la actualización significan que la inconsistencia entre RDB y la caché debe ser breve. Por ejemplo, la información relacionada con los pagos es muy sensible a la actualización, por lo que, aunque cumpla con las condiciones de caché anteriores, debe considerarse su aplicación.

Tuve que aplicar la caché a la tabla relacionada con los pagos que cumplía con las dos características anteriores. Por lo tanto, no apliqué la caché a toda la lógica que utiliza la tabla relacionada con los pagos, sino que decidí aplicar la caché parcialmente a la lógica relativamente segura donde no se realizan pagos reales.

Almacenamiento en caché local frente a almacenamiento en caché global

Ahora que hemos decidido qué datos se almacenarán en caché y el alcance del almacenamiento en caché, debemos considerar "dónde" se almacenarán los datos en caché. Generalmente, se pueden almacenar en la memoria local o en un servidor separado como Redis.

Almacenamiento en caché local

El almacenamiento en caché local es un método para almacenar los datos en caché en la memoria del servidor de la aplicación, y normalmente se utiliza Guava cache o Caffeine cache.

**Ventajas**

• Como se consulta la caché en la memoria dentro del mismo servidor mientras se ejecuta la lógica de la aplicación, la velocidad es rápida.
• Es fácil de implementar.

**Desventajas**

• Si hay varias instancias, surgen varios problemas.

Almacenamiento en caché global

El almacenamiento en caché global es un método que utiliza un servidor separado para almacenar datos en caché, como Redis.

**Ventajas**

• Como se comparte la caché entre instancias, incluso si se modifica la caché en una instancia, todas las instancias pueden obtener el mismo valor de caché.
• Incluso si aparece una nueva instancia, puede ver el almacén de caché existente, por lo que no es necesario realizar la operación de insertar la caché.

**Desventajas**

• Como debe pasar por el tráfico de red, la velocidad es más lenta que el almacenamiento en caché local.
• Se debe proporcionar un servidor de caché separado, lo que genera costos de administración de infraestructura.

¿Qué opción elegí?

Actualmente, el servidor de la aplicación de la empresa tiene una estructura que ejecuta varias instancias, pero elegí el almacenamiento en caché local.

Hay tres razones principales.

• Los datos en caché almacenados en RDB son un poco menos de 40.000, por lo que incluso si se cargan todos en la memoria, son menos de 4 MB.
• Se requería un alto rendimiento de recuperación para los datos relacionados con los pagos.
• Aunque Redis ya existe, almacenar la nueva caché en Redis genera costos de infraestructura.

¿Cómo actualizar la caché?

Si hay varios servidores de aplicación y se aplica el almacenamiento en caché local a estos, los valores de caché almacenados en cada servidor de aplicación pueden diferir. Por ejemplo, los datos de caché almacenados en el servidor A son "1", pero los datos de caché almacenados en el servidor B pueden ser "2" porque se modificaron en el servidor B. En esta situación, si el usuario envía una solicitud al equilibrador de carga, recibirá valores diferentes del servidor A y el servidor B.

Por lo tanto, es necesario configurar cada instancia para que elimine automáticamente la caché y recupere los datos de RDB. En este caso, se utiliza principalmente TTL.

¿Cuánto tiempo debe configurarse el TTL?

TTL es la abreviatura de Time To Live (tiempo de vida) y es una configuración que elimina la caché después de un cierto tiempo. Por ejemplo, si se configura el TTL en 5 segundos, los datos de caché se eliminarán automáticamente después de 5 segundos. Luego, si se produce una pérdida de caché, se recuperan los datos de RDB y se almacenan.

¿Entonces, cuánto tiempo debe configurarse el TTL?

**Lectura/escritura que se produce en un solo servidor de caché**

Si la lectura/escritura se produce en un solo servidor de caché global como Redis o en un solo servidor de aplicación donde se aplica el almacenamiento en caché local, el valor de TTL se puede aumentar a más de una unidad de tiempo. De todos modos, al escribir, se modificará la caché existente, y el servidor que obtiene los datos de esa caché siempre verá los datos actualizados.

En este caso, en lugar de configurar el TTL, también se puede configurar el servidor de caché para que vacíe gradualmente la caché mediante el algoritmo LRU cuando esté lleno.

**Lectura/escritura que se produce en varios servidores de caché**

Si la lectura/escritura se produce en varios servidores de caché global o en varios servidores de aplicación donde se aplica el almacenamiento en caché local, es mejor configurar el TTL en segundos o minutos. Esto se debe a que existe la posibilidad de leer datos antiguos de un servidor de caché que aún no ha reflejado los datos modificados.

En este caso, el TTL se determina en varios contextos, y cuanto más importante sea la actualización y mayor sea la probabilidad de cambio de valor, más corto debe ser el TTL, y cuanto menos importante sea la actualización y menor sea la probabilidad de cambio de valor, más largo puede ser el TTL.

¿Cómo configuré el TTL?

Los datos que voy a almacenar en caché están relacionados con los pagos, y aunque no se aplique la caché a la lógica estricta en la que se producen los pagos, la actualización es importante debido a la naturaleza de los pagos. Sin embargo, como la probabilidad de actualización es baja, establecí el TTL de forma segura en unos 5 segundos.

Conclusión

En resumen, el método de almacenamiento en caché que elegí es el siguiente.

• Datos relacionados con los pagos
• Se producen muchas recuperaciones, pero pocas modificaciones.
• Se aplica la caché solo a la lógica en la que se producen recuperaciones, pero no se producen pagos reales.
• Se aplica el almacenamiento en caché local y el TTL se configura en 5 segundos.

El siguiente paso es realizar una prueba de rendimiento solo para el método de almacenamiento en caché que se aplicó realmente. Todavía estoy pensando en cómo realizar la prueba de rendimiento, ¡así que lo escribiré en una publicación posterior!