Tres capas de caché entre selección y disco

Cuando su aplicación activa una instrucción SELECT, esa consulta casi nunca toca un disco giratorio o incluso un almacenamiento flash sin formato: pasa a través de tres capas de caché distintas que determinan silenciosamente si su respuesta llega en microsegundos o milisegundos. Comprender estas capas marca la diferencia entre una plataforma empresarial que escala sin esfuerzo y una que colapsa bajo la carga del mundo real.

¿Qué sucede en el momento en que una consulta SELECT abandona su aplicación?

En el momento en que su aplicación envía una consulta SELECT, ingresa a un canal que la mayoría de los desarrolladores nunca inspeccionan. El motor de la base de datos intercepta la solicitud antes de que se produzca cualquier E/S, analiza el SQL en un plan de ejecución interno y consulta inmediatamente su primera línea de defensa: la caché de resultados de la consulta. Si recientemente se ejecutó una consulta idéntica con parámetros idénticos, el motor puede devolver un conjunto de resultados almacenado en caché sin tocar una sola página de datos. A esto a veces se le llama caché de consultas o caché de resultados, y en cargas de trabajo de alta lectura y baja escritura, como paneles de análisis y módulos de informes, puede eliminar por completo la gran mayoría de las lecturas de disco.

La idea fundamental aquí es que la caché de consultas es muy sensible a las mutaciones de datos. Cualquier INSERCIÓN, ACTUALIZACIÓN o ELIMINACIÓN en la tabla subyacente invalida los resultados almacenados en caché relevantes. Esta es la razón por la que los sistemas transaccionales con mucha escritura a menudo desactivan por completo el caché de consultas y, en su lugar, dependen de las capas más profundas.

¿Qué es el Buffer Pool y por qué es más importante de lo que cree?

La segunda capa de caché, y posiblemente la más importante en los sistemas de producción, es el grupo de búfer (llamado búfer compartido en PostgreSQL, grupo de búfer InnoDB en MySQL). Esta es una región de RAM que el motor de base de datos utiliza para contener páginas de datos a las que se accedió recientemente. Cuando no se puede atender una consulta desde la caché de resultados, el motor comprueba si las páginas de datos requeridas ya residen en el grupo de búfer antes de emitir cualquier lectura de disco.

El grupo de buffer opera según el principio de localidad temporal y espacial: es probable que se acceda nuevamente a los datos a los que se accedió recientemente, y es probable que se acceda pronto a los datos almacenados cerca de los datos accedidos. Los administradores de bases de datos ajustan el tamaño del grupo de búfer como una de las decisiones de configuración de mayor influencia que toman. Un grupo de búfer demasiado pequeño provoca el desalojo constante de páginas, lo que produce un fenómeno llamado thrashing, en el que el sistema dedica más tiempo a gestionar errores de caché que a ejecutar consultas.

Información clave: en la mayoría de las cargas de trabajo OLTP, un grupo de búfer de buen tamaño significa que entre el 95% y el 99% de todas las lecturas de datos se realizan desde la RAM. El conjunto de trabajo (el subconjunto de datos que las consultas realmente tocan con frecuencia) suele ser mucho más pequeño que el tamaño total de la base de datos. Dimensionar su grupo de buffer para que se ajuste a su conjunto de trabajo, no a todo su conjunto de datos, es la acción de ajuste de mayor rendimiento que puede realizar.

¿Cómo llena la caché del sistema operativo el espacio entre la RAM y el disco?

Incluso cuando falla el grupo de buffers de la base de datos, una consulta aún no está destinada a una verdadera lectura de disco. El sistema operativo mantiene un caché de página (también llamado caché del sistema de archivos), una región de RAM administrada por el kernel que almacena en búfer las lecturas y escrituras para bloquear dispositivos. Cuando el motor de la base de datos solicita una página que no está en su grupo de búfer, el kernel del sistema operativo verifica su propia caché de páginas antes de emitir un comando de E/S físico al controlador de almacenamiento.

Esta tercera capa es en gran medida invisible para los desarrolladores de aplicaciones, pero profundamente importante en sistemas donde el grupo de búfer de la base de datos no está suficientemente abastecido. La caché de la página del sistema operativo se comparte entre todos los procesos, por lo que compite con su servidor de aplicaciones, servidor web y cualquier otro software que se ejecute en el mismo host. En los servidores de bases de datos dedicados, esta competencia es mínima y la caché del sistema operativo proporciona un importante búfer de segunda oportunidad. En hosts compartidos o contenedores con límites de memoria ajustados, la caché del sistema operativo suele ser demasiado pequeña para ayudar.

¿Qué capa de caché es responsable de lograr el mayor rendimiento en la práctica?

En los sistemas de producción del mundo real, el grupo de buffer domina

Related Posts

• La Odisea Criptográfica de DJB: De Héroe del Código a Crítico de Estándares
• CXMT ha estado ofreciendo chips DDR4 a aproximadamente la mitad del precio predominante en el mercado.
• Juego de niños: la nueva generación tecnológica y el fin del pensamiento
• LCM: Gestión del contexto sin pérdidas [pdf]