¿Qué es el almacenamiento en caché de SQL?.El caché de consultas de MySQL es una de las características destacadas de MySQL y una parte vital de la optimización de consultas.
El caché de consultas de MySQL es global compartido entre las sesiones. Almacena en caché la consulta de selección junto con el conjunto de resultados, lo que permite que las selecciones idénticas se ejecuten más rápido a medida que los datos se extraen de la memoria. Es importante tener todo idéntico, no hay nuevos comentarios, espacios …
En otras palabras, cuando envía dos veces la misma consulta, la segunda vez, el tiempo de respuesta será mucho más rápido porque la consulta anterior ya está en la memoria compartida.
Específicamente para SQL Server, los siguientes se almacenan en caché:
Datos sin procesar (datos de tabla y estructuras de índice), en la agrupación de almacenamiento intermedio Las consultas posteriores que necesitan leer los mismos datos no necesitan esperar hasta que los datos se recuperan del disco. Las modificaciones de los datos se escriben solo en el grupo de búferes y luego se endurecen al disco en un proceso asíncrono. (El registro de transacciones se utiliza para evitar la pérdida de datos en caso de pérdida de alimentación)
Planes de ejecución, en el caché de procedimientos (también llamado caché de planes). Esto evita costosas recompilaciones para consultas que se ejecutan repetidamente.
Los resultados de la consulta no se almacenan en caché en SQL Server. Eso ahorraría aún más rendimiento si la misma consulta se repite exactamente con los mismos parámetros, pero en una carga de trabajo realista, las ejecuciones posteriores de la misma consulta generalmente son para un parámetro diferente. Y la lógica para detectar la invalidación de la memoria caché para los resultados de la consulta es muy compleja, por lo que implicaría probablemente más gastos generales de lo que ahorraría.
En general, el almacenamiento en caché es el almacenamiento de los resultados de un proceso que requiere un uso intensivo de recursos para que no se tengan que gastar de nuevo.
En SQL; Siempre es específico a 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 el caso de que se cambien 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; por lo que la consulta puede ser ejecutada de nuevo por el sistema.
Usted ve esto todo el tiempo. ¿Cuánto tiempo dura mi consulta? ¿Por qué siempre es más rápido si lo ejecuto por segunda vez? Pues esta es la razón. El sistema recuerda efectivamente lo que le pediste antes y te da la respuesta que recuerda de ese momento.
El almacenamiento en caché de SQL es el almacenamiento de conjuntos de resultados generados como resultado de una consulta en una base de datos y el uso de la copia del resultado para resultados posteriores. Dicho esto, hay mucho MUCHO más para este problema que solo el «almacenamiento en caché». El problema real no es el almacenamiento en caché, es la invalidación que es la parte difícil. Almacenar información no es difícil, saber cuándo no es válido es lo relevante.
También hay un segundo problema, más sutil, relacionado con el almacenamiento en caché, y ese es el impacto de latencia de la red en el almacenamiento en caché. La mayoría de las soluciones de caché operan como un servidor independiente, como lo hace una base de datos. Para consultar el caché, se debe realizar un viaje de ida y vuelta a través de la red, como en una base de datos. Si la memoria 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 el rendimiento con la memoria caché.
Para almacenar en caché SQL de manera óptima, necesita una solución que pueda resolver varios problemas:
¿Qué contenido debe ser cacheado?
Si hay un resultado almacenado en caché, ¿debe considerarse inválido?
Si la tasa de aciertos de la memoria caché es demasiado baja, ¿se ajustará automáticamente la lógica de la memoria caché para detener el almacenamiento en caché y dejar de hacer búsquedas para evitar la penalización?
La realidad es que para dar cuenta de la mayoría de los casos extremos, se necesita un conjunto muy complejo de lógica para asegurar un mejor escenario de rendimiento 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 automáticamente los datos y, de lo contrario, optimizar las solicitudes que se pueden realizar a un motor de caché externo en comparación con lo que se está realizando en la base de datos.
Uno de estos motores es de Heimdall Data . El motor de Heimdall almacena en caché automáticamente el contenido dirigido desde la aplicación a la base de datos como un controlador JDBC o como un proxy a nivel de protocolo, invalida el contenido automáticamente y optimiza también qué contenido se almacena en caché. Esto permite que los desarrolladores se centren en las funciones, no en el caché, que en algunos casos pueden ahorrar entre un 20% y un 40% del tiempo de desarrollo y depuración de una aplicación.
Leer también: Almacenamiento en caché de base de datos, que es, definición ; ¿Que es almacenamiento en caché y cómo funciona? Ventajas y desventajas
This post is also available in:
Español
