La gestión de la caché es en realidad un elemento clave de la gestión de la base de datos, Laurent Ribardière presenta en el 4D Summit Portland 2016 el nuevo gestor de caché que implementó en la versión 4D v16 de 64 bits.
Antes de ver la presentación técnica con los detalles de la implementación, recomendamos comenzar con estas dos publicaciones del blog, que describen el beneficio de la característica en sí:
Comportamiento del Cache Manager en versiones anteriores
Hasta 4D v16, la caché solía estar dividida en 4 grandes bloques del mismo tamaño. Por ejemplo, una caché de 4 GB se dividía en cuatro bloques de 1 GB cada uno. Básicamente, los objetos se asignan en uno de los bloques y cuando se necesita espacio en la memoria, para evitar la fragmentación, los datos de un bloque grande se borran todos a la vez.
En algún caso, podría quedar memoria en este bloque (porque se está utilizando un registro, por ejemplo) y ahí es donde podría producirse la fragmentación. Cuantas más tablas, selecciones actuales y usuarios conectados tengas en un servidor, más aumenta este riesgo de fragmentación. Y al final, cada vez que necesites cargar un objeto grande en memoria, puedes quedarte atascado. Aunque pongas más memoria, el problema sigue siendo el mismo.
El otro inconveniente de este mecanismo es que siempre se libera un bloque grande de una vez. Por ejemplo, si tienes una caché de 128 GB, liberarás 32 GB a la vez, por lo que perderás mucha información cargada en la memoria caché cuando no era necesaria.
4D v16 Cache Manager totalmente optimizado
Puede haber muchas razones por las que algunos objetos de la memoria no pueden ser liberados inmediatamente y tienen que permanecer en la memoria caché. Así que la idea es la siguiente: en lugar de tratar de evitar la fragmentación, vamos a tratar de salir con la fragmentación. El nuevo gestor de caché sólo funciona en 64 bits, donde el espacio de memoria virtual es de hasta264, es decir, casi infinito. Por supuesto, la memoria física es siempre limitada, pero internamente los objetos serán asignados dentro de este enorme espacio virtual. De hecho, utilizamos la Unidad de Gestión de Memoria (MMU) del procesador para asignar la memoria virtual a la memoria física.
Lo bueno para la implementación interna de 4D es que el sistema se encarga de la desfragmentación de la memoria física por sí mismo, reordenando los objetos en la memoria siempre que sea necesario, pero sin cambiar las direcciones en la memoria virtual. Así que la desfragmentación es totalmente transparente para nosotros en el código C++ interno de 4D. Así es como podemos trabajar con una caché muy grande sin preocuparnos por la fragmentación, ya que está totalmente gestionada por el sistema, y sin tener que liberar a menudo objetos de la memoria.
El algoritmo interno del gestor de caché se basa en realidad en un concepto de prioridad de los objetos. Los objetos con una prioridad alta permanecerán en la caché más tiempo que los objetos con una prioridad baja. E incluso proporcionaremos comandos para dar al desarrollador 4D el control sobre la prioridad de las tablas o índices. De hecho, se podrá cambiar la prioridad en la caché de una tabla o índice al inicio o incluso dinámicamente cuando se necesite.
El nuevo gestor de caché beneficiará sobre todo a las bases de datos muy grandes. Empieza a ser útil cuando los datos no caben en la caché ya que hay que elegir qué objeto mantener o liberar en memoria.