Správa mezipaměti je vlastně klíčovým prvkem správy databáze, Laurent Ribardière představí na 4D Summitu Portland 2016 nového správce mezipaměti, kterého implementoval do 64bitové verze 4D v16.

Před zhlédnutím technické prezentace s podrobnostmi o implementaci doporučujeme začít těmito dvěma příspěvky na blogu, které popisují samotný přínos funkce:

Chování Správce mezipaměti v předchozích verzích

Až do verze 4D v16 bývala mezipaměť rozdělena do 4 velkých bloků stejné velikosti. Například mezipaměť o velikosti 4 GB bývala rozdělena do čtyř bloků po 1 GB. V podstatě se objekty alokovaly do jednoho z bloků a kdykoli bylo potřeba paměťového prostoru, aby se zabránilo fragmentaci, data jednoho velkého bloku se vymazala najednou.

V některých případech může v tomto bloku zbývat paměť (například proto, že se používá záznam), a právě zde může dojít k fragmentaci. Čím více tabulek, aktuálních výběrů a připojených uživatelů na serveru máte, tím více se toto riziko fragmentace zvyšuje. A nakonec, kdykoli potřebujete načíst velký objekt do paměti, můžete se zaseknout. I když vložíte více paměti, problém zůstane stejný.

Další nevýhodou tohoto mechanismu je, že vždy uvolňujete jeden velký blok najednou. Například pokud máte 128 GB cache, uvolníte najednou 32 GB, takže přijdete o spoustu informací načtených do paměti cache, zatímco to nebylo nutné.

4D v16 plně optimalizovaný správce mezipaměti

Může existovat mnoho důvodů, proč některé objekty v paměti nelze uvolnit hned a musí zůstat v paměti cache. Myšlenka je tedy následující: namísto snahy vyhnout se fragmentaci se pokusme s fragmentací odejít. Nový správce mezipaměti funguje pouze v 64bitové paměti, kde je virtuální paměťový prostor až²⁶⁴, tedy téměř nekonečný. Fyzická paměť je samozřejmě vždy omezená, ale interně budou objekty alokovány uvnitř tohoto obrovského virtuálního prostoru. K mapování virtuální paměti na fyzickou paměť vlastně používáme jednotku správy paměti (MMU) procesoru.

Pro interní implementaci 4D je výhodné, že systém sám zvládá defragmentaci fyzické paměti tím, že přeskupuje objekty v paměti, kdykoli je to potřeba, ale beze změny adres ve virtuální paměti. Defragmentace je tedy pro nás v interním kódu 4D v C++ zcela transparentní. Takto můžeme pracovat s velmi rozsáhlou mezipamětí, aniž bychom se museli obtěžovat fragmentací, protože ji plně zvládá systém, a aniž bychom museli často uvolňovat objekty z paměti.

Interní algoritmus správce cache je vlastně založen na konceptu priority objektů. Objekt s vysokou prioritou zůstane v mezipaměti déle než objekty s nízkou prioritou. A dokonce poskytneme příkazy, které umožní vývojáři 4D kontrolovat prioritu tabulek nebo indexů. Ve skutečnosti budete moci změnit prioritu v mezipaměti tabulky nebo indexu při spuštění nebo dokonce dynamicky, kdykoli budete potřebovat.

Nový správce mezipaměti bude ve skutečnosti přínosem hlavně pro velmi rozsáhlé databáze. Začne být užitečný, když se data do cache nevejdou, protože je třeba udělat volbu, který objekt v paměti ponechat a který uvolnit.