La mejor respuesta
Como Scott McNulty respondió anteriormente a esta pregunta, el almacenamiento en caché de SQL es el almacenamiento de conjuntos de resultados generados como resultado de una consulta contra un base de datos y usar la copia del resultado para resultados posteriores. Dicho esto, hay MUCHO más en este problema que solo «almacenamiento en caché». El problema real no es el almacenamiento en caché, es la invalidación la parte difícil. Almacenar información no es difícil, saber cuándo no es válida sí lo es.
También hay un segundo problema más sutil relacionado con el almacenamiento en caché, y es el impacto de la latencia de red del almacenamiento en caché. La mayoría de las soluciones de caché funcionan como un servidor independiente, al igual que lo hace una base de datos. Para consultar la caché, se debe realizar un viaje de ida y vuelta a través de la red, nuevamente, como en una base de datos. Si el caché no tiene la respuesta de manera confiable, Y responde más rápido que la base de datos, entonces es muy difícil mejorar realmente el rendimiento con el caché.
Para almacenar en caché SQL de manera óptima, necesita una solución que pueda resolver varios problemas:
- ¿Qué contenido debe almacenarse en caché?
- Si hay un resultado en caché, ¿debería considerarse no válido?
- Si el caché la tasa es demasiado baja, ¿la lógica de la caché se ajustará automáticamente para detener el almacenamiento en caché y dejar de realizar búsquedas para evitar la penalización?
La realidad es que para tener en cuenta la mayoría de los casos de esquina, se necesita un proceso muy complejo conjunto de lógica para asegurar un escenario de rendimiento óptimo para el almacenamiento en caché. Esto no es tan simple como implementar un motor de caché como Redis o Hazelcast en su aplicación. . En su lugar, necesita un motor de caché inteligente que pueda inspeccionar qué datos se están modificando, invalidar datos automáticamente y optimizar las solicitudes que se pueden realizar a un motor de caché externo frente a lo que se está haciendo en la base de datos.
Uno de estos motores es de Heimdall Data (descargo de responsabilidad, soy el director de tecnología de Heimdall Data). El motor Heimdall almacena automáticamente en caché el contenido dirigido desde la aplicación a la base de datos, ya sea como un controlador JDBC o como un proxy de nivel de protocolo, invalida el contenido automáticamente y optimiza el contenido que también se almacena en caché. Esto permite a los desarrolladores centrarse en las funciones, no en el caché, lo que en algunos casos puede ahorrar entre un 20\% y un 40\% del tiempo de desarrollo y depuración de una aplicación.
Respuesta
El almacenamiento en caché en general es almacenar los resultados de un proceso que consume muchos recursos para que los recursos no tengan que gastarse nuevamente.
En SQL; siempre es específico de la tecnología del proveedor. MS-SQL, Oracle, MySQL y PostGres tienen diferentes opciones para lo que almacenan en caché. Los resultados, la consulta, incluso el plan de ejecución de la consulta se pueden almacenar para su uso en intentos posteriores de procesar la misma información.
En caso de que se modifiquen los datos subyacentes, el sistema generalmente tiene un mecanismo para indicar que la información almacenada en caché está «sucia» y ya no se puede utilizar por completo; para que el sistema pueda volver a ejecutar la consulta.
Esto se ve todo el tiempo. ¿Cuánto tiempo tarda mi consulta? ¿Por qué siempre es más rápido si lo ejecuto por segunda vez? Bueno, esta es la razón. El sistema recuerda efectivamente lo que le preguntó antes y le da la respuesta que recuerda de ese momento.