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 a pedido (de forma dinámica) accediendo a bases de datos back-end.
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 back-end, [1] [2] se utiliza el almacenamiento en caché de bases de datos de nivel medio para lograr 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 diferentes hosts. El rendimiento de una aplicación puede verse limitado por la velocidad de la red . Esta limitación se puede minimizar si la base de datos se encuentra en el nivel de aplicación. Debido a que el software de base de datos comercial hace un uso extensivo de 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 liviana para almacenar en caché los datos del sistema de administración de base de datos comercial .
Beneficios
El almacenamiento en caché de bases de datos mejora la escalabilidad al distribuir la carga de trabajo de consultas desde el backend a múltiples sistemas frontend económicos. 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 normales no. El almacenamiento en caché puede mejorar la disponibilidad de los datos, al proporcionar un servicio continuo para aplicaciones que dependen solo de tablas almacenadas en caché incluso si el servidor backend no está disponible. Otro beneficio es la mejora de 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 el nivel medio y el nivel de datos. [3]
Elementos de diseño potenciales
- 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: para los cachés actualizables, las actualizaciones que ocurren en el caché se deben propagar a la base de datos de destino y cualquier actualización que ocurra directamente en la base de datos de destino debe llegar al caché automáticamente.
- Propagación de actualizaciones sincrónica y asincrónica: las actualizaciones en la tabla de caché se propagarán a la base de datos de destino en dos modos. El modo sincrónico garantiza que, una vez que se complete la operación de la base de datos, las actualizaciones se apliquen también a la base de datos de destino. En el caso del modo asincrónico, las actualizaciones se retrasan en la base de datos de destino. El modo sincrónico proporciona una alta consistencia de caché y es adecuado para aplicaciones en tiempo real. El modo asincrónico 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, a nivel de tabla y de conjunto de resultados: la mayor parte de las bases de datos corporativas son históricas y se accede a ellas con poca frecuencia. Sin embargo, hay cierta información a la que se debería poder acceder de forma instantánea, como los datos de clientes premium, etc.
- Recuperación de tablas almacenadas en caché: en caso de falla del sistema o de energía, durante el reinicio de la plataforma de almacenamiento en caché se deben recuperar todas las transacciones confirmadas en las tablas almacenadas en caché.
- Herramientas para validar la coherencia de la memoria caché: en caso de un modo asincrónico de propagación de actualizaciones, la memoria caché en diferentes nodos de memoria caché 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 un equilibrio de carga. El almacenamiento en caché en un entorno en clúster abarca varios nodos, lo que mantiene la coherencia de los datos almacenados en caché en todos ellos.
- El acceso transparente a las tablas no almacenadas en caché reside en la base de datos de destino: el caché de la base de datos debe realizar un seguimiento de las consultas y debe poder enrutarse de manera inteligente al caché de la base de datos o a la base de datos de origen según la localidad de los datos sin ninguna modificación del código de la aplicación .
- Conmutación por error transparente: no debería haber interrupciones del servicio en caso de que falle la plataforma de almacenamiento en caché. Las conexiones de los clientes deberían enrutarse a la base de datos de destino.
- No se realizaron cambios en la aplicación o se realizaron muy pocos: compatibilidad con interfaces estándar JDBC, ODBC, etc. que harán que la aplicación funcione sin problemas sin necesidad de realizar cambios en el código de la aplicación. Debe enrutar todas las llamadas a procedimientos almacenados a la base de datos de destino para que no sea necesario migrarlas.
- Implementar un caché interno especializado: las bases de datos orientadas al rendimiento como ScyllaDB omiten por completo el caché de Linux durante las lecturas y utilizan en su lugar un caché interno integrado basado en filas. [4]
Dificultades en las implementaciones
- Recorrido de la caché en caso de eliminación o eventos de invalidación: los diseños de caché que aprovechan motores de caché externos como Redis o Hazelcast suelen activar la invalidación mediante la emisión de eliminaciones contra los objetos invalidados. Esto podría provocar que una sola operación de escritura active miles de eliminaciones, lo que afecta el rendimiento.
- Falta de seguimiento de claves: nuevamente, si se utiliza un motor de caché externo, cualquier solicitud a menudo activará una búsqueda de clave en la capa de caché. Si esto falla, puede activar un RTT adicional, lo que aumenta la latencia general de las solicitudes. Sin embargo, los motores como Redis y Hazelcast brindan soporte para notificaciones de cambio de clave, lo que permite que las capas de caché locales se actualicen cuando se cambian las claves en una capa de caché remota. Al rastrear estas claves localmente, se pueden evitar las búsquedas remotas en caso de falla de caché, lo que evita una penalización por acierto de caché.
- Invalidación como un evento instantáneo, no un rango de tiempo: cuando se debe cambiar una tabla como parte de una transacción, el modo SQL puede afectar si una consulta en otra conexión debe ver los cambios o no. Por lo tanto, aunque una transacción aún no se haya confirmado o revertido, cualquier cambio en una tabla durante la transacción debe hacer que la tabla se considere volátil hasta que se complete la transacción. A menudo, los motores de caché solo invalidarán un resultado antes o después de que se ejecute la consulta.
- Cachés distribuidos con falta de comunicación: si un diseño de caché utiliza una capa de almacenamiento subyacente, cuando se utiliza como caché distribuido, las invalidaciones se realizan localmente, en función de las tablas en las que se escribe en un momento determinado. Desafortunadamente, otros nodos pueden haber escrito objetos de caché para la misma tabla, y estos objetos no se invalidarán. Cuando se utiliza para datos de sesión local con persistencia de cliente ascendente, esto puede ser aceptable, pero para datos compartidos que necesitan mantener la coherencia entre sesiones, esto puede causar problemas de coherencia de datos.
Referencias
- ^ Larson, Per-åke; Goldstein, Jonathan (2004). "MTCache: almacenamiento en caché transparente de bases de datos de nivel medio". CiteSeerX 10.1.1.95.875 .
- ^ ab Altinel, Mehmet; Luo, Qiong; Krishnamurthy, Sailesh; Mohan, C.; Pirahesh, Hamid; Lindsay, Bruce G.; Woo, Honguk; Brown, Larry (2002). "DBCache: almacenamiento en caché de bases de datos para servidores de aplicaciones web" (PDF) . CiteSeerX 10.1.1.104.8991 .
- ^ "Almacenamiento en caché de bases de datos de nivel medio para comercio electrónico". CiteSeerX 10.1.1.140.8455 .
- ^ "Por qué las bases de datos deberían omitir la caché de páginas de Linux". 13 de marzo de 2024. Consultado el 2 de abril de 2024 .
Enlaces externos
- Almacenamiento en caché de bases de datos de nivel medio para comercio electrónico
