La gestion du cache est en fait un élément clé de la gestion de la base de données, Laurent Ribardière présente au 4D Summit Portland 2016 le nouveau gestionnaire de cache qu’il a implémenté dans la version 64 bits de 4D v16.

Avant de regarder la présentation technique avec les détails de l’implémentation, nous recommandons de commencer par ces deux articles de blog, décrivant l’avantage de la fonctionnalité elle-même :

Comportement du gestionnaire de cache dans les versions précédentes

Jusqu’à 4D v16, le cache était divisé en 4 grands blocs de même taille. Par exemple, un cache de 4 Go était divisé en quatre blocs de 1 Go chacun. En principe, les objets sont alloués dans l’un des blocs et lorsque l’espace mémoire est requis, afin d’éviter la fragmentation, les données d’un grand bloc sont effacées en une seule fois.

Dans certains cas, il peut rester de la mémoire dans ce bloc (parce qu’un enregistrement est utilisé par exemple) et c’est là que la fragmentation peut se produire. Plus vous avez de tables, de sélections en cours et d’utilisateurs connectés sur un serveur, plus ce risque de fragmentation augmente. Et au final, chaque fois que vous devez charger un gros objet en mémoire, vous risquez d’être bloqué. Même si vous mettez plus de mémoire, le problème reste le même.

L’autre inconvénient de ce mécanisme est que vous libérez toujours un gros bloc en une seule fois. Par exemple, si vous avez un cache de 128 Go, vous libérez 32 Go en une seule fois, ce qui vous fait perdre beaucoup d’informations chargées dans la mémoire cache alors que ce n’était pas nécessaire.

Le gestionnaire de cache de 4D v16 entièrement optimisé

Il peut y avoir de nombreuses raisons pour lesquelles certains objets en mémoire ne peuvent pas être libérés immédiatement et doivent rester dans la mémoire cache. L’idée est donc la suivante : au lieu d’essayer d’éviter la fragmentation, essayons de partir avec la fragmentation. Le nouveau gestionnaire de cache ne fonctionne qu’en 64 bits, où l’espace mémoire virtuel peut atteindre²⁶⁴, donc presque infini. Bien sûr, la mémoire physique est toujours limitée, mais les objets internes seront alloués à l’intérieur de cet énorme espace virtuel. Nous utilisons en fait l’unité de gestion de la mémoire (MMU) du processeur pour faire correspondre la mémoire virtuelle à la mémoire physique.

L’avantage de l’implémentation interne de 4D est que le système gère lui-même la défragmentation de la mémoire physique, en réorganisant les objets en mémoire chaque fois que cela est nécessaire, mais sans modifier les adresses de la mémoire virtuelle. La défragmentation est donc totalement transparente pour nous dans le code C++ interne de 4D. C’est ainsi que nous pouvons travailler avec un très grand cache sans nous soucier de la fragmentation, qui est entièrement gérée par le système, et sans avoir à libérer souvent des objets de la mémoire.

L’algorithme interne du gestionnaire de cache est en fait basé sur un concept de priorité des objets. Les objets ayant une priorité élevée resteront dans le cache plus longtemps que les objets ayant une priorité faible. Nous fournirons même des commandes pour permettre au développeur 4D de contrôler la priorité des tables ou des index. Vous serez en fait en mesure de changer la priorité dans le cache d’une table ou d’un index au démarrage ou même dynamiquement quand vous en avez besoin.

Le nouveau gestionnaire de cache sera surtout utile aux très grandes bases de données. Il commence à être utile lorsque les données ne tiennent pas dans le cache, car il faut choisir quel objet conserver ou libérer en mémoire.