A gestão de cache é na realidade um elemento chave da gestão da base de dados, Laurent Ribardière apresenta na Cimeira 4D Portland 2016 o novo gestor de cache que implementou na versão 4D v16 de 64 bits.

Antes de assistir à apresentação técnica com detalhes sobre a implementação, recomendamos que comece com estes dois posts no blogue, descrevendo o benefício da característica em si:

Comportamento do Cache Manager nas versões anteriores

Até 4D v16, a cache costumava ser dividida em 4 grandes blocos do mesmo tamanho. Por exemplo, uma cache de 4 GB costumava ser dividida em quatro blocos de 1 GB cada. Basicamente, são atribuídos objectos num dos blocos e sempre que é necessário espaço de memória, a fim de evitar a fragmentação, os dados de um bloco grande são eliminados todos de uma só vez.

Em alguns casos, a memória poderia permanecer neste bloco (porque está a ser utilizado um registo, por exemplo) e é aqui que a fragmentação poderia acontecer. Quanto mais tabelas, selecções actuais e utilizadores conectados tiver num servidor, mais este risco de fragmentação aumenta. E no final, sempre que precisar de carregar um grande objecto na memória, poderá ficar preso. Mesmo que se coloque mais memória, o problema permanece o mesmo.

A outra desvantagem deste mecanismo é que se liberta sempre um grande bloco de uma só vez. Por exemplo, se tiver uma cache de 128 GB, irá libertar 32 GB de uma só vez, perdendo assim muita informação carregada na memória cache, ao passo que não foi necessário.

4D v16 Cache Manager totalmente optimizado

Pode haver muitas razões para que alguns objectos em memória não possam ser libertados de imediato e tenham de permanecer na memória cache. Portanto, a ideia é a seguinte: em vez de tentar evitar a fragmentação, vamos tentar sair com a fragmentação. O novo gestor de cache só funciona em 64 bits, onde o espaço de memória virtual é de até²⁶⁴, por isso quase infinito. Claro que a memória física é sempre limitada, mas internamente os objectos serão alocados dentro deste enorme espaço virtual. Na realidade, utilizamos a Unidade de Gestão de Memória (MMU) do processador para mapear a memória virtual para a memória física.

O que é bom para a implementação interna 4D é que o sistema trata da desfragmentação da memória física em si, rearranjando objectos na memória sempre que necessário, mas sem alterar os endereços na memória virtual. Assim, a desfragmentação é totalmente transparente para nós no código interno C++ 4D. É assim que podemos trabalhar com uma cache muito grande sem nos preocuparmos com a fragmentação, uma vez que é totalmente manuseada pelo sistema e sem ter de libertar frequentemente objectos da memória.

O algoritmo interno do gestor da cache é na realidade baseado num conceito de prioridade de objectos. Os objectos com alta prioridade permanecerão na cache por mais tempo do que os objectos com baixa prioridade. E iremos mesmo fornecer comandos para dar ao programador 4D o controlo sobre a prioridade das tabelas ou índices. Será realmente capaz de alterar a prioridade em cache de uma tabela ou índice no arranque ou mesmo dinamicamente sempre que precisar dele.

O novo gestor de cache irá, na realidade, beneficiar na sua maioria de bases de dados muito grandes. Começa a ser útil quando os dados não cabem na cache, uma vez que há escolha sobre qual o objecto a manter ou a libertar na memória.