...

As we aim to have more than one option of storage we need to keep storage api separated from implementation, so we'll have one module containing api and a separate module for each specific implementation.

...

Possible implementations

...

PageMemory code base migration (persistent)

Page Memory

...

from Ignite 2.x is a good candidate as a persistent storage implementation in 3.0

...

although some refactoring and modifications are needed during migration.

Ideas of refactoring are covered in depth in [1], but here is a short list of proposed changes:

1. WAL logging is eliminated as Storage component in general should integrate with new replication component (IEP-61) and reuse its replication log as an analogue of WAL log from 2.x.
   
   
2. Single physical partition file on disk is replaced with a set of files: main "partition" file and several smaller files with incremental modifications to main file. This will allow to simplify checkpointing algorithm and also help to get rid of binary recovery phase.

RocksDB

In-memory storages

For in-memory storages we can consider both heap and off-heap solutions, including porting Page Memory without persistence support.

...

Discussion Links

//NA

Reference Links

...

1.  https://github.com/apache/ignite-3/blob/ignite-14647/modules/vault/README.md