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 (dinámicamente) accediendo a bases de datos 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 backend, [1] [2] se utiliza el almacenamiento en caché de bases de datos de nivel medio 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 diferentes hosts. El rendimiento de una aplicación puede estar limitado por la velocidad de la red . Esta limitación se puede minimizar teniendo la base de datos 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 bases de datos comerciales .
Beneficios
El almacenamiento en caché de la base de datos mejora la escalabilidad al distribuir la carga de trabajo de consultas desde el backend a múltiples sistemas front-end 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 únicamente de tablas almacenadas en caché incluso si el servidor backend no está disponible. Otro beneficio es la mejora de las velocidades de acceso a los datos gracias a la localidad 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]
Posibles elementos de diseño.
- 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 de tiempo real.
- Actualizaciones bidireccionales: para cachés actualizables, las actualizaciones que ocurren en el caché deben propagarse 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 síncrono garantiza que una vez completada la operación de la base de datos, las actualizaciones también se apliquen en la base de datos de destino. En el caso del 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 ofrece un alto rendimiento y es adecuado para aplicaciones casi en tiempo real.
- Granularidad de caché múltiple: nivel de base de datos, nivel de tabla y almacenamiento en caché 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 debería ser accesible instantáneamente, como los datos del cliente 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 caché: en caso de modo asíncrono de propagación de actualizaciones, la caché en diferentes nodos de caché y la base de datos de destino pueden divergir. Esto debe resolverse manualmente, identificando desajustes y tomando medidas correctivas si es necesario.
- Escalable horizontalmente: la computación en clúster puede aumentar la disponibilidad y lograr el equilibrio de carga. El almacenamiento en caché en un entorno agrupado abarca varios nodos, manteniendo los datos almacenados en caché coherentes en todos los nodos.
- El acceso transparente a tablas no almacenadas en caché reside en la base de datos de destino: la caché de la base de datos debe realizar un seguimiento de las consultas y debe poder enrutarse de manera inteligente a la 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 falla de la plataforma de almacenamiento en caché. Las conexiones del cliente deben enrutarse a la base de datos de destino.
- Ninguno o muy pocos cambios en la aplicación: soporte para interfaces estándar JDBC, ODBC, etc. que harán que la aplicación funcione sin problemas sin ningún cambio 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.
- Implemente 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]
Errores en las implementaciones
- Caché caminando tras eliminaciones o eventos de invalidación: los diseños de caché que aprovechan motores de caché externos como Redis o Hazelcast a menudo activarán la invalidación al emitir eliminaciones contra los objetos invalidados. Esto podría dar como resultado que una sola operación de escritura provoque miles de eliminaciones, lo que afectaría 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 claves en la capa de caché. Si esto falla, puede desencadenar un RTT adicional, lo que aumenta la latencia general de las solicitudes. Sin embargo , motores como Redis y Hazelcast brindan soporte de notificación de cambio de clave, lo que permite que las capas de caché local se actualicen cuando las claves se cambian en una capa de caché remota. Al rastrear estas claves localmente, se pueden evitar búsquedas remotas de errores de caché, lo que evita una penalización por aciertos 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. Como tal, si bien una transacción aún no se ha confirmado ni revertido, cualquier cambio en una tabla durante la transacción debería hacer que la tabla se considere volátil hasta que se complete la transacción. A menudo, los motores de caché solo invalidan un resultado antes o después de ejecutar la consulta.
- Cachés distribuidos con falta de comunicación: si un diseño de caché utiliza una capa de almacenamiento subyacente, cuando se usa como caché distribuido, las invalidaciones se realizan localmente, según las tablas en las que se escriben en un momento determinado. Desafortunadamente, es posible que otros nodos hayan 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 del cliente ascendente, esto puede ser aceptable, pero para datos compartidos que necesitan mantener la coherencia entre sesiones, esto puede causar problemas de coherencia de los 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; Mohán, C.; Pirahesh, Hamid; Lindsay, Bruce G.; Woo, Honguk; Marrón, 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 negocios electrónicos". CiteSeerX 10.1.1.140.8455 .
- ^ "Por qué las bases de datos deberían omitir el 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 negocios electrónicos
