キャッシュ管理は、実はデータベース管理の重要な要素であり、Laurent Ribardièreは 4D Summit Portland 2016で、4D v16 64ビット版に実装した新しいキャッシュマネージャーを発表しました。

実装の詳細を説明した技術プレゼンテーションを見る前に、まずはこの機能のメリットそのものを説明した、以下の2つのブログ記事からご覧いただくことをお勧めします。

旧バージョンのCache Managerの挙動

4D v16までは、キャッシュは同じ大きさの4つの大きなブロックに分割されていました。例えば、4GBのキャッシュは、1GBずつ4つのブロックに分割されていました。基本的にオブジェクトはブロックの1つに割り当てられ、メモリスペースが必要になるたびに、断片化を避けるために、1つの大きなブロックのデータが一度に消去されます。

場合によっては、このブロックにメモリが残っていることもあり（例えばレコードを使用しているため）、ここでフラグメンテーションが発生する可能性がある。サーバー上のテーブル、現在の選択項目、接続しているユーザーの数が多ければ多いほど、このフラグメンテーションのリスクは高まります。そして結局、大きなオブジェクトをメモリにロードする必要があるときはいつでも、行き詰まる可能性があるのです。たとえメモリを増設しても、問題は変わりません。

この仕組みのもうひとつの欠点は、常に1つの大きなブロックを一度に解放してしまうことです。例えば、128GBのキャッシュを持っている場合、32GBを一度に解放することになり、キャッシュメモリに読み込まれた多くの情報が、必要でないにもかかわらず、失われてしまうのです。

4D v16はキャッシュマネージャを完全に最適化しました。

メモリ内のオブジェクトがすぐに解放されず、キャッシュメモリに留まらなければならない理由はたくさんあるでしょう。つまり、フラグメンテーションを避けようとするのではなく、フラグメンテーションを残したままにしておこうという発想です。新しいキャッシュマネージャは64ビットでのみ動作し、仮想メモリ空間は最大^264個で、ほぼ無限です。もちろん、物理メモリは常に制限されていますが、内部的にはこの巨大な仮想空間の中にオブジェクトが割り当てられていくことになります。実際には、プロセッサのメモリ管理ユニット（MMU）を使って、仮想メモリと物理メモリをマッピングしています。

4D内部実装の良いところは、物理メモリのデフラグをシステムが自ら行い、必要なときにメモリ内のオブジェクトを再配置することで、仮想メモリのアドレスは変更せずに済むことです。つまり、4D内部C++のコードでは、デフラグは完全に透過的なのです。このように、フラグメンテーションはシステムによって完全に処理されるため、オブジェクトをメモリから頻繁に解放する必要がなく、非常に大きなキャッシュを気にすることなく作業することができるのです。

キャッシュマネージャの内部アルゴリズムは、実際にはオブジェクトの優先順位の概念に基づいています。高いプライオリティを持つオブジェクトは、低いプライオリティを持つオブジェクトよりも長くキャッシュに留まることになる。さらに、4D 開発者がテーブルやインデックスの優先順位をコント ロールできるようなコマンドも提供する予定です。実際に、起動時や必要な時に動的にテーブルやインデックスのキャッシュの優先順位を変更することができるようになります。

この新しいキャッシュマネージャは、実は非常に大規模なデータベースでその恩恵を受けることになります。データがキャッシュに収まりきらない場合、どのオブジェクトをメモリに残すか解放するかの選択が必要になるため、有用になり始めます。