NexusDB

That's a good question for a database engine. While it's essential for good performance to cache data in memory, it's also a bad idea to fill up memory with useless cached data.

Usually database engines use a LRU (least recently used) cache algorithm, which makes sure that recently used data is not discarded from the cache. NexusDB V1 and V2 are using a LRU implementation for caching as well. In most cases this is a good strategy but it has some major shortcomings when it comes to management of very short lived data like e.g. statement scope temporary tables, SQL join results, temporary SQL indexes and similar. A solution for that would be to not cache them at all but this will result in e.g. extremely slow join processing. Another solution would be to hold a second cache using a different algorithm exclusively for these objects, but this creates major complications in transaction handling and essentially wipes out the advantage of the cache. So what to do?

NexusDB V3 is going to have a brand new technology for its cache. We're going to use an "adaptive caching system" variant. At it's base are a LRU and a LFU algorithm which each organizes a certain percentage of the total cache. On top of that is an adaptive system that adjusts the proportions of these two algorithms. This adaptive system is designed to "recognize" situations like table/index iterations (typical for SQL join operations), index builds, restructure and similar and thus avoid lengthy caching of the involved data. While similar in the idea to other adaptive systems it's use as a database buffer manager and the integrated management of Level 1 and Level 2 cache (for NexusDB's AWE technology - I'm going to talk about that in detail soon) means that the resulting concept and implementation differ significantly from other solutions.

The new NexusDB V3 caching implementation takes the best of the LRU and LFU strategies and applies them in a unique implementation to get even more performance out of the available memory.