La gestione della cache è in realtà un elemento chiave della gestione del database, Laurent Ribardière presenta al 4D Summit Portland 2016 il nuovo gestore della cache che ha implementato nella versione 4D v16 a 64 bit.

Prima di guardare la presentazione tecnica con i dettagli dell’implementazione, vi consigliamo di iniziare con questi due post del blog, che descrivono i vantaggi della funzionalità stessa:

Comportamento del Cache Manager nelle versioni precedenti

Fino alla versione 4D v16, la cache veniva divisa in 4 grandi blocchi della stessa dimensione. Ad esempio, una cache di 4 GB veniva suddivisa in quattro blocchi di 1 GB ciascuno. In pratica, gli oggetti vengono allocati in uno dei blocchi e ogni volta che serve spazio in memoria, per evitare la frammentazione, i dati di un blocco grande vengono cancellati tutti in una volta.

In alcuni casi, potrebbe rimanere della memoria in questo blocco (ad esempio perché si sta utilizzando un record) ed è qui che potrebbe verificarsi la frammentazione. Più tabelle, selezioni correnti e utenti connessi sono presenti su un server, più aumenta il rischio di frammentazione. E alla fine, ogni volta che si deve caricare un oggetto grande in memoria, si rischia di rimanere bloccati. Anche se si mette più memoria, il problema rimane lo stesso.

L’altro inconveniente di questo meccanismo è che si rilascia sempre un blocco grande in una volta sola. Ad esempio, se si dispone di una cache da 128 GB, ne verranno rilasciati 32 in una volta sola, perdendo così molte informazioni caricate nella memoria cache mentre non erano necessarie.

Gestione della cache completamente ottimizzata in 4D v16

Ci possono essere molti motivi per cui alcuni oggetti in memoria non possono essere liberati subito e devono rimanere nella memoria cache. L’idea è quindi la seguente: invece di cercare di evitare la frammentazione, cerchiamo di lasciare la frammentazione. Il nuovo gestore della cache funziona solo a 64 bit, dove lo spazio di memoria virtuale è fino a²⁶⁴, quindi quasi infinito. Naturalmente, la memoria fisica è sempre limitata, ma internamente gli oggetti saranno allocati all’interno di questo enorme spazio virtuale. In realtà utilizziamo la Memory Management Unit (MMU) del processore per mappare la memoria virtuale in quella fisica.

L’aspetto positivo dell’implementazione interna di 4D è che il sistema gestisce autonomamente la deframmentazione della memoria fisica, riorganizzando gli oggetti in memoria ogni volta che è necessario, ma senza modificare gli indirizzi della memoria virtuale. Quindi la deframmentazione è totalmente trasparente per noi nel codice C++ interno di 4D. In questo modo possiamo lavorare con una cache molto grande senza preoccuparci della frammentazione, che è completamente gestita dal sistema, e senza dover rilasciare spesso gli oggetti dalla memoria.

L’algoritmo interno del gestore della cache si basa sul concetto di priorità degli oggetti. Gli oggetti ad alta priorità rimarranno nella cache più a lungo di quelli a bassa priorità. Inoltre, forniremo anche dei comandi per dare allo sviluppatore 4D il controllo sulla priorità delle tabelle o degli indici. Sarà possibile modificare la priorità nella cache di una tabella o di un indice all’avvio o anche dinamicamente ogni volta che se ne ha bisogno.

Il nuovo gestore della cache sarà utile soprattutto per i database molto grandi. Inizia a essere utile quando i dati non entrano nella cache, in quanto si deve scegliere quale oggetto tenere o rilasciare in memoria.