Almacenamiento en caché de bases de datos

El almacenamiento en caché de bases de datos es un proceso incluido en el diseño de aplicaciones informáticas que generan páginas web bajo demanda (de forma dinámica) mediante el acceso a bases de datos de backend.

Cuando estas aplicaciones se implementan en entornos de múltiples niveles que involucran clientes basados ​​en navegador, servidores de aplicaciones web y bases de datos de backend, ^{[ 1 ] [ 2 ]} se utiliza el almacenamiento en caché de la base de datos de nivel intermedio para lograr una alta escalabilidad y rendimiento. ^{[ 2 ]}

En una arquitectura de tres niveles , el nivel de software de aplicación y el nivel de almacenamiento de datos pueden estar en hosts diferentes. El rendimiento de una aplicación puede verse limitado por la velocidad de la red . Esta limitación se puede minimizar al ubicar la base de datos en el nivel de aplicación. Dado que el software de base de datos comercial utiliza intensivamente los recursos del sistema, no siempre es práctico tener la aplicación y la base de datos en el mismo host. En este caso, se puede utilizar una aplicación de base de datos más ligera para almacenar en caché los datos del sistema de gestión de bases de datos comercial .

El almacenamiento en caché de bases de datos mejora la escalabilidad al distribuir la carga de trabajo de las consultas desde el backend a múltiples sistemas frontend de bajo costo. Permite flexibilidad en el procesamiento de datos; por ejemplo, los datos de los clientes Platinum se pueden almacenar en caché, mientras que los de los clientes ordinarios no. El almacenamiento en caché puede mejorar la disponibilidad de los datos, al proporcionar un servicio continuo para las aplicaciones que dependen únicamente de las tablas almacenadas en caché, incluso si el servidor backend no está disponible. Otro beneficio es la mejora en la velocidad de acceso a los datos gracias a la localización de los datos y la suavización de los picos de carga al evitar viajes de ida y vuelta entre la capa intermedia y la capa de datos. ^{[ 3 ]}

• Tablas de caché actualizables: Muchos sistemas de caché son de solo lectura, lo que limita su uso a un pequeño segmento de las aplicaciones, aplicaciones que no son en tiempo real.
• Actualizaciones bidireccionales: En el caso de cachés actualizables, las actualizaciones que se produzcan en la caché deben propagarse a la base de datos de destino, y cualquier actualización que se produzca directamente en la base de datos de destino debe llegar a la caché automáticamente.
• Propagación de actualizaciones síncronas y asíncronas: Las actualizaciones en la tabla de caché se propagarán a la base de datos de destino en dos modos. El modo síncrono garantiza que, una vez finalizada la operación en la base de datos, las actualizaciones se apliquen también en la base de datos de destino. En el modo asíncrono, las actualizaciones se retrasan en la base de datos de destino. El modo síncrono proporciona una alta consistencia de caché y es adecuado para aplicaciones en tiempo real. El modo asíncrono proporciona un alto rendimiento y es adecuado para aplicaciones casi en tiempo real.
• Granularidad de caché múltiple: almacenamiento en caché a nivel de base de datos, tabla y conjunto de resultados: gran parte de las bases de datos corporativas son históricas y se acceden con poca frecuencia. Sin embargo, hay información que debe ser accesible instantáneamente, como los datos de clientes premium, etc.
• Recuperación de tablas en caché: En caso de fallo del sistema o de la alimentación eléctrica, durante el reinicio de la plataforma de almacenamiento en caché se deben recuperar todas las transacciones confirmadas en las tablas en caché.
• Herramientas para validar la coherencia de la caché: En caso de propagación de actualizaciones asíncrona, la caché en diferentes nodos y la base de datos de destino pueden divergir. Esto debe resolverse manualmente, identificando las discrepancias y tomando medidas correctivas si es necesario.
• Escalabilidad horizontal: La computación en clúster puede aumentar la disponibilidad y lograr el equilibrio de carga. El almacenamiento en caché en un entorno de clúster abarca varios nodos, lo que mantiene la coherencia de los datos almacenados en caché entre ellos.
• Acceso transparente a tablas no almacenadas en caché que residen en la base de datos de destino: la caché de la base de datos debe realizar un seguimiento de las consultas y debe poder enrutarlas de forma inteligente a la caché de la base de datos o a la base de datos de origen en función de la ubicación de los datos, sin necesidad de modificar el código de la aplicación .
• Conmutación por error transparente: No debería haber interrupciones del servicio en caso de fallo de la plataforma de almacenamiento en caché. Las conexiones de los clientes se redirigirán a la base de datos de destino.
• Pocos o ningún cambio en la aplicación: Compatibilidad con interfaces estándar como JDBC, ODBC, etc., que permiten que la aplicación funcione sin problemas y sin necesidad de modificar el código. Todas las llamadas a procedimientos almacenados deben dirigirse a la base de datos de destino para evitar su migración.
• Implementar una caché interna especializada: Las bases de datos orientadas al rendimiento, como ScyllaDB, omiten por completo la caché de Linux durante las lecturas y utilizan en su lugar una caché interna integrada basada en filas. ^{[ 4 ]}

• Recorrido de caché ante eventos de eliminación o invalidación: Los diseños de caché que utilizan motores de caché externos como Redis o Hazelcast suelen provocar la invalidación al eliminar los objetos invalidados. Esto puede provocar que una sola operación de escritura desencadene miles de eliminaciones, lo que afecta al rendimiento.
• Falta de seguimiento de claves: Si se utiliza un motor de caché externo, cualquier solicitud suele activar una búsqueda de clave en la capa de caché. Si no se encuentra la clave, puede generar un tiempo de ida y vuelta (RTT) adicional, lo que aumenta la latencia general de las solicitudes. Sin embargo, motores como Redis y Hazelcast ofrecen soporte para la notificación de cambios de clave, lo que permite actualizar las capas de caché locales cuando las claves cambian en una capa de caché remota. Al realizar el seguimiento local de estas claves, se evitan las búsquedas remotas en caso de que no se encuentre la clave, lo que previene la penalización por acierto de caché.
• Invalidación como evento instantáneo, no como intervalo de tiempo: Cuando una tabla se modifica como parte de una transacción, el modo SQL puede influir en si una consulta en otra conexión debe ver los cambios o no. Por lo tanto, mientras una transacción no se haya confirmado ni revertido, cualquier cambio en una tabla durante la transacción debería hacer que la tabla se considere volátil hasta que la transacción se complete. A menudo, los motores de caché solo invalidan un resultado antes o después de que se ejecute la consulta.
• Cachés distribuidas sin comunicación: Si un diseño de caché utiliza una capa de almacenamiento subyacente, al usarse como caché distribuida, las invalidaciones se realizan localmente, según las tablas que se escriben en un momento dado. Desafortunadamente, otros nodos pueden haber escrito objetos de caché para la misma tabla, y estos objetos no se invalidarán. Si bien esto puede ser aceptable para datos de sesión locales con persistencia del cliente ascendente, para datos compartidos que necesitan mantener la coherencia entre sesiones, puede causar problemas de consistencia de datos.

• Almacenamiento en caché de bases de datos de nivel intermedio para comercio electrónico