Page History

...

Now let's introduce an integer number that will define an index of Page - idx (4 bytes, unique within a cache, partition and in current local node). In continious memory segment page is located at specific offset:

idx * blockSizepageSize = file offset

Different caches and its partitions bring more complex addressing scheme but it is still possible to map from page ID to position in particular file:

pageId => file + offset in this file

Let's also add partition identifier (2 bytes), and composed indetifier is effectivePageId, see PageIdUtils#effectivePageId

Using this page identifier itIt's possible to link pages together to build dependencies between them. For instance, this is how we can link 2 pages together by keeping child page ID in the root page:

...

If Ignite Persistence is used then after a restart Ignite will load the tree's root node (metadata page) and be able to iterate over the tree layers preloading each new missing page in memory from disk on demand. Also, the tree pages can be merged into one if < less of 50% of space within page is used by payload data.

B+Tree are used for SQL indexes: tree maps field value to reference to entry value.

Segment structure

Ignite also Actually memory region allocated in RAM is not continious sequence of pages. Ignite uses a special component that manages information about pages currently available in memory segment (FullPageIdTable). There is one page ID table per memory segment chunk (UnsafeChunk, DirectMemoryRegion). For unsafe segment chunk sun.misc.Unsafe is used internally, which provides memory for off-heap data storage.

PageIdTable . This table manages mapping from Page ID to relative pointer map (rowAddr) within unsafe segment . This table is chunk.

Page based eviction

If durable memory operates with disk (native peristence is covered in Ignite Persistent Store - under the hood) then PageIdTable table is also used to check if a page is actually available in memory or has to be loaded from disk. As a result, even SQL queries can be fully utilized from Ignite applications when only a subset of pages is in memory because . In this case required pages will be taken from disk during query execution. 

If memory amount memory amount is less than whole index sizewhole size of B+tree for SQL index, Ignite still can operate. When Ignite runs out of memory for the new pages allocation, some of the pages will be purged from RAM back to disk(as it can be found in disc). The eviction of pages is based on the algorithms described below.

...

Let's suppose RAM memory is fully filled with pages, and it is required to allocate new. It is required to evict some page from memory

...