Die Cache-Verwaltung ist ein Schlüsselelement der Datenbankverwaltung. Laurent Ribardière präsentiert auf dem 4D Summit Portland 2016 den neuen Cache-Manager, den er in der 4D v16 64-Bit Version implementiert hat.

Bevor Sie sich die technische Präsentation mit Details zur Implementierung ansehen, empfehlen wir Ihnen, mit diesen beiden Blog-Beiträgen zu beginnen, die den Nutzen der Funktion selbst beschreiben:

Verhalten des Cache Managers in früheren Versionen

Bis zu 4D v16 wurde der Cache in 4 große Blöcke gleicher Größe aufgeteilt. Zum Beispiel wurde ein Cache von 4 GB in vier Blöcke von je 1 GB aufgeteilt. Grundsätzlich werden Objekte einem der Blöcke zugeordnet, und wenn Speicherplatz benötigt wird, werden die Daten eines großen Blocks auf einmal gelöscht, um eine Fragmentierung zu vermeiden.

In manchen Fällen kann es vorkommen, dass in diesem Block Speicherplatz übrig bleibt (z. B. weil ein Datensatz verwendet wird), und in diesem Fall kann es zu einer Fragmentierung kommen. Je mehr Tabellen, aktuelle Auswahlen und verbundene Benutzer Sie auf einem Server haben, desto mehr steigt dieses Fragmentierungsrisiko. Und wenn Sie ein großes Objekt in den Speicher laden müssen, kann es passieren, dass Sie nicht weiterkommen. Selbst wenn Sie mehr Speicherplatz zur Verfügung stellen, bleibt das Problem dasselbe.

Ein weiterer Nachteil dieses Mechanismus ist, dass Sie immer einen großen Block auf einmal freigeben. Wenn Sie z. B. einen 128 GB großen Cache haben, geben Sie 32 GB auf einmal frei, so dass Sie eine Menge Informationen verlieren, die in den Cache-Speicher geladen wurden, obwohl dies nicht notwendig war.

4D v16 vollständig optimierter Cache Manager

Es kann viele Gründe geben, warum einige Objekte im Speicher nicht sofort freigegeben werden können und im Cache-Speicher verbleiben müssen. Die Idee ist also folgende: Anstatt zu versuchen, Fragmentierung zu vermeiden, sollten wir versuchen, mit Fragmentierung auszukommen. Der neue Cache-Manager funktioniert nur in 64-Bit, wo der virtuelle Speicherplatz bis zu²⁶⁴, also fast unendlich groß ist. Natürlich ist der physische Speicher immer begrenzt, aber intern werden die Objekte in diesem riesigen virtuellen Speicher zugewiesen. Wir verwenden die Memory Management Unit (MMU) des Prozessors, um den virtuellen Speicher dem physischen Speicher zuzuordnen.

Das Gute an der internen 4D-Implementierung ist, dass das System die Defragmentierung des physischen Speichers selbst vornimmt, indem es die Objekte im Speicher bei Bedarf neu anordnet, ohne jedoch die Adressen im virtuellen Speicher zu ändern. Die Defragmentierung ist also für uns im 4D internen C++ Code völlig transparent. Auf diese Weise können wir mit einem sehr großen Cache arbeiten, ohne uns um die Fragmentierung zu kümmern, da diese vollständig vom System übernommen wird, und ohne häufig Objekte aus dem Speicher freigeben zu müssen.

Der interne Algorithmus des Cache-Managers basiert auf einem Konzept der Objektpriorität. Objekte mit einer hohen Priorität verbleiben länger im Cache als Objekte mit einer niedrigen Priorität. Und wir werden sogar Befehle bereitstellen, die dem 4D Entwickler die Kontrolle über die Priorität von Tabellen oder Indizes geben. Sie werden in der Lage sein, die Priorität im Cache einer Tabelle oder eines Index beim Start oder sogar dynamisch zu ändern, wann immer Sie es brauchen.

Der neue Cache-Manager ist vor allem für sehr große Datenbanken von Vorteil. Er wird vor allem dann nützlich, wenn die Daten nicht in den Cache passen, da dann entschieden werden muss, welches Objekt im Speicher gehalten oder freigegeben werden soll.